Skip to main content
Resources

Résolutions approuvées par le Conseil d’administration | Séance ouverte de l’atelier du Conseil d’administration, Los Angeles | Réunion ordinaire du Conseil d’administration de l’ICANN

Cette page est disponible en:

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

  1. Ordre du jour approuvé :
    1. Approbation des procès-verbaux
    2. Reporter l’application de la conformité pour obtenir le formulaire d’autorisation du bureau d’enregistrement entrant
    3. Recommandations pour l’utilisation technique des règles de génération d’étiquettes pour la zone racine
    4. Adoption du plan opérationnel et budget de l’IANA pour l’exercice fiscal 2021
    5. Révision de la concurrence, la confiance et le choix du consommateur (CCT) - Plan de mise en œuvre des six recommandations acceptées
    6. Directeur et représentant juridique de la filiale de Bruxelles
  2. Ordre du jour principal :
    1. Avis du GAC : Communiqué de Montréal (novembre 2019)
    2. Délégation du domaine البحرين. (« albahrain »), représentant Bahreïn en script arabe, à l’Autorité de réglementation des télécommunications (TRA)
    3. Délégation du domaine .ລາວ (« lao »), représentant la République démocratique populaire lao en script lao au Centre Internet national lao (LANIC)
    4. Examen de la recommandation du BAMC relative à la demande de réexamen 19-4

 

  1. Ordre du jour approuvé :

    1. Approbation des procès-verbaux

      Il est résolu (2020.01.26.01) que le Conseil d’administration de l’ICANN approuve les procès-verbaux de sa réunion ordinaire du 3 novembre 2019, de sa réunion extraordinaire du 21 novembre 2019, et de sa réunion extraordinaire du 12 décembre 2019.

    2. Reporter l’application de la conformité pour obtenir le formulaire d’autorisation du bureau d’enregistrement entrant

      Attendu que la politique de transfert exige qu’un transfert entre bureaux d’enregistrement « ne puisse se poursuivre que si la confirmation du transfert est reçue par le bureau d’enregistrement entrant de la part du contact de transfert » et que cette autorisation « doit être effectuée via un formulaire d’autorisation (FOA) normalisé ».

      Attendu que le 9 octobre 2019 le Groupe des représentants des bureaux d’enregistrement (RrSG) a écrit au conseil de la GNSO signalant que le RrSG avait identifié un problème dans la mise en œuvre de l’exigence du FOA pour le bureau d’enregistrement entrant, et lui demandant de solliciter au Conseil d’administration de l’ICANN de renvoyer ce problème à la prochaine révision de la politique de transfert et de demander au département de la conformité contractuelle de l’ICANN de ne pas appliquer l’exigence d’obtention du FOA au bureau d’enregistrement gagnant pendant que cette révision est en cours.

      Attendu que le 31 octobre 2019 le conseil de la GNSO a demandé au Conseil d’administration de l’ICANN d’enjoindre l’organisation ICANN à différer l’application de la conformité de l’exigence du FOA pour le bureau d’enregistrement gagnant jusqu’à ce que cette question soit réglée dans la révision prévue de la politique de transfert de la GNSO.

      Il est résolu (2020.01.26.02) que le Conseil d’administration accepte la demande du conseil de la GNSO et charge le Président-directeur général de l’ICANN, ou son ou ses représentants, de reporter l’application de la conformité à l’exigence d’obtention du FOA au bureau d’enregistrement entrant jusqu’à ce que la question soit réglée dans la révision prévue de la politique de transfert du conseil de la GNSO.

      Fondements de la résolution 2020.01.26.02

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

      Le Conseil d’administration aborde cette question à la demande du conseil de la GNSO. Le 31 octobre 2019, le conseil de la GNSO a envoyé une lettre au Conseil d’administration de l’ICANN lui demandant d’enjoindre l’organisation ICANN à reporter l’application de la conformité de l’exigence du FOA pour le bureau d’enregistrement gagnant jusqu’à ce que cette question soit réglée dans la révision prévue de la politique de transfert de la GNSO.

      Quelle est la proposition à l’étude ?

      La proposition à l’étude est une demande du conseil de la GNSO pour que le Conseil d’administration de l’ICANN demande à l’organisation ICANN de reporter l’application de la conformité contractuelle à l’exigence de la politique de transfert concernant le FOA du bureau d’enregistrement entrant.

      La politique de transfert établit qu’un transfert entre bureaux d’enregistrement « ne peut avoir lieu que si la confirmation du transfert est reçue par le bureau d’enregistrement entrant de la part du contact de transfert ». Une telle autorisation « doit être effectuée via un formulaire d’autorisation (FOA) valide normalisé ». La spécification temporaire, en vigueur depuis le 25 mai 2018, qui a remplacé cette exigence d’obtention d’un FOA pour le bureau d’enregistrement entrant dans certaines circonstances, établit que « [j]usqu’au moment où le service RDAP (ou d’autres méthodes sécurisées de transfert de données) est requis par l’ICANN, si le bureau d’enregistrement entrant ne parvient pas à accéder aux données d’enregistrement alors en vigueur pour un nom de domaine faisant l’objet d’un transfert, les exigences connexes de la politique de transfert seront remplacées…[.]. » La section 1.1 de l’annexe G de la spécification temporaire prévoit que lorsque le bureau d’enregistrement entrant ne peut pas accéder aux données d’enregistrement alors en vigueur pour le nom de domaine faisant l’objet d’un transfert, le « bureau d’enregistrement entrant n’EST PAS TENU d’obtenir un formulaire d’autorisation du contact de transfert ».

      Toutefois, cette disposition de remplacement de l’annexe G de la spécification temporaire ne s’applique que si les données d’enregistrement alors en vigueur ne sont pas accessibles dans le WHOIS / service d’annuaire de données d’enregistrement (RDDS) public au moment de la demande de transfert. Lorsque les données d’enregistrement sont affichées dans le WHOIS/RDDS public, l’exigence du FOA pour le bureau d’enregistrement gagnant continue de s’appliquer.

      Comme il est indiqué plus en détail ci-dessous, le Groupe des représentants des bureaux d’enregistrement (RrSG) a identifié des problèmes liés à la mise en œuvre de cette exigence. Le conseil de la GNSO a cité ces questions en présentant cette demande au Conseil d’administration.

      La politique temporaire sur les données d’enregistrement pour les gTLD (politique provisoire), en vigueur depuis le 20 mai 2019, exige la mise en œuvre continue de mesures conformes à la spécification temporaire. En outre, le rapport final de l’étape 1 du processus accéléré d’élaboration de politiques sur la spécification temporaire relative aux données d’enregistrement des gTLD, à la recommandation 24, est conforme à la spécification temporaire et ne modifie pas les obligations contractuelles actuelles. Par conséquent, les questions de mise en œuvre identifiées par le RrSG continueront à persister lorsque la politique sur les données d’enregistrement prendra effet.

      À la lumière de ces problèmes de mise en œuvre, le conseil de la GNSO a demandé au Conseil d’administration de l’ICANN de déléguer la question du FOA du bureau d’enregistrement entrant à la révision prévue de la politique de transfert et de demander à l’organisation ICANN de reporter l’application de la conformité de l’exigence du FOA pour le bureau d’enregistrement gagnant jusqu’à ce que ce problème soit réglé dans la révision de la politique de transfert.

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

      Le RrSG a soulevé des préoccupations au sujet de l’exigence du FOA pour le bureau d’enregistrement entrant dans une lettre adressée au conseil de la GNSO le 9 octobre 2019. En soulevant ces questions, le RrSG a manifesté sa préoccupation du fait que que la politique de transfert doit être mise en œuvre conformément au Règlement général sur la protection des données (RGPD), à la loi sur la protection des données personnelles des consommateurs résidant en Californie (CCPA) et à d’autres lois applicables en matière de protection de la vie privée.

      Dans sa lettre, le RrSG a souligné que, même si des données sont présentes dans le champ de l’adresse électronique du titulaire de nom de domaine dans la sortie publique du service RDDS, un e-mail envoyé à cette adresse peut ne pas être envoyé directement au titulaire s’il a été dérouté, supprimé ou remplacé par une URL de format Web, ou l’utilisation d’adresses e-mail pseudomysées. Le RrSG considère que si un bureau d’enregistrement a mis en place un système pour envoyer le FOA du bureau d’enregistrement entrant à toute adresse figurant dans le RDDS public, il n’y a aucune garantie que l’e-mail puisse arriver au titulaire du nom de domaine. Il en résulte que les bureaux d’enregistrement soutiennent qu’ils ne sont pas en mesure d’établir un processus automatisé fiable pour continuer à traiter le grand volume de transferts entre bureaux d’enregistrement. Selon les bureaux d’enregistrement, cela irait à l’encontre de l’objectif de la politique de transfert, qui est de permettre aux bureaux d’enregistrement d’avoir la possibilité de transférer des noms de domaine à d’autres bureaux d’enregistrement. En outre, le RrSG affirme que de nombreux bureaux d’enregistrement estiment que, en vertu du règlement général sur la protection des données (RGPD) de l’Union européenne, le bureau d’enregistrement entrant n’a pas le consentement pour traiter ces informations car cela exigerait que les bureaux d’enregistrement envoient un e-mail à une personne qui n’est pas son client.

      Le 1er mai 2018, avant l’adoption de la spécification temporaire, le comité Tech-Ops de la chambre des parties contractantes (CPH) a proposé à l’organisation ICANN de supprimer l’exigence de la FOA au bureau d’enregistrement entrant, en précisant dans une lettre que, « après le 25 mai 2018, les bureaux d’enregistrement entrants n’auront pas la possibilité de récupérer l’adresse e-mail du titulaire de nom de domaine ou un proxy à partir des données publiques du WHOIS ; les données ne seront pas disponibles pour le bureau d’enregistrement sortant ou pour le registre de façon cohérente ». Ils ont en outre déclaré que le processus de transfert actuel, qui exige les deux FOA, a été élaboré avant que les codes d’autorisation soient utilisés de façon uniforme par les bureaux d’enregistrement. De surcroît, le comité a déclaré que le FOA du bureau d’enregistrement entrant fournit une protection négligeable dans le contexte d’un transfert de domaine et que les bureaux d’enregistrement comptent rarement sur le FOA du bureau d’enregistrement entrant dans le contexte d’un différend en matière de transfert.

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

      Dans la lettre du 9 octobre 2019, le RrSG a déclaré qu’il avait « observé que la grande majorité des bureaux d’enregistrement accrédités par l’ICANN n’envoient plus le FOA du bureau d’enregistrement entrant après la spécification temporaire, et qu’il ne semble pas y avoir de preuve d’une augmentation des transferts non autorisés depuis mai 2018 ». En outre, le département de la conformité contractuelle de l’ICANN n’a pas constaté d’augmentation importante des plaintes concernant les transferts non autorisés. Les données recueillies par le département de la conformité contractuelle de l’ICANN montrent que 143 cas de transfert non autorisés ont été fermés 13 mois avant l’adoption de la spécification temporaire (mai 2017 – mai 2018) ; et que 138 cas ont été clos directement 13 mois à la suite de l’adoption de la spécification temporaire (juin 2018 – juin 2019).

      Tel qu’identifié par le comité Tech-Ops de la chambre des parties contractantes, lorsque l’adresse e-mail n’est pas présente dans le RDDS public lors des transferts de gTLD, le code AuthInfo suffit pour confirmer l’intention du titulaire de nom de domaine de transférer. Le FOA du bureau d’enregistrement sortant confirme également cette intention.

      L’exigence du FOA pour le bureau d’enregistrement entrant continue de causer des difficultés de mise en œuvre et des problèmes de conformité pour de nombreux bureaux d’enregistrement. Cette période de conformité différée permettra à la communauté de l’ICANN de prendre en compte l’exigence du FOA pour le bureau d’enregistrement par le biais de la révision de la politique de transfert. En outre, le temps supplémentaire permettra aux parties contractantes concernées d’évaluer tout impact potentiel sur la politique de transfert et de permettre au département de la conformité contractuelle de l’ICANN de concentrer ses ressources sur les demandes ayant une plus grande urgence ou un impact plus important.

      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 ne devrait avoir aucun impact sur les ressources de l’ICANN, la communauté, et/ou le public.

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

      Il ne devrait y avoir aucun impact sur la sécurité, la stabilité ou la résilience du DNS.

      S’agit-il d’un processus d’élaboration de politiques défini au sein des organisations de soutien de l’ICANN ou d’une fonction organisationnelle administrative de l’ICANN nécessitant ou non une consultation publique ?

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

      Cette décision relève-t-elle de la mission de l’ICANN ? En quoi sert-elle l’intérêt public mondial ?

      Cette décision est conforme à la mission de l’ICANN et sert l’intérêt public dans la mesure où elle aide à garantir la mise en œuvre uniforme et coordonnée des politiques dans les gTLD.

    3. Recommandations pour l’utilisation technique des règles de génération d’étiquettes pour la zone racine

      Attendu que le Conseil d’administration de l’ICANN a approuvé la procédure pour développer et maintenir les règles de génération d’étiquettes pour la zone racine relatives aux étiquettes IDNA le 4 novembre 2013, que la procédure a été mise en œuvre pour développer de manière incrémentielle les règles de génération d’étiquettes pour la zone racine afin de déterminer les domaines de premier niveau (TLD) valides et leurs variantes d’étiquettes valides.

      Attendu que plusieurs communautés partageant une écriture ont achevé leurs propositions de RZ-LGR, et que seize scripts ont été intégrés dans la troisième version des RZ-LGR, tandis qu’un bon nombre de scripts restants se trouvent dans le processus de finalisation des propositions de RZ-LGR.

      Attendu que le 14 mars 2019 le Conseil d’administration de l’ICANN a approuvé les recommandations pour la gestion des variantes TLD IDN qui exigent l’utilisation des RZ-LGR pour déterminer les TLD IDN valides et leurs variantes d’étiquettes valides, demandant à la ccNSO et à la GNSO de prendre en compte ces recommandations pour élaborer leurs politiques respectives concernant les variantes de TLD IDN tout en garantissant une solution cohérente.

      Attendu que le Conseil d’administration de l’ICANN a en outre demandé à la communauté de l’ICANN de former un groupe d’étude pour examiner tout problème concernant l’utilisation technique des RZ-LGR afin de déterminer les TLD IDN valides et leurs variantes d’étiquettes.

      Attendu que, la communauté de l’ICANN a formé le groupe d’étude qui a finalisé les recommandations pour l’utilisation technique des RZ-LGR après avoir pris en considération les commentaires de la communauté, et que ces recommandations ont été publiées le 7 octobre 2019. Ces recommandations ont été révisées par l’organisation ICANN et examinées par le Conseil d’administration de l’ICANN.

      Il est résolu (2020.01.26.03) que le Conseil d’administration demande que les conseils de la ccNSO et de la GNSO tiennent compte des recommandations pour l’utilisation technique des RZ-LGR tout en élaborant leurs politiques respectives pour définir et gérer les variantes TLD IDN pour les TLD actuels ainsi que pour les futures candidatures de TLD.

      Fondements de la résolution 2020.01.26.03

      Le travail initial de la communauté en 2012 sur les questions relatives aux variantes TLD IDN, dans le cadre du Rapport intégré (IIR)1, a identifié qu’il n’existe aucune définition acceptée de ce qui peut constituer une relation de variante entre les étiquettes de premier niveau. Pour aborder cette question, l’organisation ICANN et la communauté ont élaboré la procédure pour développer et maintenir les règles de génération d’étiquettes pour la zone racine relatives aux étiquettes IDNA (procédure LGR)2. Cette procédure permet de définir des règles de génération d’étiquettes pour différents scripts afin de déterminer des étiquettes TLD valides et leurs variantes d’étiquettes. En 2013, le Conseil d’administration de l’ICANN a approuvé cette procédure et a demandé à l’organisation ICANN et à la communauté de l’entreprendre. Sur la base du processus stipulé dans la procédure LGR, de nombreux panels de génération d’étiquettes (GP) ont complété leurs propositions de RZ-LGR, dont seize scripts ont déjà été intégrés dans la troisième version des RZ-LGR (RZ-LGR-3). Une grande partie des communautés partageant une écriture restantes se trouvent dans le processus de finalisation de leurs propositions de RZ-LGR. En outre, le Conseil d’administration de l’ICANN a approuvé les recommandations3 pour la gestion des variantes TLD IDN, qui exigent l’utilisation de RZ-LGR pour déterminer les TLD IDN valides et leurs variantes d’étiquettes, et a demandé à la ccNSO et à la GNSO de les prendre en compte dans leurs processus d’élaboration de politiques.

      Compte tenu de la disponibilité des RZ-LGR et de leur rôle central pour déterminer les TLD valides et leurs variantes d’étiquettes, le Conseil d’administration de l’ICANN a demandé à la communauté de l’ICANN (y compris les organisations de soutien (SO), les comités consultatifs (AC) et le Conseil d’architecture de l’Internet (IAB)) d’étudier les questions relatives à l’utilisation technique des RZ-LGR de façon cohérente dans tous les TLD IDN, y compris les gTLD IDN et les ccTLD IDN. En conséquence, le groupe d’étude (SG) RZ-LGR a été formé à partir des candidats des SO, des AC, de l’IAB et d’autres volontaires de la communauté de l’ICANN pour répondre à la demande du Conseil d’administration de l’ICANN. Après sa formation, le groupe d’étude RZ-LGR a tout d’abord défini la portée de son travail et l’a achevé après avoir reçu les commentaires de la communauté à travers la première consultation publique lancée en août 2018. Le groupe d’étude a délibéré sur les détails techniques pertinents fondés sur cette portée et a élaboré un ensemble de recommandations. Ces recommandations ont été publiées dans le deuxième commentaire public par le groupe d’étude en mai 2019. Sur la base de la contribution de la communauté, le groupe d’étude a finalisé ces recommandations qui ont été publiées le 7 octobre 2019 pour un examen plus approfondi du Conseil d’administration de l’ICANN.

      Ces recommandations auront un impact financier en raison de la maintenance des RZ-LGR basées sur la procédure LGR et du déploiement et de la maintenance d’un outil LGR pour traiter les étiquettes TLD basées sur les RZ-LGR. L’impact financier continu du maintien des RZ-LGR devrait être moins important que le soutien financier existant dépensé pour son développement. En outre, un outil LGR a déjà été développé et déployé par l’organisation ICANN pour soutenir les GP spécifiques à des scripts particuliers dans le travail de développement de leurs propositions de RZ-LGR qui peuvent être utilisées pour le traitement des étiquettes TLD à l’avenir. L’impact fiscal réel dépend également des recommandations éventuellement élaborées par les conseils de la ccNSO et de la GNSO par le biais de leurs processus politiques respectifs liés aux TLD IDN et à leurs variantes d’étiquettes, et adoptées par le Conseil d’administration de l’ICANN.

      Les recommandations soutiennent la mission de l’ICANN et contribuent à un fonctionnement sûr et stable du système d’identificateurs uniques de plusieurs façons : elles soutiennent une définition uniforme des variantes TLD IDN dans les gTLD et les ccTLD, ainsi que pour les TLD existants et les futures applications TLD ; elles soutiennent un mécanisme communautaire pour maintenir les RZ-LGR en conformité avec la procédure LGR qui maintient sa stabilité ; et mettent en évidence et corrigent toute divergence entre ce qui est autorisé par les RZ-LGR et ce qui est délégué dans la zone racine. Cela est réalisé tout en respectant le rôle communautaire d’élaboration de politiques. Le travail de soutien de l’utilisation des RZ-LGR pour déterminer et éventuellement déléguer de manière cohérente les variantes TLD IDN contribue également à l’intérêt public en améliorant l’accès au système des noms de domaine (DNS) de l’Internet en différents scripts.

    4. Adoption du plan opérationnel et budget de l’IANA pour l’exercice fiscal 2021

      Attendu que la version préliminaire du plan opérationnel et budget (OP&B) de l’IANA pour l’exercice fiscal 2021 a été publiée pour consultation publique le 14 octobre 2019, conformément aux statuts constitutifs.

      Attendu que les commentaires reçus dans le cadre du processus de consultation publique ont été examinés et répondus, et qu’ils ont été présentés au Comité des finances du Conseil d’administration (BFC) pour examen et commentaires.

      Attendu que tous les commentaires publics ont été pris en considération et que, lorsque cela s’est avéré approprié et faisable, ils ont été intégrés dans une version finale du plan opérationnel et budget de l’IANA pour l’exercice fiscal 2021. Attendu que, dans le cadre des statuts constitutifs de l’ICANN, le plan opérationnel et budget de l’IANA doit être adopté par le Conseil d’administration et ensuite publié sur le site Web de l’ICANN.

      Attendu que les commentaires publics reçus, de même que d’autres commentaires sollicités auprès de la communauté, ont été pris en compte pour déterminer les révisions à effectuer sur la version préliminaire du plan opérationnel et budget de l’IANA pour l’exercice fiscal 2021.

      Il est résolu (2020.01.26.04) que le Conseil d’administration adopte le plan opérationnel et budget de l’IANA pour l’exercice fiscal 2021.

      Fondements de la résolution 2020.01.26.04

      Conformément à l’article 22.4 des statuts constitutifs de l’ICANN, le Conseil d’administration adopte un budget annuel qui est publié sur le site Web de l’ICANN. Le 14 octobre 2019, les versions préliminaires du plan opérationnel et budget de la PTI pour l’exercice fiscal 2021 et du plan opérationnel et budget de l’IANA pour l’exercice fiscal 2021 ont été publiées pour consultation publique. Le 9 janvier 2020, le Conseil d’administration de la PTI a approuvé le plan opérationnel et budget de la PTI pour l’exercice fiscal 2021, et ledit budget a servi de base au plan opérationnel et budget de l’IANA pour l’exercice fiscal 2021.

      Le plan opérationnel et budget de la PTI pour l’exercice fiscal 2021 et la version préliminaire du budget de l’IANA pour l’exercice fiscal 2021 se sont basés sur de nombreuses discussions avec les membres de la communauté de l’ICANN et de l’organisation ICANN, y compris des consultations importantes avec les organisations de soutien et les comités consultatifs de l’ICANN et d’autres groupes de parties prenantes tout au long des mois précédents.

      Tous les commentaires reçus, quelle que soit leur origine, ont été pris en considération lors de l’élaboration du plan opérationnel et budget de l’IANA pour l’exercice fiscal 2021. Lorsque cela s’est avéré possible et approprié, ces contributions ont été incorporées dans la version finale du plan opérationnel et budget de l’IANA pour l’exercice fiscal 2021 proposée pour adoption.

      Le plan opérationnel et budget de l’IANA pour l’exercice fiscal 2021 aura un impact positif sur l’ICANN du fait qu’il fournit un cadre approprié pour la réalisation des services de l’IANA et fournit également la base permettant à l’organisation d’être tenue responsable d’une manière transparente.

      Cette décision sert à l’intérêt public et à la mission de l’ICANN, car elle est pleinement conforme aux plans stratégiques et opérationnels de l’ICANN, et ses résultats permettront à l’ICANN de remplir sa mission.

      Un impact fiscal est à prévoir sur l’ICANN et sur la communauté à l’issue de cette décision. Des effets positifs sont à prévoir sur la sécurité, la stabilité et la résilience du système des noms de domaine (DNS) eu égard aux financements consacrés à ces aspects du DNS.

      Il s’agit d’une fonction administrative organisationnelle qui, comme indiqué ci-dessus, a déjà fait l’objet d’une consultation publique.

    5. Révision de la concurrence, la confiance et le choix du consommateur (CCT) - Plan de mise en œuvre des six recommandations acceptées

      Attendu qu’en vertu de l’Affirmation d’engagements, l’ICANN était obligée à « organiser une évaluation destinée à examiner dans quelle mesure l’expansion des gTLD a contribué à promouvoir la concurrence, la confiance et le choix du consommateur, ainsi que l’efficacité (a) du processus de dépôt et d’évaluation de candidatures, et (b) des sauvegardes mises en place pour atténuer les risques liés à l’introduction ou à l’expansion ». La création d’une équipe de révision communautaire, l’équipe de révision de la concurrence, la confiance et le choix du consommateur (CCT-RT), a été annoncée le 23 décembre 2015 pour remplir ce mandat.

      Attendu que le 8 septembre 2018 la CCT-RT a présenté un rapport final contenant trente-cinq recommandations consensuelles au Conseil d’administration de l’ICANN pour examen (« Rapport final »).

      Attendu que le Conseil d’administration de l’ICANN a pris des décisions sur chacune des 35 recommandations figurant dans le rapport final, tel que spécifié dans la fiche de suivi intitulée « Recommandations finales de la CCT : décisions du Conseil (1er mars 2019) » (« Fiche de suivi »).

      Attendu que le Conseil d’administration a décidé d’accepter les recommandations 1, 17, 21, 22, 30 et 31 portant sur la CCT sujettes aux considérations de coût et de mise en œuvre, tel que spécifié dans la fiche de suivi, et a chargé le Président-directeur général de l’ICANN, ou son ou ses représentants, de mettre au point et de soumettre au Conseil d’administration un plan de mise en œuvre devant être achevé et présenté à la communauté dans les six mois suivant la décision du Conseil d’administration.

      Attendu qu’un Plan de mise en œuvre a été soumis à consultation publique le 11 septembre 2019. La communauté a également été invitée à faire part de ses observations concernant la proposition d’inclure les recommandations de mise en œuvre de la CCT dans le processus de planification et de budgétisation opérationnelle de l’ICANN afin de leur accorder, le cas échéant, la priorité qui leur revient au sein des travaux de l’ICANN. Cinq commentaires ont fait suite à cet appel ; les réponses et les analyses de l’organisation ICANN à ces observations figurent dans le récapitulatif émis par l’ICANN.

      Il est résolu (2020.01.26.05) que le Conseil d’administration charge le Président-directeur général de l’ICANN, ou son/ses représentant(s), de lancer la mise en œuvre des recommandations de la CCT-RT acceptées tel qu’indiquées dans le Plan de mise en œuvre. Les travaux de mise en œuvre n’impliquant pas de coût additionnel ni de ressources significatives doivent commencer dans les plus brefs délais. Les recommandations en matière de CCT figurant dans le plan de mise en œuvre qui requièrent des ressources et un budget considérables doivent figurer dans la procédure de planification et de budgétisation opérationnelle afin de bénéficier de l’attention de la communauté et pour que leurs travaux soient, le cas échéant, prioritaires.

      Fondements de la résolution 2020.01.26.05

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

      Comme stipulé par le chapitre 1 des statuts constitutifs de l’ICANN, les révisions constituent des mécanismes de reddition de comptes essentiels pour permettre à l’ICANN d’accomplir sa mission et pour le maintien d’un modèle multipartite sain. Elles contribuent également à garantir que l’ICANN sert l’intérêt public. Lancée en vertu de l’Affirmation d’engagements (AoC), cette première révision de la concurrence, la confiance et le choix du consommateur (CCT) constitue une facette majeure de l’engagement de l’ICANN à examiner et à évaluer de façon continue les domaines clés.

      Le 8 septembre 2018, l’équipe de révision de la concurrence, la confiance et le choix du consommateur (CCT-RT) a remis son rapport final et ses recommandations au Conseil d’administration de l’ICANN.

      Le 1er mars 2019, le Conseil d’administration de l’ICANN a pris des mesures au sujet des recommandations finales remises par la CCT-RT. Conformément à ses statuts constitutifs, le Conseil d’administration de l’ICANN a examiné attentivement la meilleure façon d’aborder les recommandations et les a regroupées selon trois types de statuts : acceptée, en cours ou renvoyée à différentes parties de la communauté ainsi que détaillé dans la fiche de suivi adossée aux résolutions du Conseil d’administration.

      Le Conseil d’administration prend aujourd’hui des mesures pour la mise en œuvre directe des recommandations acceptées comme indiqué dans le plan de mise en œuvre.

      Quelle est la proposition à l’étude ?

      L’organisation ICANN a établi un Plan de mise en œuvre suite à la résolution 2019.03.01.03 du Conseil d’administration en vue de : 1) Accepter les recommandations 1, 17, 21, 22, 30 et 31 portant sur la CCT sujettes aux considérations de coût et de mise en œuvre; et 2) charger l’ICANN de « mettre au point et de soumettre au Conseil d’administration un plan de mise en œuvre des recommandations acceptées ».

      Le Plan de mise en œuvre définit l’approche à adopter pour la mise en œuvre des recommandations acceptées. Il comprend des renseignements tels que la description des activités, la durée estimée, les besoins en ressources (y compris les sources de financement), les interdépendances et autres éléments potentiellement disponibles.

      Le Plan de mise en œuvre énonce les différentes étapes et jalons de mise en œuvre et précise également, autant que possible, les coûts anticipés et les ressources nécessaires pour son achèvement. Il précise l’allocation des ressources aux recommandations spécifiques pour soutenir l’ICANN dans sa mission, l’équilibrage des ressources et l’établissement de priorités permettant de financer les travaux sélectionnés et de répondre ainsi aux recommandations de la CCT-RT.

      Le Plan de mise en œuvre a été développé par les principaux experts techniques de l’ICANN, spécialisés dans les thèmes des six recommandations acceptées.

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

      Le Plan de mise en œuvre a été soumis au commentaire public le 11 septembre 2019. La communauté a été invitée à faire part de ses observations au sujet de la proposition d’inclure les recommandations de mise en œuvre de la CCT dans la procédure de planification et budgétisation opérationnelle, afin de leur accorder la priorité qui leur revient au sein des travaux de l’ICANN. Cinq contributions en réponse à l’appel à se prononcer sur ce point (clôt au 31 octobre) ont été reçues. Les commentaires ont été traités dans la section « analyse » du rapport de synthèse de la consultation publique, comme convenu.

      Avant la publication du Plan de mise en oeuvre, les responsables chargés de la mise en œuvre de la CCT-RT 4 ont été invités par le Conseil d’administration à participer au Groupe Caucus du Conseil d’administration consacré à la CCT pour discuter des plans et des orientations encadrant les mesures prises pour répondre à la décision du Conseil d’administration du 1er mars en réponse aux recommandations finales en matière de CCT.

      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 ?

      Tel que stipulé dans le Plan de mise en œuvre, la mise en œuvre de ces recommandations peut demander, à certains étapes, davantage de ressources que celles allouées dans le budget actuel. Par conséquent, le Conseil d’administration demande dans sa résolution que les recommandations figurant dans le Plan de mise en œuvre requérant des ressources et un budget significatif soient intégrées aux cycles de planification et de budgétisation opérationnelle.

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

      L’adoption du Plan de mise en œuvre permettra à l’ICANN de lancer la mise en œuvre de certaines des recommandations formulées par l’équipe de révision communautaire dans les plus brefs délais. La mise en œuvre de recommandations spécifiques imposera à la communauté de participer à certaines consultations, tel qu’indiqué dans le Plan de mise en œuvre. Cela risque de peser tant sur ses ressources que sur sa charge de travail.

      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.

      Cette décision relève-t-elle de la mission de l’ICANN ? En quoi sert-elle l’intérêt public mondial ?

      Cette décision relève de la mission et du mandat de l’ICANN. Émanant d’un engagement clé inscrit en 2009 dans l’Affirmation d’engagements, désormais intégrée aux statuts constitutifs de l’ICANN, elle relève de l’intérêt public. Les révisions sont des mécanismes importants et essentiels à travers lesquels l’organisation ICANN respecte ses engagements. La portée de cette révision est intrinsèquement liée aux valeurs fondamentales de l’ICANN, à savoir l’introduction et la promotion de la concurrence dans l’enregistrement des noms de domaine.

      S’agit-il d’un processus d’élaboration de politiques défini au sein des organisations de soutien de l’ICANN ou d’une fonction organisationnelle administrative de l’ICANN nécessitant ou non une consultation publique ?

      Avant de procéder à sa révision, le Conseil d’administration a reçu des commentaires publics.

    6. Directeur et représentant juridique de la filiale de Bruxelles

      Attendu que la Société pour l’attribution des noms de domaine et des numéros sur Internet, société d’utilité publique à but non lucratif dûment constituée et existant sous les lois de l’État de Californie et des États-Unis d’Amérique, dont le siège principal est situé à 12025 E. Waterfront Drive, Suite 300, Los Angeles, en Californie, USA 90094 (« ICANN »), a établi une filiale d’une entité étrangère à but non lucratif en Belgique, actuellement sise à 6 Rond Point Schuman, b. 5, 1040 Bruxelles sous le nom de « Société pour l’attribution des noms de domaine et des numéros sur Internet ».

      Attendu qu’en vertu de la résolution 2017.06. 24.13 du Conseil d’administration de l’ICANN, Jean-Jacques Sahel a été nommé directeur et représentant légal de la filiale en Belgique, nommé à ce poste jusqu’au retrait de sa désignation suite à une résolution du Conseil d’administration.

      Attendu que les fonctions de Jean-Jacques Sahel en tant que directeur et représentant légal de la filiale en Belgique prennent fin en octobre 2019, suite à sa démission de l’ICANN.

      Attendu que Christopher Mondini, [INFORMATION PERSONNELLE DE CONTACT EXPURGÉE], assumera ses fonctions de directeur et représentant juridique de la filiale de l’ICANN sise à Bruxelles, Belgique, à compter du 26 janvier 2020.

      Il est résolu (2020.01.26.06) que l’autorité octroyée à Jean-Jacques Sahel pour agir en tant que directeur et représentant juridique de la filiale de l’ICANN sise à Bruxelles soit abrogée, prenant effet immédiatement.

      Il est résolu (2020.01.26.07) que Christopher Mondini devienne le nouveau directeur et représentant légal de la filiale de l’ICANN sise à Bruxelles, Belgique, prenant effet au 26 janvier 2020.

      Il est résolu (2020.01.26.08) que Christopher Mondini détienne les pleins pouvoirs pour effectuer la gestion quotidienne du bureau de l’ICANN sis à Bruxelles, Belgique, y compris et sans se limiter aux pouvoirs spécifiques concernant le fonctionnement de cette filiale suivants :

      1. représenter la société auprès de toutes les autorités publiques gouvernementales, régionales, provinciales, municipales ou autres, les tribunaux de commerce, la Banque Carrefour des entreprises, les autorités de règlementation des entreprises, les autorités fiscales, y compris l’administration de la T.V.A., le service de chèques postaux, la douane, la poste, les services téléphoniques et télégraphiques et tous les autres services et autorités publics ;

      2. signer la correspondance quotidienne, recevoir et signer les reçus pour des lettres ou colis envoyés à la société à travers la poste, la douane, les services de chemin de fer, aériens et toute autre société de transports et services ;

      3. souscrire, signer, transférer ou annuler toutes les polices d’assurance et tous les contrats de fourniture d’eau, gaz, électricité, téléphone et d’autres pour la filiale et payer des factures, des notes, et d’autres cotisations qui s’y rapportent ;

      4. signer et accepter tous les devis, contrats et ordres d’achat ou de vente de matériel de bureau et d’autres biens d’investissement, les services et les fournitures nécessaires au fonctionnement de la filiale qui n’obligent pas la société à dépenser plus de 500 € ;

      5. prendre ou consentir des baux, y compris les baux à long terme, sur l’immobilier, le matériel ou d’autres actifs immobilisés et conclure des accords dans le même but, avec l’approbation du Président-directeur général de l’ICANN ou du Conseil d’administration de l’ICANN ;

      6. demander, collecter et recevoir des sommes d’argent, des documents ou des biens de toute nature et signer les reçus y afférents ;

      7. associer la filiale à toutes les organisations professionnelles ou d’affaires ;

      8. représenter la filiale dans les procédures judiciaires ou d’arbitrage, comme demandeur ou défendeur, prendre toutes les mesures nécessaires concernant les procédures ci-dessus, obtenir tous les jugements et les exécuter ;

      9. rédiger tous les documents et les signer afin d’être en mesure d’exercer les pouvoirs énumérés ci-dessus ;

      10. adopter toutes les mesures nécessaires pour mettre en œuvre les résolutions et recommandations du Conseil d’administration ;

      11. Déplacer le siège de la filiale en Belgique suite à l’approbation du Président-directeur général ou du Conseil d’administration de l’ICANN.

      Fondements des résolutions 2020.01.26.06 à 2020.01.26.08

      L’ICANN s’engage à poursuivre sa portée et sa présence à l’échelle internationale dans tous les fuseaux horaires du monde entier. À cette fin, le Conseil d’administration de l’ICANN a adopté des résolutions pour créer une filiale en Belgique et a nommé, en 2017, Jean-Jacques Sahel comme directeur et représentant juridique, lui octroyant les pouvoirs nécessaires à l’exercice de ses fonctions. En octobre 2019, M. Sahel a démissionné de ses fonctions à l’ICANN. Le Conseil doit donc nommer un nouveau directeur et représentant légal de la filiale. Cette résolution, qui désigne M. Mondini comme directeur et représentant juridique de la filiale et lui octroie les pouvoirs spécifiques nécessaires à la gestion de la filiale, garantit la continuité suite à la démission du directeur et représentant légal actuel de la filiale de l’ICANN.

      L’engagement de l’ICANN en faveur d’une portée mondiale va dans le même sens que l’intérêt public et que sa mission dans la mesure où il renforce l’importance accordée aux parties prenantes du monde entier.

      L’impact au niveau du budget de l’ICANN se limite aux dépenses pour la désignation du nouveau directeur de filiale et sera imputable au budget correspondant à l’exercice financier 2020.

      Cette résolution ne devrait avoir aucun impact 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.

  2. Ordre du jour principal :

    1. Avis du GAC : Communiqué de Montréal (novembre 2019)

      Attendu que le Comité consultatif gouvernemental (GAC) s’est réuni dans le cadre de l’ICANN66 à Montréal et a émis le 6 novembre 2019 un communiqué (« Communiqué de Montréal ») contentant quatre éléments d’avis consensuel et trois éléments de suivi d’avis préalables. L’avis consensuel porte sur la révision de la CCT et les cycles de nouveaux gTLD, le service d’annuaire de données d’enregistrement des noms de domaine et de la protection de données. Le suivi des avis préalables porte sur la protection des identificateurs et des noms de la Croix rouge et du Croissant rouge, les protections d’OIG et le service d’annuaire de données d’enregistrement et la protection des données.

      Attendu que, dans une lettredatant du 16 décembre 2019, le Président-directeur général de l’ICANN a informé sur les efforts de mise en œuvre de la révision CCT et a demandé des éclaircissements à la présidente du GAC sur l’avis du GAC à ce sujet.

      Attendu que, dans le cadre d’un appel du 17 décembre 2019, le Conseil d’administration de l’ICANN et le GAC ont échangé au sujet du Communiqué de Montréal et des demandes d’éclaircissement émises par le Conseil d’administration de l’ICANN et portant sur l’avis du GAC.

      Attendu que, dans une lettre du 19 décembre 2019, le Conseil de la GNSO a exprimé au Conseil d’administration sa position sur le suivi de l’avis préalable figurant dans le Communiqué de Montréal.

      Attendu que, dans une lettre datée du 6 janvier 2020, l’ICANN a fait le point sur le calendrier de mise en œuvre de l’étape 1 de l’EPDP, suite à la demande du GAC exprimée dans son Communiqué de Montréal.

      Attendu que, dans une lettre datée du 22 janvier 2020, le GAC a fournit des éclaircissements supplémentaires sur l’avis qu’il a émis dans le Communiqué de Montréal.

      Attendu que le Conseil d’administration a élaboré une fiche de suivi en réponse à l’avis du GAC du Communiqué de Montréal, en tenant compte des échanges ayant eu lieu entre le Conseil d’administration et le GAC ainsi que des informations fournies par le conseil de la GNSO.

      Il est résolu (2020.01.26.09) que le Conseil d’administration adopte la fiche de suivi intitulée « Avis du GAC – Communiqué de Montréal : actions et mises à jours (26 janvier 2020) » en réponse aux éléments de l’avis du GAC du Communiqué de Montréal.

      Fondements de la résolution 2020.01.26.09

      Le chapitre 12, article 12.2(a)(ix) des statuts constitutifs de l’ICANN autorise le GAC à « soumettre directement des sujets au Conseil d’administration, par le biais d’un commentaire ou d’un avis préalable, ou en recommandant une mesure spécifique, l’élaboration d’une nouvelle politique ou la révision des politiques actuelles, » Dans son Communiqué de Montréal (6 novembre 2019) l’avis consensuel adressé par le GAC au Conseil d’administration porte sur la révision de la CCT et les séries ultérieures de nouveaux gTLD, le service d’annuaire des données d’enregistrement des noms de domaine et la protection de données. Le GAC a également émis des suivis d’avis préalables portant sur la protection des identificateurs et des noms de la Croix rouge et du Croissant rouge, les protections des OIG, le service d’annuaire des données d’enregistrement et la protection de données. Les statuts constitutifs prévoient que le Conseil d’administration examine l’avis du GAC en matière de politique publique pour la formulation et l’adoption de politiques. Dans le cas contraire, il est tenu d’en avertir le GAC en précisant ses motivations. Tout avis du GAC approuvé par consensus global du GAC (comme défini dans les statuts constitutifs) ne peut être rejeté que par un vote d’au moins 60 % du Conseil d’administration, et le GAC et le Conseil d’administration doivent ensuite essayer de trouver une solution réciproquement acceptable, en toute bonne foi, en temps voulu et de manière efficace.

      Aujourd’hui, le Conseil d’administration prend des mesures portant sur chacun des points figurant dans le Communiqué de Montréal.

      Les mesures prises par le Conseil d’administration sont décrites dans la fiche de suivi datée du 26 janvier 2020.

      Dans le cadre de l’adoption de sa réponse à l’avis du GAC du Communiqué de Montréal, le Conseil d’administration a examiné divers documents dont, sans s’y limiter, les suivants :

      L’adoption de l’avis du GAC comme fourni dans la fiche de suivi aura un impact positif sur la communauté, car cela aidera à résoudre les questions posées par l’avis du GAC sur les gTLD ainsi que d’autres problématiques. La prise de mesures suivant l’avis du GAC est conforme à la mission de l’ICANN ainsi qu’au rôle du GAC au sein du modèle multipartite et sert l’intérêt public. Aucun impact financier associé à l’adoption de cette résolution n’est prévu. L’approbation de la résolution n’aura pas de conséquences sur 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.

    2. Délégation du domaine البحرين. (« albahrain »), représentant Bahreïn en script arabe, à l’Autorité de réglementation des télécommunications (TRA)

      Il est résolu (2020.01.26.10) que dans le cadre de sa mission prévue par le contrat des fonctions IANA relatives au nommage conclu avec l’ICANN, l’IANA a étudié et évalué la demande de délégation du domaine de premier niveau géographique البحرين. à l’autorité de règlementation des télécommunications. La documentation montre que cette demande a suivi les procédures appropriées pour son évaluation.

      Fondements de la résolution 2020.01.26.10

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

      Conformément au contrat des fonctions IANA relatives au nommage, dans le cadre de ses fonctions de nommage de l’IANA, la PTI a analysé une requête de la délégation des ccTLD et soumet son rapport à l’étude du Conseil d’administration. Cet examen par le Conseil d’administration est destiné à s’assurer que les procédures établies ont été suivies.

      Quelle est la proposition à l’étude ?

      Il est proposé d’approuver une demande visant à créer le domaine de premier niveau géographique .البحرين. en alphabet arabe et à confier le rôle de gestionnaire à l’autorité de règlementation des télécommunications.

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

      Lors de l’évaluation d’une demande de délégation, l’IANA consulte 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é ?

      L’IANA n’est pas au courant d’aucune question ou inquiétude soulevées par la communauté concernant cette demande.

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

      Le Conseil d’administration a examiné les évaluations suivantes :

      [EXPURGÉ – INFORMATIONS SENSIBLES RELATIVES À LA 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 correspond aux obligations de l’ICANN en vertu du 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. Le rôle de l’ICANN n’est pas celui d’évaluer les répercussions financières des activités relatives aux ccTLD 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 repré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.

    3. Délégation du domaine .ລາວ (« lao »), représentant la République démocratique populaire lao en script lao au Centre Internet national lao (LANIC)

      Il est résolu (2020.01.26.11) que dans le cadre de sa mission prévue par le contrat des fonctions IANA relatives au nommage conclu avec l’ICANN, l’IANA a étudié et évalué la demande de délégation du domaine de premier niveau géographique .ລາວ au centre Internet national lao. La documentation montre que cette demande a suivi les procédures appropriées pour son évaluation.

      Fondements de la résolution 2020.01.26.11

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

      Conformément au contrat des fonctions IANA relatives au nommage, dans le cadre de ses fonctions de nommage de l’IANA, la PTI a analysé une requête de la délégation des ccTLD et soumet son rapport à l’étude du Conseil d’administration. Cet examen par le Conseil d’administration est destiné à s’assurer que les procédures établies ont été suivies.

      Quelle est la proposition à l’étude ?

      Il est proposé d’approuver une demande visant à créer le domaine de premier niveau géographique ລາວ en alphabet lao et à confier le rôle de gestionnaire au Centre Internet national lao.

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

      Lors de l’évaluation d’une demande de délégation, l’IANA consulte 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é ?

      L’IANA n’est pas au courant d’aucune question ou inquiétude soulevées par la communauté concernant cette demande.

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

      Le Conseil d’administration a examiné les évaluations suivantes :

      [EXPURGÉ – INFORMATIONS SENSIBLES RELATIVES À LA 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 correspond aux obligations de l’ICANN en vertu du 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. Le rôle de l’ICANN n’est pas celui d’évaluer les répercussions financières des activités relatives aux ccTLD 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 repré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 recommandation du BAMC relative à la demande de réexamen 19-4

      Attendu que Merck KGaA et Merck Registry Holdings, Inc. (les « Demandeurs ») ont présenté la demande de réexamen 19-4 visant à ce que l’organisation ICANN reconsidère le rejet de leur demande conjointe d’un deuxième ajournement de l’enchère pour conflit de chaînes au sujet du générique de premier niveau (gTLD) .MERCK (deuxième demande).

      Attendu que les Demandeurs reprochent au personnel ICANN de ne pas avoir pris en compte des informations essentielles et d’avoir manqué aux politiques établies par l’ICANN de favoriser les règlements de conflits de chaînes et d’autoriser, de façon discrétionnaire, des dérogations des dates butoir lors du rejet de la deuxième demande.

      Attendu que les Demandeurs exprimèrent qu’en rejetant leur deuxième demande l’ICANN n’a pas respecté les engagements souscrits dans le cadre de ses statuts constitutifs de « prendre des décisions suivant des politiques documentées de façon neutre et objective en faisant preuve d’intégrité et d’impartialité ».

      Attendu que, le Comité du Conseil d’administration chargé des mécanismes de responsabilité (BAMC) a précédemment déterminé que la demande 19-4 était suffisamment fondée et a envoyé la demande 19-4 à l’ombudsman à des fins d’examen conformément au chapitre 4 articles 4.2(j) et (k) des statuts constitutifs de l’ICANN.

      Attendu que, l’ombudsman s’est abstenu de prendre part aux discussions relatives à cette question conformément au chapitre 4 article 4.2(l)(iii) des statuts constitutifs.

      Attendu que, après examen attentif du bien-fondé de la demande 19-4 et de la documentation pertinente, le BAMC a recommandé que la demande 19-4 soit rejetée puisqu’à travers le rejet de la deuxième demande, le personnel de l’ICANN n’avait manqué ni à la prise en compte de la documentation, ni aux engagements de l’ICANN, ni à ses valeurs fondamentales ou à ses politiques antérieures.

      Attendu que le BAMC a recommandé au Conseil d’administration de charger l’organisation ICANN de s’informer auprès des Demandeurs des derniers développements, et dans le cas où ils informeraient des progrès depuis le dépôt de la demande 19-4 et qu’une résolution privée semble envisageable à court terme, de considérer l’octroi d’une dérogation offrant aux Demandeurs un délai supplémentaire pour leur permettre d’achever le processus de résolution privée.

      Attendu que les Demandeurs ont présenté une réfutation de la recommandation du BAMC conformément à l’article 4.2(q) du chapitre 4 des statuts constitutifs de l’ICANN.

      Attendu que la réfutation rend compte des derniers développements survenus dans l’approche d’une résolution privée de l’enchère pour conflit de chaînes et du fait que les Demandeurs ne seront pas à même de résoudre leur différend au sujet du .MERCK au cours du prochain mois et qu’ils demandent le report de l’enchère à la fin du mois d’août 2020.

      Il a été décidé (2020.01.26.12), que le Conseil d’administration adopte la recommandation du BAMC et rejette en conséquence la demande de réexamen 19-4.

      Il a été décidé (2020.01.26.13) que le Conseil d’administration charge le Président-directeur général ou son (ses) représentant(s) de s’informer des récents développement en matière de règlement de différends auprès des Demandeurs. Si les Demandeurs déclarent d’un commun accord que des progrès ont été faits depuis le dépôt de la demande 19-4 et si l’ICANN considère qu’une résolution privée semble envisageable à court terme, le Conseil d’administration demandera au Président-directeur général, ou à son ou ses représentants, de considérer l’octroi d’une dérogation offrant un délai supplémentaire aux requérants pour leur permettre d’achever le processus de résolution privée.

      Il est résolu (2020.01.26.14) que si les Demandeurs n’informent pas des développements récents concernant la procédure de résolution et/ou si l’organisation ICANN n’envisage pas une solution privée à court terme, le Conseil d’administration chargera le Président-directeur général, ou son ou ses représentants, de poursuivre le traitement de les candidatures relatives au .MERCK et, si l’ICANN estime qu’il y a lieu de le faire, d’organiser une enchère.

      Fondements des résolutions 2020.01.26.12 et 2020.01.26.14

      1. Bref résumé et recommandation

        L’ensemble des faits est énoncé dans la recommandation du BAMC relative à la demande 19-4 (Recommandation du BAMC), que le Conseil d’administration a examinée et prise en compte et qui est jointe à ces présentes.

        Le 19 décembre 2019, après examen attentif du bien-fondé de la demande 19-4 et de la documentation pertinente, le BAMC a recommandé que la demande 19-4 soit rejetée puisque dans son rejet de la deuxième demande, le personnel de l’ICANN n’avait manqué ni à la prise en compte de la documentation, ni aux engagements de l’ICANN, ni à ses valeurs fondamentales ou à ses politiques antérieures.

        Le 3 janvier 2020, les Demandeurs ont soumis une réfutation à la recommandation du BAMC (la réfutation) conformément à l’article 4.2(q) du chapitre 4 des statuts constitutifs de l’ICANN. Les Demandeurs déclarent que : (1) Le BAMC a qualifié de façon erronée la nature du différend en matière de droits des marques déposées entre les Demandeurs et le terme « Merck » ; (2) la règle du guide de candidature interdisant les renouvellements multiples ne s’applique pas aux Demandeurs ; (3) le BAMC a pénalisé les Demandeurs de façon inappropriée étant donnée l’absence d’évidences du manquement imputé au personnel de l’ICANN dans l’examen de la documentation ; (4) en rejetant leur deuxième demande, le personnel de l’ICANN fait une fois encore preuve de discrimination à l’égard des Demandeurs ; et (5) bien que les Demandeurs aient initialement prévu de résoudre le conflit de chaînes en début 2020, ils demandent à présent au personnel de l’ICANN de reporter les enchères jusqu’à la fin d’août 2020 pour leur permettre une résolution privée du conflit de chaînes.

        Le Conseil d’administration, après avoir examiné attentivement la recommandation du BAMCet tous les documents pertinents en lien avec la demande 19-4, a décidé de rejeter celle-ci. Suivant la recommandation du BAMC, le Conseil d’administration demande à l’organisation ICANN de s’enquérir auprès des Demandeurs des derniers développements en matière de règlement du conflit bien que la réfutation laisse entrevoir qu’une résolution privée ne saurait être obtenue avant août 2020. Si les requérants affirment conjointement avoir avancé depuis le dépôt de la demande 19-4 et si l’ICANN considère qu’une résolution privée est plus proche que ne le suggère la réfutation, le Conseil d’administration demandera à l’ICANN de considérer l’octroi d’une dérogation offrant un délai supplémentaire aux Demandeurs pour leur permettre d’achever le processus de résolution privée.

      2. Problématique

        Les problématiques sont les suivantes :

        • Le personnel de l’ICANN a-t-il omis de considérer des informations importantes des Demandeurs lors du rejet de leur deuxième demande de report de l’enchère de l’ensemble conflictuel .MERCK ?

        • Lors du rejet de la deuxième demande des Demandeurs de reporter l’enchère de l’ensemble conflictuel .MERCK, le personnel de l’ICANN a-t-il manqué aux politiques établies qui promeuvent la résolution volontaire des conflits de chaînes et permettant de reporter les dates butoir ?

        • Lors du rejet de la deuxième demande des Demandeurs de reporter l’enchère de l’ensemble conflictuel .MERCK, le personnel de l’ICANN a-t-il manqué à son engagement de « prendre des décisions en appliquant des politiques documentées de façon cohérente, neutre, et en tout intégrité et équité ?

      3. Analyse et fondements

        1. Le personnel de l’ICANN n’a pas manqué à l’examen de la documentation pertinente avant son rejet de la deuxième demande.

          Lors de son rejet de la deuxième demande, le personnel de l’ICANN a examiné toute la documentation pertinente. Les Demandeurs affirment que le personnel de l’ICANN a ignoré les précédents en matière de litiges multi-juridictionnels entre eux concernant la marque déposée « Merck », de même que les différents jugements attendus « dans les prochains mois » de plusieurs affaires en cours, tout comme leur espoir de résoudre « bientôt » leur conflit portant sur .MERCK à travers un accord volontaire.5 Les requérants soulignent que ces éléments sont déterminants dans le cadre de leur deuxième demande.6 Le BAMC a conclu les points suivants : (1) les requérants n’ont pas présenté de preuves étayant l’affirmation selon laquelle le personnel de l’ICANN n’aurait pas pris en considération le contexte du différend ; (2) la longue histoire du conflit est bien connue du personnel de l’ICANN ; (3) celui-ci est au courant des efforts actuels des requérants pour parvenir à une résolution privée ; et (4) en tout état de cause, l’information concernant la dispute des requérants ou les tentatives de résolution privée ne revêtent pas un caractère décisif dans la décision du personnel de l’ICANN face à la deuxième demande.7

          Dans leur réfutation, les Demandeurs invoquent que, face à leur affirmation vis-à-vis du manquement du personnel de l’ICANN à considérer la documentation pertinente fournie, aucune demande de preuve ne leur a été faite et qu’il est impossible de prouver ce type de manquement.8 Le Conseil d’administration reconnait que le personnel de l’ICANN n’a pas fait de référence explicite au « contexte politiquement sensible et à la complexité juridique »9 entourant les Demandeurs dans sa décision portant sur la deuxième demande ; toutefois, le registre indique le contraire de ce que les Demandeurs soutiennent, à savoir, que le personnel de l’ICANN était pleinement conscient de ce contexte. Les Demandeurs doivent réfuter cette évidence, ce qu’ils ont échoué à faire. En conséquence, le BAMC a conclu, avec l’approbation du Conseil d’administration, que le personnel de l’ICANN était au fait de l’historique long et contentieux des Demandeurs.10

          Dans le cadre du rejet de la deuxième demande, les Demandeurs ont également remis en cause l’affirmation du personnel de l’ICANN selon laquelle deux semaines représentaient «un temps suffisant pour conclure et parvenir à une auto-résolution de l’ensemble conflictuel.» Les Demandeurs affirment que le personnel de l’ICANN n’a pas pris la mesure des efforts réalisés par les Demandeurs pour parvenir à un règlement volontaire ; sans quoi (d’après les Demandeurs), le personnel de l’ICANN aurait compris que deux semaines ne permettraient pas aux parties, en raison du contexte sensible et juridiquement complexe, de résoudre leur différend.11 Toutefois, dans son rejet de la deuxième demande, le personnel de l’ICANN précisa que celui-ci ne devait en rien entraîner la suspension par les parties de leur tentative de résolution privée du conflit de chaînes. La déclaration affirmait clairement que les deux parties restaient libres de poursuivre leurs négociations pour suspendre le conflit de chaînes jusqu’à la date butoir. Rien dans le rejet par le personnel de l’ICANN de la deuxième demande ne laisse entendre que celui-ci ait négligé la complexité du différend soulevé par les Demandeurs. Le Conseil d’administration est d’accord avec le BAMC pour dire qu’il n’existe aucune indication d’un manquement du personnel de l’ICANN à prendre ces informations en compte.

          En tout état de cause, le BAMC a conclu que l’information concernant l’historique des différends et des tentatives de résolution des Demandeurs n’était pas centrale ni pertinente pour la décision du personnel de l’ICANN vis-à-vis de la deuxième demande.12 Le Conseil d’administration coïncide. Le rejet par le personnel de l’ICANN de la deuxième demande se fonde sur la règle de ne pas octroyer plus d’une dérogation pour ajourner l’enchère suite à tout ensemble conflictuel, indépendamment de l’objet de la demande.13

        2. Le personnel de l’ICANN n’a pas manqué à la politique de l’ICANN visant à favoriser les règlements volontaires.

          Les Demandeurs déclarent que le rejet de la deuxième demande par le personnel de l’ICANN constitue un manquement à la politique de l’organisation visant à favoriser les règlements volontaires des ensembles conflictuels et considérant les enchères d’ensembles conflictuels comme dernier recours, uniquement. 14. Le BAMC a conclu, et le Conseil d’administration est d’accord, que le rejet de la deuxième demande était en accord avec et ne portait pas atteinte à la politique de l’ICANN visant à favoriser la résolution volontaire des conflits de chaînes et ne considérant les enchères que comme un moyen pour départager les parties. 15

          Dans leur réfutation, les Demandeurs contestent l’affirmation du BAMC selon laquelle le guide de candidature préconise de « n’octroyer qu’un seul report et que l’ICANN ne puisse en octroyer davantage aux parties en litige qui en font la demande ».16 Les Demandeurs affirment que cette formulation ne s’applique pas dans leur cas puisqu’elle figure dans la section du guide de candidature consacrée aux procédures d’évaluation de la priorité communautaire, alors que « plus d’une candidature communautaire remplit les critères de la priorité communautaire et aucune des candidatures communautaires pour .MERCK ne remplit les critères de la priorité communautaire ».17

          Toutefois, bien que la discussion sur la règle de report unique du guide de candidature figure dans la section consacrée aux procédures d’évaluation de la priorité communautaire, la formulation du guide de candidature précise clairement que les demandes mutuelles de report des enchères ne seraient octroyées qu’à une seule reprise. En outre, tel que signalé par le BAMC et reconnu par les Demandeurs, le guide de candidature n’est pas le seul document à mentionner la règle du report unique. Le « formulaire de demande d’avancement/ report de date d’une enchère » (le formulaire de demande de report) précise que « l’ICANN peut répondre positivement à une demande de report par ensemble conflictuel. » 18 Comme souligné par le BAMC, la version actuelle des règles régissant les enchères pour les nouveaux gTLD mentionne le formulaire de report de date d’une enchère.19 Ce formulaire « offre aux candidats ayant reçu une notification d’intention d’enchère la possibilité de déposer une demande d’avancement ou de report de la date des enchères prévue » à condition que tous les membres de l’ensemble conflictuel acceptent ledit report ( ou avancement).20 Le formulaire de demande de report est à disposition de toutgroupe de candidats pour toutensemble conflictuel (à condition que tous les membres de l’ensemble conflictuel soient d’accord avec le report). Le formulaire de demande de report ne limite pas la règle du report unique à un certain type de d’ensemble conflictuel mais l’applique, au contraire, à tous.21

          Le Conseil d’administration conclut que le formulaire de demande de report met en évidence la règle de l’organisation ICANN selon laquelle une seule demande mutuelle de report d’enchère est accordée et que la référence faite à ce sujet dans le guide de candidature et les règles régissant les enchères ne limitent pas l’application de cette règle à un certain type d’ensemble conflictuel, ni ne permettent des reports multiples à certains types d’ensemble conflictuels.

          Les Demandeurs ont également suggéré dans leur réfutation que bien qu’ayant tenté en toute bonne foi de résoudre l’ensemble conflictuel .MERCK pendant plus de cinq mois (plus de huit à présent) et que, depuis la date d’enchère initialement prévue pour cet ensemble conflictuel, le 2 mai 2019, « la situation est devenue plus compliquée » – laissant entendre ainsi que cinq mois ne suffiront pas. .22 Toutefois, il est à noter que les Demandeurs ont eu plus de cinq mois pour régler leur différend. Les Demandeurs sont impliqués dans des conflits entre eux depuis des décennies. Depuis le dépôt en 2012 de leurs candidatures concurrentielles pour .MERCK, les Demandeurs savaient pertinemment que sans un accord privé, celles-ci seraient vouées à être mises en enchère, ou ne serait-ce que depuis mars 2013, lors de l’enregistrement d’une objection pour atteinte aux droits de Merck KGaA contre la candidature de Merck Registry Holdings, Inc.directement liée à l’utilisation du nom « Merck ».23 Cet argument des Demandeurs ne justifie donc pas un réexamen.

          Le BAMC a conclu, et le Conseil d’administration l’approuve pour les raisons susmentionnées et celles figurant dans la recommandation du BAMC, que le rejet de la deuxième demande et, de façon plus générale, la règle de l’ICANN s’opposant à un second report des enchères dans les situations de conflit de chaînes, ne portait pas atteinte à la politique de l’ICANN en faveur de la résolution volontaire de ces conflits et considérait les enchères uniquement comme un moyen de départager les parties. En outre, il est a noter que la règle s’opposant à un second report n’empêche pas les résolutions, mais plutôt, en fixant une date butoir pour les enchères, elle dissuade les parties de prolonger indéfiniment leurs différends en matière de gTLD. Ce recours aux enchères pour mettre un terme à un conflit après un délai raisonnable s’inscrit pleinement dans la politique de l’ICANN en faveur d’une résolution et de sa conception des enchères comme une solution de dernier recours pour résoudre les conflits de chaînes.

        3. Le personnel de l’ICANN n’a pas manqué à son obligation d’appliquer les politiques de façon neutre et objective.

          Les Demandeurs soutiennent que le rejet de leur deuxième demande constitue un manquement du personnel de l’ICANN à l’engagement de prendre des « décisions en appliquant les politiques documentées, en toute intégrité et équité. » Le BAMC a conclu, et le Conseil d’administration l’approuve, que ni les engagements de l’ICANN d’appliquer des politiques en toute neutralité ni tout autre engagement n’empêche le recours à la règle de l’ICANN qui s’oppose à l’octroi d’un deuxième report ou qui exigent une réponse au cas par cas.

          Dans leur réfutation, les Demandeurs laissent entendre que « étant données les circonstances exceptionnelles » le personnel de l’ICANN aurait dû considérer la deuxième demande en faisant preuve de « flexibilité et de discrétion », même si l’organisation ICANN interdit par ailleurs les deuxièmes demandes de report. 24 Le « caractère exceptionnel [. . .] des circonstances » en jeu, d’après les Demandeurs, provient du fait que les deux Demandeurs sont ici « pleinement alignés » dans la mesure ou « ils sont pleinement d’accord sur le report de la vente aux enchères ». 25 Toutefois, ces circonstances ne sont en rien uniques; l’accord entre les Demandeurs constitue un pré-requis pour toute demande de report. 26Le Conseil d’administration a conclu que cet argument ne justifie donc pas un réexamen.

          Les Demandeurs s’opposent à la conclusion du BAMC selon laquelle le fait d’appliquer la règle d’un seul report « permet de traiter toute demande de deuxième report en toute équité, l’ensemble de ces demandes étant rejetées. » 27 Les Demandeurs avancent que le rejet de leur seconde demande de la part du personnel de l’ICANN constitue une « discrimination à leur encontre ».28 Tel que le signalent les Demandeurs, l’engagement souscrit par l’ICANN de prendre « des décisions en appliquant des politiques documentées de façon neutre et objective en toute intégrité et équité » 29 « vise notamment à prévenir toute discrimination à l’égard d’une partie en particulier ».30 Néanmoins, les Demandeurs n’ont pas pu démontrer que le personnel de l’ICANN ait fait preuve d’un traitement différenciéà l’égard de l’une des parties, n’ayant pu signaler de partie ayant bénéficié d’un traitement différent ni n’ont pu signaler le moindre manquement de l’ICANN à sa politique de n’autoriser qu’une seule demande de report d’enchères. Le Conseil d’administration coïncide avec la conclusion du BAMC selon laquelle la règle du report unique permet en réalité au personnel de l’ICANN de traiter toute demande de deuxième report en toute égalité. Cet argument ne justifie donc pas un réexamen.

        4. L’opposition des Demandeurs à la règle objectant un deuxième report des enchères ne justifie donc pas un réexamen.

          Les Demandeurs s’opposent avant tout à la règle de l’organisation ICANN visant à rejeter, dans tous les cas de figure, un deuxième report.31 Le BAMC a conclu qu’aucun des arguments des Demandeurs n’a démontré que cette règle contredisait la mission de l’ICANN, ses engagements, ses valeurs fondamentales et/ou ses politiques établies, ni ne justifie nullement un réexamen du rejet de la deuxième demande.32

          Dans leur réfutation, les Demandeurs précisent qu’ils ne remettent pas en question la règle qui s’oppose au deuxième report des enchères, mais « la motivation du personnel de l’ICANN à refuser un deuxième report des enchères ».33 En vertu des raisons énoncées dans la recommendation du BAMC, le Conseil d’administration conclut que ce qui a motivé le personnel à rejeter la deuxième demande tient à sa volonté de se conformer à la règle de l’ICANN du report unique. Le Conseil d’administration conclut que les arguments portant sur la motivation du personnel de l’ICANN ne justifient pas de réexamen.

        5. Actualisation des Demandeurs concernant les négoiations pour la résolution

          Dans leur réfutation, les Demandeurs ont fait part des développements récents concernant le litige en cours qu’il mettent en lien avec les négociations portant sur .MERCK. Les Demandeurs ont initialement déclaré qu’ils étaient « très près de parvenir à la résolution de leurs différends », bien que les règlements des différends en cours en Australie, en Chine, en Inde, en Suisse, aux EUA et au R-U soient prévus pour juin 2020 ; et « une fois que les décisions sus-mentionnées et que les audiences aient eu lieu, nous serons en meilleure position pour parvenir à un règlement ». Les Demandeurs sollicitent actuellement un délai jusqu’en août 2020 pour tenter de résoudre leur conflit de chaînes.34

          Le Conseil d’administration considère que mandater l’organisation ICANN pour de futures mises à jours sur ce sujet n’a guère de chance d’aboutir à d’autres ou à de nouvelles informations. Quoi qu’il en soit, le Conseil d’administration reconnait que les Demandeurs ont proposé de « fournir au Conseil d’administration des actualisations détaillées des décisions de justice attendues en juin 2020 et des progrès accomplis en vue d’un règlement ».35 Par conséquent, pour faire bonne mesure, le Conseil d’administration a chargé le Président-directeur général, ou sa ou ses représentants, de s’enquérir de toute actualisation auprès des Demandeurs afin de savoir si : (i) les Demandeurs ont reçu certaines des décisions de justice attendues en janvier 2020; et (ii) quels progrès ont été accomplis, le cas échéant, en vue d’un accord. Si des progrès sont reconnus de part et d’autre par les Demandeurs depuis le dépôt de leur demande 19-4 et que l’organisation ICANN observe avec satisfaction que ceux-ci approchent une résolution privée, le Conseil d’administration demandera à l’organisation ICANN de leur proposer une dérogation leur permettant de bénéficier d’un délai supplémentaire pour parvenir à un règlement du différend. Si les Demandeurs ne fournissent aucune actualisation des progrès réalisés en vue d’un accord, et/ou si l’ICANN n’est pas persuadée que les Demandeurs approchent une résolution privée, le Conseil d’administration chargera le Président-directeur général, ou son ou ses représentants, de poursuivre le traitement de la candidature de .MERCK, et, notamment, si l’organisation ICANN le considère approprié, de programmer une enchère.

          Cette décision s’inscrit dans le cadre de la mission de l’ICANN et sert l’intérêt public puisqu’il est important de s’assurer qu’en menant à bien sa mission, l’ICANN s’acquitte de ses responsabilités vis-à-vis de la communauté en opérant dans le cadre de son acte constitutif, de ses statuts constitutifs et de ses autres procédures établies. Dans le cadre de cette redevabilité, une procédure permettant de demander le réexamen de cette action ou inaction de la part du Conseil d’administration sera mise à disposition de toute personne ou entité matériellement affectée par le Conseil d’administration de l’ICANN ou son personnel. Cette mesure n’a aucun impact financier sur l’ICANN et n’aura pas d’incidence négative 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.


1 https://www.icann.org/en/system/files/files/idn-vip-integrated-issues-final-clean-20feb12-en.pdf

2 https://www.icann.org/en/system/files/files/draft-lgr-procedure-20mar13-en.pdf

3 https://www.icann.org/resources/pages/idn-variant-tld-implementation-2018-07-26-en

4 les responsables de mise en œuvre son d’anciens membres de la CCT-RT s’étant portés volontaires pour fournir des éclaircissements, à la demande, sur les intentions, les fondements, les évènements ayant prévalu aux conclusions, et aux mesures de mise en œuvre. Pour plus d’information voir https://community.icann.org/display/CCT/Implementation+Shepherds.

5 Demande 19-4, paragraphe 8, pages .

6 Voir id.

7 Pages 9 et 10 de la recommandation du BAMC .

8 Pages 3 et 4 de la Réfutation .

9 Demande 19-4, § 8, p. 7.

10 Numéro 28, 9 de la page 4 de la recommandation du BAMC. .

11 Page 4 de la réfutation Les Demandeurs affirment également que dans sa recommandation, le BAMC énonce que ceux-ci « possèdent chacun des droits de marque déposée impliquant le terme « Merck », lesquels ont été et sont toujours sujets de litige dans de nombreuses juridictions depuis des décennies », indiquant ainsi que le personnel de l’ICANN n’a pas pris en compte l’historique des Demandeurs lorsqu’il a évalué la seconde demande, car « toutes les affaires en cours » ont été initiées suite à leur candidature pour le gTLD .MERCK en 2012. Page 3 de la réfutation. Que les disputes légales des Demandeurs aient commencé il y a sept ans ou il y a des décennies n’est pas pertinent, le BAMC et le personnel de l’ICANN étant au fait de l’historique du litige des Demandeurs. Plus important encore, le Conseil d’administration approuve l’opinion du BAMC selon laquelle l’historique des Demandeurs (aussi longue soit-il) n’est pas essentiel à cette seconde demande.

12 Numéro 28, 9 de la page 4 de la recommandation du BAMC. .

13 Id.

14 Demande 19-4, paragraphe 8, pages .

15 Consultez les pages 11 et 12 de la recommandation du BAMC.

16 Page 4 de la réfutation, citant la page 9 de la recommandation du BAMC.

17 Id., page 5.

18 Formulaire de demande de report https://newgtlds.icann.org/en/applicants/auctions/date-advancement-postponement-form-09nov17-en.pdf (accent mis sur les originaux ).

19 numéro 53 à la page 10 de la recommandation du BAMC, citant les règles régissant les enchères pour les nouveau gTLD (3 Nov. 2014), paragraphe 10, https://newgtlds.icann.org/en/applicants/auctions/rules-03nov14-en.pdf

20 Formulaire de demande de report.

21 Le Conseil d’administration reconnait que les règles régissant les enchères stipulent que les candidats doivent soumettre une demande de report via le portail des utilisateurs de l’ICANN sans avoir recours au formulaire de demande de report dans certaines circonstances. Paragraphe 10 des règles régissant les enchères. Toutefois, la discussion sur le report figurant parmi les règles régissant les enchères n’indique en rien que l’ICANN puisse octroyer de multiples reports pour un même ensemble conflictuel. Consultez id. Le Conseil d’administration conclut que les règles régissant les enchères ne contiennent pas pas de règle en faveur de reports multiples de l’enchère d’un ensemble conflictuel.

22 Page 10 de la réfutation

23Détermination des experts au sujet de l’objection pour atteinte aux droits, mars 2013. https://www.wipo.int/export/sites/www/amc/en/domains/lro/docs/lro2013-0009.pdf; https://www.wipo.int/export/sites/www/amc/en/domains/lro/docs/lro2013-0010.pdf; https://www.wipo.int/export/sites/www/amc/en/domains/lro/docs/lro2013-0011.pdf. Les Demandeurs ont été encore une fois avertis de la nécessité éventuelle de régler l’ensemble conflictuel via une résolution privée ou via une enchère lors de la demande de réexamen 16-12, déposée en août 2016 par Merck KGaA. Pages 11 et 12 de la recommandation du BAMC .

24 Pages 3 et 4 de la Réfutation .

25 Id.

26 Paragraphe 10 des règles régissant les enchères ; Consultez également le Formulaire de demande de report.

27 Page 7 de la réfutation, citant la page 14 de la recommandation du BAMC.

28 Id.

29 Article 1.2(a) du chapitre 1 des statuts constitutifs de l’ICANN.

30 Page 7 de la réfutation

31 Demande 19-4, paragraphe 8, pages .

32 Page 15 de la recommandation du BAMC.

33 Page 8 de la réfutation

34 Page 10 de la réfutation

35 Id.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."