Skip to main content
Resources

Ce document a été traduit dans plusieurs langues dans un but purement informatif. Le texte original faisant foi (en anglais) peut être consulté sur :

Cette page est disponible en:

12 – 14 October 2014

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

 

  1. Ordre du jour approuvé :
    1. Approbation des procès-verbaux
  2. Ordre du jour principal :
    1. L'avis du GAC dans le communiqué de Pékin concernant les sauvegardes de catégorie 2 - Accès exclusif au registre
    2. Aucune résolution adoptée. Décisions d'experts jugées incohérentes quant à l'objection relative aux chaînes prêtant à confusion
    3. Demande de reconsidération 14-37, I-Registry Ltd
    4. L'avis du GAC concernant les protections pour la Croix rouge et le Croissant rouge – Communiqué de Singapour
    5. Divers

 

La réunion du Comité du programme des nouveaux gTLD du Conseil d’administration de l'ICANN du 12 octobre 2014 s'est poursuivie le 14 octobre 2014. Les résolutions suivantes ont été adoptées lors de la réunion :

  1. Ordre du jour approuvé :

    1. Approbation des procès-verbaux

      Résolu (2014.10.12.NG01), le Comité du programme des nouveaux gTLD (NGPC) du Conseil d'administration de l'ICANN approuve les procès-verbaux de la réunion du 8 septembre 2014.

  2. Ordre du jour principal :

    1. L'avis du GAC dans le communiqué de Pékin concernant les sauvegardes de catégorie 2 - Accès exclusif au registre

      Aucune résolution adoptée.

    2. Décisions d'experts jugées incohérentes quant à l'objection relative aux chaînes prêtant à confusion.

      Attendu que, le 10 octobre 2013 le Comité de gouvernance du Conseil d'administration (BCG) a demandé au personnel de rédiger un rapport pour le NGPC sur les objections relatives aux chaînes prêtant à confusion (SCO) « en fixant des options pour traiter la situation qui a été soulevée au sein de la demande de reconsidération, à savoir les résultats différents du processus de résolution des litiges sur l'objection relative aux chaînes prêtant à confusion lors de litiges similaires impliquant la chaîne objet de la candidature d'Amazon et la chaîne objet de la candidature de TLDH. »

      Attendu que, le NGPC a pris en considération d'éventuels moyens pour répondre aux incohérences perçues dans les décisions d'experts sur le processus concernant les SCO du programme des nouveaux gTLD, y compris la mise en place éventuelle d'un nouveau mécanisme de révision.

      Attendu que, le 5 février 2014, le NGPC du Conseil d’administration de l'ICANN a chargé le président de l'ICANN et CEO, ou son délégué, d'entamer une période de consultation publique sur les principes cadre d'un éventuel mécanisme de révision pour répondre aux décisions d'experts jugées incohérentes sur l'objection relative aux chaînes prêtant à confusion (le « mécanisme de révision proposé »). Le mécanisme de révision proposé, si adopté, serait limité aux décisions d'experts sur l'objection relative aux chaînes prêtant à confusion .CAR/.CARS et .CAM/.COM, et constituerait un changement dans le processus d'objection établi dans le guide de candidature des nouveaux gTLD.

      Attendu que, le NGPC a soigneusement pris en considération le rapport que le BGC a demandé au personnel de rédiger en réponse à la demande de reconsidération 13-9, les commentaires publics reçus pour le mécanisme de révision proposé, d'autres commentaires apportés au NGPC pour prise en considération, ainsi que les processus établis dans le guide de candidature.

      Attendu que, comme établi dans le guide de candidature, l'ICANN se réserve le droit de prendre en considération individuellement une candidature pour un nouveau gTLD pour déterminer si l’approbation serait dans le meilleur intérêt de la communauté Internet.

      Attendu que le NGPC prend cette décision en vertu des pouvoirs que lui a délégués le Conseil d'administration en date du 10 avril 2012 pour exercer l'autorité du Conseil d'administration dans toute question relative au programme des nouveaux gTLD.

      Résolu (2014.10.12.NG02), le NGPC a identifié les décisions suivantes des experts sur l'objection relative aux chaînes prêtant à confusion comme n'étant pas dans le meilleur intérêt du programme des nouveaux gTLD et de la communauté Internet :

      Révision des décisions des experts sur le SCO Chaîne Décisions des experts quant au SCO
      VeriSign Inc. (Objecteur) v. United TLD Holdco Ltd. (Candidat) .CAM [PDF, 5.96 MB]
      Commercial Connect LLC (Objecteur) v. Amazon EU S.à r.l. (Candidat) .通販 [PDF, 73 KB]1 Domaine de premier niveau Holdings Limited [PDF, 721 KB](.购物)

      Résolu (2014.10.12.NG03), le NGPC a chargé le président et CEO, ou son délégué, de prendre toutes les mesures nécessaires pour établir des processus et des procédures, conformément à cette résolution et aux principes liés, en vertu desquels le centre international pour le règlement des différends (CIRD) devra établir un panel de trois membres pour évaluer à nouveau les documents présentés, et les décisions des experts, dans les deux procédures d'objection établies dans la charte sous la colonne « Révision des décisions des experts sur le SCO » et rendre une décision finale sur ces deux procédures. Ainsi, le NGPC recommande que le panel de trois membres revoie également les « décisions des experts liées au SCO » référencées dans la charte ci-dessus.

      Fondements des résolutions 2014.10.12.NG02 – 2014.10.12.NG03

      Aujourd'hui, le NGPC prend des mesures pour répondre aux décisions des experts jugées incohérentes et déraisonnables résultant du processus d'objection relative aux chaînes prêtant à confusion du programme des nouveaux gTLD. L'action du NGPC fait partie de son rôle consistant à apporter une surveillance générale du programme des nouveaux gTLD. L'une des responsabilités du NGPC est de « résoudre les questions liées à l'approbation des candidatures et à la délégation des gTLD conformément au programme des nouveaux gTLD pour la série actuelle du programme. » (Voir la charte NGPC,Article II.D).

      Le guide de candidature des nouveaux gTLD (AGB ou guide de candidature) identifie quatre raisons pour lesquelles une objection formelle peut être déposée contre une chaîne faisant l'objet d'une candidature. Il s'agit d'une objection relative à une chaîne prêtant à confusion ou SCO, qui peut être déposée par un objecteur (conforme aux exigences) si l'objecteur pense qu'une chaîne faisant l'objet d'une candidature gTLD est similaire au point qu'il puisse y avoir une confusion avec un TLD existant ou une autre chaîne faisant l'objet d'une candidature d'un gTLD dans la même série de candidatures. Une telle objection peut, en cas d'aboutissement, modifier la configuration des ensembles conflictuels préliminaires, car les deux chaînes gTLD faisant l'objet d'une candidature seront considérées comme directement conflictuelles (voir le module 4 de l'AGB, Procédures de conflit de chaînes). Toutes les procédures de SCO ont été administrées par le centre international pour le règlement des différends (CIRD), et les décisions des experts ont été émises lors de telle procédures.

      Certaines parties prenantes ont soulevé des inquiétudes quant aux incohérences perçues ou quant au caractère déraisonnable de certaines décisions d'experts sur une SCO. Le NGPC a surveillé ces inquiétudes durant l'année passée, et en a discuté lors de certaines réunions. Le 10 octobre 2013 le Comité de gouvernance du Conseil d'administration (BCG) a demandé au personnel de rédiger un rapport pour le NGPC sur les objections relatives aux chaînes prêtant à confusion (SCO) « en présentant des options pour traiter la situation qui a été soulevée au sein de cette demande, à savoir les différents résultats du processus de résolution des litiges sur l'objection relative aux chaînes prêtant à confusion lors de litiges similaires impliquant la chaîne objet de la candidature d'Amazon et la chaîne objet de la candidature de TLDH. » (Voir http://www.icann.org/en/groups/board/governance/reconsideration/recommendation-amazon-10oct13-en.pdf [PDF, 131 KB]).

      À la lumière de la demande du BGC suite à sa prise en considération des demandes de reconsidération 13-9 et 13-10, et des inquiétudes soulevées par la communauté à propos des décisions des experts jugées incohérentes, le NGPC a pris en considération ses options, y compris la mise en place éventuelle d'un mécanisme de révision qui n'était pas envisagé dans le guide de candidature qui pourrait être disponible dans des circonstances limitées.

      Le 5 février 2014, le NGPC a chargé le président de l'ICANN et CEO d'entamer une période de consultation publique sur les principes cadres d'un éventuel mécanisme de révision pour répondre aux décisions d'experts jugées incohérentes sur l'objection relative aux chaînes prêtant à confusion. Le mécanisme de révision proposé, comme rédigé et publié pour commentaire public, serait limité aux décisions des experts sur les SCO .CAR/.CARS et .CAM/.COM. La période de consultation publique sur le mécanisme de révision proposé s'est clôturée le 3 avril 2014, et un résumé des commentaires [PDF, 165 KB] a été publiquement publié.

      En ce moment, le NGPC prend les mesures nécessaires pour répondre aux incohérences perçues ou autrement jugées déraisonnables des décisions des experts en renvoyant au CIRD certaines décisions des experts pour une évaluation par le panel composé de trois membres. Le NGPC a identifié ces décisions comme n'étant pas dans le meilleur intérêt du programme des nouveaux gTLD et de la communauté Internet. Il sera donné au CIRD des règles supplémentaires pour mener la révision des décisions des experts identifiées, incluant ce qui suit :

      • Le panel de révision sera constitué de trois membres nommés par le CIRD (le « panel de révision »).

      • La seule question soumise à la révision par le panel de révision sera les décisions des experts sur les SCO identifiées dans ces résolutions.

      • Le dossier en révision sera limité à la transcription de la procédure donnant lieu à la décision initiale des experts, le cas échéant, des rapports des experts, une preuve documentaire admise comme élément de preuve pendant la procédure initiale, ou une autre preuve pertinente pour la révision qui a été présentée lors de la procédure initiale. Aucun document supplémentaire, dossier ou autre preuve ne peut être soumis pour prise en considération, sauf s'il est recommandé que le panel de révision prenne en considération les « décisions d'experts liées au SCO » identifiées dans la charte ci-dessus dans le cadre de sa révision.

      • La norme de révision à appliquer par le panel de révision est : savoir si le panel d'expert initial pouvait raisonnablement en arriver à la décision parvenue dans la SCO sous-jacente via une application appropriée de la norme de révision comme mentionné dans le guide de candidature et dans les procédures supplémentaires du CIRD pour le programme des nouveaux gTLD de l'ICANN.

      • L'ICANN paiera les frais qui s'appliquent pour mener la révision par le panel de révision.

      • Les possibles résultats de la révision sont : (1) la décision initiale des experts est soutenue par la norme de révision et par la référence aux décisions identifiées, et restera en application ; ou (2) la décision initiale ne peut raisonnablement pas être soutenue, basée sur la norme de révision et sur la référence aux décisions identifiées, et sera annulée. Le panel de révision soumettra une décision écrite incluant une explication et les fondements de sa décision.

      Dans le cadre des mois de délibération sur la question, le NGPC considère les éléments suivants comme importants :

      1. Le NGPC prend note que le guide de candidature a été développé par la communauté lors d'un processus multipartite pendant plusieurs années. Le NGPC a pris en considération le fait de savoir s'il est approprié de modifier à ce moment le guide de candidature pour mettre en place un mécanisme de révision pour répondre à certaines décisions des experts jugées incohérentes. Le 18 avril 2013, l'ICANN a publié une proposition de mécanisme de révision pour commentaire public. Le NGPC a soigneusement pris en considération les commentaires publics reçus. Le NGPC note que les commentaires soumis pendant la période de consultation publique tombent généralement dans les catégories et thèmes suivants, chacun d'eux étant discuté de manière plus complète dans le résumé de commentaire public :

        1. Ne pas adopter le mécanisme de révision proposé.

        2. Adopter le mécanisme de révision proposé.

        3. Adopter un mécanisme de révision avec une plus grande portée.

        4. Ne pas adopter le mécanisme de révision ni en étendre la portée.

        5. Adopter une forme de révision, mais pas nécessairement celle postée pour commentaire public.

        6. Des modifications sont recommandées pour les principes cadre du mécanisme de révision proposé, si un mécanisme est adopté.

        Les commentaires présentés par les diverses parties prenantes soulignent la difficulté de la question et les tensions qui existent entre équilibrer les inquiétudes à propos des décisions jugées incohérentes, et les processus établis dans le guide qui ont été sujets à de multiples séries de commentaire public pendant plusieurs années.

        Comme souligné dans beaucoup de commentaires, adopter un mécanisme de révision si loin dans le processus pourrait être injuste car les candidats ont accepté les processus inclus dans le guide de candidature, qui n'incluaient pas ce mécanisme de révision, et les candidats se sont fiés à ces processus. Le NGPC reconnait que, bien que dans l'ensemble, un mécanisme de révision n'est pas approprié à la série actuelle du programme des nouveaux gTLD, il est recommandé que le développement de règles et processus pour les prochaines séries du programme des nouveaux gTLD (à développer via le processus multipartite) devrait chercher à savoir s'il y a un besoin de processus de révision formel en ce qui concerne les décisions des experts.

      2. Le NGPC a pris en considération son rôle et ses objectifs pour apporter une surveillance générale du programme des nouveaux gTLD. L'une des responsabilités du NGPC en apportant une surveillance générale du programme des nouveaux gTLD est de « résoudre les questions liées à l'approbation des candidatures et à la délégation des gTLD conformément au programme des nouveaux gTLD pour la série actuelle du programme. » (Voir Charte NGPC, article II.D). De plus, le guide de candidature (article 5.1) stipule que :

        Le conseil d’administration de l’ICANN détient la responsabilité ultime du nouveau programme gTLD. Le Conseil se réserve le droit de considérer individuellement une candidature pour un nouveau gTLD pour déterminer si l’approbation serait dans le meilleur intérêt de la communauté Internet. Dans des circonstances exceptionnelles, le Conseil d’administration peut considérer individuellement une candidature pour un gTLD. Par exemple, le Conseil peut considérer individuellement une candidature suite à l'avis du GAC sur les nouveaux gTLD ou suite à l’utilisation d’un mécanisme de responsabilité de l'ICANN.

        Répondre à l'incohérence perçue ou au caractère déraisonnable des décisions des experts sur l'objection relative aux chaînes prêtant à confusion fait partie du pouvoir discrétionnaire accordé au NGPC dans sa charte concernant « l'approbation des candidatures » et « la délégation des gTLD », en plus du pouvoir réservé au Conseil d’administration dans le guide de candidature de prendre en considération les candidatures individuelles pour un gTLD selon des circonstances exceptionnelles. Le NGPC considère que les décisions des experts identifiées présentent des circonstances exceptionnelles justifiant une action par le NGPC car chacune des décisions des experts dépassent les normes standards de ce qui est perçu comme raisonnable et juste. Alors que certains membres de la communauté peuvent identifier d'autres décisions comme incohérentes ou déraisonnables, les décisions des experts sur la SCO identifiées sont les seules que le NGPC a jugé approprié à un examen plus approfondi. Le NGPC note, cependant, qu'il a également identifié les décisions des experts sur l'objection relative aux chaînes prêtant à confusion pour .CAR/.CARS comme n'étant pas dans le meilleur intérêt du programme des nouveaux gTLD et de la communauté Internet. Néanmoins, étant donné que les parties concernées par l'ensemble conflictuel .CAR/.CARS ont récemment résolu leurs conflits de candidatures, le NGPC ne prend aucune mesure pour renvoyer ces décisions d'experts au CIRD pour une nouvelle évaluation et rendre ensuite une décision finale.

      3. Le NGPC a également pris en considération le fait de savoir s'il y avait une base suffisante pour déterminer l'existence de certaines incohérences perçues dans les décisions des experts, et en particulier savoir pourquoi les décisions identifiées devraient être renvoyées au CIRD alors que d'autres décisions ne devraient pas. Le NGPC note que bien qu'en apparence certaines des décisions des experts peuvent sembler incohérentes, y compris d'autres décisions, et des décisions de l'intérêt public limité et des processus d'objection de la part de la communauté, il y a des explications raisonnables pour ces divergences apparentes, à la fois au niveau de la procédure et au niveau substantiel.

        Tout d'abord, au niveau de la procédure, chaque panel d'experts repose sa décision sur des documents présentés par les parties concernées par l'objection, et l'objecteur apporte la charge de la preuve. Deux panels en confrontant les questions identiques, pourraient, et si nécessaire devraient, atteindre des décisions différentes, en se basant sur la force des documents présentés.

        Ensuite, au niveau substantiel, certaines décisions des experts soulignées par la communauté qui ont prétendument abouti à une « incohérence » ou « un caractère déraisonnable », ont présenté des distinctions nuancées concernant l'objection en particulier. Ces nuances ne devraient pas être ignorées simplement parce qu'une des parties au litige n'est pas d'accord avec le résultat final. De plus, la norme guidant le panel d'experts implique un certain degré de subjectivité, et pour cela, on ne s'attendrait pas à ce que des panels d'experts indépendants en arrivent à chaque fois aux mêmes conclusions. Cependant, pour les décisions identifiées, une explication raisonnable pour ces divergences apparentes n'est pas si évidente, même en prenant en compte toutes les explications précédentes à propos du : pourquoi des « divergences » raisonnables peuvent exister. Laisser ces décisions d'experts ne serait pas dans le meilleur intérêt de la communauté Internet.

      4. Le NGPC a pris considération le fait de savoir s'il était approprié, comme suggéré par certains commentaires, d'étendre la portée du mécanisme de révision proposé pour inclure d'autres décisions d'experts, comme certaines résultant de la communauté et des objections de public limitées, ainsi que d'autres décisions sur l'objection relative aux chaînes prêtant à confusion, et des possibles versions singulières ou plurielles d'une même chaîne. Le NGPC a déterminé que, promouvoir les objectifs de prévisibilité et d'équité, en établissant un mécanisme de révision plus large peut être plus approprié dans le cadre de futures discussions de la communauté à propos des prochaines séries du programme des nouveaux gTLD. Les candidats ont déjà pris des mesures en se fiant à de nombreuses décisions d'experts, y compris en signant des contrats de registre, en faisant une transition vers la délégation, en retirant leurs candidatures, et en demandant des remboursements. Permettre l'annulation de ces actions à l'heure actuelle ne ralentirait pas seulement la prise en considération de toutes les candidatures, mais augmenterait également les questions d'injustice pour ceux qui ont déjà agi en se fiant au guide de candidature.

        Il devrait également être noté qu'en réponse à l'avis du GAC, le NGPC a précédemment pris en considération la question de savoir si la confusion du client peut entrainer l'autorisation de versions singulières et plurielles de chaînes similaires. Le 25 juin 2013, le NGPC a adopté une résolution déterminant qu'« aucun changement [n'étaient] utiles aux mécanismes existants dans le guide de candidature pour répondre à la confusion éventuelle du client suite à l'autorisation de versions singulières et plurielles d'une même chaînes » http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-25jun13-en.htm#2.d. Le NGPC note à nouveau que le sujet de versions singulières et plurielles de certaines chaînes peut aussi être l'objet de plus de discussion au sein de la communauté étant donné qu'il est lié aux futures séries du programme des nouveaux gTLD.

      5. Le NGPC a pris en considération les courriers de la communauté sur cette question en plus des commentaires de la communauté exprimés lors des réunions de l'ICANN. Les inquiétudes soulevées dans les réunions de l'ICANN et par courrier ont été prises en compte dans les délibérations sur ce sujet.

      Le NGPC a remis à plus tard sa prise en considération des recommandations du BGC sur les demandes de reconsidération 13-9 et 13-10 en attendant la fin de la révision du NGPC sur les questions abordées ci-dessus. Maintenant que le NGPC a pris des mesures comme noté ci-dessus, il résumera dès que possible sa prise en compte des recommandations du BGC sur les demandes de reconsidération 13-9 et 13-10.

      Il y aura des impacts financiers directs sur l'ICANN liés à l'adoption de cette résolution puisque certaines procédures seront renvoyées au CIRD pour une nouvelle révision par un panel d'experts composé de trois membres. L'approbation de la résolution n'aura pas de conséquences sur les questions de sécurité, stabilité ou résilience en lien avec le système des noms de domaine.

      Prendre cette mesure est une action administrative et organisationnelle qui a été sujet à commentaire public. La synthèse des commentaires publics peut être consultée sur :https://www.icann.org/en/system/files/files/report-comments-sco-framework-principles-24apr14-en.pdf [PDF, 165 KB]).

    3. Demande de reconsidération 14-37, I-Registry Ltd.

      Attendu que, iRegistry Ltd. (« le demandeur ») a déposé la demande de reconsidération 14-37 demandant au comité du programme des nouveaux gTLD (« NGPC ») d'annuler les résolutions 2014.07.30.NG01 – 2014.07.30.NG04 (la « résolution ») « ou au moins d'amender » la résolution, et ensuite de mettre « en suspens » la décision de, comment répondre aux collisions de noms, jusqu'à ce que les questions soulevées par le demandeur « aient été résolues. »

      Attendu que le BGC a examiné les questions soulevées dans la demande de révision 14-37.

      Attendu que le BGC a recommandé que la demande de reconsidération soit rejetée au motif que le demandeur n'a pas présenté de motif de reconsidération valable, et que le NGPC approuve.

      Résolu (2014.10.12.NG04), le NGPC adopte la recommandation du BGC sur la demande de reconsidération 14-37, disponible sur : https://www.icann.org/en/system/files/files/recommendation-i-registry-04sep14-en.pdf [PDF, 150 KB].

      Fondements de la résolution 2014.10.12.NG04

      1. Bref récapitulatif

        iRegistry Ltd. (« le demandeur ») est un registre de noms de domaine qui conteste l'adoption par le NGPC du cadre de gestion de l'occurrence de collisions de noms de domaine (le « cadre »).

        Après avoir conduit diverses études indépendantes concernant la question de collision de nom, l'ICANN a mis en œuvre une période de consultation publique du 26 février 2014 au 21 avril 2014 pendant laquelle la communauté a donné des retours sur de possibles solutions pour la question de collision de nom, y compris la question de la mise en œuvre d'un cadre pour gérer et atténuer les collisions de noms. L'ICANN a reçu 28 commentaires, aucun venant du demandeur.2

        Après avoir pris en considération les commentaires publics reçus, les études détaillées analysant la question, et l'avis du pertinent comité consultatif de l'ICANN, le NGPC a approuvé les résolutions 2014.07.30.NG01 – 2014.07.30.NG04 (la « résolution »)3 le 30 juillet 2014, en adoptant le cadre. Le cadre énonce les procédures que les opérateurs de registre doivent suivre pour empêcher les collisions de noms de compromettre la sécurité ou la stabilité d'Internet.

        Le demandeur a déposé la demande immédiate (demande 14-37), en plaidant que le NGPC n'avait pas suffisamment impliqué le public dans sa décision d'adopter un cadre et en soutenant que le cadre allait entrainer une confusion parmi les titulaires de nom de domaine, une plus faible quantité d'enregistrements, et impacterait donc de manière financière le demandeur. Le BGC a pris en considération la demande 14-37 et a conclu que : (1) il n'y a pas de preuve que les actions du NGPC consistant en l'adoption de la résolution soutienne la reconsidération, (ii) le demandeur n'a pas démontré que le NGPC n'avait pas pris en considération certains documents d'information en adoptant la résolution ou que le NGPC s'est fondé sur des documents d'information faux ou imprécis en adoptant la résolution ; (iii) le demandeur n'a pas démontré qu'il avait été matériellement et négativement affecté par la résolution. Par conséquent, le BGC a recommandé le rejet de la demande de reconsidération 14-37 (la recommandation du BGC est évoquée dans le présent document comme si elle y était intégralement exposée). Le NGPC approuve.

      2. Résumé des faits de contexte pertinents

        Pour servir les valeurs fondamentales de l'ICANN visant à préserver et améliorer la stabilité, la fiabilité, la sécurité et l'interopérabilité mondiale d'Internet (statuts constitutifs, Art. 1, § 2.1), le comité consultatif sur la sécurité et la stabilité de l'ICANN (SSAC) a publié le SAC057 : Rapport consultatif du SSAC sur les certificats de noms internes le 15 mars 2013.4 Le rapport a identifié une autorité de certification (CA), une pratique qui, si largement exploitée, pourrait poser des risques quant à la vie privée et à l'intégrité des communications Internet sécurisées (collisions de noms). Le SSAC a conseillé à l'ICANN de prendre des mesures immédiates pour atténuer les risques. Les questions identifiées dans le SAC057 font partie de la catégorie plus générale des questions sur les collisions de noms. Par conséquent, le 18 mai 2013, le Conseil d’administration de l'ICANN a approuvé une résolution en demandant une étude en réponse à l'avis du SSAC dans le SAC057.5

        Le 5 août 2013, l'CANN a commandé une étude préparée par Interisle Consulting Group, sur la possibilité et sur les conséquences potentielles de la collision entre les étiquettes des nouveaux gTLD publics et les usages privés en cours de ces mêmes chaînes.6

        Le 7 octobre 2013, l'ICANN a introduit le plan de gestion de l'occurrence de collisions de noms des nouveaux gTLD (le « plan »), qui a permis l'utilisation d'une voie alternative de délégation.7 Dans le cadre de la résolution adoptant le plan, le NGPC a recommandé que le Conseil d’administration de l'ICANN « ordonne au président de l'ICANN et CEO de développer un plan à long terme pour gérer les risques de collisions de noms liés à la délégation des nouveaux TLD, et de travailler avec la communauté pour développer un plan à long terme pour conserver et mesurer les données de serveur racine.8

        En novembre 2013, l'ICANN a engagé JAS Globan Advisors LLC (JAS) pour mener le développement du cadre, en coopération avec la communauté.9

        Du 26 février 2014 au 21 avril 2014, l'ICANN a mis en place une période de consultation publique lors de laquelle la communauté a apporté des retours sur les solutions possibles à la question des collisions de noms, y compris la question de la mise en place d'un cadre pour gérer et atténuer les collisions de noms ; l'ICANN a reçu 28 commentaires, aucun d'eux ne provenait du demandeur.10 Le demandeur n'a pas participé au forum de commentaire public. Après la collecte des commentaires publics, JAS a publié la version finale du rapport de la phase un sur l'atténuation des risques de collisions dans l'espace de noms du DNS.11

        Le 6 juin 2014, le SSAC a publié SAC066 : Le Commentaire du SSAC sur le rapport de la phase un de JAS sur l'atténuation des risques de collision dans l'espace de noms du DNS, dans lequel il a exprimé son avis et ses recommandations au Conseil d'administration quant au cadre présenté dans l'étude JAS et le cadre sur les collisions de noms.12

        Le 27 juillet 2014, le demandeur a envoyé une lettre à l'ICANN : (i) demandant à l'ICANN d' « évaluer en détails » une proposition pour répondre au problème de collisions de noms ; et (ii) en donnant cinq propositions spécifiques quant à la manière de répondre à la question. (Demande, Ex. D.) L'ICANN a confirmé la réception de la lettre du demandeur le 29 juillet 2014. (Demande, Ex. E.)

        Le 30 juillet 2014, le NGPC a approuvé les résolutions 2014.07.30.NG01 – 2014.07.30.NG04 (la « résolution »), et a adopté le cadre. Le cadre énonce les procédures que les registres doivent suivre pour empêcher les collisions de noms de compromettre la sécurité ou la stabilité d'Internet et demande au « président et CEO, ou son (ses) représentant(s), de prendre les mesures nécessaires pour mettre en œuvre » le cadre.13

        Le 4 août 2014, la division des domaines mondiaux de l'ICANN a remis à chaque nouvel opérateur de registre gTLD une évaluation de l'occurrence de collisions de noms (l'« évaluation »), qui a identifié les mesures que doivent prendre les registres pour éviter les questions de collisions de noms, conformément au cadre.14 Ce même jour, le demandeur a reçu l'évaluation par e-mail. (Demande, Ex. A.)

        Le 12 août 2014, l'ICANN a présenté un séminaire web donnant un aperçu du cadre orienté en particulier sur les opérateurs de registre.15

        Le 13 août 2014, le demandeur a déposé la requête réclamant la reconsidération de la résolution du NGPC.

        Tandis que la manière de traiter une catégorie de noms affectée par la question de collision de nom ne fait pas encore partie du cadre, l'ICANN est en pleine phase de rassemblement des contributions du public sur ce sujet. Plus particulièrement, l'ICANN a ouvert un forum de commentaire public sur cette question particulière, qui aura lieu du 25 août 2014 au 7 octobre 2014.16

        Le 4 septembre 2014, le BGC a adressé ses recommandations concernant la demande de reconsidération 14-37.17 Le 11 septembre 2014, le demandeur a déposé une clarification sur la demande de reconsidération 14-3718 contenant plus de détails présumés concernant la manière dont le demandeur a été matériellement affecté par la résolution et l'adoption du cadre.

      3. Questions

        Les questions à reconsidérer concernent le fait de savoir si le NGPC :

        1. n'a pas pris en considération les documents de contribution de la communauté en approuvant la résolution (Demande, § 8, Pg. 11); et
        2. a sous-estimé les conséquences négatives éventuelles de la résolution. (Id., § 8, Pgs. 7-8.)
      4. Normes applicables pour l'évaluation des demandes de reconsidération

        En vertu des statuts constitutifs de l’ICANN, le BGC doit évaluer et, en cas de contestation des actions du Conseil d'administration (ou du NGPC), faire des recommandations relatives aux demandes de reconsidération au Conseil d'administration (ou au NGPC). Voir Chapitre IV, Article 2 des statuts constitutifs. Le NGPC, qui s'est vu investi des pouvoirs du Conseil d'administration en la matière, a examiné et pris en considération de façon minutieuse la recommandation du BGC concernant la demande de reconsidération 14-37 et conclut que l’analyse est correcte.19

      5. Analyse et fondements

        Le demandeur n'a pas démontré que le Conseil d’administration n'avait pas pris en considération les documents d'information ou qu'il s'était fié sur des documents faux ou imprécis en adoptant les résolutions ; par conséquent, la reconsidération n'est pas appropriée.

        1. La demande justifie un rejet sommaire.

          Le BGC a conclu, et le NGPC approuve, que l'argumentation du demandeur n'est pas valable car le demandeur « avait été avisé et avait l'opportunité de, mais ne l'a pas fait, participer à la période de consultation publique concernant l'action contestée. » (Statuts, Chapitre. IV, § 2.9.) En particulier, les statuts constitutifs de l'ICANN permettent au BGC de rejeter sommairement une demande de reconsidération si « le demandeur a été avisé et avait l'opportunité de, mais ne l'a pas fait, participer à la période de consultation publique concernant l'action contestée [.] » (Statuts, Chapitre. IV, § 2.9.)

          Du 26 février 2014 au 21 avril 2014, l'ICANN a mis en œuvre une période de consultation publique, qui fut annoncée sur le site de l'ICANN, et durant laquelle la communauté a apporté des retours sur les solutions possibles, y compris un cadre, aux questions de collisions.20 Le forum a généré 28 commentaires, mais le demandeur n'a pas participé au forum de commentaire public, et n'a pas donné de justification, d'excuse, ou d'explication quant au fait de s'être abstenu. La seule communication qu'il déclare avoir eu avec l'ICANN concernant les collisions de nom est la lettre datée du 27 juillet 2014 qui a été rédigée bien après la fin de la période de consultation publique.21 Étant donné que la période de consultation publique est incontestablement liée à la résolution, un rejet sommaire se justifie sur la base de la non-participation du demandeur. Cependant, par soucis de complétude, le NGPC va néanmoins traiter le bien-fondé de la demande.

        2. Le NGPC a pris en considération tous les documents d'information.

          Le BGC a conclu, et le NGPC approuve, que le demandeur n'a pas démontré que le NGPC avait omis de prendre en considération des documents d'information pertinents.

          De façon à présenter une base pour la reconsidération de l'action du Conseil d’administration, le demandeur doit démontrer que le Conseil (ou dans ce cas, le NGPC) avait omis de prendre en considération des documents d'information ou qu'il avait pris en considération des documents faux ou imprécis en adoptant la résolution. (Statuts, Chapitre. IV, § 2.2.) Le demandeur ne soutient pas que le NGPC a pris en considération des documents d'information faux ou imprécis, mais il déclare que le NGPC a omis de prendre en considération les documents d'information de deux manières. Premièrement, le demandeur déclare que le NGPC n'a pas suffisamment consulté le public avant d'adopter la résolution. Ensuite, le demandeur affirme que le NGPC a omis de prendre en considération la manière dont la résolution aurait des effets négatifs sur les registres et les utilisateurs Internet. Aucun de ces arguments ne résiste à l'examen, et aucun n'est un motif de reconsidération.

          1. Le NGPC a pris en considération les commentaires publics sollicités pendant une longue période de consultation publique.

            Le demandeur affirme que le NGPC a « omis de prendre en compte les contributions de la communauté ». (Demande, § 8, p. 11.) Contrairement aux affirmations du demandeur, le NGPC a bien pris en considération les retours reçus dans le « forum de commentaire public »22 ouvert du 26 février 2014 au 21 avril 2014. Le demandeur n'explique pas pourquoi lui n'a pas participé à ce forum. S'il avait participé, son point de vue aurait été inclus avec les 28 commentaires détaillés pris en considération qui ont été soumis par divers parties prenantes et membres du public, y compris d'autres registres.23 La période de consultation publique pour ce sujet a été en fait plus longue que prévu. En général, les périodes de consultation publique sont ouvertes pendant 21 jours, et si des commentaires sont reçus pendant cette période, il y a une période de réponse de 21 jours.24 Ici, la période de consultation publique a duré 33 jours et a été suivie par une période de réponse de 21 jours. De plus, l'ICANN a rendu possible une session publique entière sur la question des collisions de noms lors de la réunion de Londres le 23 juin 2014 et a donc donné une autre occasion d'apporter des commentaires et une participation publique ; le demandeur a à nouveau choisi de ne pas participer.25 En conséquence, le demandeur ne peut de manière raisonnable affirmer que le NGPC n'a pas pris en considération les contributions publiques avant d'avoir adopté la résolution. En résumé, le demandeur n'a pas soutenu de manière convaincante que le NGPC avait omis de prendre en considération des documents d'information dans le forum de commentaire public en adoptant la résolution, et n'a donc pas présenté de motifs de reconsidération valables. (Statuts, Chapitre. IV, § 2.2.)

          2. Le NGPC a pris en considération tous les documents d'information pertinents pour la résolution.

            Le demandeur cherche à obtenir la reconsidération de la résolution car il affirme que le NGPC « n'a pas correctement évalué les implications de la décision. » (Demande, § 8, p. 12.) Le demandeur fonde son affirmation sur le fait que les questions soulevées dans sa lettre du 27 juillet 2014 n'ont pas été expressément abordées dans l'article « Fondement » de la résolution. Cet argument n'est pas un élément de base pour la reconsidération pour deux raisons.

            Premièrement, la résolution prend bien en compte le contenu de l'information apportée dans la lettre du demandeur du 27 juillet 2014. La lettre du 27 juillet 2014 contenait cinq demandes, toutes en lien soit avec les « règles RPM » ou le point de vue du demandeur déclarant qu'un seul ensemble de règles communes devrait s'appliquer à tous les gTLD. (Demande, § 8, p. 10 & Ex. D.) Malgré que le demandeur prétende le contraire, les mêmes questions qui ont été soulevées dans la lettre du 27 juillet 2014 ont toutes été présentées au NGPC pendant la période de consultation publique par les autres parties prenantes et ont été traitées par le NGPC. La résolution reconnait que le NGPC a pris en considération les commentaires publics qui : (i) ont exprimé une inquiétude concernant « l'interaction entre les listes de blocage de collision de nom et les mécanismes de protections des droits sur la propriété intellectuelle »26» ; (ii) ont fait référence à la manière dont « la question de collision de nom créé un paysage concurrentiel inégal » ; et (iii) ont débattu des avantages et inconvénients du fait de traiter les opérateurs des nouveaux gTLD différemment des anciens opérateurs.27 De plus, l'ICANN a déjà déterminé que la question du RPM exige davantage de commentaires publics avant qu'une décision ne puisse être prise concernant la manière dont traiter cette question. En réalité, l'ICANN est actuellement en train de solliciter des commentaires, entre le 25 août et le 7 octobre 2014, quant à l'approche qui devrait être prise « concernant les mécanismes de protection des droits pour la libération de noms de liste de SLD bloqués. »28 En d'autres termes, il ne manquait aucun document d'information au NGPC quant aux questions applicables, en dépit de savoir s'il a expressément pris en considération la lettre du demandeur du 27 juillet 2014.

            Ensuite, le désaccord du demandeur avec le fondement du cadre ne peut pas servir de base correcte à la reconsidération. Le NGPC a pris en considération les études détaillées indépendantes traitant de la question des collisions de noms, y compris celle préparée par JAS et celle préparée par Interisle Consulting Group.29 De plus, le NGPC a pris en compte l'avis du SSAC avant d'adopter la résolution. La fonction du SSAC est de « conseiller la communauté et le Conseil d’administration de l’ICANN sur des sujets liés à la sécurité et à l'intégrité des systèmes de nommage et d’allocation d'adresses Internet. » (Statuts, Chapitre. XI, § 2.a) En résumé, le NGPC a pris en considération les commentaires publics, les rapports analytiques indépendants, et l'avis du comité consultatif pertinent de l'ICANN. Bien que le demandeur ait formulé une plainte déclarant que le NGPC « n'avait pas mentionné la lettre » (que le demandeur a envoyée des mois après la fin de la période de consultation publique) et qu'en conséquence « il n'a pas correctement traité les implications de la décision » pour approuver le cadre, ces allégations ne constituent pas une plainte sur le fait que le NGPC ait omis de prendre en considération tout document d'information. En conséquence, aucune reconsidération n'est justifiée.

            Enfin, le demandeur affirme également que la reconsidération est justifiée car « rien n'indique que le GAC30 a eu l'occasion d'apporter des retours » sur les rapports JAS ou l'avis du SSAC. (Demande § 7, Pg.7) Le GAC donne un « avis sur les activités de l’ICANN concernant les questions gouvernementales, en particulier en présence d’une interaction entre les politiques de l’ICANN et différentes lois et accords internationaux, ou susceptibles d’affecter les questions de politique publique. » (Statuts, Chapitre. XI, § 2.1.) Le fait que le GAC n'ait pas émis d'avis formel sur la manière dont l'ICANN devrait traiter les collisions de noms ne signifie pas que le NGPC ait omis de prendre en considération des documents d'information. Si le GAC avait émis un tel avis, le Conseil d’administration de l'ICANN l'aurait pris en considération, comme exigé selon les statuts constitutifs de l'ICANN. (Statuts, Chap. XI, §§ 2.1.i, 2.1.j.) De plus, en juillet 2013, le communiqué de Durban du GAC avait signalé que le Conseil d’administration « prend en considération en priorité les recommandations contenues dans le rapport du SSAC sur les domaines sans point (SAC053) et les certificats de noms internes (SAC057), » et cette dernière question de collision de noms.31 Le Conseil d’administration a bien pris en considération l'avis du SSAC, et ensuite a adopté le cadre.

            À nouveau, comme le demandeur ne montre pas que le NGPC a omis de prendre en considération des documents d'information en adoptant la résolution, la reconsidération n'est pas appropriée. (Statuts, Chapitre. IV, § 2.2.)

        3. Une confusion présumée ne sert pas de base à la reconsidération.

          Le BGC a conclu, et le NGPC approuve, que le demandeur n'a pas démontré que le NGPC avait omis de prendre connaissance des informations pertinentes concernant l'importance de sensibiliser le public à propos du cadre.

          Le demandeur se plaint que le NGPC a omis de prendre en considération le fait supposé que « la majorité globale » des titulaires de nom de domaine ne sont pas conscients du problème des collisions de noms et qu'ils seront donc « désorientés quant à la disponibilités des noms de domaine en général. » (Demande, § 7, p. 6.) Cependant, il est évident que le NGPC a pris en considération les informations concernant l'importance de sensibiliser le public sur le cadre. La résolution dédie une disposition entière (article B.6) aux « documents d'information » et demande à l'ICANN de « produire au besoin des documents d'information. . . . [et] de veiller à ce que ces informations soient mises à disposition des parties potentiellement affectées par les collisions de noms. »32 Même si le cadre a été récemment adopté, l'ICANN a déjà publié et donné une large variété de documents d'information, y compris des séminaires web orientés sur les opérateurs de registre, des livres et des vidéos pour les professionnels des technologies de l'information, et une page de « Questions fréquentes » concernant le cadre.33 De plus, l'ICANN a consacré des ressources pour s'assurer que les questions à propos de l'évaluation ou du cadre auront une réponse de manière rapide et précise. Autrement dit, loin d'avoir omis de prendre en considération le risque de confusion concernant la résolution, l'ICANN a pris des mesures pro actives et significatives pour s'assurer que les parties affectées saisissent le cadre et les étapes qu'elle demande.34 Aucune reconsidération n'est justifiée en se basant sur le fait que le NGPC n'a pas pris en considération des informations concernant la sensibilisation du public, étant donné qu'il est clair que le NGPC a bien pris en considération une telle information et qu'il a agi en utilisant les ressources éducatives mentionnées ci-dessus.

        4. Le demandeur n'a pas démontré qu'il a été matériellement affecté par la résolution.

          Le BGC a conclu, et le NGPC approuve, que le demandeur n'a pas démontré qu'il avait été matériellement et négativement affecté par la résolution.

          En l'absence de toute preuve que le demandeur a été matériellement et négativement affecté par la résolution, la reconsidération n'est pas appropriée. (Statuts, Chap. IV, §§ 2.1-2.2.) Ici, le demandeur affirme qu'il est matériellement affecté par la résolution pour deux raisons. (Demande, § 6, Pgs. 4-5.) Premièrement, il prétend que le cadre ne donne aucune orientation claire quant à la manière d'éviter les dommages liés aux collisions de noms. (Id., Pg. 5.) Ensuite, le demande prétend qu'il va subir une « baisse des taux d'enregistrement » à cause de la confusion que le cadre est censé causer, car le demandeur préjuge que les bureaux d'enregistrement ne vont pas « offrir des enregistrements de noms de domaine à partir des listes de collisions de noms. » (Id.) Aucune de ces inquiétudes ne s'est encore concrétisée, cependant, les deux sont de simples spéculations. 35 À nouveau, seules les personnes qui « ont été affectées de manière négative par » une mesure de l'ICANN peuvent déposer une demande de reconsidération (Statuts, Art. IV, § 2.2) (mise en gras ajoutée). Étant donné qu'à ce stade, le seul préjudice que le demandeur identifie est simplement spéculatif et hypothétique, la demande de reconsidération est prématurée.36

          Par conséquent, le demandeur n'a pas démontré qu'il a été matériellement affecté par la résolution et, sur cette seule base, la reconsidération de l'adoption de la résolution n'est pas justifiée.

      6. Décision

        Le NGPC a eu l'occasion d'étudier toutes les informations soumises par le demandeur ou en son nom, ou autrement liées à la demande 14-37. Après avoir examiné toutes les informations pertinentes présentées, le NGPC a étudié et adopté la recommandation du BGC sur la demande 14-37 https://www.icann.org/en/system/files/files/recommendation-i-registry-04sep14-en.pdf [PDF, 150 KB], qui doit être considérée comme faisant partie des présents fondements et est jointe aux documents de référence des conclusions du NGPC en la matière.

        L’adoption de la recommandation du BGC n’a aucun impact financier sur l’ICANN et n’aura pas d’impact négatif sur la sécurité systémique, la stabilité et la résilience du système des noms de domaine.

        Cette décision relève d'une fonction administrative organisationnelle qui ne nécessite pas de consultation publique.

    4. L'avis du GAC concernant les protections pour la Croix rouge et le Croissant rouge – Communiqué de Singapour

      Attendu que, le GAC s'est réuni lors de la réunion ICANN 49 à Singapour et a émis un Communiqué [PDF., 449 KB] le 27 mars 2014 ("Communiqué Singapour").

      Attendu que, dans le communiqué de Singapour le GAC a clarifié son précédent avis au Conseil d’administration de l'ICANN concernant le fait de protéger de manière permanente contre l'utilisation non-autorisée les termes associés à la Croix rouge internationale et au mouvement du Croissant rouge, et a conseillé que les protections devraient également inclure « les 189 sociétés nationales de la Croix rouge et du Croissant rouge, en anglais et dans les langues officielles de leurs États d'origine respectifs, » ainsi que les « noms complets du comité international de la Croix rouge et de la fédération internationale des sociétés de la Croix rouge et du Croissant rouge dans les six (6) langues des Nations-unies. » L'avis du GAC est identifié dans le registre d'avis du GAC sous le numéro 2014-03-27-RCRC.

      Attendu que, le GNSO a développé des recommandations politiques pour le Conseil d’administration concernant les noms de la Croix rouge et du Croissant rouge qui font l'objet du communiqué du GAC de Singapour. L'étendue des protections au sein des recommandations politiques du GNSO diffère de l'avis du GAC, et ce dernier, le GNSO, le Conseil d’administration, et la communauté de l’ICANN continuent de travailler activement pour résoudre ces différences.

      Attendu que le NGPC est responsable de la prise en considération de l'avis du GAC en vertu des pouvoirs qui lui ont été délégués par le Conseil d'administration en date du 10 avril 2012 pour exercer l'autorité du Conseil d'administration pour toutes les questions relatives au programme des nouveaux gTLD.

      Résolu (2014.10.12.NG05), le président et CEO, ou son (ses) représentant(s), est chargé d'offrir des protections temporaires pour les noms du comité international de la Croix rouge et de la fédération internationale des sociétés de la Croix rouge et du Croissant rouge, et les 189 sociétés nationales de la Croix rouge et du Croissant rouge, comme identifiées dans le registre d'avis du GAC sous le numéro 2014-03-27-RCRC alors que le GAC, le GNSO, le Conseil d’administration, et la communauté de l’ICANN continuent de travailler activement pour résoudre les différences entre l'avis du GAC et les recommandations politiques du GNSO sur l'étendue des protections pour les noms RCRC.

      Fondements de la résolution 2014.10.12.NG05

      Le NGPC prend des mesures pour apporter des protections temporaires pour les noms RCRC (Croix Rouge-Croissant rouge), identifiées dans l'avis du GAC dans le communiqué de Singapour, tout en étant attentif aux discussions non résolues parmi le GAC, le GNSO, le Conseil d’administration, et la communauté de l’ICANN pour travailler de manière active à la résolution des différences entre l'avis du GAC et les recommandations politiques du GNSO sur l'étendue des protections pour les noms RCRC.

      Section XI, Chapitre 2.1 des statuts constitutifs de l'ICANN permet au GAC de « soumettre directement des questions au Conseil, soit par la voie d'un commentaire, soit par un avis préalable, ou encore en recommandant une action spécifique ou le développement d'une nouvelle politique ou la révision des politiques actuelles ». Le GAC a présenté au Conseil d'administration son avis sur le programme des nouveaux gTLD par le biais de son communiqué de Singapour daté du 27 mars 2013 (« Communiqué de Singapour »). Les statuts de l'ICANN prévoient que le Conseil d'administration tienne compte de l'avis du GAC en matière de politique publique pour la formulation et l'adoption de politiques. Au cas où le Conseil d'administration déciderait d’agir contrairement à l’avis du GAC, il est tenu d'en avertir ce dernier en indiquant ses motivations. Le Conseil d'administration et le GAC tenteront ensuite, en toute bonne foi, de trouver une solution réciproquement acceptable. Si aucune solution n'est trouvée, le Conseil d'administration doit donner dans sa décision finale les raisons qui l'ont amené à ne pas suivre l'avis du GAC.

      Dans le communiqué de Singapour le GAC a clarifié son précédent avis au Conseil d’administration de l'ICANN concernant le fait de protéger de manière permanente contre l'utilisation non-autorisée les termes associés au mouvement international de la Croix rouge et du Croissant rouge, et a conseillé que les protections devraient également inclure « les 189 sociétés nationales de la Croix rouge et du Croissant rouge, en anglais et dans les langues officielles de leurs États d'origine respectifs, » ainsi que les « noms complets du comité international de la Croix rouge et de la fédération internationale des sociétés de la Croix rouge et du Croissant rouge dans les six (6) langues des Nations-unies. »

      Le GNSO a également apporté des recommandations politiques au Conseil d’administration de l'ICANN sur ces mêmes noms RCRC qui font l'objet de l'avis du GAC dans le communiqué de Singapour. Contrairement à l'avis du GAC, les recommandations de politique du GNSO ne prévoient pas de protections permanentes pour l'ensemble des noms du RCRC. À la place, la politique du GNSO recommande que ces noms soient protégés en les faisant entrer dans le TMCH pour une notification de réclamation de 90 jours.

      Le 30 avril 2014, le Conseil d’administration de l'ICANN a adopté les recommandations politiques du conseil de la GNSO sur les protections OIG-OING qui n'étaient pas incohérentes avec l'avis du GAC, et a demandé du temps supplémentaire pour prendre en considération les politiques de recommandations restantes qui sont incohérentes avec l'avis du GAC sur le même sujet. Le Conseil d’administration s'est engagé à faciliter les discussions parmi les parties pertinentes pour concilier toutes les différences restantes entre les recommandations politiques et l'avis du GAC sur ce sujet, et a auparavant chargé le NGPC d'aider à ce processus. Le NGPC prend des mesures pour apporter des protections temporaires pour les noms RCRC identifiées dans l'avis du GAC dans le communiqué de Singapour, tout en étant attentif aux discussions non résolues parmi le GAC, le GNSO, le Conseil d’administration, et la communauté de l’ICANN pour travailler de manière active à la résolution des différences entre l'avis du GAC et les recommandations politiques du GNSO sur l'étendue des protections pour les noms RCRC.

      L'action du NGPC aura un impact positif sur la communauté étant donné qu'il va permettre des protections temporaires pour les noms RCRC, tout en autorisant la poursuite des discussions. Dans le cadre de ses délibérations, le NGPC a passé en revue les documents suivants :

      Aucun impact fiscal associé à l'adoption de cette résolution n'est prévu. L'approbation de la résolution proposée n'aura pas d'impact sur la sécurité, la stabilité ou la résilience du DNS. Il ne s'agit pas 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 commentaire du public. Des mesures ultérieures liées aux protections des noms RCRC peuvent faire l'objet de commentaire public.

    5. Divers

      Aucune résolution adoptée.

Published on 14 October 2014


1 Traduction japonaise de « achat en-ligne »

2 Voir Rapport de commentaire public, disponible sur https://www.icann.org/en/system/files/files/report-comments-name-collision-10jun14-en.pdf [PDF, 229 KB].

3 Voir Résolution, disponible sur https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-07-30-en.

4 Voir https://www.icann.org/en/system/files/files/sac-057-en.pdf [PDF,1.13 MB].

5 Voir https://features.icann.org/ssac-advisory-internal-name-certificates.

6 Voir Répondre aux conséquences des collisions de noms, disponible sur https://www.icann.org/news/announcement-3-2013-08-05-en.

7 Voir Questions fréquentes sur le plan de gestion de l'occurrence de collisions de noms des nouveaux gTLD, disponible sur https://www.icann.org/news/announcement-2013-12-03-en.

8 Voir https://www.icann.org/resources/board-material/resolutions-new-gtld-2013-10-07-en#1.a.

9 Voir https://www.icann.org/resources/pages/name-collision-2013-12-06-en.

10 Voir Rapport de commentaire public, disponible sur https://www.icann.org/en/system/files/files/report-comments-name-collision-10jun14-en.pdf [PDF, 229 KB].

11 Voir rapport JAS, disponible sur https://www.icann.org/en/system/files/files/name-collision-mitigation-study-06jun14-en.pdf [PDF, 391 KB].

12 Voir https://www.icann.org/en/system/files/files/sac-066-en.pdf [PDF, 305 KB].

13 Voir Résolution, disponible sur https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-07-30-en.

14 Voir l'évaluation de l'occurrence de collisions de noms, disponible sur http://newgtlds.icann.org/sites/default/files/agreements/name-collision-assessment-04aug14-en.pdf [PDF, 91 KB].

15 Voir https://www.icann.org/resources/pages/name-collision-2013-12-06-en.

16 Voirmise en place de mécanismes de protection de droits dans le cadre de l'atténuation des collisions de noms disponible sur https://www.icann.org/public-comments/name-collision-rpm-2014-08-25-en.

17 https://www.icann.org/en/system/files/files/recommendation-i-registry-04sep14-en.pdf [PDF, 150 KB]

18 https://www.icann.org/en/system/files/files/clarification-i-registry-11sep14-en.pdf [PDF, 59 KB]

19 L'existence d'un processus de reconsidération permettant au BGC d'examiner une question et, s'il le souhaite, de soumettre une recommandation pour approbation au Conseil d'administration/NGPC a des effets positifs en matière de transparence et de responsabilité de l’ICANN. Cette approche permet à la communauté de s’assurer que le personnel et le Conseil agissent dans le respect des politiques, des Règlements et des Statuts constitutifs de l'ICANN.

20 Voir Rapport de commentaire public, disponible sur https://www.icann.org/en/system/files/files/report-comments-name-collision-10jun14-en.pdf [PDF, 229 KB].

21 Le demandeur déclare qu'il a envoyé une lettre au NGPC « bien avant » la réunion du NGPC, mais cette déclaration est fausse étant donné qu'il y a seulement trois jours entre la date de la lettre et la réunion du NGPC du 30 juillet 2014. Voir Demande, § 8, p. 9.

22 Voir Résolution, disponible sur https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf [PDF, 634 KB].

23 Voir Rapport sur les commentaires publics, disponible sur https://www.icann.org/en/system/files/files/report-comments-name-collision-10jun14-en.pdf [PDF, 229 KB].

24 Voir https://www.icann.org/resources/pages/how-2014-03-17-en

25 Voir Présentation de Londres sur la collision de nom ICANN 50, disponible sur https://london50.icann.org/en/schedule/mon-name-collision/presentation-name-collision-23jun14-en.

26 Voir Résolution, disponible sur https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf [PDF, 634 KB].

27 Voir Rapport de commentaire public, Pg. 11, disponible sur https://www.icann.org/en/system/files/files/report-comments-name-collision-10jun14-en.pdf [PDF, 229 KB].

28 Voir mise en place de mécanismes de protection de droits dans le cadre de l'atténuation des collisions de noms disponible sur https://www.icann.org/public-comments/name-collision-rpm-2014-08-25-en

29 Voir Résolution, disponible sur https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-07-30-en.

30 Comité consultatif gouvernemental.

31 Voir Communiqué du GAC émis lors de l'ICANN 47, disponible sur https://www.icann.org/news/announcement-2013-07-18-en; SAC057, disponible sur https://www.icann.org/en/system/files/files/sac-057-en.pdf [PDF, 1.13 KB].

32 Voir Résolution, disponible sur https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf [PDF, 634 KB].

33 Voir Ressources & information sur la collision de noms, disponible sur https://www.icann.org/resources/pages/name-collision-2013-12-06-en.

34 L'ICANN s'est également engagée dans des activités de sensibilisation significatives sur LinkedIn et via divers types de médias, ainsi qu'en lançant une publicité Google Adwords.

35 En réalité, le cadre va permettre aux noms d'être activés dans le DNS alors qu'ils ne l'étaient pas avant. En conséquence, le cadre pourrait bien mener à une augmentation des enregistrements.

36 Le 11 septembre 2014, après que le BGC ait émis sa recommandation, le demandeur a déposé une clarification à la demande de reconsidération 14-37, soi-disant en donnant des détails supplémentaires concernant la manière dont le demandeur a été matériellement et négativement affecté par la résolution. Malgré qu'il prétende le contraire, les allégations continues du demandeur quant à un préjudice potentiel sont toujours spéculatives et hypothétiques.

resolutions-new-gtld-12oct14-fr.pdf  [430 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."