Résolutions du Conseil d’administration approuvées | Réunion ordinaire du Conseil d’administration de l’ICANN 14 mars 2019

  1. Ordre du jour approuvé :
    1. Approbation du procès-verbal
    2. Approbation de l’amendement visant à mettre en œuvre le service de registre demandé par Verisign afin d’ouvrir à l’enregistrement le nom de domaine de second niveau avec un seul caractère O.COM
    3. Report de l’application de la mise en œuvre de la politique relative au WHOIS détaillé
    4. Nomination des auditeurs indépendants pour l’exercice fiscal 2019
    5. Acceptation des révisions de la charte du Comité chargé de l’efficacité organisationnelle
    6. Nomination des représentants de l’Organisation des opérateurs de serveur racine auprès du RSSAC
    7. Approbation de l’amendement du contrat des fonctions IANA relatives au nommage
    8. Remerciements à l’attention des hôtes locaux de la 64e réunion de l’ICANN
    9. Remerciements à l'attention des sponsors de la 64e réunion de l’ICANN
    10. Remerciements à l'attention des interprètes, du personnel, des organisateurs et des équipes de l’hôtel de la 64e réunion de l’ICANN
  2. Ordre du jour principal :
    1. Recommandations pour la gestion des variantes de TLD IDN
    2. Préparation à la mise en œuvre des séries ultérieures de nouveaux gTLD
    3. Transfert du domaine de premier niveau .VU (Vanuatu) à l’Autorité de régulation des télécommunications, des radiocommunications et des contenus audiovisuels (TRBR)
    4. Examen de la demande de réexamen 16-5 : DotMusic Limited
    5. Examen de .AMAZON
    6. Acceptation de la seconde révision organisationnelle du NomCom – Rapport final et recommandations
    7. Prochaines étapes concernant la composition de l’équipe chargée de la révision des fonctions IANA relatives au nommage
    8. Divers
      1. Projet d’analyse de la collision de noms – Première étude

  1. Ordre du jour approuvé :

    1. Approbation du procès-verbal

      Il est résolu (2019.03.14.01) que le Conseil d’administration approuve les procès-verbaux de la réunion extraordinaire du Conseil d’administration de l’ICANN du 16 janvier 2019 et de la réunion ordinaire du Conseil d’administration de l’ICANN du 27 janvier 2019.

    2. Approbation de l’amendement visant à mettre en œuvre le service de registre demandé par Verisign afin d’ouvrir à l’enregistrement le nom de domaine de second niveau avec un seul caractère O.COM

      Attendu que, l’organisation ICANN a évalué la proposition d’amendement du contrat de registre .COM de Verisign en tant que service de registre conformément aux exigences prévues aux sections 3.1(d)(iii) et 3.1(d)(iv) du contrat de registre .COM et, dans le respect de la politique d’évaluation des services de registre, l’organisation ICANN n’a relevé aucun problème significatif de sécurité ou stabilité et a publié la proposition d’amendement à des fins de consultation publique.

      Attendu que, l’organisation ICANN a estimé que le service de registre proposé pourrait poser d’importants problèmes en matière de concurrence et a renvoyé cette question au département de la justice des États-Unis, et la division antitrust du département de la justice des États-Unis a fait savoir à l’organisation ICANN qu’elle ne souhaitait pas ouvrir une enquête à ce sujet.

      Attendu que, l’organisation ICANN a lancé une période de consultation publique du 10 mai 2018 au 20 juin 2018 sur la proposition d’amendement visant à mettre en œuvre le service de registre approuvé demandé par Verisign afin d’ouvrir à l’enregistrement le nom de domaine avec un seul caractère O.COM, et un résumé et une analyse des commentaires ont été transmis au Conseil d’administration.

      Attendu que, la proposition d’ouverture à l’enregistrement du nom de domaine avec un seul caractère O.COM serait compatible avec la recommandation du Groupe de travail sur les noms réservés de la GNSO.

      Attendu que, le Conseil d’administration de l’ICANN a pris en considération les commentaires publics reçus et le résumé et l'analyse des commentaires par l’organisation ICANN.

      Attendu que, le Conseil d’administration de l'ICANN est arrivé à la conclusion que la proposition d’amendement visant à ouvrir à l’enregistrement le nom de domaine avec un seul caractère O.COM est limitée aux circonstances particulières de ce nom de domaine, et l’approbation de l’amendement ne crée pas de précédent s’appliquant à d’autres circonstances.

      Il est résolu (2019.03.14.02) que l'amendement du contrat de registre .COM visant à ouvrir à l’enregistrement le nom de domaine avec un seul caractère O.COM dans l’espace des noms .COM est approuvé, et le président-directeur général, ou son ou ses représentants, sont autorisés à prendre les décisions s’imposant afin de mettre en œuvre ledit amendement.

      Fondements de la résolution 2019.03.14.02

      Pourquoi le Conseil d’administration aborde-t-il cette question maintenant ?

      En novembre 2017, Verisign a soumis une demande de service de registre afin de mettre à l’essai l’ouverture à l’enregistrement d’un nom de domaine O.COM via des enchères, et d’affecter les recettes provenant des enchères à des domaines d’intérêt public pour la communauté Internet, dans le respect du cadre d’attribution des noms de domaine de second niveau avec un seul caractère (SCSLD) de l’organisation ICANN.

      L’organisation ICANN a passé en revue le service de registre proposé et n’a relevé aucun problème significatif de sécurité ou stabilité. Toutefois, l’organisation ICANN a estimé que le service de registre proposé pourrait poser d’importants problèmes en matière de concurrence. Le 7 décembre 2017, l’organisation ICANN a renvoyé cette question au département de la justice des États-Unis. Le 14 décembre 2017, la division antitrust du département de la justice des États-Unis a fait savoir à l’organisation ICANN qu’elle ne souhaitait pas ouvrir une enquête à ce sujet.

      Suite à une décision préliminaire approuvant le service de registre proposé, l’organisation ICANN a publié la proposition d’amendement du contrat de registre .COM visant à permettre la mise en d'œuvre du service à des fins de consultation publique du 10 mai 2018 au 20 juin 2018.

      La proposition d’amendement tient compte de l’analyse et des recommandations relatives aux noms de domaine avec un seul caractère du Groupe de travail sur les noms réservés de la GNSO, du Conseil de la GNSO et de l’organisation ICANN ainsi que des retours de la communauté, et elle est conforme à l’approbation par le Conseil d’administration de l'ICANN de l’ouverture à l’enregistrement de noms de domaine avec un seul caractère dans d’autres domaines génériques de premier niveau historiques (gTLD). À ce jour, le Conseil d'administration de l'ICANN a approuvé l’ouverture à l’enregistrement de noms de domaine avec un seul caractère dans bien d’autres gTLD historiques dont .ORG, .BIZ, .INFO, .MOBI et .PRO. De plus, il n’est pas requis que les noms de domaine avec un seul caractère soient réservés aux gTLD introduits dans le cadre du programme des nouveaux gTLD.

      L’organisation ICANN a pris des mesures afin d’évaluer et d’examiner la proposition d’amendement et les retours de la communauté, et cette proposition et ces retours ont été transmis au Conseil d'administration de l'ICANN afin qu’il les examine et en tienne compte avant de prendre une décision.

      Quelle est la proposition à l’étude ?

      En vertu de la proposition d’amendement, le nom de domaine avec un seul caractère O.COM sera attribué via un processus d’enchère et géré par un prestataire de services tiers. Verisign ne percevra pas, directement ou indirectement, les recettes issues de la vente, de l’attribution, du transfert ou du renouvellement de O.COM et ne percevra que les frais de registre standard pour l’enregistrement de O.COM, soit 7,85 USD. Les recettes provenant des enchères de O.COM seront remises à une ou plusieurs organisations à but non lucratif, ou à leurs successeurs, œuvrant dans des domaines d'intérêt public pour la communauté Internet. Aucune des recettes provenant des enchères ne sera utilisée directement ou indirectement au profit de Verisign, de ses sociétés affiliées, ou de ses administrateurs, dirigeants ou employés. Tout titulaire de nom de domaine potentiel peut participer au processus d’enchère et sélectionner un bureau d'enregistrement accrédité par l'ICANN pour la gestion de l’enregistrement de O.COM si le nom de domaine lui a été attribué. Aucune restriction ne sera imposée quant à la manière dont le titulaire de nom de domaine peut sélectionner un bureau d'enregistrement accrédité par l'ICANN .COM.

      Le titulaire de nom de domaine gagnant doit : (i) envoyer l’intégralité du montant de l’enchère gagnante dans un délai de quatorze (14) jours à compter de la date à laquelle il a été déterminé qu’il avait remporté l’enchère, et (ii) s’engager à soumettre à la caisse cinq pour cent (5 %) du premier versement de l’enchère gagnante pour chaque année où le nom de domaine est renouvelé après expiration de la période d’enregistrement initiale de cinq (5) ans (individuellement un « Versement ultérieur »), et ce jusqu’à la vingt-cinquième (25e) année comprise où le titulaire de nom de domaine gagnant renouvelle le nom de domaine avec un seul caractère. Les versements ultérieurs visent à encourager un mécanisme de financement continu au profit de la ou des organisations à but non lucratif jusqu’à expiration du versement ultérieur. À titre d’exemple, si l’enchère se tient en 2020 et que l’enchère gagnante s’élève à 10 000 USD, le premier versement de l’enchère gagnante pour le nom de domaine avec un seul caractère s’élèvera à 10 000 USD et sera effectué en 2020, et le versement ultérieur annuel après la période initiale de cinq (5) ans s’élèvera à 500 USD et sera effectué de 2026 à 2045 (c’est-à-dire 5 % du premier versement de l’enchère gagnante).

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

      Du 11 mai 2018 au 20 juin 2018, l’organisation ICANN a mené un processus de consultation publique sur la proposition d’amendement. La proposition a reçu vingt-neuf (29) commentaires de vingt-quatre (24) entités distinctes.

      Quelles sont les inquiétudes ou questions soulevées par la communauté ?

      De manière générale, les commentaires soumis peuvent être classés dans les catégories suivantes, chaque catégorie étant expliquée plus en détail ci-dessous :

      1. Soutien à la proposition d’amendement visant à ouvrir à l’enregistrement O.COM.
      2. Craintes quant au fait que l’ouverture à l’enregistrement de O.COM pourrait poser des problèmes de sécurité et de stabilité.
      3. Craintes quant au fait que les exigences proposées pour la mise à l’essai de l’ouverture à l’enregistrement de O.COM pourraient créer un précédent pour l’ouverture à l’enregistrement de futurs noms de domaine avec un seul caractère .COM ou pour l’ensemble de l’espace des noms .COM.
      4. Craintes quant au fait que les « Versements ultérieurs » proposés effectués par le titulaire de nom de domaine afin de renouveler O.COM puissent être un moyen pour Verisign d’augmenter les frais de renouvellement pour l’ensemble de l’espace des noms .COM.
      5. Craintes quant à la proposition de restriction des transferts pour le nom de domaine O.COM imposée par Verisign une fois le nom attribué.
      6. Craintes concernant le manque de protection de certains droits avec l’ouverture à l’enregistrement de O.COM dans la proposition d’amendement.
      7. Craintes quant au fait que le fournisseur de services d’enchère n’impose des exigences relatives au processus d’enchère et à la présélection comme cela a été proposé par Verisign pour l’ouverture à l’enregistrement de O.COM et quant au manque de transparence du processus.
      8. Suggestions concernant la proposition de répartition des fonds suite à l’enchère de O.COM comme proposé dans l’amendement.

      Plusieurs personnes ont donné des retours positifs quant à l’ouverture à l’enregistrement de noms de domaine avec un seul caractère .COM et la proposition d’utiliser les recettes provenant des enchères afin de renforcer l’intérêt général en matière d’Internet et ont formulé des suggestions quant à la manière d’utiliser les recettes. Un des thèmes récurrents des commentaires est le besoin de transparence tout au long du processus d’enchère, de la sélection du fournisseur de services d’enchère à la proposition de processus de gestion de l’ouverture à l’enregistrement du nom de domaine.

      Deux personnes ont fait savoir que O.COM pourrait poser des problèmes de sécurité et de stabilité au sein de l’espace des noms .COM si on permettait son enregistrement. En outre, des personnes ont fait part de leurs craintes quant à l’approche proposée par Verisign pour l’enchère et l’ouverture à l’enregistrement du nom de domaine O.COM. Elles estiment que les exigences proposées pour O.COM sont incompatibles avec la façon dont les noms de domaine .COM actuels sont enregistrés et renouvelés. Et elles ont soulevé le manque de protection de certains droits avec l’ouverture à l’enregistrement de O.COM.

      Les problèmes de sécurité et stabilité soulevés lors de la période de consultation publique portaient sur le risque de « confusion associée à un script » avec l'ouverture à l’enregistrement du nom de domaine avec un seul caractère O.COM dans le script latin étant donné que les versions en script grec et cyrillique de O.COM existent dans l’espace des noms .COM. Après une évaluation interne, il a été déterminé que le risque n’est pas plus élevé qu’avec d’autres noms de domaine avec un seul caractère déjà ouverts à l’enregistrement dans d’autres TLD.

      Plusieurs commentaires ont fait part de craintes quant au fait que les exigences proposées pour l’ouverture à l’enregistrement de O.COM pourraient créer un précédent pour l’ouverture à l’enregistrement de futurs noms de domaine avec un seul caractère .COM ou pour l’ensemble de l’espace des noms .COM. Plus précisément, des personnes ont laissé entendre que le versement ultérieur proposé par Verisign effectué par le titulaire de nom de domaine afin de renouveler O.COM permettrait à Verisign d’introduire des frais ou frais de renouvellement supérieurs pour d’autres futurs noms de domaine avec un seul caractère lancés dans l’espace des noms .COM ou pour tous les noms de domaine .COM. L’organisation ICANN met en avant la RSEP proposée par Verisign et la proposition d’amendement du contrat de registre .COM, assure que Verisign ne percevra que les frais de registre standard pour l’enregistrement initial de O.COM et tous les renouvellements ultérieurs, ce qui est conforme aux dispositions de la section 7.3(d) du contrat de registre .COM relatives à la détermination du montant des frais de registre. À compter de la date de soumission de la proposition, ces frais de registre, définis comme le prix maximum dans le contrat de registre .COM, s’élèvent à 7,85 USD. Les seuls frais de renouvellement que Verisign percevra sont les frais de renouvellement standard au moment du renouvellement. Le versement ultérieur que le titulaire de nom de domaine gagnant est tenu d’effectuer vise à « encourager un mécanisme de financement continu au profit de la ou des organisations à but non lucratif jusqu’à expiration du versement ultérieur ».

      Les commentaires font également part de craintes quant à la restriction des transferts pour le nom de domaine O.COM proposée par Verisign une fois le nom attribué, cela pouvant entraîner des complications inutiles au sein de l’espace des noms .COM. De plus, si cette restriction est permise, certaines personnes craignent que Verisign n’étende la restriction aux futurs noms de domaine avec un seul caractère .COM ouverts à l’enregistrement. Selon les commentaires, en raison de la rareté des noms avec un seul caractère dans le précieux espace des noms .COM, le titulaire de nom de domaine gagnant pourrait être autorisé à utiliser le ou les noms de son choix. Après examen des commentaires publics, Verisign a volontairement supprimé de la proposition d’amendement la proposition de restriction des transferts de titulaire de nom de domaine à titulaire de nom de domaine.

      D’autres craintes ont été soulevées quant à l’absence de certains mécanismes de protection des droits (RPM) avec l’ouverture à l’enregistrement de O.COM et aux éventuels problèmes de sécurité et stabilité une fois O.COM ajouté à l’espace des noms .COM. Toutefois, en vertu du contrat de registre .COM, rien n’exige de proposer une période d'enregistrement prioritaire avant l’ouverture à l’enregistrement des noms réservés. De plus, les demandes de RSEP soumises puis approuvées par le Conseil d’administration pour .BIZ (2008), .INFO (2010) et .ORG (2011), qui visaient à ouvrir à l’enregistrement les noms réservés avec un seul caractère et deux caractères, ne prévoyaient pas de période d'enregistrement prioritaire. La politique uniforme de règlement de litiges relatifs aux noms de domaine s’applique à tous litiges portant sur des marques déposées découlant de l’attribution d’un nom dans l’espace des noms .COM, dont O.COM.

      Quels sont les principaux documents examinés par le Conseil d’administration ?

      Dans le cadre de ses délibérations, le Conseil d’administration a examiné plusieurs documents, y compris, mais sans s’y limiter, les documents et supports suivants :

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

      Le Conseil d’administration a examiné avec attention les commentaires publics reçus pour l’amendement visant à mettre en œuvre le service de registre demandé par Verisign afin d’ouvrir à l’enregistrement le nom de domaine avec un seul caractère O.COM, ainsi que le résumé et l’analyse de ces commentaires. Le Conseil d’administration a également examiné les termes convenus par l’opérateur de registre dans le cadre des négociations bilatérales avec l’organisation ICANN.

      Le Conseil d’administration salue le temps consacré par la communauté à examiner la proposition d’amendement visant à ouvrir à l’enregistrement O.COM. De plus, le Conseil d’administration a fondé son appréciation sur l’engagement et les feedbacks de la communauté qui a formulé des suggestions intéressantes soutenant l’approche proposée par Verisign visant à utiliser les recettes provenant des enchères de O.COM à des fins d’intérêt public pour la communauté Internet.

      Le Conseil d’administration prend également note des craintes exprimées par certains membres de la communauté eu égard au risque de « confusion associée à un script » avec l'ouverture à l’enregistrement du nom de domaine avec un seul caractère O.COM et à la mesure dans laquelle le nom de domaine avec un seul caractère pourrait constituer une atteinte à la sécurité et la stabilité. Toutefois, le Conseil d’administration prend acte que d’autres noms de domaine avec un seul caractère dans les nouveaux gTLD et les gTLD historiques sont aujourd’hui disponibles, et que les travaux se poursuivent au sein de la communauté afin d’atténuer les éventuels problèmes de sécurité et stabilité liés au risque de confusion associée à un script. Ces travaux comprennent la proposition de version préliminaire finale de la version 4.0 des directives relatives à la mise en œuvre des noms de domaine internationalisés (directives relatives aux IDN v4) publiée par le Groupe de travail sur les directives relatives aux IDN (IDNGWG) qui recommande des pratiques visant à minimiser le risque de cybersquattage et de confusion des consommateurs. Le Conseil d’administration note que la version préliminaire des directives relatives aux IDN v4 « encourage les registres de TLD à appliquer des limites supplémentaires aux enregistrements afin de minimiser le risque de confusion associée au script… » mais n’impose pas de mesures d’atténuation spécifiques, et que ces directives relatives aux IDN v4 n’ont pas encore été adoptées par le Conseil d’administration. L’organisation ICANN a pour pratique de respecter les politiques et procédures existantes et d’appliquer les exigences prévues par des recommandations communautaires en cours uniquement après leur adoption et mise en œuvre. Récemment, lors de l’atelier de Genval en septembre 2018, le Conseil d’administration a discuté de la manière dont l'organisation ICANN devrait examiner les demandes des parties contractantes, alors que les travaux en cours de la communauté pourraient entraîner un changement de processus susceptible d’avoir un impact sur la demande.

      Le Conseil d’administration prend également acte des craintes soulevées par la communauté quant au fait que certains aspects de la proposition d'ouverture à l’enregistrement de O.COM via le processus d’enchère mis à l’essai présentent des exigences différentes que pour d’autres noms de domaine dans l’espace des noms .COM et pourraient avoir un impact sur d’autres noms de domaine dans l’espace des noms .COM à présent et à l’avenir. Le Conseil d’administration tient compte des craintes soulevées par la communauté et reconnaît en outre l’approche de Verisign visant à ouvrir à l’enregistrement O.COM via un processus mis à l’essai permettant à Verisign et à de potentiels titulaires de noms de domaine d’acquérir de précieuses informations sur le processus. Comme indiqué, le service proposé n’aurait pas d'impact sur les fonctions, méthodes, fixations des prix, procédures ou spécifications existantes pour l’enregistrement de tout autre nom de domaine dans l’espace des noms .COM. De plus, Verisign est tenue de respecter les conditions du contrat de registre .COM et l’ouverture à l’enregistrement de O.COM ne remettra pas en cause ces engagements. Le Conseil d’administration prend également note de la mise à jour de la proposition d’amendement effectuée par Verisign afin de supprimer la restriction des transferts en réponse aux craintes exprimées par la communauté.

      Le Conseil d’administration prend aussi note des craintes soulevées eu égard à l’ensemble du processus d’enchère dans la proposition d’amendement et retient que le processus d’enchère proposé ressemble à la façon dont la plupart des opérateurs de registre gèrent et ont géré les enchères de noms de domaine. En outre, les opérateurs de registre pour les TLD historiques tels que .BIZ, .INFO et .ORG ont eu recours à des processus similaires pour la vente aux enchères de leurs TLD avec un seul ou deux caractères. Tous les opérateurs de registre, historiques ou gTLD, peuvent définir et organiser des enchères sans contrôle ou restriction de leur TLD et divulguent rarement à l’avance les informations relatives à l’enchère ou les frais à s’acquitter auprès du fournisseur de services d’enchère.

      Le Conseil d’administration prend aussi acte des craintes soulevées quant au plan proposé par Verisign visant à ouvrir à l’enregistrement O.COM sans les RPM que les opérateurs de registre des nouveaux gTLD sont tenus de mettre en place pour leurs TLD. Les commentaires laissaient entendre qu’avec l’ouverture à l’enregistrement de O.COM, Verisign devrait être tenue, comme les opérateurs de nouveaux gTLD, de prévoir une période d'enregistrement prioritaire de 90 jours. Bien que le Conseil d’administration prenne acte des craintes exprimées par certains membres de la communauté eu égard au plan proposé par Verisign visant à ouvrir à l’enregistrement O.COM sans les RPM, il précise que le contrat de registre .COM n’oblige pas à prévoir une période d'enregistrement prioritaire avant l’ouverture à l’enregistrement de noms réservés. De plus, les demandes de RSEP soumises puis approuvées par le Conseil d’administration pour .BIZ (2008), .INFO (2010) et .ORG (2011), qui préconisaient des amendements au contrat de registre afin d’ouvrir à l’enregistrement les noms réservés avec un seul caractère et deux caractères, ne prévoyaient pas de période d'enregistrement prioritaire. La politique uniforme de règlement de litiges relatifs aux noms de domaine s’applique à tous litiges portant sur des marques déposées découlant de l’attribution d’un nom dans l’espace des noms .COM, dont O.COM.

      Y a-t-il des effets positifs ou négatifs pour la communauté ?

      L’approbation par le Conseil d’administration de la proposition d’amendement visant à ouvrir à l’enregistrement le nom de domaine avec un seul caractère O.COM devrait avoir un impact positif. Comme l’ont souligné plusieurs membres de la communauté lors de la période de consultation publique, il s’agit d’une décision importante qui permettra d’ouvrir à l’enregistrement davantage de noms de domaine avec un seul caractère, notamment dans l’espace des noms .COM. De plus, les commentaires sont favorables à l’approche proposée par Verisign visant à utiliser les recettes provenant des enchères de O.COM à des fins d’intérêt public pour la communauté Internet et encouragent Verisign à procéder à une répartition transparente des recettes.

      Y a-t-il des répercussions financières sur l’organisation ICANN (plan stratégique, plan opérationnel, budget), la communauté et/ou le public ?

      L'ouverture à l’enregistrement du nom de domaine avec un seul caractère O.COM ne devrait pas avoir d’impact financier significatif sur l’organisation ICANN.

      Y a-t-il des implications en termes de sécurité/stabilité/résilience du DNS ?

      Tel qu'indiqué précédemment, la question de savoir si l’ouverture à l’enregistrement de O.COM pourrait poser des problèmes en matière de sécurité ou de stabilité a été soulevée lors de la période de consultation publique. Parmi les craintes exprimées, on peut citer l’éventuel risque de « confusion associée à un script » du script latin « O.COM » avec les caractères grecs et cyrilliques se trouvant déjà dans l’espace des noms O.COM et le fait que l’ouverture à l’enregistrement de O.COM pourrait aller à l’encontre de la version préliminaire des directives relatives aux IDN v4. L’organisation ICANN a confirmé au Conseil d’administration que la version préliminaire des directives relatives aux IDN v4 « encourage les registres de TLD à appliquer des limites supplémentaires aux enregistrements afin de minimiser le risque de confusion associée au script… » mais n’impose pas de mesures d’atténuation spécifiques, et que cette ouverture à l’enregistrement de O.COM n’irait pas à l’encontre des directives relatives aux IDN v4. En outre, les directives relatives aux IDN v4 ne sont pas encore adoptées par le Conseil d’administration étant donné que l’organisation ICANN continue de définir le plan de mise en œuvre afin d’assurer une transition en douceur vers les nouvelles directives. Les directives relatives aux IDN v4 prévoient la nécessité de traiter les domaines existants comme des exceptions : « Lorsqu’un nom de domaine préexistant impose à un registre de faire une exception transitoire à l’une de ces directives, les termes de cette action doivent être facilement accessibles en ligne, notamment le calendrier prévu pour la résolution de ces questions transitoires. ». Et Verisign doit respecter cette exigence en temps utile.

    3. Report de l’application de la mise en œuvre de la politique relative au WHOIS détaillé

      Attendu que, la politique relative à la transition vers le WHOIS détaillé impose à Verisign de commencer à accepter les données d’enregistrement sous forme « détaillée » des bureaux d’enregistrement pour les noms de domaine .COM et .NET à compter du 30 novembre 2019, impose de soumettre au registre tous les enregistrements de nouveaux noms de domaine sous forme « détaillée » d’ici au 31 mai 2020, et impose de procéder à la migration de toutes les données d’enregistrement pertinentes pour les noms de domaine existants du WHOIS « résumé » au WHOIS « détaillé » d'ici au 30 novembre 2020.

      Attendu que, en vue du déploiement de l’acceptation des données du WHOIS détaillé, Verisign a proposé des amendements aux contrats entre opérateurs de registre et bureaux d’enregistrement pour les domaines .COM et .NET.

      Attendu que, le Groupe des représentants des bureaux d'enregistrement a fait part de ses inquiétudes concernant les amendements proposés par Verisign fondées sur des questions relatives au règlement général sur la protection des données de l’Union européenne, au traitement des données, et aux nouvelles exigences et obligations imposées aux bureaux d’enregistrement.

      Attendu que, l’organisation ICANN a continué à faciliter les discussions entre Verisign et le Groupe des représentants des bureaux d'enregistrement afin de parvenir à un accord sur les propositions d’amendements des contrats entre opérateurs de registre et bureaux d’enregistrement visant à mettre en œuvre la politique relative à la transition vers le WHOIS détaillé.

      Attendu que, Verisign et le Groupe des représentants des bureaux d'enregistrement ont besoin de davantage de temps afin de parvenir à un accord sur les propositions d'amendements des contrats entre registres et bureaux d'enregistrement concernés visant à mettre en œuvre la politique relative à la transition vers le WHOIS détaillé.

      Attendu que, le report de la période d’application permettra à la communauté de l’ICANN et au Conseil d’administration de disposer de temps afin d’examiner le rapport final issu du processus accéléré d'élaboration de politiques (EPDP) sur la spécification temporaire relative aux données d’enregistrement des gTLD.

      Attendu que, un délai supplémentaire permettra aux parties contractantes concernées et à l’Organisation ICANN d’évaluer tout impact potentiel des recommandations de l’EPDP sur la politique relative à la transition vers le WHOIS détaillé.

      Il est résolu (2019.3.14.03) que le président-directeur général, ou son ou ses représentants, sont autorisés à reporter la mise en conformité de la politique relative à la transition vers le WHOIS détaillé au 30 novembre 2019, au 31 mai 2020 et au 30 novembre 2020, respectivement.

      Fondements de la résolution 2019.03.14.03

      La politique relative à la transition vers le WHOIS détaillé définit une approche par étapes afin d’assurer la transition des registres .COM et .NET du WHOIS « résumé » au WHOIS « détaillé ». Les trois étapes sont les suivantes :

      1. L'opérateur de registre (RO) commence à accepter les données du WHOIS détaillé des bureaux d’enregistrement ;
      2. Les enregistrements des nouveaux noms de domaine .COM et .NET sont créés en tant qu’enregistrements sous forme détaillée ; et
      3. Il est procédé à la migration de toutes les données d’enregistrement de noms de domaine existants du WHOIS « résumé » au WHOIS « détaillé » dans un délai d'un an à compter de la date à laquelle le RO commence à accepter les données du WHOIS détaillé des bureaux d’enregistrement.

      La politique relative à la transition vers le WHOIS détaillé impose à Verisign de commencer à accepter les données d’enregistrement sous forme « détaillée » des bureaux d’enregistrement à compter du 31 mai 2019, aux bureaux d’enregistrement de soumettre les données d’enregistrement sous forme détaillée à Verisign pour tous les enregistrements de nouveaux noms de domaine à compter du 30 novembre 2019, et impose la migration de toutes les données d’enregistrement de noms de domaine existants du WHOIS « résumé » au WHOIS « détaillé » d’ici au 31 mai 2020. Afin de préparer l’acceptation des données du WHOIS détaillé, Verisign, l’opérateur de registre pour .COM et .NET, a proposé des amendements des contrats entre opérateurs de registre et bureaux d’enregistrement pour .COM et .NET de façon à établir le cadre juridique qui permettra l’acceptation des données. Bien que la politique de consensus relative au WHOIS détaillé s’applique également au TLD .JOBS, l’opérateur de registre pour .JOBS, Employ Media, n’a pas requis de modifications du contrat entre opérateur de registre et bureau d’enregistrement pour commencer à accepter les données d’enregistrement détaillées et les bureaux d’enregistrement ont déjà commencé à soumettre des données d’enregistrement détaillées pour .JOBS conformément à la politique.

      Suite à la procédure d’amendement des contrats entre opérateurs de registre et bureaux d’enregistrement, l'organisation ICANN a facilité des discussions entre Verisign et le Groupe des représentants des bureaux d'enregistrement afin de parvenir à un accord sur les propositions d'amendements des contrats entre opérateurs de registre et bureaux d’enregistrement, mais les parties ne sont pas encore parvenues à un accord. De plus, la communauté travaille, via l’EPDP de la GNSO, au développement d’une politique de consensus permanente afin de remplacer, ou de confirmer, la spécification temporaire relative aux données d’enregistrement des gTLD.

      Le Conseil d’administration prend actuellement des mesures visant à autoriser le président-directeur général de l'ICANN à reporter de 180 jours la mise en conformité de la politique relative à la transition vers le WHOIS détaillé. Cela permettra à la communauté et au Conseil d’administration de disposer de davantage de temps afin d’examiner les recommandations du rapport final issu de l’EPDP. Ce report permettra également aux parties contractantes concernées et à l’organisation ICANN d’évaluer tout impact potentiel des recommandations de l’EPDP sur la politique relative à la transition vers le WHOIS détaillé.

      Il est possible que de nouveaux reports s’avèrent nécessaires si l’équipe responsable de l’EPDP recommande d’importants changements de la spécification temporaire relative aux données d’enregistrement des gTLD.

      Les délibérations du Conseil d’administration à cet égard se sont appuyées sur plusieurs supports importants dont :

      La décision du Conseil d’administration ne devrait pas avoir d’impact financier sur l’ICANN qui n’ait déjà été prévu dans le budget actuel. Cette décision sert l’intérêt public et est conforme à la mission de l’ICANN dans la mesure où elle garantit la mise en œuvre uniforme et coordonnée des politiques dans les gTLD.

      Cette résolution relève d’une fonction administrative organisationnelle qui ne nécessite pas de consultation publique.

    4. Nomination des auditeurs indépendants pour l’exercice fiscal 2019

      Attendu que, l’article 22.2 des statuts constitutifs de l’ICANN (http://www.icann.org/general/bylaws.htm) exige qu’à la fin de l’exercice fiscal les livres de l’ICANN soient vérifiés par des comptables agréés qui seront nommés par le Conseil d’administration.

      Attendu que, le Comité d’audit du Conseil d’administration a envisagé de faire appel à un auditeur indépendant pour l’exercice fiscal prenant fin le 30 juin 2019, et a recommandé au Conseil d’administration d’autoriser le président-directeur général, ou son ou ses représentants, à prendre toutes les dispositions nécessaires pour faire appel aux cabinets membres du réseau BDO LLP et BDO.

      Il est résolu (2019.03.14.04) que le Conseil d’administration autorise le président-directeur général, ou son ou ses représentants, à prendre toutes les mesures nécessaires pour faire appel aux cabinets membres du réseau BDO LLP et BDO afin de procéder à l’audit des états financiers de l’exercice fiscal prenant fin le 30 juin 2019.

      Fondements de la résolution 2019.03.14.04

      Depuis l’audit de l’exercice fiscal 2014, les auditeurs indépendants de l’ICANN sont des membres du réseau BDO LLP et BDO. Sur la base du rapport de l'organisation et de l’évaluation par le Comité d’audit des travaux réalisés, le comité recommande au Conseil d’administration d’autoriser le président-directeur général de l’ICANN, ou son ou ses représentants, à prendre toutes les mesures nécessaires pour faire appel aux cabinets du réseau BDO LLP et BDO afin de procéder à l’audit financier de l’exercice fiscal 2019 et de remplir toutes les obligations prévues en matière d’audit indépendant annuel dans toute juridiction.

      L’ICANN pousse ainsi un peu plus loin sa responsabilité à l’égard de ses statuts et de ses processus. Les conclusions de l’audit indépendant seront rendues publiques. Prendre cette décision est à la fois conforme à la mission de l’ICANN et dans l'intérêt public car engager un auditeur indépendant est conforme à l’obligation qu’a l'ICANN de mener un audit de ses états financiers et aide à servir les parties prenantes de l’ICANN de manière plus responsable.

      Cette décision aura un impact financier sur l’ICANN. Elle ne devrait pas avoir d’impact direct sur la sécurité, la stabilité et la résilience du système des noms de domaine.

      Il s’agit d’une fonction administrative organisationnelle qui ne nécessite pas de consultation publique.

    5. Acceptation des révisions de la charte du Comité chargé de l’efficacité organisationnelle

      Attendu que, le Comité chargé de l'efficacité organisationnelle du Conseil d’administration de l’ICANN est tenu d’assurer un contrôle des révisions organisationnelles et spécifiques prévues par les statuts constitutifs de l’ICANN. En vertu du chapitre 18 des statuts constitutifs post-transition du rôle de supervision des fonctions IANA, l’ICANN est également tenue de procéder à des révisions, périodiques et à titre spécial, des fonctions IANA relatives au nommage, dont le but est d’évaluer les performances de la PTI par rapport au contrat des fonctions IANA relatives au nommage et au cahier des charges des fonctions IANA relatives au nommage. À ce jour, aucun comité du Conseil d’administration n’a été désigné afin de contrôler les processus de révision des fonctions IANA (IFR) relatives au nommage.

      Attendu que, le Comité chargé de l'efficacité organisationnelle a proposé des révisions de sa charte actuelle afin d’intégrer le contrôle des IFR.

      Attendu que, le Comité de gouvernance du Conseil d’administration, chargé d’examiner les chartes du Comité, accepte la proposition de l’OEC et recommande au Conseil d’administration d’adopter cette charte de l’OEC révisée.

      Il est résolu (2019.03.14.05) que le Conseil d’administration adopte les révisions proposées de la charte du Comité chargé de l'efficacité organisationnelle.

      Fondements de la résolution 2019.03.14.05

      Pourquoi le Conseil d’administration aborde-t-il cette question maintenant ?

      Le Conseil d’administration aborde cette question en raison de l'obligation pour le Conseil d'administration d’approuver les révisions des chartes des comités du Conseil d’administration.

      Quelle est la proposition à l’étude ?

      Le Comité chargé de l'efficacité organisationnelle (OEC) propose de modifier l’obligation de contrôle du Comité de sorte à y inclure les processus de révision des fonctions IANA (IFR) relatives au nommage. L’OEC propose de prendre en charge le contrôle des IFR étant donné qu’il s’occupe déjà du contrôle des révisions organisationnelles et spécifiques.

      Quels sont les principaux documents examinés par le Conseil d’administration ?

      Le Conseil d’administration a examiné les révisions proposées de la charte de l’OEC 2017. Voir les supports de référence, l’annexe A (avec modifications visibles) et l’annexe B (version propre sans modifications visibles).

      Y a-t-il des effets positifs ou négatifs pour la communauté ?

      Les révisions proposées visent à apporter des clarifications et à harmoniser les révisions prévues par les statuts constitutifs afin que le Conseil d’administration soit toujours tenu d’en assurer le contrôle. Ces évolutions devraient avoir un impact positif sur la communauté. Les IFR constituent un moyen clé pour l’ICANN de confirmer que l’entité Identificateurs techniques publics, sa société affiliée et son contractant, remplit ses missions conformément aux contrats, et il convient de définir des contrôles de ces révisions au niveau du Conseil d’administration.

      Y a-t-il des impacts financiers ou des répercussions à prévoir sur l’ICANN (plan stratégique, plan opérationnel et budget), la communauté et/ou le public ?

      Les changements proposés n’auront pas d’impact financier ou de conséquences défavorables sur les plans opérationnels et stratégiques de l’ICANN.

      Y a-t-il des implications en termes de sécurité/stabilité/résilience du DNS ?

      Cette décision n’a aucune implication sur la sécurité, la stabilité ou la résilience du DNS.

      Dans quelle mesure cette décision s’inscrit-elle dans la mission de l’ICANN et quel intérêt public sert-elle ?

      La décision du Conseil d’administration est conforme à l’engagement de l’ICANN, prévu par le chapitre 18 des statuts constitutifs, de veiller à ce que la PTI assure les fonctions IANA relatives au nommage dans le respect des exigences contractuelles prévues dans le contrat des fonctions IANA relatives au nommage et le cahier des charges des fonctions IANA relatives au nommage. Cette décision servira l’intérêt public en ce qu’elle garantit que le Conseil d’administration de l’ICANN effectuera un contrôle de la manière dont l’ICANN et la PTI respectent l’engagement de l’ICANN d’assurer des services en matière de fonctions IANA relatives au nommage à la hauteur des attentes des clients et de la communauté de l’ICANN dans son ensemble.

      Une consultation publique est-elle nécessaire avant que le Conseil d’administration prenne une décision ?

      Aucune consultation publique n’est nécessaire.

    6. Nomination des représentants de l’Organisation des opérateurs de serveur racine auprès du RSSAC

      Attendu que, les statuts constitutifs de l’ICANN prévoient la création d’un Comité consultatif du système des serveurs racine (RSSAC) chargé d’adresser à la communauté de l’ICANN et au Conseil d’administration de l’ICANN des recommandations sur les questions liées à l’exploitation, l’administration, la sécurité et l’intégrité du système des serveurs racine d’Internet.

      Attendu que, les statuts constitutifs de l’ICANN prévoient que le Conseil d’administration désigne les membres du RSSAC pour chaque opérateur de serveur racine en se fondant sur les recommandations des coprésidents du RSSAC.

      Attendu que, en février 2019, le Centre de coordination des réseaux IP européens (RIPE NCC) a demandé le changement de son représentant pour le reste du mandat en cours, qui expire le 31 décembre 2020.

      Attendu que, les coprésidents du RSSAC ont recommandé au Conseil d’administration de l’ICANN de nommer au RSSAC un représentant du RIPE NCC.

      Il est résolu (2019.03.14.06) que le Conseil d’administration de l’ICANN nomme Kaveh Ranjbar comme représentant auprès du RSSAC jusqu’au 31 décembre 2020.

      Fondements de la résolution 2019.03.14.06

      En mai 2013, les organisations d’opérateurs de serveurs racine ont convenu de la composition initiale des représentants pour le RSSAC, chacune ayant proposé la candidature d’une personne. En juillet 2013, le Conseil d’administration de l’ICANN a approuvé cette composition initiale du RSSAC, les mandats étant échelonnés.

      En février 2019, le RIPE NCC a demandé le changement de son représentant pour le reste du mandat en cours, qui expire le 31 décembre 2020.

      La nomination de membres du RSSAC ne devrait pas avoir d’impact financier sur l’organisation ICANN qui n’ait déjà été intégré aux ressources budgétaires nécessaires pour un soutien continu du RSSAC.

      Cette résolution relève d’une fonction administrative organisationnelle qui ne nécessite pas de consultation publique. La nomination des membres du RSSAC contribue à l’engagement de l’organisation ICANN à renforcer la sécurité, la stabilité et la résilience du DNS.

    7. Approbation de l’amendement du contrat des fonctions IANA relatives au nommage

      Attendu que, l’article 16.3 des statuts constitutifs de l’ICANN impose à l’ICANN et à la PTI de conserver un contrat des fonctions IANA relatives au nommage pour l’exécution des performances de la PTI eu égard aux fonctions IANA relatives au nommage. Le contrat des fonctions IANA relatives au nommage initial a été approuvé en 2016 par les conseils d’administration de l’ICANN et de la PTI dans le cadre de la transition du rôle de supervision des fonctions IANA.

      Attendu que, le contrat des fonctions IANA relatives au nommage comprend actuellement un tableau indiquant en détail les conventions de service opérationnelles (tableau SLA) telles que convenues avec la communauté multipartite lors du processus de transition du rôle de supervision des fonctions IANA.

      Attendu que, l’organisation ICANN, la PTI et le Comité permanent de clients (CSC) sont tous d’accord pour affirmer que le fait de devoir modifier le contrat des fonctions IANA relatives au nommage à chaque fois qu’une SLA individuelle doit être modifiée, supprimée ou ajoutée n’est pas tenable et ne répond pas aux besoins de l’ICANN, de la PTI ou des clients des fonctions IANA relatives au nommage. Par conséquent, une proposition a été dégagée afin d’amender le contrat des fonctions IANA relatives au nommage une seule fois de sorte que le tableau SLA ne fasse plus partie du contrat, et afin d’imposer de modifier lesdites SLA de sorte à respecter le « processus d’amendement des conventions de service pour les fonctions IANA relatives au nommage » approuvé et publié par la communauté.

      Attendu que, l’organisation ICANN, la PTI et le CSC ont participé à l’élaboration du processus d’amendement des conventions de service pour les fonctions IANA relatives au nommage, et le CSC a sensibilisé les clients des fonctions IANA relatives au nommage audit processus.

      Attendu que, l’ICANN a sollicité des commentaires publics sur la proposition d’amendement du contrat des fonctions IANA relatives au nommage du 7 janvier 2019 au 18 février 2019.

      Attendu que, le forum de commentaires publics pour la proposition d’amendement du contrat des fonctions IANA relatives au nommage a été clôturé le 18 février 2018 ; l’ICANN a reçu un commentaire du Groupe des représentants des opérateurs de registres favorable à la proposition d’amendement. Un résumé et une analyse des commentaires ont été publiés le 25 février 2019 et transmis au Conseil d’administration.

      Il est résolu (2019.03.14.07) que la proposition d’amendement n° 1 du contrat des fonctions IANA relatives au nommage est approuvée, et le président-directeur général, ou son ou ses représentants, sont autorisés à prendre toutes les mesures adéquates afin de conclure et d’exécuter le contrat.

      Fondements de la résolution 2019.03.14.07

      Le Comité permanent de clients (CSC), en collaboration avec l’organisation ICANN et la PTI, a recommandé des modifications en se fondant sur les données opérationnelles obtenues. En proposant que les SLA soient déplacées du contrat à un tableau SLA sur une page web de la PTI, il était entendu qu’un processus complet de modification des SLA était requis afin de garantir que des consultations adéquates aient lieu avec les clients des fonctions IANA relatives au nommage et la communauté de l’ICANN dans son ensemble.

      Lors de la réunion du CSC en date du 17 décembre 2018, deux processus de modification des SLA ont été approuvés : un « processus d’amendement des conventions de service pour les fonctions IANA relatives au nommage » et une « procédure de modification du processus d’amendement des conventions de service pour les fonctions IANA relatives au nommage ». L’organisation ICANN et la direction de la PTI ont participé aux débats et également convenu des processus. Les processus n’entreront pas en vigueur tant que le contrat des fonctions IANA relatives au nommage n’a pas été amendé.

      Le Conseil d’administration approuve aujourd’hui l’amendement du contrat des fonctions IANA relatives au nommage car le fait de déplacer les SLA pour les fonctions IANA relatives au nommage du contrat à un tableau SLA sur une page web permet aux modifications des SLA de mieux répondre aux besoins des clients des fonctions relatives au nommage, tandis que le respect du nouveau « processus d’amendement des conventions de service pour les fonctions IANA relatives au nommage » garantit que toutes ces modifications suivent un processus strict afin d’assurer des niveaux adéquats de consultation communautaire et d’accord entre le CSC et l’ICANN/la PTI.

      La décision du Conseil d’administration tient compte des retours de la communauté, qui ont soutenu l’amendement via l’approbation du CSC, et des commentaires publics du RySG selon lesquels « Cet amendement du contrat des fonctions IANA relatives au nommage adopte un processus de modification des SLA qui a été élaboré et convenu via une collaboration entre le CSC, la PTI et l’organisation ICANN. Le processus de modification des SLA permettra au CSC et à la PTI a) de modifier les SLA si besoin est, b) d’ajouter de nouveaux SLA au fur et à mesure que de nouveaux services voient le jour en ligne, et c) de supprimer les SLA qui n’ont plus de raison d’être. _Le RySG soutient l’amendement et demande au Conseil d’administration de l’ICANN de l’approuver de sorte que les SLA devant être modifiées, ajoutées ou supprimées le soient le plus vite possible. »

      La décision prise via cette résolution n’aura pas d’autre impact sur les ressources de l’ICANN ou la sécurité et la stabilité du DNS. Cette décision s’inscrit dans la mission de l’ICANN étant donné qu’elle aide l’ICANN à assurer les fonctions IANA relatives au nommage.

    8. Remerciements à l’attention des hôtes locaux de la 64e réunion de l’ICANN

      Le Conseil d’administration tient à exprimer ses remerciements à Mme Yukari Sato, ministre d'État chargé des affaires intérieures et des communications, à M. Kizō Hisamoto, maire de Kobe, au Prof. Jun Murai, président du Comité des hôtes locaux de l’ICANN64, et aux membres du Comité des hôtes locaux de l’ICANN64, ainsi qu’à GMO Internet Inc., à Japan Registry Services Co. Ltd., à Internet Initiative Japan Inc., à Internet Association Japan, à Internet Multifeed Co., à Interlink Co. Ltd., à NTT Docomo Inc., à l’Association des services de télécommunications, au Centre d'information de réseaux du Japon, à BusinessRalliart Inc., à l’Institut d’études supérieures des sciences de l’information de Kyoto, à Com Laude (Japan) Corporation, à Taka Enterprise Ltd., à l’Association des fournisseurs d’accès à Internet japonais, au projet WIDE, à NTT Communications Corporation, à KDDI Corporation, à Nippon Telegraph and Telephone West Corporation. Merci également au ministère des affaires intérieures et des communications, au Kobe Convention Bureau et à la Tsutomu Nakauchi Foundation pour leur soutien.

    9. Remerciements à l'attention des partenaires de la 64e réunion de l'ICANN

      Le Conseil d’administration tient à remercier les sponsors suivants : Verisign, Public Interest Registry, Afilias plc et CentralNic.

    10. Remerciements à l'attention des interprètes, du personnel, des organisateurs et des équipes de l’hôtel chargés de l’organisation de la 64e réunion de l’ICANN

      Le Conseil d’administration exprime sa gratitude aux scribes, aux interprètes, à l’équipe audiovisuelle, aux équipes techniques et à l’ensemble du personnel de l’ICANN pour les efforts réalisés afin de faciliter le bon déroulement de la réunion. Le Conseil d’administration souhaite également remercier la direction et le personnel du Kobe Portopia Hotel et du Kobe International Conference Center pour avoir prêté ces magnifiques locaux en cette occasion. Le Conseil d’administration remercie tout particulièrement l’équipe du Kobe International Conference Center, Omura Masatoshi, Rikako Nakanishi, Aya Fukuda, Eiji Makatsuj i, Yuko Zikumaru, Tetsuya Shori et Lance Ferguson, et les organisateurs et l’équipe informatique du Kobe Portopia Hotel, Hitoshi Nakauchi, Tsuyoshi Ito, Takahiko Kishimoto, Kenji Kino, Shingo Murakami, Takumi Nishihara, Tomoko Nishio, Tomoya Takeda, Makoto Sakai, Shohei Inoue, Yosuke Taniguchi, Rose Tanasugarn et Gilbert Yeo, directeur de Pryde Productions.

  2. Ordre du jour principal :

    1. Recommandations pour la gestion des variantes de TLD IDN

      Attendu que, les noms de domaine internationalisés (IDN) permettent aux internautes d’accéder aux noms de domaine dans leurs langues maternelles et demeurent une composante clé des travaux de l’ICANN.

      Attendu que, le Conseil d’administration reconnaît l’importance des variantes IDN pour certaines chaînes de domaine de premier niveau (TLD) IDN et la nécessité de mettre en œuvre des variantes d’étiquettes dans la zone racine de façon à garantir la sécurité et la stabilité du DNS.

      Attendu que, le Conseil d’administration a décidé en 2010 que les variantes de TLD IDN ne seront pas déléguées jusqu’à ce qu’un travail conséquent soit réalisé et a enjoint à l’organisation ICANN d’élaborer un rapport précisant ce qui doit être fait en matière d'évaluation, d’éventuelle délégation, d’attribution et d’exploitation des domaines génériques de premier niveau (gTLD) contenant des IDN à variantes de caractères, afin de faciliter le développement d’approches fonctionnelles en matière de déploiement de gTLD contenant des IDN à variantes de caractères.

      Attendu que, sur la base de six études de cas, réalisés dans le cadre de l’Étude des questions liées à la gestion des variantes de TLD IDN de 2012, l’organisation ICANN et la communauté ont identifié deux lacunes à combler : l’absence de définition des variantes de TLD IDN, et l’absence de mécanisme de gestion des variantes de TLD IDN.

      Attendu que, la procédure d’élaboration et de maintien des règles de génération d'étiquettes pour la zone racine eu égard aux étiquettes IDNA (la procédure RZ-LGR) a été élaborée par la communauté afin de définir les variantes de TLD IDN et, suite à l’adoption en 2013 de la résolution du Conseil d’administration approuvant la procédure RZ-LGR, a été mise en œuvre afin de développer progressivement les règles de génération d'étiquettes pour la zone racine et de combler ainsi la première lacune.

      Attendu que, l’organisation ICANN a élaboré les recommandations pour la gestion des variantes de TLD IDN (les recommandations relatives aux variantes de TLD), un recueil de six documents achevés après l’incorporation des commentaires publics, et les a publiées en tant que mécanismes permettant de combler la seconde lacune identifiée par la communauté dans la mise en œuvre des variantes de TLD IDN.

      Il est résolu (2019.03.14.08) que le Conseil d’administration approuve les recommandations relatives aux variantes de TLD et demande à la ccNSO et la GNSO de les prendre en compte lors de l’élaboration de leurs politiques respectives visant à définir et gérer les variantes de TLD IDN pour les TLD actuels et les futures demandes de TLD.

      Il est résolu (2019.03.14.09) que le Conseil d’administration demande à la ccNSO et à la GNSO de se tenir informées l’une l’autre de l’avancée de l’élaboration de certains aspects de leurs politiques et procédures afin de garantir qu’une solution homogène basée sur les recommandations relatives aux variantes de TLD est mise en place pour les variantes de ccTLD IDN et les variantes de gTLD IDN.

      Il est résolu (2019.03.14.10) que le Conseil d’administration prend également acte des importants efforts et contributions de la communauté depuis le lancement du projet sur la question des variantes IDN en 2011, qui a mené à l’élaboration des recommandations relatives aux variantes de TLD.

      Fondements des résolutions 2019.03.14.08 2019.03.14.10

      Les noms de domaine internationalisés (IDN) permettent aux personnes du monde entier d’utiliser les noms de domaine dans des langues et scripts locaux. Certaines communautés partageant un script ont déterminé que des étiquettes de domaine distinctes d'un point de vue technique pouvaient être jugées indifférenciables d’autres étiquettes de domaine et donc qualifiées de d’étiquettes « identiques », c’est-à-dire de variantes d’étiquettes. La norme de 2008 relative aux IDN dans les applications (IDNA), en plus de préciser comment utiliser des noms de domaine dans de multiples scripts, invite également dans le RFC 58941 « les registres à définir et appliquer des restrictions supplémentaires visant, si besoin est, à réduire le risque de confusion et autres problèmes … Pour de nombreux scripts, le recours aux techniques des variantes … peut permettre d’atténuer d’éventuels problèmes perçus par les utilisateurs. … En règle générale, les utilisateurs y trouveront leur compte si les registres n’autorisent que des caractères de scripts bien compris par le registre ou ses conseillers. »

      Sur la base de la norme de 2008 relative aux IDNA, les variantes d’étiquettes doivent au moins être identifiées et gérées afin de veiller à ce que les utilisateurs finaux soient à l’abri de menaces à la sécurité. Quelques-unes des variantes d’étiquettes identifiées pourraient même être activées afin de promouvoir l’accessibilité des IDN, dans la mesure où plusieurs communautés de langues utilisant un script peuvent utiliser une variante d’étiquette différente. Dans certains cas, des demandes de ccTLD IDN et de nouveaux gTLD ont permis d’identifier des étiquettes supplémentaires considérées comme variantes d’étiquettes, ce qui indique que la communauté peut considérer ces différentes étiquettes comme des variantes l’une de l’autre. Toutefois, en raison de l’absence de définition claire et de solution les mettant en œuvre, le Conseil d’administration a décidé, via une résolution en date du 25 septembre 2010, « qu’aucune variante de gTLD ne sera déléguée via le programme des nouveaux gTLD avant que ne soient élaborées des solutions de gestion des variantes adaptées ». La résolution enjoignait également au personnel de l’ICANN de rédiger « un rapport thématique précisant ce qui doit être fait en matière d'évaluation, d’éventuelle délégation, d’attribution et d’exploitation des gTLD contenant des IDN à variantes de caractères, dans le cadre du processus des nouveaux gTLD visant à faciliter le développement d’approches fonctionnelles en matière de déploiement de gTLD contenant des IDN à variantes de caractères ».

      Atteindre ces objectifs de sécurité et d’accessibilité de manière stable constitue un grand défi à relever. Afin de répondre à ces questions linguistiques et techniques complexes, l’organisation ICANN a lancé le projet sur la question des variantes IDN sous la direction du Conseil d’administration de l’ICANN. Elle a dans un premier temps fait appel à des experts de six communautés partageant une écriture qui ont analysé les problèmes se posant lors de l’identification de variantes d’étiquettes pour chacun de ces scripts. Cette analyse des problèmes pour les scripts arabe, chinois, cyrillique, devanagari, grec et latin de 2011, intégrée dans le rapport intégré (IIR) (2012), a soulevé deux enjeux :

      1. « Aujourd’hui, dans l’environnement du DNS, il n’existe pas de définition acceptée de ce qui peut constituer une relation de variante entre des étiquettes de premier niveau,
      2. et il n’existe pas non plus de mécanisme de gestion des variantes pour le premier niveau, en dépit du fait qu’un tel mécanisme ait souvent été proposé afin de trouver des solutions à un problème donné. »

      1. Définition des variantes de TLD

      L’IIR a présenté le travail de suivi qui pourrait être entrepris. Pour résoudre le premier problème souligné dans l’IIR, la communauté a mis au point une procédure d’élaboration et de maintien des règles de génération d'étiquettes pour la zone racine eu égard aux étiquettes IDNA (la procédure RZ-LGR). Sur demande du Conseil d’administration de l’ICANN en date du 11 avril 2013, l’ICANN a lancé la procédure RZ-LGR qui comprend deux étapes : chaque communauté élabore une proposition de règles de génération d'étiquettes (LGR) basées sur un script, et un panel d’experts révise et incorpore chaque proposition aux LGR pour la zone racine (RZ-LGR). Plusieurs communautés partageant une écriture ont finalisé leur proposition, les propositions pour les scripts arabe, éthiopien, géorgien, khmer, lao et thaï ayant été incorporées dans la deuxième version des RZ-LGR (RZ-LGR-2). Bien d’autres communautés partageant une écriture participent également à la définition de leurs règles. En outre, une spécification visant à coder ces données linguistiques dans un format lisible par machine a aussi été élaborée et publiée par l’intermédiaire de l’IETF en tant que document sur le processus de standardisation d’Internet RFC 7940 : Représentation des ensembles de règles de génération d'étiquettes à l’aide de XML. Un outil LGR a également été mis au point afin de créer, d’utiliser et de gérer les LGR. Il est mis à la disposition de la communauté en ligne et peut aussi être téléchargé avec une licence gratuite.

      2. Analyse des mécanismes de gestion des variantes de TLD

      Les règles de génération d'étiquettes pour la zone racine issues du processus décrit ci-dessus produisent des variantes d’étiquettes TLD qui peuvent être attribuées. Afin de répondre au deuxième besoin énoncé dans le rapport intégré, à savoir la nécessité d’adopter un mécanisme de gestion des variantes, la communauté de l’ICANN doit élaborer les politiques et procédures qui régissent cette attribution des variantes de noms. L’ensemble de documents, achevé après la consultation publique avant d’être publié, propose des recommandations dont doivent tenir compte la ccNSO et la GNSO lors de l’élaboration de politiques et procédures conformément à leurs processus d'élaboration de politiques (PDP) respectifs. Ces documents analysent également les recommandations et leur impact sur le processus de candidature aux nouveaux gTLD, tel que décrit dans le guide de candidature aux nouveaux gTLD, et sur le processus de candidature aux ccTLD IDN, sur la base du plan de mise en d'œuvre final pour la procédure accélérée ccTLD IDN. Les principes fondamentaux des recommandations et de l’analyse présentées découlent en grande partie des observations de la communauté consignées dans le rapport intégré et des avis présentés par le Comité consultatif sur la sécurité et la stabilité (SSAC) dans son rapport SAC 60.

      Lors du développement de l’analyse, l’équipe de l’organisation ICANN a eu de multiples interactions avec le Groupe de travail du Conseil d'administration de l’ICANN sur les variantes IDN (BIWG) depuis 2014, et le BIWG a orienté la réalisation de ces travaux. Les recommandations ont été conçues dans un souci de prudence, étant donné qu'il s’agit de la première mise en œuvre des variantes de TLD IDN, et que la solution pourrait profiter de l’expérience de mise en œuvre acquise au fil du temps.

      Le Conseil d’administration de l'ICANN prend note que les travaux relatifs aux RZ-LGR sont en bonne voie. Le Conseil d’administration prend également note que l’ensemble initial de recommandations pour la mise en œuvre des variantes de TLD IDN de manière prudente et uniforme a été mis à disposition de la ccNSO et de la GNSO à des fins de nouvel examen dans le cadre de leurs travaux d’élaboration de politiques et procédures pertinentes. Les conditions préalables identifiées par la communauté dans le rapport intégré ayant été remplies, les prochaines étapes peuvent à présent être menées par les organisations de soutien (SO).

      Cela aura un impact positif sur la communauté, bien qu’il existe des risques. Au pire, on empêche les variantes de TLD IDN identifiées de faire l’objet d'une candidature, ce qui contribuera à renforcer la sécurité des utilisateurs finaux, tant qu’un mécanisme de gestion viable n’ait été élaboré par les organisations de soutien. De plus, si la ccNSO et la GNSO conviennent de mécanismes de gestion uniformes pour la délégation de certaines de ces variantes d’étiquettes, cela pourrait aider à promouvoir l’accessibilité des noms de domaine au sein des communautés qui ont besoin de ces variantes de TLD IDN. Poursuivre dans cette direction est risqué, notamment si la communauté ne parvient à convenir d’une approche uniforme à l’égard des TLD, cela pouvant créer une confusion chez les utilisateurs finaux, ou dans d’autres cas porter atteinte à leur sécurité. Les variantes de TLD IDN peuvent également alourdir les obligations de gestion des titulaires de noms de domaine, comme l’indique le SSAC dans son rapport SAC060. Suite à la résolution, la ccNSO et la GNSO devront élaborer leurs propres politiques et procédures pour la mise en œuvre des variantes de TLD IDN, en tenant compte des recommandations fournies. Toutefois, cette résolution n’impose ni à la ccNSO ni à la GNSO d’effectuer des travaux d’élaboration de politiques sur ce sujet. Après soumission, le cas échéant, des rapports finaux respectifs contenant les recommandations politiques et élaborés via les PDP concernés au Conseil d’administration de l'ICANN à des fins d’approbation, le Conseil d’administration évaluera dans quelle mesure ces politiques et procédures tiennent compte des recommandations relatives aux variantes de TLD, leur impact et les risques associés. À ce stade, le Conseil d’administration décidera d’adopter ou non les recommandations politiques et de poursuivre la mise en œuvre des variantes de TLD IDN.

      Un impact financier est à prévoir. Le degré de cet impact financier dépendra du processus final d’évaluation des demandes de variantes de TLD IDN et du calendrier de ce processus de candidature suggéré par la communauté. Par conséquent, l’impact devra être évalué lorsque la ccNSO et la GNSO auront achevé leurs politiques et procédures pour la mise en œuvre des variantes de TLD IDN et les auront présentées au Conseil d’administration à des fins d’examen.

      Les recommandations favorisent le fonctionnement sécurisé et stable du système d’identifiant unique, tout en répondant au besoin en variantes de TLD IDN identifié par la communauté et en respectant le rôle d’élaboration de politiques de la communauté. Les travaux sur les variantes de TLD IDN contribuent aussi à l’intérêt général en renforçant l’accès au système des noms de domaine (DNS) de l’Internet en différents scripts et langues.

    2. Préparation à la mise en œuvre des séries ultérieures de nouveaux gTLD

      Aucune résolution n’est adoptée.

    3. Transfert du domaine de premier niveau .VU (Vanuatu) à l’Autorité de régulation des télécommunications, des radiocommunications et des contenus audiovisuels (TRBR)

      Il est résolu (2019.03.14.11) que, dans le cadre de l’exercice de ses responsabilités en vertu du contrat des fonctions IANA relatives au nommage conclu avec l’ICANN, la PTI a examiné et évalué la demande de transfert du domaine de premier niveau géographique .VU à l’Autorité de régulation des télécommunications, des radiocommunications et des contenus audiovisuels (TRBR). La documentation montre que cette demande a suivi les procédures appropriées pour son évaluation.

      Fondements de la résolution 2019.03.14.11

      Pourquoi le Conseil d’administration aborde-t-il cette question maintenant ?

      Conformément au contrat des fonctions IANA relatives au nommage, la PTI a évalué la demande de transfert du ccTLD et présente son rapport au Conseil d’administration à des fins d’examen. Cet examen par le Conseil d’administration est destiné à s’assurer que les procédures correctes ont été suivies.

      Quelle est la proposition à l’étude ?

      La proposition consiste à approuver une demande de transfert du domaine de premier niveau géographique .VU et à attribuer le rôle de gestionnaire à l’Autorité de régulation des télécommunications, des radiocommunications et des contenus audiovisuels (TRBR).

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

      Lors de l’évaluation de cette candidature de transfert, la PTI a consulté le candidat et d’autres parties intéressées. Dans le cadre du processus de candidature, le candidat doit expliquer quelles consultations ont été effectuées dans le pays au sujet du ccTLD en question et dans quelle mesure celles-ci s’appliquent à la communauté Internet locale.

      Quelles sont les inquiétudes ou questions soulevées par la communauté ?

      La PTI n’a pas connaissance de questions ou d’inquiétudes soulevées par la communauté concernant cette demande.

      Quels sont les principaux documents examinés par le Conseil d’administration ?

      [SUPPRIMÉ – INFORMATIONS SENSIBLES RELATIVES À UNE DÉLÉGATION]

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

      Le Conseil d’administration n’a identifié aucun facteur d’inquiétude concernant cette demande.

      Y a-t-il des effets positifs ou négatifs pour la communauté ?

      L’approbation en temps voulu des gestionnaires de noms de domaine géographiques répondant aux critères d’intérêt public a un effet positif sur la mission de l’ICANN et les communautés locales auxquelles des domaines de premier niveau géographiques sont attribués. Elle permet de respecter les obligations prévues par le contrat des fonctions IANA relatives au nommage.

      Y a-t-il des répercussions financières sur l’ICANN (plan stratégique, plan opérationnel, budget), la communauté et/ou le public ?

      La gestion des délégations des extensions géographiques dans la zone racine du DNS fait partie des fonctions IANA et le processus de délégation ne devrait pas avoir de répercussion majeure sur les dépenses prévues. L'ICANN n'est pas tenue d'évaluer les répercussions financières des activités internes des domaines de premier niveau géographiques dans un pays.

      Y a-t-il des implications sur la sécurité, la stabilité ou la résilience du DNS ?

      L’ICANN estime que cette demande ne présente aucun risque significatif pour la sécurité, la stabilité ou la résilience du DNS. Il s’agit d’une fonction administrative organisationnelle qui ne nécessite pas de consultation publique.

    4. Examen de la demande de réexamen 16-5 : DotMusic Limited

      Attendu que, DotMusic Limited (DotMusic) a présenté une candidature communautaire pour .MUSIC (la candidature), qui a été placée dans un ensemble conflictuel avec d’autres candidatures .MUSIC.

      Attendu que, DotMusic a participé à l’évaluation de la priorité communautaire (CPE), mais ne l’a pas réussie.

      Attendu que, DotMusic, la Fédération internationale des musiciens, la Fédération internationale des conseils des arts et des agences culturelles, le Worldwide Independent Network, Merlin Network, l’Independent Music Companies Association, l’American Association of Independent Music, l’Association of Independent Music, la Content Creators Coalition, la Nashville Songwriters Association International et ReverbNation (collectivement les requérants) ont soumis la demande de réexamen 16-5 afin d’obtenir le réexamen du rapport CPE de la candidature et l’acceptation par l’organisation ICANN dudit rapport CPE.

      Attendu que, alors que la demande 16-5 était en cours, le Conseil d’administration a enjoint à l’organisation ICANN de mener une révision du processus CPE (la révision du processus CPE). Le Comité de gouvernance du Conseil d’administration (BGC) a déterminé que les demandes de réexamen en cours concernant le processus CPE, y compris la demande 16-5, seraient suspendues jusqu’à la fin de la révision du processus CPE.2

      Attendu que, le 13 décembre 2017, l’organisation ICANN a publié trois rapports sur la révision du processus CPE (les rapports sur la révision du processus CPE).

      Attendu que, le 15 mars 2018, le Conseil d’administration a voté les résolutions 2018.03.15.08 à 2018.03.15.11, dans lesquelles le Conseil d’administration a reconnu et accepté les conclusions des rapports sur la révision du processus CPE ; a déclaré que la révision du processus CPE était terminée ; a conclu que, sur la base des conclusions des rapports sur la révision du processus CPE, il n’y aurait aucune révision ou modification du processus CPE pour la série actuelle du programme des nouveaux gTLD ; et a enjoint au Comité du Conseil d’administration chargé des mécanismes de responsabilité (BAMC) de poursuivre l’examen du reste des demandes de réexamen relatives au processus CPE qui avaient été suspendues jusqu’à l’achèvement de la révision du processus CPE.

      Attendu que, conformément aux résolutions 2018.03.15.08 à 2018.03.15.11, le BAMC a invité les requérants à soumettre d’autres supports et à effectuer une présentation au BAMC afin d’appuyer la demande 16-5 ; les requérants ont rejeté les deux invitations du BAMC.

      Attendu que, le BAMC a étudié minutieusement le bien-fondé de la demande 16-5 et l’ensemble des supports y afférents et a recommandé que la demande 16-5 soit rejetée du fait que le fournisseur CPE n’a pas enfreint les politiques ou procédures établies lorsqu’il a mené la CPE et que l’organisation ICANN a respecté les politiques définies, les statuts constitutifs et l’acte constitutif lorsqu’elle a accepté le rapport CPE. Le BAMC a également recommandé que le Conseil d’administration rejette la demande 16-5 parce que les requérants n’ont pas relevé d’application erronée des politiques ou procédures par le fournisseur CPE qui aurait affecté de manière significative ou négative les requérants.

      Attendu que, le Conseil d’administration a examiné attentivement la recommandation du BAMC concernant la demande 16-5 et l’ensemble des supports y afférents, dont la réfutation du requérant, et le Conseil d’administration est d’accord avec la recommandation du BAMC et en conclut que la réfutation n’offre ni argument ni élément de preuve supplémentaire justifiant le réexamen.

      Il est résolu (2019.03.14.12) que le Conseil d’administration adopte la recommandation du BAMC relative à la demande 16-5.

      Fondements de la résolution 2019.03.14.12

      1. Bref résumé et recommandation

        L’ensemble des faits sont exposés dans la recommandation du BAMC relative à la demande 16-5 (la recommandation du BAMC), que le Conseil d’administration a examinée et prise en compte et qui est jointe aux présentes.

        Le 25 janvier 2018, le BAMC a évalué la demande 16-5 et l’ensemble des supports y afférents et a recommandé que le Conseil d’administration rejette la demande 16-5 du fait que le fournisseur CPE n’a pas enfreint les politiques ou procédures établies lorsqu’il a mené la CPE et que l’organisation ICANN a respecté les politiques définies, les statuts constitutifs et l’acte constitutif lorsqu’elle a accepté le rapport CPE. Le BAMC a également recommandé que le Conseil d’administration rejette la demande 16-5 parce que les requérants n’ont pas relevé d’application erronée des politiques ou procédures par le fournisseur CPE qui aurait affecté de manière significative ou négative les requérants.

        Le Conseil d’administration a examiné attentivement la recommandation du BAMC [PDF, 211 KB] ainsi que l’ensemble des supports liés à la demande 16-5, et le Conseil d'administration est d'accord avec la recommandation du BAMC [PDF, 211 KB].

        Le 12 février 2019, les requérants ont proposé une réfutation de la recommandation du BAMC (la réfutation). Le Conseil d’administration souligne que la réfutation n’est pas prévue par les statuts constitutifs applicables à la demande 16-5.3 Toutefois, le Conseil d’administration a tenu compte des arguments énoncés dans la réfutation des requérants et estime qu’ils ne justifient pas de réexamen pour les raisons indiquées ci-dessous.

      2. Problématique

        Les problématiques sont les suivantes :

        • La déclaration du panel du processus de révision indépendante (IRP) dans les affaires Little Birch LLC et al. v. ICANN et Despegar Online SRL et al. v. ICANN (l’IRP Despegar) oblige-t-elle le Conseil d’administration à réexaminer le rapport CPE ?
        • L’acceptation par le Conseil d’administration des avis de catégorie 1 et 2 du Comité consultatif gouvernemental (GAC) de l’ICANN obligeait-elle le fournisseur CPE à accorder à la candidature la priorité communautaire ?
        • Le fournisseur CPE avait-il un conflit d'intérêts eu égard à la candidature ?
        • L’organisation ICANN a-t-elle procédé à des révisions du rapport CPE, et si c’est le cas, ces révisions respectaient-elles les politiques ou procédures établies ?
        • Le fournisseur CPE a-t-il respecté les politiques et procédures établies dans son application du critère CPE 1 ? Quand est-il de l’établissement de la communauté ?
        • Le fournisseur CPE a-t-il respecté les politiques et procédures établies dans son application du sous-critère CPE 2-A-Lien ?
        • Le fournisseur CPE a-t-il respecté les politiques et procédures établies dans son application du sous-critère CPE 4-A-Soutien ?

        Ces problématiques sont étudiées à la lumière des normes relatives aux demandes de réexamen en vigueur au moment où cette demande 16-5 a été soumise. Ces normes sont détaillées dans la recommandation du BAMC et sont jointes aux présentes.

      3. Analyse et fondements

        1. Critères et procédures CPE

          La CPE est un mécanisme de résolution de conflits mis à la disposition des candidats qui ont qualifié leurs candidatures de candidatures communautaires.4 Les normes CPE et le processus CPE sont définis au module 4, section 4.2 du guide de candidature (le guide). Les candidatures communautaires soumises à la CPE sont évaluées via les critères suivants : Critère 1 : Établissement de la communauté ; Critère 2 : Lien entre la chaîne proposée et la communauté ; Critère 3 : Politiques d’enregistrement ; et Critère 4 : Soutien communautaire.5 Conformément au guide, les critères sont présentés dans l’ordre dans lequel ils seront évalués par le fournisseur CPE. Pour réussir une CPE, une candidature doit recevoir au moins 14 des 16 points attribués par les quatre critères, chaque critère attribuant un maximum de quatre points. Une candidature qui réussit la CPE « élimine toutes les candidatures classiques en conflit direct avec celle-ci, indépendamment du degré d’admissibilité de ces dernières » .6 La CPE est effectuée par un panel indépendant composé de deux évaluateurs désignés par le fournisseur CPE.7 Le fournisseur CPE a pour rôle de déterminer si la candidature communautaire respecte les quatre critères de priorité communautaire indiqués au module 4.2.3 du guide.8

          Le processus CPE ne détermine pas l’existence, l’adéquation ou la validité d’une communauté. Il se contente de déterminer si une candidature communautaire satisfait ou non aux critères CPE pour la priorité communautaire. Comme l’indique le guide, « si le [fournisseur CPE] arrive à la conclusion qu'une candidature n'atteint pas le seuil de notation requis pour réussir une évaluation de la priorité communautaire, cela ne signifie pas nécessairement que la communauté elle-même est inappropriée ou non valide ».9

        2. La déclaration de l’IRP Despegar ne justifie pas un réexamen.

          Les requérants avancent l’argument selon lequel le réexamen est justifié car le processus CPE est soi-disant intrinsèquement imparfait. Pour appuyer leur thèse, les requérants font référence à la déclaration de l’IRP Despegar qui, selon eux, met en avant des problèmes et craintes que le panel IRP a eu avec le processus CPE.10 Les requérants maintiennent que les craintes exprimées par le panel de l’IRP Despegar démontrent que le fournisseur CPE et l’organisation ICANN ont enfreint les politiques et procédures établies liées à l’évaluation de la candidature.11 Le panel de l’IRP Despegar a recommandé, entre autres choses, qu’un système soit mis en place pour les futures séries de nouveaux gTLD afin de garantir que les évaluations CPE sont menées « de manière cohérente et prévisible par les différents évaluateurs individuels » et que les valeurs fondamentales de l’organisation ICANN « soient diffusées . . . à des entités telles que le [fournisseur CPE] ».12 Les requérants semblent estimer que la déclaration de l’IRP Despegar oblige le Conseil d’administration soit à procéder à un examen du processus CPE dans son ensemble —ce que le Conseil d’administration a fait lors de la révision du processus CPE —soit à rejeter le rapport CPE sur le fondement de prétendues imperfections.13

          Toutefois, comme l’a conclu le BAMC, conclusion à laquelle le Conseil d'administration adhère, rien dans la déclaration de l’IRP Despegar, ni même l’acceptation par l’organisation ICANN de cette déclaration, n’impose une telle obligation. En acceptant la déclaration de l’IRP Despegar (résolution de 2016),14 le Conseil d’administration « a pris note des suggestions du panel [IRP] » et a enjoint à l’organisation ICANN de « veiller à ce que les révisions du programme des nouveaux gTLD tiennent compte des questions soulevées par le panel eu égard à l’homogénéité et à la prévisibilité du processus CPE et des évaluations des fournisseurs tiers ».15 En outre, la révision du processus CPE a permis de procéder à un nouvel examen minutieux du processus CPE, en tenant particulièrement compte de la relation de l’organisation ICANN avec le fournisseur CPE.16

          Rien dans la déclaration de l’IRP Despegar, ni même l’acceptation par l’organisation ICANN de cette déclaration, n’impose que le processus CPE soit modifié pour la candidature,17 ou que le BAMC change sa norme de révision pour les demandes de réexamen contestant les rapports CPE. Par conséquent, rien dans la déclaration de l’IRP Despegar ou la résolution de 2016 n’impose au Conseil d’administration de prendre une mesure eu égard au rapport CPE autre que celle consistant à déterminer si l’organisation ICANN et le fournisseur CPE ont respecté les politiques et procédures établies quant à ce rapport. Comme vu plus en détail ci-dessous, les requérants ne constatent aucune violation des politiques ou procédures établies pour le rapport CPE.

          De plus, quant à l’argument des requérants selon lequel la déclaration de l’IRP Despegar oblige le Conseil d’administration à procéder à un examen du processus CPE dans son ensemble, comme décrit ci-dessus, le Conseil d’administration a bel et bien procédé à un tel examen : la révision du processus CPE. DotMusic a contesté les conclusions de la révision du processus CPE dans la demande 18-5,18 contestation que le Conseil d’administration a rejetée.19 Les requérants n’ont pas trouvé d’informations importantes dont le Conseil d’administration n’aurait pas tenu compte, ou d’informations fausses ou trompeuses sur lesquelles le Conseil d’administration se serait appuyé, dans son refus d’annuler le rapport CPE à la lumière de la déclaration de l’IRP Despegar ou dans la réponse qu’il a apportée.

        3. L’acceptation par le Conseil d’administration des avis du GAC de catégorie 1 et 2 n’a aucune influence sur la revendication de priorité communautaire de DotMusic.

          Les requérants affirment que l’organisation ICANN aurait dû accorder un « traitement préférentiel » à la candidature en réponse aux avis du GAC de catégorie 1 et 2.20 L’avis du GAC de catégorie 1 suggérait que certains types de chaînes bénéficient de sauvegardes supplémentaires. Ces types de chaînes comprenaient : (a) des chaînes qui concernent des secteurs réglementés ; (b) des chaînes qui soulèvent des problèmes en matière de protection des consommateurs ; et (c) d’autres chaînes sensibles. .MUSIC était l’un des nouveaux gTLD concernés par l’avis du GAC de catégorie 1 car il s’agissait d’une chaîne qui soulevait des problèmes en matière de protection des consommateurs, à savoir des problèmes de propriété intellectuelle.21 L’avis du GAC de catégorie 2 suggérait, entre autres, que les chaînes représentant des termes génériques (les chaînes à termes génériques) ne soient pas exploitées en tant que registres à accès exclusif sauf si, ce faisant, « un objectif d’intérêt public était servi » .22 .MUSIC était également l’une des chaînes à termes génériques soumises à l’avis du GAC de catégorie 2.

          Le BAMC a déterminé, et le Conseil d'administration est d'accord, que rien dans l’acceptation du Conseil d’administration et sa réponse aux avis du GAC de catégorie 1 et 2 n'imposait à l’organisation ICANN d’accorder un « traitement préférentiel » aux candidatures communautaires pour .MUSIC.23 Les avis du GAC de catégorie 1 et 2 ne font même pas la distinction entre candidatures communautaires et candidatures standard. De plus, contrairement à ce qu’affirment les requérants, la chaîne .MUSIC était soumise à l’avis de catégorie 1 car elle soulevait des problèmes de propriété intellectuelle, et non parce qu’elle concernait un secteur réglementé.24 Ainsi, rien dans l’avis du GAC de catégorie 1 n’indiquait que .MUSIC concernait une communauté « soudée » comme le prétendaient les requérants.25 Eu égard à l’avis de catégorie 2, le GAC a affirmé que les chaînes à termes génériques, telles que .MUSIC, représentaient des termes génériques pour lesquels un accès réservé aux registres n’était pas adapté. L’avis du GAC et l’acceptation par l’organisation ICANN de l’avis de catégorie 2 n’ont ni influence sur la priorité communautaire ni lien avec cette dernière. De ce fait, le Conseil d'administration est d'accord avec la conclusion du BAMC selon laquelle l’argument des requérants ne justifie pas un réexamen.

        4. Rien dans les recommandations de l’Organisation de soutien aux extensions génériques (GNSO) n'imposait que les revendications de priorité communautaire soient « prises pour argent comptant ».

          Les requérants estiment que la CPE n’aurait pas dû être requise du tout car la GNSO de l’organisation ICANN a recommandé que les affirmations des représentants de la communauté quant à une candidature soient « prises pour argent comptant ».26 Les requérants ont mal interprété la terminologie des directives de la GNSO relatives à la mise en œuvre, qui ne sont pas les recommandations politiques de la GNSO et qui préconisent un certain type de CPE. Plus précisément, la GNSO a indiqué ce qui suit :

          Si un candidat revendique, pour sa demande de TLD, le soutien qu’apporterait ledit TLD à une communauté particulière, comme dans le cas d'un TLD sponsorisé ou de tout autre TLD réservé à une communauté précise, cette revendication sera prise pour argent comptant sauf dans les cas suivants :

          (i) la revendication concerne une chaîne faisant l'objet d'une autre candidature et n'est utilisée que dans le but d'obtenir la priorité pour cette candidature ; et

          (ii) une procédure d'objection officielle a été lancée.27

          Par conséquent, le guide prévoit ce qui suit : « L’évaluation de la qualification de communautaire par un candidat est menée uniquement en cas de conflit aboutissant à une évaluation de la priorité communautaire. »28 Un candidat à une candidature communautaire doit choisir d’être soumis à une CPE même si cela n’est pas requis. De tels candidats choisissent de se soumettre à une CPE car ce n’est que via la CPE qu'ils peuvent se voir accorder la priorité sur d’autres candidatures concurrentes pour la même chaîne.29 Ainsi, aucune politique ou procédure établie n’exige que l’organisation ICANN « prenne pour argent comptant » la revendication de priorité communautaire de DotMusic. L’ICANN n’a donc pas enfreint de politiques ou procédures en refusant de « prendre pour argent comptant » la revendication de priorité communautaire de DotMusic.

        5. Les requérants n’ont pas prouvé l’existence de conflits d’intérêts de la part du fournisseur CPE.

          Les requérants soutiennent que le fournisseur CPE avait un conflit d'intérêts concernant la candidature car Eric Schmidt, directeur général de Google de 2001 à 2017, était membre du Conseil d'administration de l’Economist Group, la société mère du fournisseur CPE, de novembre 2013 à décembre 2015,30 Vint Cerf, vice-président de Google depuis 2003, « a présidé un panel de stratégie de l’ICANN en 2013 (lorsque les candidatures étaient en cours d’évaluation) », et Google a également soumis une candidature pour .MUSIC.31 Le Conseil d'administration est d'accord avec le BAMC, cet argument ne justifie pas un réexamen, et ce pour les raisons suivantes.

          Premièrement, les requérants ne présentent aucune preuve démontrant que le fournisseur CPE n’a pas confirmé qu’aucun des panélistes de l’évaluation ou des principaux membres d’équipe avait des conflits d’intérêts eu égard aux candidatures communautaires tel que requis par le guide, le document décrivant le processus du panel CPE et les directives relatives à la CPE.32 Les requérants n’ont pas affirmé qu’Eric Schmidt —un haut dirigeant— était panéliste de l’évaluation ou principal membre d’équipe (il ne l’était pas), ou qu’il avait eu une influence sur le rapport CPE ou avait connaissance de ce dernier (ou même qu’il avait un lien quelconque avec le fournisseur CPE, qui est une division à part entière de l’Economist Group). De fait, le rapport CPE a été publié deux mois après que M. Schmidt a cessé d’être membre du conseil d'administration de l’Economist Group.33 De même, DotMusic n’a pas expliqué dans quelle mesure la présence de Vint Cerf dans le panel de stratégie de l’ICANN relatif à l’écosystème de gouvernance de l'Internet 34 en 2013, trois ans avant la publication du rapport CPE, avait eu un quelconque impact sur la candidature.

          Deuxièmement, le seul fondement de l’argument de partialité des requérants est qu’ils soutiennent (sur la base d’extraits tirés de 22 rapports CPE) que les candidatures communautaires en concurrence avec Google avaient plus de chance de ne pas réussir la CPE.35 Le fait que de nombreuses candidatures n’aient pas réussi la CPE n’apporte pas la preuve d’un vice de procédure. Une candidature qui réussit la CPE se voit accorder la priorité sur toutes les autres candidatures, le processus CPE plaçant ainsi volontairement la barre haute pour la réussite d’une candidature.36 De ce fait, le fait que de nombreuses candidatures n’ont pas réussi la CPE ne prouve en aucun cas que le fournisseur CPE n’a pas respecté les politiques et procédures établies afin de garantir que les membres du fournisseur CPE n’ont pas de conflits d’intérêts concernant la candidature.37 De plus, le rapport CoE sur lequel DotMusic fonde ces arguments arrive à la conclusion suivante : « rien ne prouve que Google ait influencé d’une quelconque façon les décisions prises sur les CPE ».38

        6. L’organisation ICANN ne participe pas à la notation des critères CPE.

          Les requérants prétendent que certaines communications entre l’organisation ICANN et le fournisseur CPE identifiées dans le cadre de l’IRP Dot Registry v. ICANN (les communications CPE) prouvent que l’organisation ICANN a procédé à une révision « importante » du rapport CPE, en violation des politiques et procédures établies.39 Le BAMC est arrivé à la conclusion, que le Conseil d'administration soutient, selon laquelle rien dans les communications CPE ne vient étayer l’opinion des requérants selon laquelle l’organisation ICANN a révisé la notation du fournisseur CPE concernant la candidature de DotMusic. Le rapport 1 sur la portée de la révision du processus CPE confirme que « rien ne prouve que l’organisation ICANN ait eu une influence indue sur le fournisseur CPE eu égard aux rapports CPE publiés par le fournisseur CPE ou n’ait commis d’irrégularités dans le processus CPE », y compris concernant la candidature.40 Lorsque l’organisation ICANN a fourni des feedbacks au fournisseur CPE, ces feedbacks ne préconisaient pas de contester les conclusions du fournisseur CPE (y compris les notations) mais plutôt de s’assurer que les rapports CPE étaient clairs et « que le fournisseur CPE avait fait une présentation détaillée de chacun des critères CPE dans le rapport CPE ».41 Le cabinet FTI a constaté que « l’organisation ICANN n’avait pas suggéré que le fournisseur CPE modifie la notation finale ou ajuste les fondements exposés dans les rapports CPE ».42

          Les requérants ne font état d’aucune politique ou procédure (car il n’y en a pas) empêchant l’organisation ICANN de communiquer avec le fournisseur CPE sur la terminologie utilisée dans les rapports CPE. De même, rien dans les communications CPE ne prouve, comme le prétendent les requérants, que le fournisseur CPE ne dispose pas de l’expertise requise afin de mener des CPE. Ainsi, les requérants n’ont pas invoqué de fondement qui justifierait un réexamen à cet égard.

        7. Le rapport CPE ne portait pas atteinte aux garanties de procédure régulière.

          Le Conseil d'administration est d’accord avec la position du BAMC qui estime que l’affirmation des requérants selon laquelle le fournisseur CPE et l’organisation ICANN n’ont pas « respecté la procédure régulière » ne justifie pas de réexamen.43 Les requérants n’ont pas prouvé le non-respect par le fournisseur CPE des politiques et procédures établies pour la CPE tel qu’indiqué dans le guide.

          Le BAMC a noté que les statuts constitutifs concernés ne font pas référence aux garanties de procédure régulière.44 En fait, les requérants suggèrent qu’il devrait y avoir une procédure d’appel officielle pour les décisions prises par des fournisseurs de services tiers de l’organisation ICANN, y compris le fournisseur CPE, la commission chargée des objections pour violation des droits d’autrui et les panels relatifs aux chaînes prêtant à confusion. Les méthodes permettant de contester des décisions dans le cadre du processus de résolution des conflits des gTLD sont indiquées dans le guide, qui a été développé après des années d’intenses débats avec toute une gamme de groupes de parties prenantes, dont des gouvernements, des particuliers, la société civile, les unités constitutives des utilisateurs commerciaux et des représentants de la propriété intellectuelle, et la communauté technologique.45 Plusieurs versions préliminaires du guide ont été publiées à des fins de consultation publique et révisées à la lumière des retours pertinents de la communauté.46 Le temps où il était possible de contester le guide est depuis longtemps révolu.47

          En outre, le guide fournit un moyen de contester les résultats du processus CPE : Le module 6 du guide prévoit que les candidats, y compris DotMusic, « pourront avoir recours à tout mécanisme de responsabilité figurant dans les statuts constitutifs de l’ICANN afin de contester toute décision finale prise par l’ICANN eu égard à la candidature ».48 Les requérants ont exercé ce droit en invoquant le processus de réexamen à plusieurs reprises,49 notamment avec la demande 16-5.

          L’application par le fournisseur CPE des critères CPE à la candidature étant conforme au guide, l’acceptation par l’organisation ICANN du rapport CPE était également conforme aux politiques et procédures en vigueur et aucune atteinte aux garanties de procédure régulière n’était à signaler. Le fait qu’il n’y avait pas de possibilité de faire appel des résultats substantielles de l’évaluation ne signifie pas non plus qu’il y a eu atteinte aux garanties de procédure régulière.

        8. La revendication des requérants concernant les recettes provenant des enchères ne justifie pas de réexamen.

          Le Conseil d'administration est d’accord avec la conclusion du BAMC qui estime que les requérants n’ont pas fourni de preuve (car il n’y en a pas) soutenant leur revendication selon laquelle l’acceptation par l’organisation ICANN du rapport CPE relevait d’une obligation financière à générer des recettes via le processus d’enchère. De plus, les requérants n’ont pas démontré de violation d’une politique ou procédure de l’ICANN en vigueur. Cet argument ne justifie donc pas un réexamen.

        9. Le fournisseur CPE a respecté les politiques et procédures établies dans son application des critères CPE.

          Les requérants contestent la décision du fournisseur CPE de n’attribuer que 10 des 16 points possibles à la candidature. Pour les raisons indiquées à la section VI.I de l’annexe 1 de la recommandation du BAMC qui est incorporée par renvoi dans les présentes, le Conseil d'administration accepte les conclusions du BAMC selon lesquelles le réexamen n’est pas justifié car les requérants n’ont pu prouver que le fournisseur CPE avait violé une politique ou procédure établie lors de la notation de la candidature. En outre, le Conseil d'administration est d’accord avec le BAMC sur le fait que l’argument des requérants est en complet désaccord avec les conclusions du fournisseur CPE et que cela ne constitue pas un fondement suffisant pour un réexamen.

        10. Les revendications des requérants concernant la révision du processus CPE ne justifient pas un réexamen.

          Le BAMC a déterminé, et le Conseil d'administration est d'accord avec lui, que les revendications des requérants concernant la révision du processus CPE ne justifient pas un réexamen pour toutes les raisons détaillées dans la section VI.K de l’annexe 1 à la recommandation du BAMC qui est incorporée par renvoi dans les présentes. Plus particulièrement, le Conseil d’administration estime que les critiques des requérants concernant la conclusion de la révision du processus CPE ne justifient pas le réexamen. Le Conseil d’administration indique également avoir répondu à bon nombre des craintes des requérants dans sa décision sur la demande de réexamen 18-5 qui est incorporée par renvoi dans les présentes.

          Le Conseil d’administration est également d’accord avec la conclusion du BAMC selon laquelle la demande du requérant, DotMusic 50, visant à ce que l’organisation ICANN divulgue tous les documents portant sur la révision du processus CPE n’est requise par aucune politique ou procédure établie. En outre, le Conseil d’administration a déjà répondu à la demande de DotMusic visant à obtenir les mêmes documents dans sa décision sur la demande de réexamen 18-1 qui est incorporée par renvoi dans les présentes. Le Conseil d’administration est également d’accord avec la conclusion du BAMC selon laquelle aucune politique ou procédure établie n’impose à l’organisation ICANN de prendre en charge les coûts et dépenses engagés par DotMusic afin d’examiner les documents présentés par l’organisation ICANN et de préparer les soumissions supplémentaires de ces documents au BAMC. Le Conseil d’administration est aussi d’accord avec le BAMC quant au fait qu’aucune politique ou procédure n'impose à l’organisation ICANN de fournir à DotMusic une liste de craintes spécifiques concernant la demande 16-5 suite à la soumission supplémentaire de DotMusic et de planifier une présentation physique afin de dissiper ces craintes (une fois que les conditions susmentionnées sont remplies).51

        11. La réfutation ne présente aucun argument ou fait justifiant le réexamen.

          Dans un premier temps, la demande 16-5 a été soumise conformément aux statuts constitutifs du 11 février 2016, voir la discussion ci-dessus, qui n’exigent pas de réfutation à la recommandation du BAMC.52 Toutefois, le Conseil d’administration a examiné la réfutation des requérants et estime qu'ils n'ont pas fourni de nouveaux arguments ou faits justifiant le réexamen.

          1. Les arguments des requérants concernant la définition de la communauté ne justifient pas de réexamen.

            Les requérants prétendent que le fournisseur CPE a appliqué de manière erronée les critères d’évaluation à l’établissement de la communauté (critère 1) car il s’est appuyé sur la définition de la communauté donnée en réponse à la question 20D de la candidature de DotMusic. Les requérants soutiennent que le guide imposait au fournisseur CPE de s’appuyer uniquement sur la définition de la communauté figurant dans la réponse de DotMusic à la question 20A.53 En appui à cet argument, les requérants renvoient à un tableau de l’annexe 2 au module 2 du guide qui explique les questions d’évaluation, les critères, la notation et la méthodologie d’évaluation de candidatures à des nouveaux gTLD.54 L’explication de la colonne « Question » du tableau pour la question 20A est la suivante :

            Fournir le nom et la description complète de la communauté que le candidat s'engage à servir. Dans le cas où cette candidature est soumise à une évaluation de priorité communautaire, elle sera notée en tenant compte de la communauté identifiée dans la réponse à cette question. Le nom de la communauté ne doit pas être officiellement adopté afin de qualifier la candidature de communautaire.55

            Les requérants affirment que cette explication imposait au fournisseur CPE d’appliquer la définition de la communauté figurant dans la réponse de DotMusic à la question 20A. Le Conseil d’administration estime que cet argument ignore l’explication donnée dans la colonne « Critère » pour la question 20A qui est telle que suit :

            Les réponses à la question 20 seront considérées comme des engagements fermes envers ladite communauté et consignées dans le contrat de registre, à condition que la candidature soit retenue. Les réponses ne sont pas notées dans l'évaluation initiale. Les réponses peuvent être notées dans une évaluation de la priorité communautaire, le cas échéant. Les critères et la méthodologie de notation pour l'évaluation de la priorité communautaire sont décrits dans le module 4 du guide de candidature.56

            Aucune disposition du module 4 du guide n’impose au fournisseur CPE de ne tenir compte que de la réponse de DotMusic à la question 20A sans se pencher sur le reste de la candidature lors de l’évaluation du critère 1.57 De ce fait, le Conseil d’administration estime que cet argument ne justifie pas de réexamen car les requérants n’ont pas prouvé que l’évaluation du critère effectuée par le fournisseur CPE était contraire au guide ou à toute autre politique ou procédure établie.

            Deuxièmement, DotMusic prétend que le fournisseur CPE utilisait la mauvaise définition de communauté car le fournisseur CPE « n’a pas explicitement fait mention de la définition de communauté du requérant lors de son CPE » et « a créé sa propre définition générale de la communauté qui découlait de la question 20D ».58 En réponse à la question 20A (« le nom et la description complète de la communauté que le candidat s'engage à servir »), DotMusic a indiqué que le nom de la communauté était la « communauté musicale », puis il a décrit la communauté. Dans sa description de la communauté, DotMusic a précisé que « la communauté musicale est strictement définie à l’aide de codes NAICS établis. . . organisée avec la définition suivante », puis a dressé une liste des codes NAICS que le fournisseur CPE a incluse dans le rapport CPE.59 De ce fait, même si le fournisseur CPE avait été tenu de ne tenir compte que de la réponse de DotMusic à la question 20A—ce qui n’était pas le cas—l’examen effectué par le fournisseur CPE des codes NAICS aurait été convenable.

            Troisièmement, les requérants affirment que la terminologie utilisée dans la réponse de DotMusic à la question 20D concernait le « critère d’éligibilité », non pas la définition de la communauté, et par conséquent le fournisseur CPE n’aurait pas dû en tenir compte lorsqu’il a évalué le critère 1.60 Tel qu’expliqué ci-dessus, le guide n’exige pas ce niveau de séparation. De plus, le Conseil d’administration note que la question 20D ne fait pas référence à l’éligibilité. La question 20D demandait à DotMusic d’ « [e]xpliquer la relation entre la chaîne gTLD faisant l’objet d'une candidature et la communauté identifiée à la [question 20A] ».61

            En réponse à la question 20D, DotMusic a indiqué, entre autres, que « .MUSIC est lié à la communauté en représentant toutes les unités constitutives impliquées dans la création, la production et la distribution musicales, y compris les organismes culturels et conseils des arts publics ainsi que d’autres organisations complémentaires [sic] menant des activités de soutien conformes à la mission de .MUSIC ».62 DotMusic ne voit aucun critère du guide ou aucune politique ou procédure en vigueur qui aurait interdit au fournisseur CPE de tenir compte des « unités constitutives » « représentées » par la communauté définie dans la candidature lorsqu’il a évalué l’établissement de la communauté. Pour ce motif supplémentaire, cet argument ne justifie pas un réexamen.

            Quatrièmement, DotMusic prétend que, du fait qu'il a défini la communauté musicale comme une « communauté organisée d’individus, d’organisations et d’entreprises, une alliance logique de communautés de même nature (« COMMUNAUTÉ »), qui est liée par la musique », le fournisseur CPE était tenu de « reconnaître que [DotMusic] répondait parfaitement à la définition d’une « alliance logique » qui est « connue et reconnue » parmi ses membres ».63 Le BAMC a répondu à cet argument dans sa recommandation 64 et le Conseil d’administration incorpore aux présentes le raisonnement du BAMC tel qu’il a été formulé. Le BAMC a souligné que le guide prévoyait qu’ « une alliance logique de communautés » était « viable » en tant que communauté, « à condition que les conditions de connaissance et reconnaissance de la communauté soient présentes au sein des membres ».65 Comme le fournisseur CPE n’a pas trouvé ces conditions de connaissance et reconnaissance parmi les membres de la communauté globale, le fournisseur CPE a suivi la directive du guide et a attribué zéro point à la candidature pour le critère 1.66

          2. Les autres arguments des requérants ont été préalablement analysés et ne justifient pas de réexamen.

            Les requérants réitèrent les critiques à l’encontre des rapports sur la révision du processus CPE qui ont déjà été soulevés plusieurs fois, notamment dans la demande 18-5.67 Le Conseil d’administration a répondu à ces arguments le 18 juillet 2018, réponses qui sont incorporées par renvoi dans les présentes.68 Les autres arguments des requérants dans leur réfutation reprennent les arguments avancés dans la demande 16-5 et les supports soumis à l’appui de cette demande, et le BAMC a tenu compte de tous ces documents lors de l’élaboration de sa recommandation.

          3. La réponse des requérants à l’invitation à fournir des informations supplémentaires.

            Enfin, le Conseil d’administration doit répondre à l’affirmation des requérants selon laquelle ils n’ont jamais « rejeté » l’invitation du BAMC à fournir des documents supplémentaires à l’appui de la demande 16-5. Dans la réfutation, les requérants précisent qu’il est « inexact » de qualifier leur réponse à l’invitation du BAMC de rejet.69 La formulation de leur réponse est pourtant sans équivoque. Le 5 avril 2018, en réponse à l’invitation du BAMC à soumettre des documents supplémentaires, les requérants ont répondu ce qui suit : « DotMusic rejette la tentative de l’ICANN d’imposer des contraintes artificielles sur toutes soumissions supplémentaires concernant la demande de réexamen 16-5 ». Par la suite, DotMusic n’a soumis aucun document supplémentaire.70 Il n’est pas correct de suggérer à présent que la réponse de DotMusic au BAMC constituait plutôt une demande « de soumissions écrites libres et de présentation physique ».71

            Pour les motifs précédents, le Conseil d’administration est arrivé à la conclusion que le réexamen n’était pas justifié.

            Cette action relève de la mission de l’ICANN et sert l'intérêt public dans la mesure où il est important de veiller à ce que, dans le cadre de sa mission et à l'égard de la communauté, l'ICANN mène ses activités dans le respect de l'acte constitutif, des statuts constitutifs et autres procédures établies, via un processus permettant à une personne ou une entité substantiellement affectée par une action du Conseil d'administration ou du personnel de l'ICANN de demander le réexamen, par le Conseil d'administration, de cette action ou inaction. L’adoption de la recommandation du BAMC n’a pas de répercussions financières sur l’ICANN et n’aura aucune incidence sur la sécurité, 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.

    5. Examen de .AMAZON

      Aucune résolution n’est adoptée.

    6. Acceptation de la seconde révision organisationnelle du NomCom – Rapport final et recommandations

      Attendu que, la deuxième révision organisationnelle du Comité de nomination (NomCom) a débuté en juin 2017 conformément au chapitre 4, article 4.4 des statuts constitutifs de l’ICANN.

      Attendu que, l’auditeur indépendant qui a mené la deuxième révision du NomCom a rédigé un rapport d’évaluation qui a été publié à des fins de consultation publique le 10 janvier 2018, la version préliminaire du rapport final qui a été publiée à des fins de consultation publique le 27 mars 2018, et un rapport final, contenant vingt-sept (27) recommandations, qui a été publié le 5 juin 2018.

      Attendu que, l’équipe chargée de la planification de la mise en œuvre de la révision du NomCom a analysé la faisabilité et l’utilité des recommandations de l’auditeur indépendant, a réfléchi aux répercussions budgétaires provisoires, et a estimé les ressources requises afin de proposer un calendrier de mise en œuvre hiérarchisé.

      Attendu que, l’équipe chargée de la planification de la mise en œuvre de la révision du NomCom a préparé une version préliminaire du document Évaluation de faisabilité et plan initial de mise en œuvre (le FAIIP) et l’a présentée aux groupes de la communauté intéressés lors de l’ICANN63 ; elle a reçu un large soutien de la part de son auditoire.

      Attendu que, après avoir consulté régulièrement la communauté et les NomComs 2018 et 2019, l’équipe chargée de la planification de la mise en œuvre a approuvé le FAIIP final par consensus absolu le 14 décembre 2018.

      Attendu que, le Conseil d’administration prend note que le processus d’approbation du FAIIP n’a pas complètement reflété la procédure détaillée dans l’organigramme, qui prévoit que l’organisation de soutien (SO) ou le comité consultatif (AC) soumis à la révision approuve le FAIIP. Cet écart s’explique par le rôle et la composition du NomCom qui diffèrent considérablement de ceux des conseils et dirigeants de ces SO et AC soumis aux révisions organisationnelles.72 Le soutien unanime apporté par l’équipe chargée de la planification de la mise en œuvre au FAIIP, la représentativité de ses membres, la transparence de ses travaux et la responsabilité de ses initiatives de sensibilisation dans le cadre de ses missions, y compris lors de l’ICANN63, tout cela compense le manque d’approbation officielle d’un comité ou conseil consultatif lors de la révision organisationnelle d’une SO ou d’un AC.

      Attendu que, l’équipe chargée de la planification de la mise en œuvre de la révision du NomCom a soutenu les 27 recommandations de l’auditeur indépendant, tout en apportant de légères modifications à quatre d’entre elles, tel que détaillé dans le FAIIP.

      Attendu que, le Comité du Conseil d’administration chargé de l'efficacité organisationnelle (OEC) du Conseil d'administration de l'ICANN a reçu des informations de l’auditeur indépendant sur son rapport final et de l’équipe chargée de la planification de la mise en œuvre de la révision du NomCom sur son FAIIP lors de la réunion de l’OEC du 8 janvier 2019.

      Attendu que, l’OEC a examiné le rapport final, le FAIIP et les commentaires publics afin de parvenir à une recommandation sur la façon d’effectuer la deuxième révision du NomCom, recommandation qui sera transmise au Conseil d’administration. L’OEC a recommandé au Conseil d’administration d’accepter le rapport final de la révision du NomCom de l’auditeur indépendant ainsi que le FAIIP de l’équipe chargée de la planification de la mise en œuvre. L’OEC a également recommandé au Conseil d’administration d’enjoindre à l’équipe chargée de la planification de la mise en œuvre de la révision du NomCom de former un groupe de travail sur la mise en œuvre chargé de définir un plan de mise en œuvre détaillé pour les recommandations, tel que détaillé dans le FAIIP, dans un délai de six mois à compter de l’adoption de cette résolution, et à ce groupe de travail sur la mise en œuvre de contrôler la mise en œuvre de ces recommandations, une fois que le Conseil d’administration aura approuvé ledit plan de mise en œuvre détaillé.73

      Il est résolu (2019.03.14.13) que le Conseil d’administration salue le travail ardu de l’auditeur indépendant et remercie ce dernier d’avoir produit un rapport final complet afin d’améliorer l’efficacité, la responsabilité et la transparence du NomCom.

      Il est résolu (2019.03.14.14) que le Conseil d’administration salue le travail et le soutien du Groupe de travail sur la révision du NomCom et de l’équipe chargée de la planification de la mise en œuvre de la révision du NomCom lors du processus de révision. Le Conseil d’administration remercie l’équipe chargée de la planification de la mise en œuvre de la révision du NomCom pour son travail ardu et pointu d’élaboration du document Évaluation de faisabilité et plan initial de mise en œuvre qui a été approuvé par consensus absolu par l’équipe chargée de la planification de la mise en œuvre de la révision du NomCom le 14 décembre 2018.

      Il est résolu (2019.03.14.15) que le Conseil d’administration accepte le rapport final de l’auditeur indépendant.

      Il est résolu (2019.03.14.16) que le Conseil d’administration accepte le document Évaluation de faisabilité et plan initial de mise en œuvre de l’équipe chargée de la planification de la mise en œuvre de la révision du NomCom, sous réserve de coûts de mise en œuvre raisonnables. Le Conseil d’administration enjoint au président-directeur général de l'ICANN, ou à son ou ses représentants, de soutenir l’équipe chargée de la planification de la mise en œuvre de la révision du NomCom dans l’élaboration et la soumission au Conseil d’administration, via l’OEC, d'un plan de mise en œuvre des recommandations acceptées. Le président-directeur général de l'ICANN, ou son ou ses représentants, sont tenus de faire régulièrement un point au Conseil d’administration sur le plan et les retours de la communauté.

      Il est résolu (2019.03.14.17) qu’afin de soutenir cette décision, le Conseil d’administration demande à l’équipe chargée de la planification de la mise en œuvre de la révision du NomCom de former un groupe de travail chargé de rédiger un plan de mise en œuvre détaillé des recommandations, tel que prévu dans le FAIIP. Le plan de mise en œuvre détaillé sera soumis au Conseil d’administration dès que possible, mais dans un délai maximum de six mois à compter de l’adoption de cette résolution. Le plan de mise en œuvre doit contenir un calendrier réaliste pour la mise en œuvre, une définition des résultats escomptés, une explication de la manière dont la mise en œuvre permet de répondre aux problèmes sous-jacents identifiés dans le rapport final, et un moyen de mesurer la situation actuelle ainsi que les progrès réalisés afin d’atteindre les résultats escomptés. Le groupe de travail travaillera également avec l’organisation ICANN afin d'inclure l’impact budgétaire prévu pour chaque étape de mise en œuvre dans son plan de mise en œuvre détaillé. Le plan de mise en œuvre intégrera une approche progressive permettant de mettre en œuvre en premier les améliorations faciles à mettre en œuvre et les moins coûteuses ; les points impliquant de plus grandes dépenses seront traités plus tard au cours du processus de mise en œuvre.

      Il est résolu (2019.03.14.18) que le Conseil d’administration enjoint au Groupe de travail sur la mise en œuvre de la révision du NomCom de contrôler le processus de mise en œuvre, une fois que le Conseil d’administration aura accepté le plan de mise en œuvre détaillé. Toute demande budgétaire liée à la mise en œuvre sera formulée conformément aux processus budgétaires annuels de l’organisation ICANN.

      Il est résolu (2019.03.14.19) que le Conseil d’administration enjoint au Groupe de travail sur la mise en œuvre de la révision du NomCom de fournir à l’OEC des rapports de mise en œuvre semi-annuels faisant état des progrès réalisés par rapport au plan de mise en œuvre, y compris, sans s’y limiter, les progrès réalisés par rapport aux indicateurs détaillés dans le plan de mise en œuvre et l’utilisation du budget alloué.

      Fondements des résolutions 2019.03.14.13 - 2019.03.14.19

      Pourquoi le Conseil d’administration aborde-t-il cette question maintenant ?

      Afin de garantir que le modèle multipartite de l’ICANN reste transparent et responsable, et afin d’améliorer ses performances, l’ICANN procède à des révisions organisationnelles de ses organisations de soutien (SO), comités consultatifs (AC) (autres que le Comité consultatif gouvernemental) et du Comité de nomination (NomCom), tel que prévu dans le chapitre 4, article 4.4 de ses statuts constitutifs. La deuxième révision du NomCom a débuté en juin 2017. L’auditeur indépendant procédant à la révision a élaboré un rapport final qui a été publié en juin 2018. Sur la base de son examen en profondeur du rapport final de l’auditeur indépendant, l’équipe chargée de la planification de la mise en œuvre de la révision du NomCom a préparé le document Évaluation de faisabilité et plan initial de mise en œuvre (FAIIP), adopté par consensus absolu le 14 décembre 2018.

      Cette décision tient également compte du fait que l’approche traditionnelle adoptée par l’ICANN pour l’évaluation et la mise en œuvre des recommandations issues de processus de révision n’est pas durable, et qu’avant de prendre acte des recommandations du rapport final, l’ICANN doit instaurer un dialogue avec la communauté sur les processus via lesquels l’ICANN et la communauté peuvent identifier ensemble des priorités et mettre en place une cadence durable pour la mise en œuvre des recommandations découlant des révisions.

      Quelle est la proposition à l’étude ?

      La proposition à l’étude consiste pour le Conseil d’administration à accepter le rapport final, à accepter le document Évaluation de faisabilité et plan initial de mise en œuvre (FAIIP), et à enjoindre à l’équipe chargée de la planification de la mise en œuvre de la révision du NomCom de former un groupe de travail sur la mise en œuvre de la révision du NomCom chargé de contrôler la mise en œuvre des recommandations, tel que prévu dans le FAIIP.

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

      Dans le cadre de ses travaux sur la révision du NomCom, l’auditeur indépendant a mené plus de 60 entretiens avec des membres actuels et d’anciens membres du NomCom, de la communauté de l’ICANN dans son ensemble, du Conseil d'administration de l'ICANN et de l’organisation ICANN, et a recueilli 85 réponses individuels à son enquête en ligne. L’auditeur indépendant a régulièrement organisé des réunions avec le Groupe de travail sur la révision du NomCom tout au long de la révision, y compris des réunions publiques lors de l’ICANN61 et l’ICANN62 et des réunions avec des groupes de la communauté lors de l’ICANN63, une consultation publique sur le rapport d’évaluation, et un séminaire web sur la version préliminaire du rapport final.

      L’auditeur indépendant a publié son rapport d’évaluation et la version préliminaire de son rapport final à des fins de consultation publique. Dix commentaires ont été soumis au forum de consultation publique, un commentaire d’un individu et neuf pour le compte d’organisations. (Voir le rapport de synthèse sur la procédure de consultation publique). Le Groupe de travail sur la révision du NomCom a également donné des feedbacks directs à l’auditeur indépendant sur les versions préliminaires initiales du rapport d’évaluation, la version préliminaire du rapport final et le rapport final.

      L’OEC a reçu des informations de l’auditeur indépendant sur son rapport final et de l’équipe chargée de la planification de la mise en œuvre de la révision du NomCom sur son FAIIP lors de sa réunion du 8 janvier 2019. L’OEC a aussi examiné les feedbacks de la communauté sur le rapport d’évaluation et la version préliminaire du rapport final de l’auditeur indépendant.

      Quelles sont les inquiétudes ou questions soulevées par la communauté ?

      Bien que l’équipe chargée de la planification de la mise en œuvre de la révision du NomCom adhère à l’esprit de toutes les recommandations de l’auditeur indépendant, elle a fait part de craintes concernant la formulation de quatre recommandations. L’équipe chargée de la planification de la mise en œuvre de la révision du NomCom a répondu aux craintes en apportant des modifications sémantiques à ces quatre recommandations.

      En général, les commentaires publics dont a tenu compte l’auditeur indépendant dans la version préliminaire de son rapport final font part d’un soutien global aux conclusions et recommandations incluses dans le rapport.

      De plus, la communauté a également soutenu la version préliminaire du document Évaluation de faisabilité et plan initial de mise en œuvre que l’équipe chargée de la planification de la mise en œuvre a présentée aux groupes de la communauté intéressés lors de l’ICANN63.

      Quels sont les principaux documents examinés par le Conseil d’administration ?

      Le Conseil d’administration a examiné les dispositions des statuts constitutifs concernées, le rapport final de l’auditeur indépendant, le FAIIP de l’équipe chargée de la planification de la mise en œuvre de la révision du NomCom, et les feedbacks de la communauté sur le rapport d'évaluation et la version préliminaire du rapport final de l’auditeur indépendant, et a tenu compte des observations de l’OEC afin de formuler cette recommandation.

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

      Le Conseil d’administration prend acte du soutien global de l’équipe chargée de la planification de la mise en œuvre de la révision du NomCom et de la communauté eu égard à la version préliminaire du rapport final et au rapport final de l’auditeur indépendant et les a examinés avec d’autres retours de la communauté reçus lors du processus de révision du NomCom.

      Pour les quatre recommandations dont l’équipe chargée de la planification de la mise en œuvre de la révision du NomCom a modifié la formulation tout en respectant leur esprit, le Conseil d’administration estime que les modifications proposées, et les fondements fournis dans le FAIIP, sont à même de résoudre les problèmes identifiés par l’auditeur indépendant dans le rapport final. Par conséquent, le Conseil d’administration accepte le rapport final et le FAIIP.

      La mise en œuvre des améliorations proposées constitue une étape importante pour veiller à ce que le NomCom soit, après la révision, en mesure de s’acquitter du rôle et des responsabilités qui lui ont été confiés en vertu des statuts constitutifs.

      Y a-t-il des effets positifs ou négatifs pour la communauté ?

      Cette décision du Conseil d’administration est censée avoir un impact positif sur la communauté dans la mesure où elle soutient le processus continu de facilitation des révisions périodiques des SO et AC de l’ICANN, tel que prévu par les statuts constitutifs. De plus, la mise en œuvre des recommandations entraînera des améliorations de la transparence, de la responsabilité et de l’efficacité du NomCom.

      Y a-t-il des répercussions financières sur l’ICANN (plan stratégique, plan opérationnel, budget), la communauté et/ou le public ?

      Cette décision du Conseil d’administration aura des répercussions financières qui seront répertoriées dans le prochain plan de mise en œuvre détaillé, qui sera lui-même soumis ultérieurement à l’examen du Conseil d’administration. Le plan de mise en œuvre détaillé indiquera comment toutes exigences budgétaires seront intégrées dans les futurs cycles budgétaires de l’ICANN.

      Y a-t-il des implications sur la sécurité, la stabilité ou la résilience du DNS ?

      Cette décision du Conseil d’administration n’est pas censée avoir d’incidence directe sur les questions liées à la sécurité, la stabilité ou la résilience du DNS.

      Dans quelle mesure cette décision s’inscrit-elle dans la mission de l’ICANN et quel intérêt public sert-elle ?

      La décision du Conseil d’administration est conforme à la mission et aux engagements de l’ICANN en vertu du chapitre 4 des statuts constitutifs afin de garantir que le modèle multipartite de l’ICANN reste transparent et responsable, et afin d’améliorer les performances de ses organisations de soutien et comités consultatifs.

      Cette décision servira l’intérêt public car elle contribuera à honorer l’engagement de l’ICANN à assurer et renforcer sa responsabilité et sa transparence.

      Une consultation publique est-elle nécessaire avant que le Conseil d’administration prenne une décision ?

      La version préliminaire du rapport final de l’auditeur indépendant a été publiée à des fins de consultation publique. La version préliminaire du document Évaluation de faisabilité et plan initial de mise en œuvre a été présentée aux groupes de la communauté intéressés lors de l’ICANN63. Aucune nouvelle consultation publique n’est requise avant que le Conseil d’administration prenne sa décision.

    7. Prochaines étapes concernant la composition de l’équipe chargée de la révision des fonctions IANA relatives au nommage

      Aucune résolution n’est adoptée.

    8. Divers

      1. Projet d’analyse de la collision de noms – Première étude

        Attendu que, le 2 novembre 2017, le Conseil d’administration a demandé au Comité consultatif sur la sécurité et la stabilité (SSAC) de l’ICANN d’élaborer un plan pour l’approbation du Conseil d’Administration, composé d’études sur le thème de la collision de noms regroupant de nombreuses informations détaillées. Voir https://www.icann.org/resources/board-material/resolutions-2017-11-02-en#2.a.

        Attendu que, le SSAC a transmis, en septembre 2018, une proposition de projet d’analyse de la collision de noms (NCAP) comprenant trois études censées répondre à l’appel de la résolution 2017 du Conseil d’administration.

        Attendu que, en octobre 2018, le Comité technique du Conseil d’administration (BTC) a demandé à l’organisation ICANN, via le Bureau du directeur de la technologie (OCTO), d’évaluer la proposition de NCAP. Par la suite, l’OCTO et le SSAC ont mené des discussions qui ont permis à l’OCTO d’obtenir des informations supplémentaires et de mieux comprendre les éléments de la proposition.

        Attendu que, l’évaluation de l’OCTO a permis d’indiquer qu’il serait utile de disposer d’une étude et d’une synthèse des précédentes recherches menées sur les collisions de noms. Toutefois, un référentiel de données et des politiques relatives à l’utilisation de ce référentiel pourraient ne pas s’avérer nécessaires s’il était décidé à l’avenir de ne plus poursuivre l’étude 2 et l’étude 3. De ce fait, l’OCTO a précisé la portée de la proposition d’étude 1 du SSAC sur la situation actuelle des collisions de noms afin de reporter la mise en œuvre d'un référentiel de données et l’élaboration de politiques y afférentes.

        Attendu que, l’OCTO a mis en avant pour le BTC une proposition d’étude sur la situation actuelle des collisions de noms avec trois objectifs : 1) examiner tous les travaux antérieurs sur la question des collisions de noms et rédiger un rapport de synthèse incorporant d’importantes connaissances tirées des travaux antérieurs dans cette étude, et qui pourrait faire office d’introduction aux personnes découvrant cette thématique ; 2) dresser une liste de résultats des données utilisées dans des études passées, identifier les lacunes, le cas échéant, et énumérer les données supplémentaires qui seraient requises afin de mener avec succès les deux autres études identifiées ; et 3) fournir des informations qui faciliteront une décision quant à la question de savoir si le NCAP devrait lancer les études 2 et 3 sur la base des résultats des travaux antérieurs et des données disponibles.

        Attendu que, le BTC a examiné la proposition d’étude de l’OCTO sur la situation actuelle des collisions de noms, y compris l’impact financier de cette étude et des 3 études et, le 4 mars 2019, a recommandé au Conseil d’administration d’enjoindre à l’organisation ICANN de lancer l’étude 1.

        Il est résolu (2019.03.14.20) que le Conseil d’administration de l’ICANN remercie le SSAC pour sa réponse à la résolution de novembre 2017, pour son élaboration d'une proposition initiale de projet d’analyse de la collision de noms (NCAP) et pour les révisions subséquentes de cette proposition.

        Il est résolu (2019.03.14.21) que le Conseil d’administration enjoint au président-directeur général de l’ICANN, ou à son ou ses représentants, de lancer l’étude 1 sur la situation actuelle des collisions de noms tel que précisé par l’organisation ICANN.

        Il est résolu (2019.03.14.22) que le Conseil d’administration enjoint au président-directeur général de l’ICANN, ou à son ou ses représentants, d’identifier et de mettre à disposition des fonds dans le respect du budget et des plafonds, les dépenses encourues pour la proposition d’étude ne devant dépasser [À REMPLIR APRÈS NÉGOCIATIONS].

        Il est résolu (2019.03.14.23) que les éléments spécifiques de cette résolution resteront confidentiels à des fins de négociation conformément au chapitre 3, article 3.5 (b) et (d) des statuts constitutifs de l’ICANN jusqu’à ce que le président-directeur général autorise la divulgation de ces informations confidentielles.

        Fondements des résolutions 2019.03.14.20 – 2019.03.14.23

        Une collision de noms survient lorsqu'une tentative de résolution d'un nom utilisé dans un espace de noms privé (p.ex. sous un domaine de premier niveau non délégué ou un nom court non qualifié) entraîne une requête auprès du système des noms de domaine (DNS). Lorsque les frontières administratives des espaces de noms publics et privés se chevauchent, la résolution de noms peut donner des résultats imprévus ou préjudiciables. Cette catégorie de chaînes pas encore déléguées est appelée « chaînes sujettes à collisions. » Dans certains cas, les résultats imprévus ou préjudiciables de la délégation de chaînes sujettes à collisions peuvent être considérés comme étant à « haut risque ». Voici des exemples de critères permettant de qualifier une chaîne sujette à collisions de chaîne à haut risque : la fréquence d'apparition élevée dans les requêtes aux serveurs racine, la sévérité de l'impact des chaînes sujettes à collisions, le type de requêtes du DNS, le type d'utilisateur provoquant la collision (p.ex. services d'urgences, contrôleurs du trafic aérien, etc.), la diversité de la source de la requête, et l'apparition dans des certificats de noms internes.

        Le Conseil d’administration a précédemment pris des décisions sur les questions de collision de noms, et il a notamment demandé au Comité consultatif sur la sécurité et la stabilité (SSAC) d’identifier des études afin de répondre à une série de questions soulevées par le Conseil d’administration et d’aider ainsi à éclairer davantage la façon dont l’ICANN s’attaquera à la question des collisions de noms au fur et à mesure du développement de l’espace des noms de domaine. En réponse à la résolution du Conseil d’administration du 2 novembre 2017, le SSAC a remis en septembre 2018 une proposition de projet d’analyse de la collision de noms (NCAP). Cette proposition comprenait trois études séquentielles censées répondre à l’appel de cette résolution.

        Le Comité technique du Conseil d’administration (BTC) a ensuite demandé au Bureau du directeur de la technologie (OCTO) d’évaluer la proposition de NCAP. Suite à cette demande, des discussions ont été menées entre l’OCTO et le SSAC, discussions qui ont permis à l’OCTO d’obtenir des informations supplémentaires et de mieux comprendre les éléments de la proposition.

        Enfin, l’OCTO a présenté au BTC une évaluation selon laquelle il serait utile de disposer d’une étude et d’une synthèse des précédentes recherches menées sur les collisions de noms. Toutefois, un référentiel de données et des politiques relatives à l’utilisation de ce référentiel pourraient ne pas s’avérer nécessaires s’il était décidé à l’avenir de ne plus poursuivre l’étude 2 et l’étude 3. De ce fait, l’OCTO a précisé la portée de la proposition d’étude 1 du SSAC sur la situation actuelle des collisions de noms afin de reporter la mise en œuvre d'un référentiel de données et l’élaboration de politiques y afférentes aux études suivantes. L’étude 1 révisée a trois objectifs : 1) examiner tous les travaux antérieurs sur la question des collisions de noms et rédiger un rapport de synthèse incorporant d’importantes connaissances tirées des travaux antérieurs dans cette étude, et qui pourrait faire office d’introduction aux personnes découvrant cette thématique ; 2) dresser une liste de résultats des données utilisées dans des études passées, identifier les lacunes, le cas échéant, et énumérer les données supplémentaires qui seraient requises afin de mener avec succès les deux autres études identifiées ; et 3) fournir des informations nécessaires afin de prendre une décision quant à la question de savoir si le NCAP devrait lancer d’autres études sur la base des résultats des travaux antérieurs et des données disponibles.

        Le Conseil d’administration prend cette décision aujourd'hui pour deux raisons. Premièrement, les travaux de l’OCTO sur le NCAP ont atteint un stade où la portée de l’étude à mener a été suffisamment précisée. Deuxièmement, il existe une interdépendance potentielle entre les résultats des études sur la collision de noms lors de la prochaine série de nouveaux gTLD, notamment quant à l’obtention de plus amples informations sur la capacité de déléguer des chaînes qui se chevauchent dans les espaces de noms publics et privés.

        Cette résolution est censée avoir un impact positif sur la sécurité, la stabilité et la résilience du DNS d'Internet, étant donné qu’elle vise à recueillir davantage d’informations sur cet important défi technique. Cela s’inscrit également dans la mission de l’ICANN consistant à assurer le fonctionnement stable et sécurisé des systèmes d’identificateurs uniques d’Internet. Cette résolution sert l’intérêt public dans le sens où elle est conforme aux principales valeurs de l’ICANN de préservation et d’amélioration de l’administration du DNS et de stabilité opérationnelle, fiabilité, sécurité, interopérabilité mondiale, résilience et ouverture du DNS et d’Internet.

        Cette résolution aura un impact financier dans la mesure où des coûts sont à prévoir afin de mener les études. Elle enjoint uniquement à l’organisation ICANN de mener l’étude 1 sur la situation actuelle des collisions de noms tel que précisé par l’organisation ICANN ; les autres études doivent être envisagées de manière indépendante et être menées sur la base des résultats de l’étude 1. Le président-directeur général de l’ICANN doit exécuter ces travaux dans le respect des pratiques budgétaires adéquates.

        Il s’agit d’une fonction administrative organisationnelle qui ne nécessite pas de consultation publique.


