Skip to main content
Resources

Procès-verbaux | Réunion ordinaire du Conseil d’administration de l’ICANN

Cette page est disponible en:

Une réunion ordinaire du Conseil d'administration de l'ICANN a eu lieu le 9 septembre 2014 à Istanbul, Turquie à 16:15 heure locale.

Steve Crocker, président, a rapidement rappelé la séance à l'ordre.

Les administrateurs suivants ont participé à toute ou à une partie de la réunion : Sébastien Bachollet, Cherine Chalaby, Fadi Chehadé (Président–directeur général), Chris Disspain, Bill Graham, Wolfgang Kleinwächter, Bruce Tonkin (vice–président), Mike Silber, Gonzalo Navarro, George Sadowsky, Olga Madruga–Forti, Bruno Lanvin, Erika Mann, et Kuo–Wei Wu.

Les administrateurs suivants se sont excusés : Ray Plzak.

Les agents de liaison suivants du Conseil d'administration ont participé à toute ou à une partie de la réunion : Heather Dryden (agent du liaison du GAC), Ram Mohan (agent de liaison du SSAC), Jonne Soininen (agent de liaison de l'IETF) et Suzanne Woolf (agent de liaison du RSSAC).

Secrétaire : John Jeffrey (conseiller juridique et secrétaire)

Participants conviés : Rinalia Abdul Rahim, Markus Kummer et Asha Hemrajani

