Skip to main content
Resources

Procès - verbal | Réunion ordinaire du comit é du programme des nouveaux gTLD

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 : http://www.icann.org/en/groups/board/documents/minutes-new-gtld-07oct13-en.htm

 

Remarque : le 10 avril 2012, le Conseil d'administration a créé le comité du programme des nouveaux gTLD, intégré par tous les membres du Conseil ayant droit de vote et n'ayant pas de conflit d'intérêts par rapport au programme des nouveaux gTLD. Le comité s'est vu accorder tous les pouvoirs du Conseil d'administration (soumis aux limitationsétablies par la loi, les statuts constitutifs et les règlementations ou par les politiques de l'ICANN en matière de conflits d'intérêt) pour exercer son autorité sur toute question relative au programme des nouveaux gTLD. Le champ d'application de l'autorité du comité estétabli dans sa charte http://www.icann.org/en/groups/board/new-gTLD.

Une réunion extraordinaire du Comité du programme des nouveaux gTLD du Conseil d'administration de l'ICANN a eu lieu par voie téléphonique le 7 octobre 2013à 13h00 UTC.

Le président du Comité, Cherine Chalaby, a rapidement ouvert la séance.

Outre le président, les administrateurs suivants ont participéà toute ouà une partie de la réunion : Fadi Chehadé (Président-directeur général de l'ICANN), Chris Disspain, Bill Graham, Olga Madruga-Forti, Erika Mann, Gonzalo Navarro, Ray Plzak, George Sadowsky, Mike Silber, et Kuo-Wei Wu. 

Jonne Soininen (agent de liaison de l'IETF) a participé au Comité en sa qualité de liaison sans droit de vote. Heather Dryden a participé en sa qualité d'observatrice du comité. Francisco da Silva (liaison TLG), s'est excusé.

Les membres du personnel ci-dessous ont participéà toute ouà une partie de la réunion : Akram Atallah, président, division des noms génériques; John Jeffrey, conseiller juridique et secrétaire ; Megan Bishop ; Samantha Eisner ; Dan Halloran ; Jamie Hedlund ; Cyrus Namazi ; Karine Perset ; Erika Randall ; Amy Stathos ; et Christine Willett. 

Paul Mockapetris y a participé en qualité d'observateur invité. Ram Mohan aété présent en tant qu'observateur invité pour le point 1 de l'ordre du jour principal.

Voici le procès verbal de la réunion du comité du programme des nouveaux gTLD ayant eu lieu le 7 octobre 2013.

  1. Ordre du jour principal
    1. Gestion de l'occurrence de collision de noms dans les nouveaux gTLD

 

  1. Ordre du jour principal :

    1. Gestion de l'occurrence de collision de noms dans les nouveaux gTLD

      À la demande du président, Paul Mockapetris a contribué avec le comité sur la question relative à la collision de noms. Paul a offert une perspective historique sur l'utilisation des noms de domaine non-complètement qualifiés, citant les problèmes passés de collision avec des adresses électroniques et les introductions de certains codes de pays. Paul a noté que l'ambiguïté s'oppose intrinsèquement à la sécurité du DNS, et a conseillé que l'ICANN devrait, autant que possible, essayer de réduire l'ambiguïté au fur et à mesure de l'introduction de nouveaux domaines. Paul a exprimé son accord par rapport au fait que le plan de gestion de l'occurrence de collision dans nouveaux gTLD proposé accomplit cela, et il a indiqué que l'ICANN devrait contrôler la vitesse du déploiement des TLD.

      À la demande du président, Ram Mohan a fourni au comité des conseils techniques supplémentaires concernant le plan de gestion de l'occurrence de collision. Ram a manifesté son soutien général au plan, et il a recommandé que le comité examine si le plan : (1) est techniquement solide, (2) résistera à l'examen détaillé, (3) résout les problèmes qu'il entend résoudre, et (4) nécessite d'éléments supplémentaires.

      Ram a dit être d'accord sur la solidité technique du plan, tout en signalant, par exemple, que le plan corrige certaines limitations de l'analyse précédente, car le nouveau plan aborde la gravité des collisions et supprime les classements des risques (qu'une grande partie de la communauté considérait des distinctions arbitraires). 

      Ram a recommandé au comité d'établir une limite claire sur le niveau approprié de sensibilisation requis par le plan. Erika Mann et Jonne Soininen ont convenu que les paramètres doivent être définis plus clairement.

      Ram a noté que le plan proposé comprend des paramètres qui lui permettront de résister à l'examen, mais que la communauté sera particulièrement attentive aux détails sur la façon d'étudier la gravité des occurrences de collision.

      Ram a remarqué que la réservation des collisions de domaines de deuxième niveau connus est une bonne idée et que l'analyse de chaque chaîne, tel que proposé dans le plan, a un fort soutien des communautés technique et de la sécurité.

      Ram a proposé des éléments supplémentaires que le plan devrait aborder, ce qui comprenait considérer la création d'une mesure à long terme pour réduire l'utilisation publique de chaînes TLD non attribuées, la création d'un plan avec l'IAB et l'IETF pour réserver des chaînes pour l'utilisation privée, en considérant les implications sur les délégations des ccTLD, et l'élaboration d'un plan pour mesurer les données des serveurs racine pour les utiliser afin d'élaborer de nouvelles recommandations. Ray Plzak a suggéré que les mesures de collecte de données devraient être plus larges et ne pas se limiter tout simplement aux noms, et devraient inclure IN-ADDR.ARPA, le domaine ARPA et les chiffres.

      Plusieurs membres du comité ont convenu que le plan doit inclure ces éléments supplémentaires.

      Ram a suggéré que la question de la collision de noms devrait probablement être supervisée par un comité du Conseil, puisque la question n'est pas exclusive aux nouveaux gTLD, et Mike Silber a demandé si le comité des risques du Conseil était le comité compétent pour superviser la question. Ray et le président ont convenu que cette question devrait être contrôlée par le comité des risques du Conseil.

      Olga Madruga-Forti a demandé si l'ICANN pourrait faire des délégations conditionnelles, le cas échéant, comme un moyen de résoudre la question des occurrences de collision. Olga a clarifié les distinctions d'une délégation conditionnelle par rapport à une délégation provisoire. Ram a mis en doute la valeur des délégations provisoire, invoquant des préoccupations quant à si le fait d'avoir plus de données qui seraient obtenues à partir d'une délégation provisoire fournirait des informations qui aideraient à décider plus facilement sur une délégation et si les essais permettraient de réduire la stabilité de certaines composantes du DNS.

      Le président de la division des domaines génériques (GDD) a noté que les délégations provisoires pourraient ne pas atténuer suffisamment le risque parce que le dommage ne se fait pas en déléguant d'abord le TLD, mais que ce potentiel de dommage se pose plutôt lors de l'activation des domaines de deuxième niveau, ce qui pourrait se produire à tout moment.

      George Sadowsky a demandé si la proposition présentée à la communauté concernant une méthode de délégation prudente est une approche techniquement solide. Le président de la GDD a noté que la plupart des plans d'atténuation qui sont discutés au sein de la communauté, tels que la délégation provisoire et le rapport Kolkman de l'IAB, pourraient potentiellement être des outils utilisés dans les plans d'atténuation qui seront développés dans le cadre de la proposition.

      Mike Silber a recommandé que le ton de la proposition devrait communiquer que les commentaires de la communauté sont pris au sérieux et ne sont pas ignorés. Erika a été d'accord.

      Le comité a examiné les modifications à la résolution pour s'attaquer aux points supplémentaires recommandés pour les inclure dans la proposition, et a examiné la résolution révisée. Gonzalo Navarro a manifesté sa préoccupation sur le fait que la révision de la résolution nécessiterait d'un temps supplémentaire. 

      Chris Disspain a proposé la résolution et Mike Silber a l'a appuyée.

      Le comité a ensuite pris les décisions suivantes :

      Attendu que le 15 mars 2013, le comité consultatif de l'ICANN sur la sécurité et la stabilité (SSAC) a publié le rapport SAC 057 : Rapport consultatif sur les certificats de noms internes

      Attendu qu'en réponse aux questions mises en relief dans le SAC 057, le Conseil d'administration de l'ICANN a demandé au Président-directeur général, en consultation avec le SSAC, d'effectuer une étude sur l'utilisation des TLD qui ne sont pas actuellement délégués au niveau de la racine du DNS public dans les entreprises (l' « étude de la collision de noms »).

      Attendu que l'étude de la collision de noms, ainsi qu'une proposition pour la gestion des risques identifiés dans l'étude (la « proposition ») ont été publiées pour consultation publique du 5 août 2013 au 17 septembre 2013. La proposition a été révisée en réponse aux commentaires publics.

      Attendu que le NGPC entreprend cette action conformément à l'autorisation qui lui a été accordée par le Conseil le 10 avril 2012 pour exercer l'autorité du Conseil de l'ICANN sur toutes les questions pouvant apparaître quant au Programme des nouveaux gTLD.

      Résolu (2013.10.07.NG01), le NGPC demande au président de la division des domaines génériques de mettre en œuvre la proposition pour gérer les occurrences de collisions entre les nouveaux gTLD et les utilisations privées existantes des mêmes chaînes, telles que présentées dans le « plan de gestion des occurrences de collision des nouveaux gTLD » joint dans l'Annexe 1 [PDF, 844 KB], et, ce faisant, de prendre en compte d'autres conseils qui pourraient être fournis par le SSAC et d'autres experts et représentants.

      Résolu (2013.10.07.NG02), le NGPC demande au Président-directeur général de l'ICANN, et le cas échéant par l'intermédiaire du président de la division des domaines génériques, de cibler de manière appropriée la campagne de sensibilisation prévue. Le NGPC recommande également au Conseil que : (1), le comité de risques du Conseil de l'ICANN examine expressément cette question et présente un rapport au Conseil d'administration, et il continue d'examiner et de faire des rapport à des intervalles réguliers, (2) le conseil enjoint au Président-directeur général de l'ICANN d'élaborer un plan à long terme pour gérer la collision de noms à la racine, et (3) le conseil enjoint au Président-directeur généra de l'ICANN de travailler avec la communauté pour élaborer un plan à long terme pour conserver et mesurer les données du serveur racine.

      Neuf membres du Comité ont voté en faveur des résolutions 013.10.07.NG01 et 2013.10.07.NG02. Gonzalo Navarro et Ray Plzak se sont abstenus de voter sur les résolutions. Les résolutions ontété adoptées.

      En s'abstenant de voter sur les résolutions, Gonzalo Navarro a déclaré que, compte tenu de l'importance de la résolution, tandis que le comité semble être d'accord avec le contenu de la proposition, la rédaction spécifique est complexe et importante et sa considération nécessite de temps supplémentaire. Ray Plzak a noté que son abstention était fondée sur les mêmes motifs. Olga Madruga-Forti a également exprimé son accord avec les commentaires de Gonzalo concernant la complexité des questions soulevées dans la résolution.

      Fondements des résolutions 2013.10.07.NG01 – 2013.10.07.NG02

      Pourquoi le Conseil aborde-t-il cette question maintenant ?

      Dans le SAC 057 : avis du SSAC sur les certifications de noms internes, le comité consultatif sur la sécurité et la stabilité (SSAC) de l'ICANN a identifié une pratique de l'autorité de certification (CA) qui, si elle était largement exploitée, pourrait présenter des risques pour la confidentialité et l'intégrité des communications Internet sécurisées et pourrait avoir un impact sur le programme des nouveaux gTLD. Le SSAC a donc conseillé à l'ICANN de prendre des mesures immédiates pour atténuer les risques. Les questions soulevées dans le SAC 057 font partie d'une catégorie de questions plus générales où une partie utilise un nom de domaine dans un réseau privé qui comprend un TLD non-délégué qui plus tard est délégué dans la racine dans le cadre du programme des nouveaux gTLD.

      Auparavant, le Conseil d'administration de l'ICANN a demandé au Président-directeur général de commander une étude sur l'utilisation des TLD qui ne sont pas actuellement délégués au niveau de la racine du DNS public. Cette étude devrait également tenir compte des conséquences potentielles sur la sécurité pour les chaînes ayant fait l'objet d'une candidature aux nouveaux gTLD liées à cette utilisation.

      L'étude demandée a été commandée et publiée le 5 août 2013 (l' « étude sur la collision de noms »). En même temps, une proposition visant à gérer les risques identifiés dans l'étude sur la collision de noms a été publiée pour consultation publique (la « proposition ») jusqu'au 17 septembre. À ce moment-là, le NGPC envisage d'adopter la proposition, qui a été révisée en réponse aux commentaires publics. L'adoption et la mise en œuvre de la proposition permettra à l'ICANN d'avancer avec la délégation des nouveaux gTLD de manière sécurisée et stable.

      Quelles sont les propositionsà l'étude ?

      La proposition examinée par le NGPC (jointe à la présente résolution dans l'annexe 1) présente un plan pour gérer les occurrences de collision entre les nouveaux gTLD et les utilisations privées existantes des mêmes chaînes. La proposition a été mise à jour en réponse aux commentaires faits par la communauté au cours du forum de consultation publique. Un point central de la proposition mise à jour comprend une étude supplémentaire pour élaborer un cadre de gestion d'occurrences de collision de noms. Le cadre inclura des processus et des paramètres appropriés pour évaluer à la fois la probabilité et la gravité du préjudice causé par l'occurrence d'une collision de noms. Ces paramètres incluent, entre autres, le nombre de demandes DNS, le type de demandes DNS, le type de requêtes, la diversité des sources des requêtes et les apparitions dans les certificats de noms internes. Le cadre mettra en correspondance un ensemble d'évaluations de l'occurrence des collisions avec, le cas échéant, les mesures d'atténuation correspondantes que l'ICANN ou les candidats aux TLD risquent de devoir mettre en place pour chaque nom de domaine de deuxième niveau (SLD) figurant dans l'ensemble de données DITL (un jour dans la vie de l'Internet).

      La proposition accorde à l'opérateur de registre le choix de procéder à la délégation avant de recevoir son rapport d'évaluation de l'occurrence de collision dans le SLD (conformément aux procédures et aux processus établis). Si l'opérateur de registre choisit cette voie alternative de délégation, il doit dès le départ bloquer tous les SLD qui apparaissent dans la base de données DITL pendant la mise en œuvre de l'évaluation.

      Une fonctionnalité supplémentaire de la proposition recommande un processus permettant aux parties affectées de signaler le problème et de demander le blocage du SLD à l'origine d'un préjudice grave et démontrable résultant de la collision de noms. Ce processus est destiné à atténuer le risque d'impact grave découlant de collisions non observées dans la base de données de l'étude.

      Finalement, la proposition décrit une campagne de sensibilisation ciblée, adressée aux parties potentiellement affectées, afin de les aider à identifier et à gérer l'origine (les causes) de l'occurrence des collisions de noms dans leurs réseaux. Dans le cadre de la campagne de sensibilisation, l'ICANN est censé inviter et collaborer avec les autres représentants et membres de la communauté intéressés à collaborer afin de faire avancer ce dossier. Le NGPC a résolu de demander au Président-directeur général de l'ICANN de cibler correctement ce projet de campagne de sensibilisation prévue.

      Les détails de la proposition sont présentés dans l'Annexe 1 [PDF, 844 KB].

      Le NGPC recommande également au Conseil de l'ICANN qu'il demande au Président-directeur général d'élaborer un plan à long terme pour gérer les risques de collision de noms liés à la délégation de nouveaux TLD, et de travailler avec la communauté pour élaborer un plan à long terme pour conserver et mesurer les données du serveur racine.

      Le NGPC recommande également au Conseil de l'ICANN que le comité des risques du Conseil de l'ICANN examine cette question expressément à des intervalles réguliers et en prépare un rapport pour le Conseil.

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

      L'ICANN a présenté les conclusions de l'étude sur la collision de noms lors de la réunion de l'ICANN à Durban, en Afrique du Sud. En outre, l'ICANN a lancé un forum de consultation publique du 5 août au 17 septembre 2013, invitant la communauté à fournir des commentaires concernant l'étude sur la collision de noms et la proposition. Pendant la période de consultation publique, 75 commentaires ont été reçus. Vous pouvez accéder au rapport qui résume les commentaires et les remarques complètes de la consultation publique sur http://forum.icann.org/lists/comments-name-collision-05aug13/. En réponse aux commentaires publics, le personnel a mis à jour la proposition examinée par le NGPC pour inclure les améliorations supplémentaires au plan de gestion des occurrences de collision de noms.

      Quelles sont les préoccupations ou les questions soulevées par la communauté ?

      Certains membres de la communauté ont manifesté une préoccupation générale parce que la question de la collision de noms est traitée à un stade tardif du programme des nouveaux gTLD et se demandent pourquoi l'ICANN n'a pas abordé la question auparavant. Les intervenants qui manifestaient des inquiétudes sur ce retard ont également demandé une prolongation de la période de consultation pour que la communauté ait le temps suffisant pour étudier ces questions et en formuler des commentaires pertinents.

      Les membres de la communauté ont suggéré que les risques identifiés dans l'étude sur la collision de noms peuvent être exagérés, notant que seulement 3 % du total des demandes aux serveurs DNS de TLD entrent en conflit avec des chaînes qui sont effectivement considérées dans le cadre du programme des nouveaux gTLD. Certains ont suggéré que la portée du problème ne garantit pas l'atténuation dans un délai de 3 à 6 mois.

      D'autres ont noté que l'expansion précédente des TLD (par exemple, .xxx, .asia) n'a pas provoqué de problèmes connus, et ont affirmé que ces délégations réussies montrent qu'il n'est pas nécessaire de retarder plus que les deux chaînes comportant le plus de risques. Certains commentaires déclaraient qu'il n'y a aucune raison démontrée pour retarder la délégation d'aucun TLD demandé qui soit actuellement dans les catégories de « risque faible » et « risque non calculé ».

      Plusieurs membres de la communauté ont apporté des observations sur la validité ou l'applicabilité des échantillons de données utilisés dans l'étude sur la collision de noms ou la méthode utilisée pour évaluer les risques. Ces commentaires ont fait remarquer qu'il est insuffisant de compter seulement le nombre de demandes pour chaque chaîne afin d'évaluer les risques, et on a conseillé de considérer la gravité des conséquences ainsi que la fréquence. Les commentaires ont également suggéré que l'étude sur la collision de noms manque de données critiques – à savoir, le trafic des domaines inexistants (NXD) dans les TLD existants ou des sous-domaines spécifiques qui reçoivent du trafic NXD dans des TLD classés dans la catégorie « risque non calculé ». En outre, les intervenants qui manifestent des inquiétudes par rapport à la méthode soutiennent que la définition d'un seuil pour classer les chaînes en « risque faible » et en « risque non-catégorisé » (c'est à dire, la division 80 % / 20 %) est une division arbitraire.

      Certains intervenants ont conseillé que l'ICANN entame une campagne agressive pour sensibiliser les entreprises du monde entier sur la meilleure façon de se préparer pour les occurrences de collision de noms.

      D'autres intervenants ont suggéré que l'ICANN doit être prête à remettre à plus tard l'introduction dans le DNS de tout nouveau gTLD identifié dans ses études comme présentant une menace de collision. Ces reports devraient rester en vigueur pour chaque chaîne gTLD identifiée jusqu'à ce que les menaces liées à cette chaîne puissent être éliminées en grande partie.

      Quels documents importants le Conseil d'administration a-t-il examinés ?

      Quels sont les facteurs que le Conseil a trouvés significatifs ?

      Le NGPC a considéré plusieurs facteurs importants lors de ses délibérations sur la possibilité d'adopter ou non la proposition pour gérer les occurrences de risque pour les noms. Les éléments suivants sont parmi les facteurs que le NGPC a trouvés significatifs :

      • le NGPC a examiné les recommandations du SSAC dans le SAC 057.

      • divers intervenants ont considéré que le fait de compter uniquement sur la fréquence des requêtes DNS pour évaluer le risque était insuffisant, et que l'ICANN doit prendre en compte une série de paramètres supplémentaires (par exemple, la fréquence des demandes, le type de requête, le type de demande, etc.) pour définir le niveau de risque. Certains commentaires ont affirmé que l'ICANN a utilisé des méthodes arbitraires pour classer les chaînes dans les catégories de risque. L'ICANN reconnaît que d'autres paramètres, en plus de la fréquence de demande, doivent être pris en compte dans l'évaluation du risque, notamment le préjudice potentiel provoqué par des occurrences de collision de noms, et adoptera les conseils concernant l'utilisation des autres paramètres proposés au moment de faire l'étude pour établir la probabilité et l'impact (par exemple, le dommage) dus aux occurrences de collision de noms.

      • plusieurs intervenants ont proposé de nouvelles idées pour gérer les risques associés aux occurrences de collision de noms. Par exemple, les membres de la communauté ont proposé de bloquer temporairement certains domaines de deuxième niveau (SLD) dans le but d'assurer l'équilibre entre le progrès de la délégation de nouveaux gTLD, tout en préservant le comportement DNS attendu des résolveurs DNS des parties qui utilisent des noms correspondant aux nouveaux gTLD dans les réseaux privés qui fuient au DNS public. Le personnel de l'ICANN reconnaît que le blocage temporaire des SLD qui apparaissaient dans les données de DITL (c'est à dire, en interdisant à ces noms de résoudre dans le TLD récemment délégué) devrait garantir que les requêtes DNS correspondantes qui fuient actuellement au DNS public continueront d'être répondues avec le message « erreur de nom (NXDOMAIN) » et que cette mesure réduira la possibilité de dommages pendant la durée du blocage. La « proposition »adopte cette recommandation.

      • plusieurs membres de la communauté ont demandé que la période de consultation publique soit prolongée pour donner à la communauté davantage de temps pour étudier les risques dans leurs réseaux. L'ICANN estime que, compte tenu des révisions apportées à la proposition, y compris l'adoption de la mesure de blocage SLD temporaire, les parties potentiellement concernées auront plus de temps pour étudier les questions dans leurs réseaux sans être affectées par les délégations de nouveaux gTLD. En outre, afin d'aborder les effets des SLD qui n'ont pas été bloqués temporairement mais qui génèrent des dommages importants, les opérateurs de registre mettront en œuvre un processus permettant à la partie affectée de faire un rapport et de demander la suspension d'un nom de domaine qui, dû aux occurrences de collision de noms, provoque un dommage significatif.

      • plusieurs intervenants ont fait remarquer que l'ICANN devrait mettre en œuvre une campagne de sensibilisation pour éduquer les parties potentiellement affectées sur la question des occurrences de collision de noms et leur impact potentiel. L'ICANN reconnaît la demande et a révisé la proposition pour inclure une campagne de sensibilisation dans le cadre de la proposition mise à jour pour gérer les occurrences de collision de noms.

      Y a-t-il des effets positifs ou négatifs pour la communauté ? Cela a-t-il un impact financier ou des répercussions sur l'ICANN (Plan stratégique, Plan opérationnel, Budget), sur la communauté ou sur le public ? Y a-t-il des questions de sécurité, de stabilité ou de résilience concernant le DNS ?

      Le SAC057 et l'étude sur la collision de noms ont identifié plusieurs risques de sécurité pour le DNS. La proposition, révisée en réponse aux commentaires de la communauté, fournit une voie à suivre pour déléguer les nouveaux gTLD de manière sécurisée et stable. L'action du NGPC pour demander au président de la division des domaines génériques d'avancer avec la mise en œuvre de la proposition aura un impact positif pour la communauté, parce que cela permettra à l'ICANN de déléguer des nouveaux gTLD lorsque le risque de dommage résultant de la délégation d'un TLD demandé est faible.

      La proposition pourrait avoir un impact financier sur l'ICANN, la communauté ou le public, car il peut y avoir des coûts supplémentaires liés à la mise en œuvre des mesures d'atténuation comprises dans la proposition, ce qui pourrait inclure des ressources supplémentaires nécessaires pour développer une campagne de sensibilisation ciblée sur les parties concernées pour les aider à identifier et gérer les occurrences de collision de noms dans leurs réseaux.

      Dans le cadre de sa fonction administrative organisationnelle, l'ICANN a publié l'étude sur la collision de noms et la proposition pour gérer les risques de collision de noms identifiés pour consultation publique. Le rapport contenant les commentaires publics est disponible sur : http://forum.icann.org/lists/comments-name-collision-05aug13/.

      Le président a ensuite levé la réunion.

minutes-new-gtld-07oct13-fr.pdf  [234 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."