Skip to main content

Résolution du NGPC en vue de remédier aux conséquences de la collision de noms

Cette page est disponible en:

Dans sa réunion du 18 mai 2013, le Conseil d'administration de l'ICANN a adopté une résolution commanditant une étude pour identifier l'impact potentiel que pourraient avoir les nouveaux gTLD demandés sur l'utilisation des TLD qui ne sont pas actuellement délégués dans la racine du DNS public.

L'étude, intitulée « Collision de noms dans le DNS », ainsi qu'une proposition pour la gestion des risques identifiés dans l'étude, ont été publiées pour consultation publique du 5 août 2013 au 17 septembre 2013. Pendant la période de consultation publique, 75 commentaires ont été reçus. Sur la base de ces commentaires, le personnel a mis à jour la proposition sur la gestion des risques identifiés dans l'étude. Le rapport contenant les commentaires publics est disponible sur : http://forum.icann.org/lists/comments-name-collision-05aug13/.

Le Comité du programme des nouveaux gTLD du Conseil d'administration de l'ICANN (NGPC) s'est réuni le 28 septembre 2013 pour examiner le dossier des collisions de noms et discuter d'une proposition pour gérer les risques associés. Le 7 octobre 2013, le NGPC s'est réuni à nouveau et a approuvé une version actualisée de la proposition, intitulée « Plan de gestion de l'occurrence de collisions dans les nouveaux gTLD » [PDF, 840 KB], destinée à atténuer les risques de collision potentiels liés à l'introduction des nouveaux gTLD.

Le « Plan de gestion de l'occurrence de collisions » prévoit que le personnel mène une étude supplémentaire en vue de l'élaboration d'un cadre de gestion de l'occurrence 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 »).

En outre, le plan 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.

Le plan exige également à chaque opérateur de TLD d'établir un processus afin de permettre 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 liées à d'autres SLD non observés dans la base de données de l'étude.

Le plan inclut 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, sous la direction du Président-directeur général, invitera les parties prenantes et les membres de la communauté intéressés à collaborer afin de faire avancer ce dossier.

Dans sa réunion du 7 octobre, le NGPC a recommandé au Conseil d'administration de l'ICANN que le dossier des collisions de noms fasse l'objet d'un suivi par le Comité des risques du Conseil d'administration et soit révisé périodiquement. Il a également recommandé que l'ICANN travaille avec la communauté dans l'élaboration d'un plan à long terme pour garder et mesurer les données du serveur racine.

Pour plus d'informations sur le NGPC, suivez le lien : http://www.icann.org/en/groups/board/new-gtld.


More Announcements
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."