Skip to main content
Resources

Résolutions approuvées | Réunion ordinaire du Conseil d’administration de l’ICANN

Cette page est disponible en:

Ce document a été traduit dans plusieurs langues dans un but purement informatif. Le texte original faisant foi (en anglais) peut être consulté sur : https://www.icann.org/resources/board-material/resolutions-2014-09-09-en

 

  1. Ordre du jour principal
    1. Désignation du président et du président élu du Comité de nomination de 2015
  2. Ordre du jour approuvé:
    1. Approbation du procès-verbal de la réunion du Conseil d'administration
    2. Désignation de Benedict Addis au Comité consultatif sur la sécurité et la stabilité
    3. Le SSAC remercie David Conrad
  3. Ordre du jour principal:
    1. Rapport du Panel d'évaluation technique des services de registre sur la requête du Registre d'intérêt public relative à la mise en œuvre du regroupement technique de .NGO et .ONG.
    2. Planification des futures séries de candidatures aux gTLD
    3. Plan opérationnel et budget de l'exercice fiscal 2015
    4. Version finale du Plan stratégique sur cinq ans de l'ICANN (exercices fiscaux 2016-2020)
    5. Reconnaissance de la Déclaration du deuxième sommet At-Large
    6. Sujets divers

 

  1. Ordre du jour principal

    1. Désignation du président et du président élu du Comité de nomination de 2015

      Attendu que le Comité de gouvernance du Conseil d'administration (BGC) a examiné les manifestations d'intérêt des candidats aux postes de président et de président élu du Comité de nomination (NomCom) de 2014, les conclusions de l'évaluation à 360° des dirigeants du NomCom de 2014, ainsi que les réponses aux questions qu'il a posées à chaque candidat ;

      Attendu que le BGC a recommandé la désignation de Stephane Van Gelder au poste de président du NomCom de 2015 ;

      Il est résolu (2014.09.09.01) que le Conseil d'administration désigne par la présente Stephane Van Gelder au poste de président du NomCom de 2015.

      Fondement de la résolution 2014.09.09.01

      En vertu des Règlements de l'ICANN, le Conseil d'administration est tenu de désigner le président et le président élu du NomCom (article VII, paragraphes 2.1 et 2.2, http://www.icann.org/en/general/bylaws.htm#VII). Le Conseil d'administration a délégué au BGC la responsabilité de faire des recommandations quant aux candidatures pour les postes de président et président élu, qui doivent être soumises à son approbation (voir la charte du BGC sur http://www.icann.org/en/committees/board-governance/charter.htm). Le BGC a publié à deux reprises un appel à manifestations d'intérêt (EOI) (https://www.icann.org/news/announcement-2-2014-07-01-en), étudié les EOI reçus, supervisé une évaluation à 360° des dirigeants du NomCom de 2014, et fait passer des entretiens à certains candidats avant de publier sa recommandation pour le poste de président du NomCom de 2015. Le Conseil d'administration a examiné et approuve cette recommandation et attend celle pour le poste de président élu du NomCom de 2015. Le Conseil d'administration voudrait remercier tous ceux qui ont manifesté leur intérêt à faire partie de la direction du NomCom.

      La désignation du président et du président élu du NomCom, déterminée au travers d'un processus public d'EOI, a un effet positif sur la transparence et la reddition de comptes de l'ICANN, et soutient l'intérêt général. L'adoption de la recommandation du BGC n'a aucun impact financier sur l'ICANN qui n'ait été prévu et n'aura pas d'impact négatif sur la sécurité, la stabilité et la résilience du système des noms de domaine.

  2. Ordre du jour approuvé:

    1. Approbation du procès-verbal de la réunion du Conseil d'administration

      Il est résolu (2014.09.09.02) que le Conseil d'administration approuve le procès-verbal de sa réunion du 30 juillet 2014.

    2. Désignation de Benedict Addis au Comité consultatif sur la sécurité et la stabilité

      Attendu que le Comité consultatif sur la sécurité et la stabilité (SSAC) évalue ses membres et procède de temps à temps à des changements ;

      Attendu que le Comité des membres du SSAC, au nom du SSAC, demande au Conseil d'administration de nommer Benedict Addis au SSAC ;

      Il est résolu (2014.09.09.03) que le Conseil d'administration nomme Benedict Addis au SSAC.

      Fondement de la résolution 2014.09.09.03

      Le SSAC est composé de diverses personnes dont l'expertise sur des sujets spécifiques lui permet de respecter sa charte et de remplir sa mission. Depuis sa création, le SSAC a invité des personnes ayant une grande connaissance et expérience dans des domaines techniques et de sécurité essentiels à la sécurité et à la stabilité du système de noms de domaine et d'adressage d'Internet.

      L'action du SSAC en tant qu'organe compétent dépend de tous les spécialistes talentueux qui ont accepté de consacrer bénévolement un peu de leur temps et de leur énergie à l'accomplissement de la mission du SSAC. Benedict Addis travaille comme agent technique au service chargé de la cyber-délinquance à l'Agence de lutte contre la grande criminalité organisée, organe britannique d'application des lois. Il a beaucoup d'expérience dans les domaines des sciences informatiques et de la sécurité des réseaux, qu'il met à profit dans le cadre de ses fonctions professionnelles. Il travaille activement sur les violations et les activités criminelles sur Internet depuis de nombreuses années. M. Addis offre une perspective précieuse au SSAC en ce qui concerne le lien entre politique gouvernementale et application des lois.

    3. Le SSAC remercie David Conrad

      Attendu que le Conseil d'administration a nommé David Conrad au SSAC le 18 mars 2011 ;

      Attendu que M. Conrad a démissionné du SSAC le 1er août 2014 ;

      Attendu que l'ICANN souhaite saluer et remercier M. Conrad pour ses services rendus à la communauté en sa qualité de membre du SSAC ;

      Il est résolu (2014.09.09.04) que David Conrad mérite la profonde gratitude du Conseil d'administration pour ses services en sa qualité de membre du SSAC, et que le Conseil d'administration lui souhaite une bonne continuation.

      Fondement de la résolution 2014.09.09.04

      Il est d'usage pour le SSAC de chercher à obtenir la reconnaissance par le Conseil d'administration des services rendus par les membres du Comité au moment de leur départ.

  3. Ordre du jour principal:

    1. Rapport du Panel d'évaluation technique des services de registre sur la requête du Registre d'intérêt public relative à la mise en œuvre du regroupement technique de .NGO et .ONG.

      Attendu que le 12 mars 2014, le Registre d'intérêt public (PIR) a soumis une demande [PDF, 24 KB] en vertu de la Politique d'évaluation des services de registre (RSEP), afin de lancer un regroupement technique impératif des noms de domaine de deuxième niveau pour .NGO et .ONG, en vertu de la pièce A des Contrats de registre respectifs ;

      Attendu que le 21 mai 2014, le personnel de l'ICANN a publié et examiné cette demande ;

      Attendu que le 4 juin 2014, le personnel de l'ICANN n'a identifié aucun problème majeur de concurrence dans son examen préliminaire. D'autre part, le personnel de l'ICANN a conclu que le service de registre proposé pourrait engendrer des problèmes majeurs en termes de stabilité ou de sécurité, et a informé [PDF, 320 KB] le PIR de la nécessité de soumettre sa proposition au Panel d'évaluation technique des services de registre (RSTEP) pour nouvelle évaluation ;

      Attendu que le 6 juin 2014, l'ICANN a transmis la demande RSEP du PIR [PDF, 952 KB] au RSTEP pour nouvelle évaluation ;

      Attendu que le 10 juin 2014, l'ICANN a publié la demande RSEP du PIR pour la soumettre à une consultation publique qui a pris fin le 30 juillet 2014, sans qu'aucun commentaire n'ait été reçu ;

      Attendu que le 29 juillet 2014, le rapport du RSTEP a été soumis à une consultation publique. La période de consultation publique qui a pris fin le 13 août 2014, sans qu'aucun commentaire n'ait été reçu ;

      Attendu que le rapport du RSTEP concluait que du point de vue de l'évaluation technique, la proposition n'engendrerait « aucun risque raisonnable menaçant fortement la stabilité ou la sécurité », comme défini dans la RSEP, en ce qui concerne le lancement du service de registre soutenant le regroupement technique impératif des noms de domaine de deuxième niveau pour .NGO et .ONG. Le rapport et les membres du RSTEP ont également identifié plusieurs éventuelles questions techniques et de mise en œuvre liées à ce nouveau service de registre pour le DNS, notamment : les implications du dégroupement de .NGO et .ONG ; la confusion éventuelle des titulaires de noms de domaine et/ou des utilisateurs finaux ; les questions d'équivalence abordées dans le contexte des variantes d'IDN ; et d'autres préoccupations relatives à l'exploitation ;

      Il est résolu (2014.09.09.05) que le Conseil d'administration adopte les conclusions du rapport du RSTEP, selon lesquelles la proposition du PIR n'engendrerait « aucun risque raisonnable menaçant fortement la stabilité ou la sécurité », et qu'il approuve la requête du PIR relative au lancement du service de registre soutenant le regroupement technique impératif des noms de domaine de deuxième niveau pour .NGO et .ONG ;

      Il est résolu (2014.09.09.06) que le Conseil d'administration autorise le président et PDG de l'ICANN, ou son/ses représentant(s), à élaborer une modification du nouveau service de registre qui prenne en compte et règle de façon appropriée les questions techniques et de mise en œuvre qui subsistent en la matière.

      Fondements des résolutions 2014.09.09.05 et 2014.09.09.06

      Pourquoi le Conseil d'administration se penche sur cette question ?

      Le 12 mars 2014, le PIR, l'opérateur de registre pour les TLD .NGO et .ONG, a soumis une requête afin de fournir un nouveau service de registre pour contribuer au regroupement technique impératif des domaines de deuxième niveau pour .NGO et .ONG. Il y donne des explications sur le regroupement technique proposé, la mise en œuvre des commandes EPP, la gestion des DNSSEC, la gestion des variantes d'IDN de deuxième niveau et les services WHOIS. Cette proposition, présentée via le processus de la RSEP, a également été transmise au RSTEP, avant d'être soumise à une consultation publique, de même que le rapport du RSTEP, conformément à la RSEP.

      Selon l'article 2.7 de la RSEP, le Conseil d'administration a 30 jours calendaires à compter de la réception du rapport du RSTEP, le 24 juillet 2014, pour prendre une décision. Le Conseil d'administration peut choisir 1) d'approuver la requête ; 2) de refuser la requête ; ou 3) de ne pas se prononcer en attendant plus d'informations.

      Quelle est la proposition étudiée ?

      Le Conseil d'administration décide aujourd'hui d'agir selon le rapport du RSTEP, qui a évalué les risques en matière de sécurité et de stabilité pouvant découler de la demande RSEP du PIR de lancer un nouveau service de registre permettant un « regroupement technique » impératif des noms de domaine de deuxième niveau. La requête du PIR indique : « Un regroupement technique consiste en deux noms de domaine sous différents TLD, qui affichent les mêmes noms de deuxième niveau partageant les paramètres suivants :

      • propriétaire du bureau d'enregistrement ;
      • dates d'enregistrement et d'expiration ;
      • titulaire, administrateur, facturation et contacts techniques ;
      • association de serveurs de noms ;
      • statut du domaine ;
      • périodes de grâce applicables (supplémentaire, renouvelable, auto-renouvelable, transférable et réactivable) ;
      • et dont les paramètres suivants sont uniques : "enregistrements DS comme demandés basés sur la RFC 5910."

      Quelles parties prenantes ou autres ont été consultées ?

      Le personnel de l'ICANN a lancé un forum de commentaires publics du 10 juin au 8 juillet 2014, et invité la communauté à faire part de ses commentaires sur la proposition RSEP du PIR. Durant cette période, aucun commentaire n'a été reçu. Le rapport final sur la consultation publique est disponible sur : https://www.icann.org/public-comments/tech-bundling-2014-06-10-en.

      De plus, l'équipe de révision du RSTEP a été contactée pour réaliser une évaluation technique du service de registre proposé, en termes de possibles conséquences sur la sécurité et la stabilité, y compris pour savoir si ce nouveau service engendrerait un risque raisonnable menaçant fortement la stabilité ou la sécurité. Le 24 juillet 2014, le rapport du RSTEP [PDF, 1.02 MB] a été rendu public à la communauté ICANN. L'ICANN a lancé un forum de commentaires publics du 29 juillet au 5 août 2014, et invité la communauté à faire part de ses commentaires sur le rapport du RSTEP. Durant cette période, aucun commentaire n'a été reçu. Le rapport final sur la consultation publique est disponible sur : https://www.icann.org/public-comments/rstep-technical-bundling-2014-07-29-en.

      Quelles préoccupations ou questions ont été soulevées par la communauté ?

      Aucun commentaire n'a été soumis pendant les périodes de consultation publique pour la proposition RSEP et pour le rapport du RSTEP. Néanmoins, le rapport du RSTEP et l'ICANN ont noté les questions techniques et de mise en œuvre suivantes, qui devront être réglées par le PIR [et/ou la communauté] dans le cadre de l'élaboration d'une modification des Contrats de registre relatifs à .NGO et .ONG, afin de lancer le nouveau service de registre :

      • Il est nécessaire d'examiner les implications du « dégroupement » si à l'avenir, le PIR (ou un registre ayant pris la relève) décide de supprimer l'association explicite entre .NGO et .ONG ;
      • La proposition du PIR laisse entendre que les contenus des domaines .NGO et .ONG sont « identiques » (ils sont donc regroupés). Cependant, il n'existe aucun mécanisme pouvant faire respecter cette similitude à tous les niveaux du DNS. De même, les candidats comme les serveurs web, les serveurs de messagerie, etc., ne comprendront pas que les domaines .NGO et .ONG doivent être traités de façon identique sans configuration explicite. Cela pourrait provoquer la confusion des utilisateurs finaux (« Pourquoi EXEMPLE.QUELQUECHOSE.ONG fonctionne et pas EXEMPLE.QUELQUECHOSE.NGO ? » et des titulaires de noms de domaine (« Pourquoi dois-je configurer mon serveur web pour inclure chaque domaine de troisième niveau pour chacun de mes domaines de deuxième niveau sous .NGO et .ONG ? »). Il est nécessaire de donner plus d'informations pour empêcher cette possible confusion dans la proposition du PIR ;
      • La similitude des noms – plus précisément, deux noms sont considérés comme étant « identiques », même si les chaînes composant ces noms sont différentes – implicite dans la proposition du PIR et à laquelle le regroupement pourrait être une solution, peut et sera sûrement considérée comme équivalente, en termes de fonctionnement, à un composant des variantes d'IDN. La communauté travaille depuis de nombreuses années à des solutions à la question des variantes, sans y parvenir totalement. Il est possible que les personnes chargées des variantes considéreront l'acceptation du regroupement technique de .NGO et .ONG comme une façon inappropriée de contourner les politiques et les processus établis pour la gestion des variantes ; et
      • Le regroupement technique est envisagé comme une possible solution aux variantes d'IDN. Néanmoins, la communauté n'a pas élaboré de cadre pour son utilisation ni approuvé cette approche de mise en œuvre. Accepter la proposition du PIR et aller de l'avant sans avoir plus d'avis de la communauté sur le regroupement technique pourrait susciter des inquiétudes auprès des candidats aux variantes d'IDN et d'autres membres de la communauté intéressés qui souhaiteraient une discussion à ce sujet pour mettre en œuvre les variantes de TLD IDN.

      Quels documents majeurs le Conseil d'administration a-t-il révisés ? Quels sont les facteurs que le Conseil d'administration a établis comme déterminants ?

      Le Conseil d'administration a étudié plusieurs documents avant de prendre ses décisions aujourd'hui. Il a également examiné plusieurs facteurs essentiels durant ses réunions visant à déterminer s'il était nécessaire d'approuver la requête. Le Conseil d'administration considère les facteurs suivants, entre autres, comme déterminants :

      Y a-t-il des répercussions positives ou négatives sur la communauté ? Y a-t-il des répercussions financières sur l'ICANN (Plan stratégique, Plan opérationnel, budget), sur la communauté et/ou sur le grand public ? Existe-t-il des problèmes de Sécurité, Stabilité et Résilience liés au DNS ?

      Le PIR a conclu que les avantages de la mise en œuvre du regroupement technique impératif serait double : 1) elle éliminerait toute confusion du public, qui pourrait exister si différents opérateurs de gTLD ont la possibilité d'enregistrer le même domaine de deuxième niveau, et 2) elle fournirait au titulaire de nom de domaine un enregistrement permettant de garantir que l'opérateur de gTLD puisse se focaliser sur sa mission et communiquer d'une manière transparente et efficace. Cependant, des informations supplémentaires sont nécessaires pour comprendre les autres conséquences possibles sur la communauté associées aux plus larges implications de ce service lors de son lancement dans le DNS.

      L'éventuel lancement de ce service de registre pourrait avoir des répercussions financières sur l'ICANN, la communauté ou le grand public, les plus larges implications de ce nouveau service pouvant engendrer des coûts supplémentaires.

      Le rapport du RSTEP mentionne l'évaluation technique du service de registre proposé, en termes de possibles conséquences sur la sécurité et la stabilité, et conclut que ce nouveau service n'engendrerait aucun risque raisonnable menaçant fortement la stabilité ou la sécurité.

      Plusieurs communautés, notamment celles intéressées par les variantes d'IDN, travaillent depuis de nombreuses années à des solutions aux questions de similitude de noms – dont le regroupement technique de .NGO et .ONG est un exemple – sans y parvenir totalement. Ces communautés seraient capables de donner des avis quant à la résolution des questions de similitude, et il serait approprié de les consulter. La décision du Conseil d'administration n'a nullement pour but de créer un précédent ou une exigence pour le traitement des questions relatives aux variantes d'IDN, et chaque situation doit être étudiée de manière spécifique.

      S'agit-il d'un processus de politique au sein d'une organisation de soutien de l'ICANN, ou d'une décision de la Fonction administrative organisationnelle de l'ICANN exigeant ou non une consultation publique ?

      La Politique d'évaluation des services de registre est une politique consensuelle de l'ICANN, en vigueur depuis le 15 août 2006. Conformément à cette politique, le 29 juillet 2014, le rapport du RSTEP a été soumis à une consultation publique, qui a pris fin le 13 août 2014, sans qu'aucun commentaire n'ait été reçu. Par ailleurs, le 10 juin 2014, l'ICANN a publié la demande RSEP du PIR pour la soumettre à une consultation publique, qui a pris fin le 30 juillet 2014, sans qu'aucun commentaire n'ait été reçu.

    2. Planification des futures séries de candidatures aux gTLD

      Aucune résolution adoptée.

    3. Plan opérationnel et budget de l'exercice fiscal 2015

      Attendu que la version préliminaire des Plan opérationnel et budget de l'exercice fiscal 2015 a été soumise à une consultation publique le 8 mai 2014, conformément aux Règlements de l'ICANN, et qu'elle est basée sur des consultations menées lors de l'exercice fiscal précédent auprès de la communauté et de l'ensemble du personnel et du Comité des finances du directoire de l'ICANN ;

      Attendu que les activités survenues et les commentaires reçus depuis le forum de commentaires publics ont été pris en compte afin d'apporter des modifications significatives à la version préliminaire des Plan opérationnel et budget de l'exercice fiscal 2015, datée du 8 mai 2014 ;

      Attendu qu'outre le forum de commentaires publics, l'ICANN a activement demandé à la communauté de faire part de ses commentaires et l'a consultée par d'autres moyens, y compris via des conférences téléphoniques en ligne, les réunions à Singapour et Londres, et des échanges de courriels ;

      Attendu que le Comité des finances du directoire de l'ICANN a discuté et informé le personnel de l'élaboration des Plan opérationnel et budget de l'exercice fiscal 2015 à chacune de ses récentes réunions, qui se sont tenues à intervalles réguliers ;

      Attendu que le Comité des finances du directoire de l'ICANN s'est réuni le 19 août 2014 pour discuter de la version finale des Plan opérationnel et budget de l'exercice fiscal 2015, et a recommandé au Conseil d'administration d'adopter ces Plan opérationnel et budget de l'exercice fiscal 2015 ;

      Attendu qu'en vertu de l'article 3.9 des Contrats d'accréditation de bureau d'enregistrement, le Conseil d'administration est tenu d'établir les frais variables d'accréditation des bureaux d'enregistrement afin d'élaborer le budget annuel ;

      Attendu que la description des frais des bureaux d'enregistrement, y compris les frais variables d'accréditation des bureaux d'enregistrement recommandés, correspondant à l'exercice fiscal 2015 a été incluse dans les Plan opérationnel et budget de l'exercice fiscal 2015 ;

      Il est résolu (2014.09.09.07) que le Conseil d'administration adopte les Plan opérationnel et budget de l'exercice fiscal 2015 et, ce faisant, établit les frais variables d'accréditation (par bureau d'enregistrement et par transaction) indiqués dans les Plan opérationnel et budget de l'exercice fiscal 2015 [PDF, 621 KB].

      Fondement de la résolution 2014.09.09.07

      Conformément à l'article XVI, paragraphe 4 des Règlements de l'ICANN, le Conseil d'administration doit adopter un budget annuel et le publier sur le site Web de l'ICANN. Le 8 mai 2014, une version préliminaire des Plan opérationnel et budget de l'exercice fiscal 2015 a été soumise à une consultation publique. Ce texte résulte de nombreuses discussions avec les membres de l'équipe exécutive et de consultations approfondies menées au cours des précédents mois auprès des organisations de soutien et des comités consultatifs de l'ICANN, et d'autres groupes de parties prenantes. Les activités survenues et les commentaires reçus depuis le forum de commentaires publics ont entraîné quelques modifications significatives de la version préliminaire des Plan opérationnel et budget de l'exercice fiscal 2015, datée du 8 mai 2014.

      Tous les commentaires reçus, de quelque façon que ce soit, ont été examinés pour élaborer la version finale des Plan opérationnel et budget de l'exercice fiscal 2015, et appliqués lorsque cela était possible et approprié.

      Outre les besoins opérationnels quotidiens, les Plan opérationnel et budget de l'exercice fiscal 2015 comprennent les points du budget des nouveaux gTLD de 2015, ainsi que les montants affectés aux diverses demandes de budget de 2015 formulées par les responsables de la communauté. Le budget annuel fait également état des répercussions du programme des nouveaux gTLD. Par ailleurs, étant donné que les frais variables d'accréditation des bureaux d'enregistrement sont la clé de l'élaboration du budget, les Plan opérationnel et budget de l'exercice fiscal 2015 déterminent ces frais, qui sont cohérents avec ceux des dernières années et seront soumis à l'approbation des bureaux d'enregistrement.

      Les Plan opérationnel et budget de l'exercice fiscal 2015 auront des effets positifs dans la mesure où ils fournissent un cadre approprié de gestion et de fonctionnement de l'ICANN. Ils permettent également à l'organisation de pouvoir rendre des comptes en toute transparence. Les répercussions financières sur l'ICANN et la communauté sont celles prévues. Les Plan opérationnel et budget de l'exercice fiscal 2015 n'auront que des effets positifs sur la sécurité, la stabilité et la résilience du système des noms de domaine (DNS), en ce qui concerne les financements de ces aspects du DNS.

    4. Version finale du Plan stratégique sur cinq ans de l'ICANN (exercices fiscaux 2016-2020)

      Point supprimé de l'ordre du jour.

    5. Reconnaissance de la Déclaration du deuxième sommet At-Large

      Attendu que le deuxième sommet At-Large (ATLAS II) s'est tenu lors de la 50e réunion de l'ICANN à Londres, Royaume-Uni, en juin 2014 ;

      Attendu qu'ATLAS II s'inscrit dans la lignée du premier sommet, organisé en mars 2009 lors de la 34e réunion de l'ICANN à Mexico ;

      Attendu que le Conseil d'administration a reçu la Déclaration finale d'ATLAS II (https://community.icann.org/download/attachments/48338039/ATLAS-II-Declaration-with-appendix-RC9.pdf?version=1&modificationDate=1407420726000&api=v2) [PDF, 204 KB];

      Attendu que la communauté At-Large continue de manifester l'esprit d'engagement et d'enthousiasme du sommet au travers d'activités de mise en œuvre post-ATLAS II ;

      Il est résolu (2014.09.09.08) que le Conseil d'administration reconnaisse la Déclaration finale d'ATLAS II et exprime ses félicitations pour ce sommet fructueux organisé lors de la 50e réunion de l'ICANN à Londres ;

      Il est résolu (2014.09.09.09) que le Conseil d'administration souligne que le sommet ATLAS II et ses retombées constituent une contribution précieuse de la communauté d'internautes At-Large au renforcement de l'ICANN ;

      Il est résolu (2014.09.09.10) que le Conseil d'administration exprime sa gratitude pour les efforts considérables fournis par la communauté At-Large au cours du sommet At-Large, de l'élaboration de la Déclaration finale d'ATLAS II et des activités de mises en œuvre post-ATLAS II ;

      Il est résolu (2014.09.09.11) que le Conseil d'administration s'attende à étudier avec l'ALAC les contributions découlant de la Déclaration finale d'ATLAS II qui lui seront adressées.

      Remarque : Trois membres du Conseil d'administration ayant droit de vote se sont abstenus de voter sur les résolutions. Ils ont déclaré, à titre d'information, soutenir le travail résultant d'ATLAS mais souhaiter souligner le fait qu'ils encouragent le Conseil d'administration à envisager à l'avenir de transformer ATLAS en un événement récurrent.

      Fondements des résolutions 2014.09.09.08 à 2014.09.09.11

      Le deuxième sommet At-Large (ATLAS II), rendu possible par l'allocation par le Conseil d'administration d'un budget spécial pour l'occasion, s'est terminé par la rédaction de la Déclaration d'ATLAS II. Olivier Crépin-Leblond a transmis cette déclaration à Steve Crocker le 7 août 2014.

      Ce document est le fruit du travail d'environ 150 structures At-Large installées dans 70 pays, qui se sont réunies en juin 2014 à Londres.

      Cette déclaration inclut les efforts des cinq groupes de travail thématiques d'ATLAS II :

      • Groupe thématique 1 (TG1) : L'avenir des modèles multipartites
      • Groupe thématique 2 (TG2) : La mondialisation de l'ICANN
      • Groupe thématique 3 (TG3) : L'Internet mondial : la perspective de l'utilisateur
      • Groupe thématique 4 (TG4) : La transparence et la reddition de comptes de l'ICANN
      • Groupe thématique 5 (TG5) : La participation de la communauté At-Large à l'ICANN

      Elle contient 43 recommandations adressées au Conseil d'administration et à l'ALAC, référencées de R-1 à R-43. Elle comprend également 10 observations à l'attention de la plus large communauté internet, référencées de O-1 à O-10.

      La communauté At-Large s'attelle actuellement à l'application de ces recommandations et observations au travers d'une équipe de travail spéciale.

      L'ALAC souhaite obtenir les commentaires de la plus large communauté internet sur la déclaration.

      Il s'agit d'une Fonction administrative organisationnelle qui ne nécessite aucune consultation publique.

    6. Sujets divers

      Aucune résolution adoptée.

resolutions-09sep14-fr.pdf  [260 KB]

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."