Les cadres et membres du personnel de l'ICANN suivants ont participé à toute ou à une partie de la réunion : Akram Atallah (Président de la division des domaines mondiaux) ; Susanna Bennett (chef de l'exploitation) ; Megan Bishop (coordinatrice du soutien au Conseil d'administration) ; David Olive (vice–président, élaboration de politiques) ; Xavier Calvez (Directeur financier) ; Samantha Eisner (conseillère principale) ; Vinciane Koenigsfeld (responsable du contenu, soutien au Conseil d'administration) ; Erika Randall (conseillère) ; Ashwin Rangan (Directeur de l'innovation et de l'information) ; Amy Stathos (conseillère juridique adjointe) ; et Theresa Swinehart (conseillère principale du Président en matière de stratégie mondiale).

  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 du Conseil d'administration
    2. Désignation de Benedict Addis au Comité consultatif sur la sécurité et la stabilité
    3. Le Comité consultatif sur la sécurité et la stabilité remercie David Conrad
  3. Ordre du jour principal:
    1. Rapport du Panel d'évaluation technique des services de registre (RSTEP) sur la demande présentée par le Registre d'intérêt public afin de mettre en place un regroupement technique pour .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. Divers

 

  1. Ordre du jour principal :

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

      Cherine Chalaby a ensuite proposé et Chris Disspain a appuyé la résolution suivante.

      Bruce Tonkin a présenté le point de l'ordre du jour et a noté que le Comité de gouvernance du Conseil recommande au Conseil d'administration de nommer Stéphane Van Gelder au poste de président du NomCom de 2015. Le BGC (Board Governance Committee, Comité de gouvernance du Conseil) formulera une recommandation concernant le président élu du NomCom ultérieurement.

      Le Président a demandé de passer au vote et le Conseil d'administration a pris la décision suivante:

      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 Stéphane 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 Stéphane Van Gelder au poste de président du NomCom de 2015.

      Treize membres du Conseil d'administration ont voté en faveur de la résolution 2014.09.09.01. Fadi Chehadé, Sébastien Bachollet, et Ray Plzak n'étaient pas disponibles pour voter la résolution. La résolution a été adoptée.

      Fondements de la résolution 2014.09.09.01

      Le règlement de l'ICANN exige que le Conseil nomme le président du comité de nomination (NomCom) et le président élu du NomCom. Voir Article VII, sections 2.1 et 2.2 sur http://www.icann.org/en/general/bylaws.htm#VII. Le Conseil a délégué la responsabilité de recommander des candidats au poste de président et de président élu du NomCom pour leur approbation par le Conseil au comité de gouvernance du Conseil. 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) (voir (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 du BGC 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é:

    Le président a donné un bref aperçu des points de l'ordre du jour approuvé. Par la suite, le Président a demandé de passer au vote et le Conseil d'administration a pris la décision suivante:

    Résolu, les résolutions ci–dessous correspondant au présent ordre du jour sont approuvées:

    1. Approbation du procès–verbal 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.

      Fondements de la résolution 2014.09.09.03

      Le SSAC est un groupe diversifié de personnes dont l'expertise dans des sujets spécifiques permet de satisfaire aux objectifs de sa charte et d'exécuter 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 Comité consultatif sur la sécurité et la stabilité 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.

      Fondements de la résolution 2014.09.09.04

      La reconnaissance exprimée par le Conseil d'administration au SSAC pour les services rendus par les membres du comité lors de leur départ s'inscrit dans les pratiques habituelles.

    4. Tous les membres du Conseil d'administration présents ont voté en faveur des résolutions 2014.09.09.02, 2014.09.09.03 et 2014.09.09.04. Fadi Chehadé, Sébastien Bachollet et Ray Plzak n'étaient pas disponibles pour voter les résolutions. Les résolutions ont été adoptées.

  3. Ordre du jour principal:

    1. Rapport du Panel d'évaluation technique des services de registre (RSTEP) sur la demande présentée par le Registre d'intérêt public afin de mettre en place un regroupement technique pour .NGO et .ONG

      Avant de passer à une analyse plus poussée de la question, Ram Mohan a constaté qu'il avait un conflit d'intérêt à ce sujet du fait de son emploi. Ram a été invité à prendre part à la discussion étant données ses connaissances dans ce domaine.

      George Sadowsky a ensuite proposé et Bruce Tonkin a appuyé la résolution proposée.

      Le président a présenté le point de l'ordre du jour et a fourni des informations générales concernant la Politique d'évaluation des services de registre (RSEP) et le Panel d'évaluation technique des services de registre (RSTEP). Le président a expliqué qu'il s'agissait d'une procédure à deux niveaux. Le RSEP s'occupe des modifications contractuelles et est traité par le personnel. Si le contrat demandé inclut un changement technique qui pourrait avoir des incidences sur la sécurité, il y a une évaluation RSTEP secondaire qui implique une commission d'experts. Dès que le rapport est soumis par le RSTEP, le Conseil d'administration a 30 jours pour rendre une décision. Le président a indiqué qu'il y avait des questions pour savoir si les règles des RSEP/RSTEP étaient appropriées ou si ces règles devaient être ajustées, mais que ce n'était pas le sujet de la discussion à ce stade.

      Le président a donné un bref aperçu de la demande du rapport du RSTEP concernant le Registre d'intérêt public (PIR) concernant regroupement technique impératif des domaines de deuxième niveau pour .NGO et .ONG (les formulations anglophone et francophone des domaines de premier niveau (TLD)). Il a indiqué que, selon le rapport, il n'y a pas de questions en matière de sécurité et de stabilité mais qu'il n'y a pas non plus de garantie que la synchronie soit maintenue indéfiniment, et que le rapport recommande que certains détails soient réglés pendant le processus d'attribution de contrat.

      Rinalia Abdul Rahim a voulu savoir si une décision du Conseil d'administration permettant au Registre d'intérêt public (PIR) de demander un regroupement technique impératif des domaines de deuxième niveau pour .NGO et .ONG allait affecter le maintien des noms de domaine internationalisés (IDN). Ram Mohan a expliqué qu'il existait des précédents de regroupement des domaines de premier niveau géographique (ccTLD). Dans les cas de la Chine, de Hong Kong et de Taïwan, par exemple, plusieurs domaines de premier niveau (TLD) ont été affectés et sont dirigés de manière regroupée par politique plutôt que par manœuvres techniques. Ram a également expliqué que, dans le cas précis du Registre d'intérêt public (PIR), les domaines de premier niveau (TLD) .NGO et .ONG ne se ressemblent ni visuellement ni par le sens, à moins que vous compreniez que l'un est francophone et que l'autre est anglophone. Aussi, si vous appliquez les règles qui ont été créés jusqu'à présent pour les variantes des noms de domaine internationalisés (IDN), les TLD du PIR sont toujours admissibles puisqu'ils sont tous les deux des noms ASCII qui ont déjà été acceptés dans le répertoire du script minimum pour un TLD. Ram a également noté que souvent, dans les différents schémas de noms de domaine internationalisés (IDN), les mots qui ont une ont une variante sont un problème, alors qu'ici, les domaines de premier niveau (TLD) sont deux abréviations différentes. Suzanne Woolf a fait la remarque qu'elle était d'accord avec l'explication des faits de Ram, mais qu'elle continue de penser que le Conseil d'administration doit s'attendre à ce que la décision de permettre la demande de regroupement du Registre d'intérêt public (PIR) soit vue comme un précédent de forcing concernant les regroupements et les variantes des noms de domaine internationalisés (IDN). Mike Silber a fait la remarque qu'il était d'accord avec Suzanne et a suggéré que les raisons rendent clair ce qui n'est pas voulu pour créer un précédent et que chaque situation doit être étudiée de manière spécifique.

      Le Président a demandé de passer au vote et le Conseil d'administration a pris la décision suivante:

      Attendu que le 12 mars 2014, le Registre d'intérêt public (PIR) a soumis une request [PDF, 25 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 registres 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, 317 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, 949 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 public comment. 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 public comment. 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.

      Quatorze membres du Conseil d'administration ont voté en faveur des résolutions 2014.09.09.05 et 2014.09.09.06. Fadi Chehadé et Ray Plzak n'étaient pas disponibles pour voter les résolutions. Les résolutions ont été adoptées.

      Fondements des Résolutions 2014.09.09.05 et 2014.09.09.06

      Pourquoi le Conseil d'administration aborde–t–il 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 à l'étude?

      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 au moins un des paramètres suivantes est unique : « enregistrements DS comme demandé basés sur la RFC 5910. » »

      Quelles parties intéressées 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 sont les préoccupations ou les questions 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 sont les documents importants examinés par le Conseil d'administration ? Quels sont les facteurs que le Conseil d'administration a jugés significatifs ?

      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. Les supports et facteurs significatifs que le Conseil d'administration a examinés dans le cadre de ses délibérations comprenaient, sans s'y limiter, ce qui suit:

      Cela a–t–il des effets positifs ou négatifs pour la communauté ? Y a–t–il un impact fiscal ou des répercussions à prévoir sur l'ICANN (plan stratégique, plan opérationnel, budget), sur la communauté et/ou sur le public ? Y a–t–il des implications sur la sécurité, la stabilité ou la résilience du 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 développement de politiques défini au sein des organisations de soutien de l'ICANN ou bien d'une fonction organisationnelle administrative de l'ICANN nécessitant une consultation publique ou ne nécessitant pas de commentaires du public ?

    2. 4. La politique d'évaluation des services de registre constitue une politique de consensus 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.

    3. Planning for Future gTLD Application Rounds

      Le président a présenté les questions à traiter, en introduisant une discussion au sujet de comment et si le Conseil d'administration devait commencer à étudier les processus organisationnels qui conduisent à une nouvelle série de candidatures pour le programme des nouveaux gTLD. Akram Atallah a fait remarquer qu'il voulait s'assurer qu'aucune résolution à ce sujet ne soit illimitée mais plutôt qu'elle encadre le travail spécifique qui doit se dérouler avant qu'une autre série de candidatures ne soit initiée. Rinalia Abdul Rahim a approuvé le commentaire d'Akram, et le fait que chaque résolution devait être exacte.

      Heather Dryden a fait remarquer qu'une résolution devait clairement mettre en œuvre les étapes suivantes avant d'initier une autre série de candidatures.

      Mike Silber a fait part de ses préoccupations relatives au fait qu'une résolution pouvait être susceptible d'être circulaire en ce qui concerne le travail qui doit être effectué avant de lancer une autre série de candidatures aux gTLD alors qu'aucune date n'avait alors été arrêtée et ne pouvait pas être arrêtée avant que le travail nécessaire n'ait été effectué.

      Sébastien Bachollet a exprimé son inquiétude concernant l'utilisation de la nomenclature « première » et « seconde » pour décrire les candidatures aux gTLD, en faisant remarque que ça ne correspondait pas à la réalité de l'ICANN. Steve Crocker a fait remarquer qu'il pourrait être déroutant de réécrire les documents qui incluent déjà cette nomenclature. Bruce Tonkin était d'accord avec Sébastien, a noté qu'il y avait eu plusieurs séries de candidatures gTLD au cours des quatorze précédentes années, et a suggéré qu'on fasse référence aux séries par année (par exemple, série 2000, série 2004, et série 2012).

      Ram Mohan a constaté que si le Conseil d'administration voulait prendre une résolution, cela pouvait être interprété comme l'autorisation d'une nouvelle série de candidatures par ce dernier, et il a exprimé ses inquiétudes concernant les réactions potentielles de la communauté et la possibilité d'avoir l'impression que le Conseil d'administration prenait une décision à la va–vite. Ram a indiqué qu'une résolution devait transmettre le poids du travail que le Conseil d'administration prévoyait de faire et la profondeur de l'analyse qui se tiendrait avant le lancement d'une nouvelle série de candidatures gTLD.

      Wolfgang Kleinwächter a noté les inquiétudes soulevées par Ram. Wolfgang a ensuite demandé s'il y avait une date d'achèvement envisagée pour l'accomplissement du travail pré requis et le lancement de la nouvelle série de candidatures. Akram a répondu que cela dépendait du timing et de quel travail le Conseil d'administration décidait qu'il fallait accomplir avant de lancer la nouvelle série.

      Chris Disspain a soutenu les inquiétudes de Ram et a proposé que le Conseil d'administration retire pour le moment ce point de l'étude, travaille à la formulation de la résolution puis en parle à la 51e réunion de l'ICANN à Los Angeles. Akram a également fait remarquer que la communauté avait de nombreuses questions concernant le timing et la procédure de révision de la procédure.

      Le Conseil d'administration a admis qu'un examen complémentaire était nécessaire et que la discussion concernant ce point était remise à la 51e réunion de l'ICANN à Los Angeles.

      Aucune résolution n'a été adoptée.

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

      George Sadowsky a proposé et Mike Silber a appuyé la résolution proposée:

      Cherine Chalaby a présenté le point de l'ordre du jour et a donné un bref aperçu des Plan opérationnel et budget de l'exercice fiscal 2015. La version préliminaire des Plan opérationnel et budget de l'exercice fiscal 2015 qui a été soumise à une consultation publique le 8 mai 2014 prévoyait un revenu de 114 millions d'USD et des frais de fonctionnement de 117 millions d'USD. Il y a eu de nombreuses remarques concernant le revenu proposé et les frais de fonctionnement. À la fin de la période des commentaires du public, le comité des finances du Conseil d'administration (BFC) a pris en considération tous les commentaires, a regardé les différentes hypothèses de revenu et l'analyse de sensibilité, et a ensuite modifié le budget. Le plan opérationnel et le budget prévisionnel révisés pour l'exercice fiscal 2015 prévoient maintenant un revenu de 104 millions d'USD et des frais de fonctionnement de 108 millions d'USD. Cherine a indiqué que pour atteindre ces chiffres réduits, le comité des finances du Conseil d'administration (BFC) reverrait toutes les hypothèses de revenu une par une ; et que le Président–directeur général et l'équipe de direction reverraient les frais de fonctionnement en détail et qu'il y aurait des réductions de recrutement de personnel, de frais de déplacement, de services professionnels, de coûts administratifs et de dépenses en capital. Cherine a également indiqué que, dans un effort de réduction des coûts, il n'y aurait pas de gala à la 51ème réunion de l'ICANN à Los Angeles puisqu'il n'y avait pas d'hôte local pour l'événement.

      Erika Mann a demandé quel type de réduction de recrutement du personnel étaient proposées. Susanna Bennett a répondu et expliqué qu'il n'y aurait pas de nouvelles embauches au cours de l'année civile 2014, que toutes les nouvelles embauches seraient repoussées à l'année 2015. Susanna a également expliqué qu'en cas de besoin, il existait un processus d'exception qui pouvait être mise à exécution conformément à certaines directives. Cherine a remarqué que cela permettrait une réduction des coûts pour l'exercice fiscal 2015 car les frais de personnel sont échelonnés sur plusieurs années.

      Jonne Soininen a demandé quelles réductions de frais de déplacement étaient proposées. Susanna a répondu et expliqué qu'il serait demandé à chaque membre de l'équipe des dirigeants mondiaux de réduire ses frais de déplacement de 10 % et qu'il appartenait à chaque département de décider comment procéder à la réduction.

      Jonne a également demandé quelles réductions de services professionnels étaient proposées. Akram a répondu et expliqué que, par exemple, son équipe avait passé en revue sa liste des tâches, déterminé ce qui pouvait être fait en interne plutôt qu'en externe, et a identifié que certains éléments pouvaient être supprimés ou remis à plus tard. Ashwin Rangan a également répondu et indiqué que le département des IT faisait partie de ce processus d'exploitation des ressources comme moyen de réduire les coûts sans aucun impact négatif sur la qualité du service. Chris Disspain a noté qu'il avait demandé à ce que l'utilisation des services professionnels soit reprise par le comité des finances (BFC), concernant les dépenses de l'ICANN.

      Gonzalo Navarro a soulevé la question suivante, à savoir pourquoi le Conseil d'administration se concentrait sur la réduction des coûts et non pas sur la réallocation des économies. Xavier Calvez et Gonzalo se sont engagés à avoir une discussion ultérieure à ce sujet.

      Cherine a ensuite lu la résolution proposée au Conseil d'administration.

      Le Président a demandé de passer au vote et le Conseil d'administration a pris la décision suivante:

      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.

      Quatorze membres du Conseil ont voté en faveur de la résolution 2014.09.09.07. Ray Plzak et Bruce Tonkin n'étaient pas disponibles pour voter cette résolution. La résolution a été adoptée.

      Fondements de la résolution 2014.09.09.07

      Conformément à l'article XVI, alinéa 4 des statuts de l'ICANN, le Conseil adopte un budget annuel et le publie 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. Un impact fiscal est à prévoir sur l'ICANN et sur la communauté. Rien que des effets positifs sont à prévoir sur la sécurité, la stabilité et la résilience du système des noms de domaine (DNS), liés aux financements consacrés à ces aspects du DNS.

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

      Point retiré de l'agenda.

    6. Reconnaissance de la Déclaration du deuxième sommet At–Large

      Sébastien Bachollet a présenté le point de l'ordre du jour et a donné un bref aperçu du deuxième sommet At–Large (ATLAS II) qui s'est tenu à Londres en juin 2014, de la présentation de la déclaration finale ATLAS II au Conseil d'administration et les modifications de la résolution proposées qui reflètent ces efforts. Le Conseil d'administration a envisagé d'éventuelles modifications du texte de la résolution. Mike Silber a fait remarquer qu'il n'était pas à l'aise avec le fait d'ébaucher les résolutions pendant les réunions, mais qu'il désirait continuer la discussion pour déterminer si le Conseil d'administration pouvait arriver à un consensus sur la résolution. Mike a également noté que, puisque l'ALAC devait désormais indiquer quelle section de la déclaration de l'ATLAS II constituait un avis, il était prématuré pour le Conseil d'administration de discuter du suivi de l'avis sur l'ALAC alors qu'il n'avait pas encore été soumis. Steve Crocker a acquiescé et a noté que la résolution devait refléter le fait que le Conseil d'administration était impatient de rencontrer l'ALAC pour discuter la déclaration.

      Wolfgang Kleinwächter a exprimé l'avis que l'ensemble de l'ICANN avait besoin d'un mouvement At–Large fort et du comité consultatif At–Large. Tout en veillant à cela, Wolfgang a recommandé au Conseil d'administration de continuer sa collaboration avec l'ALAC et d'avancer dans ce processus jusqu'au prochain niveau, bien que les prochaines étapes ne soient pas claires pour le moment. Par exemple, les prochaines étapes pourraient inclure un autre sommet ou des sommets régionaux intégrés aux réunions publiques de l'ICANN. Le sommet de la 50ème réunion de l'ICANN ne doit pas être la fin de l'histoire. Wolfgang a demandé s'il y aurait l'occasion de faire des commentaires publics sur la déclaration.

      Sébastien a fait remarquer que le Conseil d'administration devait faire plus que simplement remercier l'ALAC pour son travail ; mais plutôt indiquer qu'il assurerait le suivi de l'ALAC concernant l'avis sur la déclaration et soumettrait à la discussion les projets pour les sommets qui pourraient se tenir régulièrement. Le président a souligné l'importance de recevoir les conseils concrets de l'ALAC en tant que structure pour l'engagement entre le Conseil d'administration et l'ALAC.

      Chris Disspain a souligné que, comme il le comprenait, l'ALAC prendrait désormais la déclaration ATLAS II et déterminerait quel avis ou autre communication soumettre au Conseil d'administration. Chris a en outre souligné qu'il n'était pas, en principe, contre l'idée de faire du sommet un événement régulier, mais a demandé s'il était approprié de la mentionner maintenant puisqu'il n'y avait pas encore eu de discussion sur le sujet.

      Rinalia a suggéré que le Conseil d'administration devrait indiquer qu'il attendait avec impatience de collaborer avec l'ALAC ou la communauté des utilisateurs d'Internet à Los Angeles concernant les conseils donnés. Chris a précisé que le mot « conseil » a une signification particulière selon les statuts, et que le Conseil d'administration ne reçoit pas de conseils de la communauté des utilisateurs d'Internet ; qu'il reçoit plutôt des conseils de l'ALAC.

      Olga Madruga Forti a soutenu le message de Rinalia.

      Chris a souligné qu'il y avait un désaccord au sein du Conseil d'administration concernant le fait d'étudier l'éventuel projet de faire du sommet At–Large un événement régulier. Mike a fait remarquer que la déclaration de l'ATLAS II ne se référait pas au maintien du sommet et a demandé pourquoi le terme se trouvait dans la résolution. Bill a remarqué que le Conseil d'administration n'avait pas encore discuté s'il voulait ou non étudier les projets possibles pour rendre des sommets At–Large des événements réguliers, et a recommandé d'ajourner la discussion de la résolution jusqu'à la réunion du Conseil d'administration de Los Angeles, à ce moment–là, le Conseil d'administration pourrait débattre et approuver la résolution sous une forme ou une autre.

      Le président a expliqué que cette résolution est destinée à être un remerciement pour le travail fourni par l'ALAC et a admis que le terme suggérant que le sommet puisse devenir un événement régulier allait trop loin, et qu'il était possible de continuer la discussion à ce sujet même s'il ne figurait pas dans la résolution. Il est important de se concentrer sur le sentiment de reconnaissance que le Conseil d'administration essaie de transmettre.

      Steve Crocker a proposé et George Sadowsky a appuyé la résolution proposée.

      Le Président a demandé de passer au vote et le Conseil d'administration a pris la décision suivante:

      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, 201 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.

      Onze membres du Conseil d'administration ont voté en faveur des résolutions 2014.09.09.08, 2014.09.09.09, 2014.09.09.10 et 2014.09.09.11. Fadi Chehadé, Wolfgang Kleinwächter et Sébastien Bachollet se sont abstenus. Ray Plzak et Bruce Tonkin n'étaient pas disponibles pour voter ces résolutions. Les résolutions ont été adoptées.

      Sébastien a fait remarquer que cette abstention était basée sur le fait qu'il préférait que la résolution inclue le terme faisant référence à « l'étude de l'éventuel projet de rendre le sommet At–Large un événement régulier ». L'abstention de Wolfgang était basée sur son opinion selon laquelle rendre le sommet un événement régulier était dans l'esprit de la déclaration de l'ATLAS II et qu'il fallait y faire référence dans la résolution. Fadi s'est également abstenu pour les raisons invoquées par Wolfgang.

      Fondements des Résolutions 2014.09.09.08 et 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 (GT1) : Futur des modèles multipartites
      • Groupe thématique 2 (GT2) : La mondialisation de l'ICANN
      • Groupe thématique 3 (GT3) : L'Internet mondial : le point de vue de l'utilisateur
      • Groupe thématique 4 (GT4) : La transparence et la responsabilité de l'ICANN
      • Groupe thématique 5 (GT5) : 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 et organisationnelle pour laquelle des commentaires publics ne sont pas requis.

    7. Divers

      Ram Mohan a soulevé le problème de la modification des procédures des RSEP (panels d'évaluation des services de registre) et des RSTEP (panel d'évaluation technique des services de registre). À titre de référence, Ram a expliqué que différents problèmes peuvent déclencher un RSEP, y compris un changement de mot par un titulaire, et si une analyse plus approfondie s'imposait, il y aurait une demande de mouvement vers un RSTEP, ce qui exigerait alors l'approbation du Conseil d'administration dans le délai défini de 30 jours. Ram a fait remarquer que cette procédure était gérable lorsque chaque nouvelle série de candidature gTLD impliquait moins de dix TLD ; toutefois, la série 2012 de 1300 nouveaux TLD rendrait les procédures RSEP/RSTEP ingérables sous les directives de procédures actuelles. Sur cette base, Ram a demandé à ce que le Conseil d'administration demande au personnel de revoir et d'analyser la procédure RSEP/RSTEP, y compris l'implication du Conseil d'administration dans cette procédure, et d'élaborer des recommandations sur comment simplifier la procédure. Pour clarifier, Ram a expliqué qu'il travaillait pour un registre, qui a réalisé plusieurs RSEP et RSTEP avec l'ICANN, qu'il était donc familier des détails de cette procédure. En outre, Ram faisait également partie de la GNSO lorsque la procédure RSEP/RSTEP a été développée et adoptée comme une exigence politique de consensus.

      Le président a fait remarquer qu'à l'époque du développement de la procédure RSEP/RSTEP, une grande attention quant au respect de tout ce qui était lié à la sécurité et la stabilité était de mise et, dans un souci de prudence, le Conseil d'administration était chargé de veiller à l'exécution des changements requis. Le président était d'accord avec Ram et a suggéré que le personnel fournisse une procédure recommandée qui inclue une profondeur technique suffisante et s'assure de l'indépendance, de sorte que chaque requête devienne également une enquête très fouillée qui pourrait être applicable en ce qui concerne les problèmes de sécurité et de stabilité.

      Jonne Soininen a soulevé le problème du rôle que le GNSO devrait avoir dans la modification de la procédure RSEP/RSTEP. Le conseiller juridique et secrétaire a expliqué que la procédure a initialement été développée parce qu'il était difficile pour les registres d'ajouter de nouveaux services de registre, ce qui créait des conflits entre registres, GNSO, Conseil d'administration et personnel. La procédure actuelle a été très utile à ce jour, mais le conseiller juridique a approuvé qu'avec plus d'un millier de nouveaux gTLDS, il va être difficile de gérer les changements demandés de la même manière. Il a fait remarquer que les changements de cette procédure devaient être effectués avec prudence et en prenant en considération le fonctionnement de la procédure et si la GNSO devait fournir un travail supplémentaire avant la mise en œuvre de tout changement.

      Akram Atallah a indiqué que le personnel préparerait les recommandations concernant la procédure RSEP/RSTEP pour la revoir lors de la 51ème réunion de l'ICANN à Los Angeles.

      Aucune résolution n'a été adoptée.

Publié le 17 octobre 2014

minutes-09sep14-fr.pdf  [133 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."