1 Noms de domaine internationalisés dans les applications (IDNA) : généralités, explications et fondements

2 https://www.icann.org/en/system/files/correspondence/disspain-letter-review-new-gtld-cpe-process-26apr17-en.pdf.

3 Voir les statuts constitutifs de l’ICANN, 11 février 2016, chapitre 4, § 2 (https://www.icann.org/resources/pages/bylaws-2016-02-16-en#IV).

4 Voir le guide, module 4, § 4.2, p. 4-7 (https://newgtlds.icann.org/en/applicants/agb/string-contention-procedures-04jun12-en.pdf). Voir également https://newgtlds.icann.org/en/applicants/cpe.

5 Id. au module 4, § 4.2, p. 4-7 (https://newgtlds.icann.org/en/applicants/agb/string-contention-procedures-04jun12-en.pdf).

6 Id. au module 4, § 4.2.3, p. 4-9.

7 Id. au module 4, § 4.2.2.

8 Id. au module 4, §§ 4.2.2 et 4.2.3., p. 4-8 et 4-9 (https://newgtlds.icann.org/en/applicants/agb/string-contention-procedures-04jun12-en.pdf).

9 Guide, module 4, § 4.2.3, p. 4-9.

10 Demande 16-5, § 6, page 19 ; déclaration de l’IRP Despegar ¶¶ 66-67 (https://www.icann.org/en/system/files/files/irp-despegar-online-et-al-final-declaration-12feb16-en.pdf).

11 Demande 16-5, § 6, p. 19.

12 Id. ¶¶ 147, 150 (italique ajoutée).

13 Demande 16-5, § 6, p. 19.

14 Résolutions du Conseil d’administration 2016.03.10.10-11 (https://www.icann.org/resources/board-material/resolutions-2016-03-10-en#2.a).

15 Id.

16 Voir https://newgtlds.icann.org/en/applicants/cpe#process-review.

17 Demande 16-5, § 8, p. 17, 18.

18 Demande 18-5, https://www.icann.org/en/system/files/files/reconsideration-18-5-dotmusic-request-redacted-14apr18-en.pdf.

19 Décision du Conseil d’administration relative à la demande 18-5, https://www.icann.org/resources/board-material/resolutions-2018-07-18-en#2.f.

20 Demande 16-5, § 8, p. 5.

21 Voir le communiqué de Beijing, annexe I, p. 9 https://www.icann.org/en/system/files/correspondence/gac-to-board-18apr13-en.pdf ; voir aussi https://newgtlds.icann.org/en/applicants/gac-advice/cat2-safeguards.

22 Voir id., p. 11.

23 Voir https://www.icann.org/en/system/files/files/resolutions-new-gtld-annex-2-05feb14-en.pdf. Voir aussi http://www.icann.org/en/groups/board/documents/resolutions-new-gtld- 25jun13-en.htm ; voir aussi le rapport du NGPC de l’ICANN n° 2013-06-25-2b : Avis du GAC du communiqué de Beijing concernant l’avis relatif aux sauvegardes applicables aux chaînes de catégorie 2, documents d’information 1, p. 25-31 (http://www.icann.org/en/groups/board/documents/briefing-materials-1- 25jun13-en.pdf) ; http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm#1.d ; voir aussi http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-annex-1-item-1d- 02jul13-en.pdf, annexe I, contrat des nouveaux gTLD).

24 Demande 16-5, § 8, p. 5.

25 Id. ; voir aussi l’opinion de Blomqvist, ¶ 52, p. 41.

26 Id., § 6, p. 3, 6.

27 Rapport final de la GNSO sur l’introduction de nouveaux domaines génériques de premier niveau, directives de mise en œuvre IG-H (italique ajoutée) (http://gnso.icann.org/en/issues/new-gtlds/pdp-dec05-fr-parta-08aug07.htm).

28 Guide, module § 1.2.3.2, p. 1-27.

29 Id.

30 Demande 16-5, § 6, p. 20. Voir aussi la lettre relative à la révision du processus CPE de DotMusic, ¶¶ 26(c), 67b, p. 28, 47 (affirmant également que M. Robin Jacob, panéliste sélectionné par l’ICC dans la procédure d’objection de la communauté pour .MUSIC et .BAND, représentait Samsung, « l’un des partenaires multimilliardaires de Google », dans une action en justice (pour plus d’informations, voir la demande de réexamen 16-7, § 8, p. 18 (marquée 17) n.68, https://www.icann.org/en/system/files/files/reconsideration-16-7-dotmusic-request-redacted-30may16-en.pdf).

31 Lettre relative à la révision du processus CPE de DotMusic, ¶ 26(c), p. 28.

32 Guide § 2.4.3.1, p. 2-33 ; document relatif au processus du panel CPE, p. 2, https://newgtlds.icann.org/en/applicants/cpe ; directives relatives à la CPE, p. 22, https://newgtlds.icann.org/en/applicants/cpe.

33 M. Schmidt s’est retiré en décembre 2015 (https://www.theguardian.com/media/2015/dec/10/economist-appoints-tessa-jowell-to-board-as-googles-eric-schmidt-departs). Le rapport CPE a été publié le 10 février 2016. (https://newgtlds.icann.org/sites/default/files/tlds/music/music-cpe-1-1115-14110-en.pdf.)

34 Voir le panel de stratégie : le rôle de l'ICANN dans l'écosystème de gouvernance de l'Internet (https://www.icann.org/en/system/files/files/report-23feb14-en.pdf).

35 Demande 16-5, § 6, p. 20.

36 Voir le guide, module 4, § 4.2.3, p. 4-9 (« une candidature communautaire admissible élimine toutes les candidatures classiques en conflit direct avec celle-ci, indépendamment du degré d’admissibilité de la candidature communautaire. Cela explique pourquoi des conditions d’admissibilité très rigoureuses sont exigées pour les candidatures communautaires.

37 Les requérants font référence à un échange avec Fadi Chehadé lors du forum public. Voir https://singapore52.icann.org/en/schedule/thu-public-forum/transcript-public-forum-12feb15-en.pdf, p. 61-62. Durant cet échange, M. Chehadé a remercié DotMusic pour ses commentaires et a demandé à DotMusic d’envoyer à l’ICANN une lettre expliquant les craintes de DotMusic. DotMusic ne l’a jamais fait. Rien dans cet échange ne correspond à une « reconnaissance » d’un conflit d'intérêts, comme l’ont laissé entendre les requérants. (Voir la demande 16-5, § 6, p. 20.)

38 Rapport CoE, p. 47, cité dans la lettre relative à la révision du processus CPE de DotMusic, ¶ 26(c), p. 28.

39 Demande 16-5, § 6, p. 18.

40 Rapport 1 sur la portée du cabinet FTI, p. 3 https://www.icann.org/en/system/files/files/cpe-process-review-scope-1-communications-between-icann-cpe-provider-13dec17-en.pdf.

41 Id. p. 12.

42 Id.

43 Demande 16-5, § 8, p. 16 (marquée p. 15).

44 Voir les statuts constitutifs de l’ICANN, 11 février 2016.

45 Guide, préambule.

46 Id.

47 Voir https://newgtlds.icann.org/en/applicants/agb, qui indique que la version actuelle du guide date du 4 juin 2012. En vertu des statuts constitutifs en vigueur en juin 2012, les demandes de réexamen devaient être effectuées dans un délai de trente jours à compter de la publication des décisions du Conseil d’administration ou dans un délai de trente jours à partir du moment où un requérant a pris connaissance ou aurait normalement dû prendre connaissance de l’action contestée du personnel. Statuts constitutifs de l’ICANN, 16 mars 2012, chapitre IV, § 2.5 (https://www.icann.org/resources/pages/bylaws-2012-12-21-en#IV).

48 Guide, module 6, § 6, p. 6-4.

49 Voir la demande 14-28, https://www.icann.org/en/system/files/files/request-dotmusic-07jun14-en.pdf ; la demande 16-7, https://www.icann.org/en/system/files/files/reconsideration-16-7-dotmusic-request-redacted-30may16-en.pdf ; la demande 17-2, https://www.icann.org/en/system/files/files/reconsideration-17-2-dotmusic-request-redacted-18jun17-en.pdf ; la demande 17-4, https://www.icann.org/en/system/files/files/reconsideration-17-4-dotmusic-dotgay-request-redacted-25jul17-en.pdf ; la demande 18-1, https://www.icann.org/en/system/files/files/reconsideration-18-1-dotmusic-request-redacted-10mar18-en.pdf ; la demande 18-5, https://www.icann.org/en/system/files/files/reconsideration-18-5-dotmusic-request-redacted-14apr18-en.pdf.

50 Le Conseil d’administration prend note que cette revendication a été soulevée uniquement par le requérant DotMusic, pas les autres requérants, dans une soumission supplémentaire en appui à la demande 16-5. Voir https://www.icann.org/en/system/files/files/reconsideration-16-3-et-al-dotgay-dechert-to-icann-board-bamc-redacted-23mar18-en.pdf.

51 https://www.icann.org/en/system/files/files/reconsideration-18-5-dotmusic-bamc-recommendation-attachment-2-14jun18-en.pdf.

52 Voir les statuts constitutifs de l’ICANN, 11 février 2016, chapitre 4, § 2 (https://www.icann.org/resources/pages/bylaws-2016-02-16-en#IV).

53 Réfutation, p. 3-5 (https://www.icann.org/en/system/files/files/reconsideration-16-5-dotmusic-requestors-rebuttal-to-bamc-recommendation-request-12feb19-en.pdf).

54 Id. ; voir aussi le guide, module 2, pièce jointe 2 (https://newgtlds.icann.org/en/applicants/agb/evaluation-questions-criteria-04jun12-en.pdf).

55 Guide, module 2, pièce jointe 2, p. A-14 (https://newgtlds.icann.org/en/applicants/agb/evaluation-questions-criteria-04jun12-en.pdf) (italique ajoutée).

56 Id. (italique ajoutée)

57 Voir le guide, module 4, § 4.2.3, p. 4-10 – 4-12.

58 Réfutation, p. 6.

59 Candidature, question 20A (https://gtldresult.icann.org/applicationstatus/applicationdetails/1392).

60 Réfutation, p. 4 (guillemets internes omis).

61 Guide, pièce jointe 2 au module 2, p. A-14.

62 Candidature, question 20D (https://gtldresult.icann.org/applicationstatus/applicationdetails/1392).

63 Réfutation, p. 4-5.

64 Voir la pièce jointe 1 à la recommandation du BAMC, p. 29 (https://www.icann.org/en/system/files/files/reconsideration-16-5-dotmusic-bamc-recommendation-attachment-1-25jan19-en.pdf).

65 Guide, module 4, § 4.2.3, p. 4-12 (italique ajoutée).

66 Id.

67 Voir https://www.icann.org/en/system/files/files/reconsideration-18-5-dotmusic-request-redacted-14apr18-en.pdf.

68 Voir https://www.icann.org/resources/board-material/resolutions-2018-07-18-en#2.f.

69 Réfutation, p. 1.

70 https://www.icann.org/en/system/files/files/reconsideration-18-5-dotmusic-bamc-recommendation-attachment-2-14jun18-en.pdf (italique ajoutée).

71 Réfutation, p. 1.

72 Une mise à jour de l’organigramme, afin de clarifier ce point, sera effectuée selon les normes de révision et de mise à jour des documents relatifs aux processus de l’ICANN.

73 L’acceptation par le Conseil d’administration du plan de mise en œuvre détaillé constitue un écart par rapport à l’organigramme du processus de révision organisationnelle, mais cette étape est effectuée conformément aux pratiques standard des révisions organisationnelles car le Conseil d’administration exerce sa responsabilité fiduciaire en révisant et en acceptant ledit plan de mise en œuvre détaillé. Une mise à jour de l’organigramme sera effectuée en suivant le processus standard de révision et de mise à jour des documents relatifs aux processus de l’ICANN.