Skip to main content
Resources

Résolutions approuvées | Réunion 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/resolutions-new-gtld-07oct13-en.htm

 

  1. Ordre du jour principal
    1. Gestion des risques de collision des nouveaux gTLD
      1. Fondements des résolutions 2013.10.07.NG01 – 2013.10.07.NG02

 

  1. Ordre du jour principal:

    1. Gestion des risques de collision des nouveaux gTLD

      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 du SSAC sur les certificats de noms internes.

      Attendu que, en réponse aux questions globales soulignées dans le SAC 057, le Conseil d'administration de l'ICANN a enjoint 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 (« l'étude sur la collision des noms »).

      Attendu que l'étude sur la collision des noms, accompagnée d'une proposition de gestion des risques identifiés dans l'étude sur la collision des noms (la « proposition ») a été publiée pour consultation publique du 5 août au 17 septembre. 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 enjoint au président de la division de noms de domaine génériques de mettre en œuvre la proposition de gestion des risques de collision entre les nouveaux gTLD et les usages privés existants des mêmes chaînes tel que présenté dans le « plan de gestion des risques de collision des nouveaux gTLD » joint en tant que annexe 1 [PDF, 840 KB], et en le faisant, to prendre en compte les nouveaux conseils éventuellement fournis par le SSAC et d'autres experts et parties prenantes.

      Résolu (2013.10.07.NG02), le NGPC enjoint au président-directeur général de l'ICANN et, en tant que de besoin, par le biais du président de la division des domaines génériques, de cibler la campagne de faire-savoir programmée de manière adéquate.   Le NGPC recommande aussi au Conseil que : (1) le comité des risques du Conseil d'administration de l'ICANN examine cette affaire expressément et fasse un rapport au Conseil, continue de réviser et de rédiger des rapports à intervalles réguliers ; (2) le Conseil enjoigne au président-directeur général de l'ICANN d'élaborer un plan à long terme pour la gestion des collisions de noms au niveau de la racine et (3) le Conseil enjoigne au président-directeur général de l'ICANN de travailler avec la communauté pour élaborer un plan à long terme visant à conserver et à mesurer les données des serveurs racine.

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

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

      Dans le SAC 057 : document consultatif du SSAC sur les certificats des noms internes, le comité consultatif de l'ICANN pour la stabilité et la sécurité (SSAC) a identifé une pratique d'autorité de certification (CA) qui, si largement exploitée, pouvait poser des risques à la confidentialité et à l'intégrité des communications Internet sûres et pourrait avoir une incidence sur le programme des nouveaux gTLD. Le SSAC a donc conseillé à l'ICANN de prendre immédiatement des mesures visant à limiter les risques. Les questions identifiées dans le SAC 057 font partie d'une catégorie plus vaste de questions où une partie utilise un nom de domaine dans un réseau privé qui inclut un TLD non délégué qui devient par la suite délégué dans la racine dans le cadre du programme des nouveaux gTLD. 

      Auparavant, le Conseil d'administration de l'ICANN avait enjoint 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 devait é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 requise avait été commandée et publiée le 5 août 2013 (« l'étude sur la collision de noms »). En même temps, une proposition de gestion des risques identifiés dans l'étude sur la collision des noms a été publiée pour consultation publique (la « proposition ») jusqu'au 17 septembre. Pour le moment, 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 permettront à l'ICANN de progresser avec la délégation de nouveaux gTLD de manière sûre et stable.

      Quelles sont les propositions à l'étude ?

      La proposition examinée par le NGPC (jointe à cette résolution en tant qu'annexe 1) présente un plan de gestion des risques de collision entre les nouveaux gTLD et les usages privés existants des mêmes chaînes. La proposition a été mise à jour en réponse aux commentaires de la communauté reçus dans le cadre du forum de consultation publique. Une caractéristique fondamentale de la proposition mise à jour inclut la mise en œuvre d'une étude supplémentaire pour développer un cadre de gestion des risques de collision de noms. Le cadre comportera des paramètres et processus adéquats pour évaluer autant la probabilité que la gravité d'un dommage résultant d'un cas de collision de noms. Des exemples des paramètres pourraient inclure un nombre de requêtes DNS, le type de requêtes DNS, le type d'interrogations, la diversité des sources d'interrogation et les apparitions dans les certificats de noms internes. Le cadre spécifiera une ensemble d'évaluations de risques de collision et les mesures correspondantes pour limiter ces risques, le cas échéant, que l'ICANN ou les candidats à des TLD pourraient avoir besoin de mettre en œuvre pour chaque nom de domaine de deuxième niveau (SLD) vu dans l'ensemble de données « un jour dans la vie de l'Internet » (DITL).

      La proposition fournit à l'opérateur de registre l'option de procéder à la délégation avant de recevoir son rapport d'évaluation de risque de collision SLD (sous réserve de procédures et processus établis). Si l'opérateur de registre choisit cette voie alternative vers la délégation, il doit au départ bliquer tous les SLD qui apparaissent dans l'ensemble de données DITL pendant l'exécution de l'évaluation.

      Une caractéristique supplémentaire de la proposition recommande un processus qui permette à la partie touchée de rapporter et de demander le blocage d'un SLD parce qu'il cause un dommage manifestement grave résultant de l'occurrence d'une collision de noms. Ce processus vise à limiter le risque que des occurrences de collisions non remarquées dans l'ensemble de données de l'étude puissent avoir une incidence grave.

      Finalement, la proposition décrit une campagne de faire-savoir ciblée sur les parties potentiellement touchées pour les aider à identifier et à gérer les origines (causes) d'occurrences de collisions de noms dans leurs réseaux. Dans le cadre de la campagne de faire-savoir, l'ICANN inviterait et collaborerait avec d'autres parties et d'autres membres de la communauté qui partagent le même intérêt et souhaiteraient faire des progrès dans ce sens. Le NGPC est décidé à enjoindre au président-directeur général de l'ICANN de cibler cette proposition de campagne de faire-savoir de manière adéquate.

      Tous les détails de la proposition sont présentés en annexe 1 [PDF, 840 KB].

      Le NGPC recommande aussi au Conseil d'administration de l'ICANN d'enjoindre au président-directeur général de développer un plan à long terme pour la gestion des risques de collision de noms liés à la délégation de nouveaux gTLD et de travailler avec la communauté pour élaborer un plan à long terme visant à conserver et à mesurer les données des serveurs racine. 

      Le NGPC recommande aussi au Conseil d'administration de l'ICANN que le comité des risques du Conseil de l'ICANN révise expressément cette affaire et fasse son rapport au Conseil à intervalles réguliers.

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

      L'ICANN a présenté les conclusions de l'étude sur les collisions de noms pendant la réunion de l'ICANN à Durban en Afrique du Sud. En outre, l'ICANN a mis en place un forum de consultation publique du 5 août au 17 septembre 2013, sollicitant les commentaires de la communauté sur l'étude sur la collision des noms et sur la proposition. Pendant la période de consultation publique, 75 commentaires ont été reçus. Le rapport de la consultation publique résumant les commentaires et le texte complet des commentaires peuvent être consultés sur http://forum.icann.org/lists/comments-name-collision-05aug13/. En réponse aux commentaires publics, le personnel a mis à jour la proposition à l'étude par le NGPC pour inclure des améliorations supplémentaires du plan de gestion des risques de collision des noms.

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

      Certains membres de la communauté s'inquiètent du fait que la collision de noms soit traitée à un stade si avancé du processus des nouveaux gTLD et demandent pourquoi l'ICANN n'a pas abordé la question plus tôt. Les membres exprimant des préoccupations concernant le moment choisi demandaient aussi une prolongation de la période de consultation publique pour permettre à la communauté d'étudier ces questions et de fournir des commentaires utiles.

      Des membres de la communauté suggéraient que les risques identifiés dans l'étude sur la collision de noms pourraient être exagérés, notant que seuls 3% de l'ensemble des demandes aux serveurs DNS des TLD présentaient un conflit avec des chaînes examinées dans le cadre du programme des nouveaux gTLD. Certains suggéraient que la portée du problème ne justifiait pas la minimisation conduisant à 3 à 6 mois de retard.

      D'autres indiquaient que des expansions précédentes de TLD (par ex. .xxx, .asia) n'avaient pas causé de problèmes connus et soutenaient que ces délégations réussies démontraient qu'il n'était pas besoin de retarder plus de chaînes que les deux présentant le plus grand risque. Certains commentaires indiquaient qu'il n'y avait pas de raison justifiée pour retarder la délégation d'un TLD faisant l'objet d'une candidature et actuellement classé « à faible risque » ou « à risque non calculé ».

      Plusieurs membres de la communauté ont commenté la validité ou l'applicabilité des échantillons de données utilisés dans l'étude sur la collision de noms ou la méthodologie utilisée pour évaluer les risques. Certains commentaires indiquaient qu'il n'était pas suffisant de compter le nombre de demandes pour chaque chaîne lors de l'évaluation du risque et conseillaient de tenir compte de la gravité des conséquences en même temps que de la fréquence. Les commentaires suggéraient aussi que l'étude sur la collision des noms laissait passer des données essentielles – à savoir, le trafic de domaines non existents (NXD) dans les TLD existents ou les sous-domaines qui reçoivent un trafic NXD dans les TLD classés dans la catégorie « à risque non calculé ». En outre, les commentaires exprimant des inquiétudes concernant la méthodologie, soutenaient que l'établissement d'un seuil pour diviser les chaînes en catégories « à bas risque » et « à risque non calculé » (c'est-à-dire les 80%/20%) était arbitraire.

       Certains autres conseillaient à l'ICANN de lancer une campagne agressive pour informer les entreprises de par le monde de la meilleure façon de se préparer pour les risques de collision de noms.

      D'autres commentaires suggéraient que l'ICANN devrait être préparée à reporter l'introduction dans le DNS de tout nouveau gTLD, les études approfondies duquel auraient identifié comme présentant une menace de collision. Ces reports devraient rester en vigueur pour chaque chaîne de gTLD identifiée jusqu'à ce que les menaces y liées soient nettement éliminées.

      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 examiné plusieurs facteurs significatifs durant ses délibérations pour décider s'il fallait adopter la proposition de gestion des occurrences de risque de collision de noms. Les facteurs suivants sont au nombre de ceux que le NGPC a trouvé significatifs :

      • Le NGPC a tenu compte des recommandations du SSAC dans le SAC 057.
      • Divers commentaires indiquaient qu'il n'était pas suffisant de s'appuyer uniquement sur la fréquence des requêtes DNS pour évaluer le risque , mais que l'ICANN devait examiner une série de paramètres supplémentaires (par ex. la fréquence des requêtes, le type d'interrogation, le type de requête, etc.) pour définir le niveau de risque. Certains commentaires soutenaient que l'ICANN utilisait des méthodes arbitraires pour répartir les chaînes en catégories de risque. L'ICANN convient que d'autres paramètres, mis à part la fréquence de requêtes, devraient être pris en compte dans l'évaluation du risque, notamment le dommage potentiel causé par les occurrences de collision de noms, et suivra ce conseil concernant l'usage des autres paramètres proposés lors de la réalisation de l'étude visant à établir la probabibilité et l'impact (par ex. le dommage) pouvant résulter des occurrences de collision de noms.
      • Plusieurs commentaires proposaient de nouvelles idées pour la gestion des risques associés aux occurrences de collision de noms. Par exemple, des membres de la communauté ont proposé une nouvelle idée pour bloquer temporairement certains domaines de deuxième niveau (SLD) dans un effort de trouver un équilibre pour faire avancer la délégation des nouveaux gTLD tout en préservant le comportement DNS attendu des résolveurs de parties utilisant des noms au titre des nouveaux gTLD dans des réseaux privés qui présentent des fuites dans le DNS public. Le personnel de l'ICANN convient que le blocage temporaire de SLD qui apparaissent dans les données DITL (c'est-à-dire en interdisant à ces noms de se résoudre dans le nouveau TLD délégué) devrait garantir que les requêtes DNS correspondantes présentant actuellement des fuites dans le DNS public continueront à recevoir une réponse « erreur de nom (NXDOMAIN) », et que cette mesure minimisera la possibilité de dommage aussi longtemps que le blocage sera en vigueur. La proposition adopte cette recommandation.
      • Plusieurs membres de la communauté ont demandé que la période de consultation publique soit prolongée pour que la communauté dispose d'une période de temps supplémentaire lui permettant d'étudier les risques dans ses réseaux respectifs. L'ICANN estime que, compte tenu des révisions de la proposition, y compris l'adoption de la mesure de blocage temporaire des SLD, les parties potentiellement touchées auront plus de temps pour étudier les questions dans leurs réseaux respectifs sans être affectées par les délégations de nouveaux gTLD. De plus, afin d'aborder les effets causés par des SLD qui ne sont pas temporairement bloqués mais qui produisent un dommage significatif, les opérateurs de registre mettront en œuvre un processus qui permette à la partie touchée de signaler et demander la suspension d'un nom de domaine qui cause un dommage significatif en vertu d'une occurrence de collision.
      • Plusieurs commentaires indiquaient que l'ICANN devrait réaliser une campagne de faire-savoir visant à informer les parties potentiellement touchées sur la question d'occurrences de collision de noms et sur leur impact potentiel. L'ICANN reconnaît la demande et a révisé la proposition de sorte à inclure une campagne de faire-savoir 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 liées au DNS ?

      Le SAC057 et l'étude sur les collisions de noms identifient plusieurs risques pour la sécurité du DNS. La proposition, telle que révisée en réponse aux commentaires de la communauté, fournit une voie à suivre pour la délégation des nouveaux gTLD de manière sûre et stable. La décision du NGPC d'enjoindre au président de la division des domaines génériques de procéder à la mise en œuvre de la proposition se traduira en un impact positif pour la communauté parce qu'elle permettra à l'ICANN de procéder à la délégation de nouveaux gTLD lorsque l'éventualité de dommage résultant de la délégation d'un TLD faisant l'objet d'une candidature sera considérée réduite.

      La proposition peut avoir un impact financier sur l'ICANN, la communauté ou le public, des coûts supplémentaires pouvant être associés à la mise en œuvre des mesures de minimisation décrites dans la proposition et pouvant inclure des ressources supplémentaires nécessaires pour développer une campagne de faire-savoir ciblée sur les parties touchées pour les aider à identifier et à gérer les occurrences de collision de noms dans leurs réseaux.

      Dans le cadre de la fonction organisationnelle administrative de l'ICANN, l'ICANN a publié l'étude sur la collision de noms et la proposition de gestion des risques de collision de noms identifiés. Le rapport des commentaires public est disponible sur:http://forum.icann.org/lists/comments-name-collision-05aug13/.

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