Skip to main content
Resources

Résolutions du Conseil d'administration approuvées | Réunion ordinaire du Conseil d'administration de l'ICANN

Cette page est disponible en:

  1. Ordre du jour approuvé :
    1. Approbation du procès-verbal de la réunion du Conseil d’administration
    2. Nomination d’Andrey Kolesnikov au Comité consultatif sur la sécurité et la stabilité
    3. Approbation des amendements aux statuts de l’unité constitutive des utilisateurs non commerciaux de la GNSO
    4. Nouveaux seuils de vote de la GNSO pour résoudre la question des rôles et responsabilités post-transition de la GNSO comme participant-décideur de la communauté habilitée — Modifications proposées aux statuts constitutifs de l’ICANN
    5. Report de la transition vers la mise en œuvre de la politique du WHOIS détaillé
    6. Approbation du contrat d’agent d’entiercement de données des bureaux d’enregistrement
    7. Obtenir des commentaires supplémentaires sur le nouveau plan de roulement de la KSK
  2. Ordre du jour principal :
    1. Options pour aborder la demande du groupe des représentants des opérateurs de registres (RySG) de remboursement des frais d’accès au mécanisme de protection des droits du registre TMCH
    2. Examen de la spécification temporaire relative aux données d’enregistrement des gTLD (mise en œuvre du modèle intérimaire en matière de conformité au RGPD)
    3. Examen de la demande de réexamen 17-5
    4. Divers

 

  1. Ordre du jour approuvé :

    1. Approbation du procès-verbal de la réunion du Conseil d’administration

      Il est résolu (2018.05.13.01) que le Conseil d’administration approuve le compte-rendu de la réunion ordinaire du Conseil d’administration de l’ICANN du 15 mars 2018.

    2. Nomination d’Andrey Kolesnikov au Comité consultatif sur la sécurité et la stabilité

      Attendu que, le Comité consultatif sur la sécurité et la stabilité (SSAC) procède à l’évaluation de ses membres et à des ajustements le cas échéant.

      Attendu que, le Comité des membres du SSAC, pour le compte du SSAC, a demandé au Conseil d’administration de nommer Andrey Kolesnikov au SSAC pour un mandat de trois ans, prenant cours immédiatement après l’approbation par le Conseil d’administration et s’achevant le 31 décembre 2020.

      Il est résolu (2018.05.13.02) que le Conseil d’administration nomme Andrey Kolesnikov au SSAC pour un mandat de trois ans, prenant cours immédiatement après l’approbation par le Conseil d’administration et s’achevant le 31 décembre 2020.

      Fondements de la résolution 2018.05.13.02

      Le SSAC est un groupe diversifié composé de personnes dont l’expertise dans des sujets spécifiques lui permet de satisfaire aux objectifs de sa charte et de remplir sa mission. Depuis sa création, le SSAC a invité des personnes ayant une connaissance et une expérience approfondies dans les domaines techniques et de sécurité fondamentaux pour la sécurité et la stabilité des systèmes de nommage et d’adressage d’Internet.

      Le fonctionnement continu du SSAC en tant qu’organe compétent dépend de l’ensemble des experts dans des domaines donnés qui consentent à consacrer une partie de leur temps et de leur énergie pour mener à bien la mission du SSAC.

      Andrey a participé activement à l’ICANN pendant quelques années et est reconnu par un certain nombre de membres du SSAC pour son travail à titre de directeur général du Centre de coordination pour les domaines de premier niveau de la Fédération de Russie et plus récemment son implication dans les technologies de l’IoT, leurs normes et protocoles. Il apporte son expertise concernant les opérations ccTLD, les noms de domaine internationalisés et l’IoT et une grande capacité à réseauter au sein d’environnements multiculturels et multilingues.

      Le SSAC estime qu’Andrey Kolesnikov a beaucoup à lui apporter.

      Cette résolution relève d’une fonction administrative et organisationnelle qui ne nécessite pas de consultation publique. La nomination des membres du SSAC est prise dans l’intérêt public et s’inscrit dans la poursuite de la mission de l’ICANN dans la mesure où elle contribue à l’engagement de l’organisation ICANN de renforcer la sécurité, la stabilité et la résilience du DNS.

    3. Approbation des amendements aux statuts de l’unité constitutive des utilisateurs non commerciaux de la GNSO

      Attendu que, les statuts constitutifs de l’ICANN (Chapitre 11 article 11.5 c) indiquent que « chaque groupe de parties prenantes identifié à l’article 11.3(a) et, le cas échéant, chacune de ses unités constitutives, doit être reconnu par le Conseil d’administration de l’ICANN » ;

      Attendu que, le Conseil d’administration a mis en place un processus d’amendement des chartes de groupes de parties prenantes et des unités constitutives de la GNSO (ci-après le « processus ») ;

      Attendu que, l’unité constitutive des utilisateurs non commerciaux de la GNSO (NCUC), l’organisation de l’ICANN et le Comité du Conseil d’administration chargé de l’efficacité organisationnelle (OEC) ont rempli à ce jour toutes les étapes identifiées dans le processus, y compris la détermination que ces modifications n’auraient aucune conséquence en matière de fiscalité ou de responsabilité pour l’organisation de l’ICANN et l’OEC a recommandé que le Conseil approuve les modifications proposées.

      Il est résolu (2018.05.13.03) que le Conseil d’administration de l’ICANN approuve les amendements proposés à la charte de la NCUC, tels que dûment étayés dans ces documents d’information et pièces jointes.

      Il est résolu (2018.05.13.04), que le conseil demande au président-directeur général de l’ICANN, ou son représentant, de communiquer la présente résolution à la direction de la NCUC et qu’il fournisse l’accès à la mise à jour de la charte de la NCUC sur les pages Web de l’ICANN et de la NCUC.

      Fondements des résolutions 2018.05.13.03 à 2018.05.13.04

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

      Les statuts constitutifs de l’ICANN (chapitre 11 article 11.5 c) indiquent que « chaque groupe de parties prenantes identifié à l’article 11.3(a) et, le cas échéant, chacune de ses unités constitutives, doivent être reconnus par le Conseil d’administration de l’ICANN. » Le Conseil d’administration de l’ICANN suit un processus par lequel il approuve officiellement tout amendement de la charte d’un groupe de parties prenantes ou unité constitutive de la GNSO pour soutenir le maintien de la reconnaissance.

      En septembre 2013, le Conseil d’administration a mis au point un processus d’amendement des chartes des groupes de représentants et des unités constitutives de la GNSO (le « processus ») afin de fournir une méthodologie simplifiée pour rester en conformité avec les exigences des statuts.

      En mai 2017, l’Unité constitutive des utilisateurs non commerciaux (NCUC) de la GNSO a approuvé la version modifiée de ses documents constitutifs et a bénéficié du Processus.

      Quelles sont les propositions à l’étude ?

      La NCUC a modifié substantiellement sa charte actuelle afin de s’adapter à l’évolution de sa composition et de lui permettre de gérer plus efficacement ses responsabilités en matière d’élaboration de politiques. Parmi les différentes modifications apportées à la charte, les plus significatives sont les suivantes :

      1. alignement de diverses dispositions de la charte du groupe de représentants des entités non commerciales ;
      2. ajout d’un nouveau chapitre qui détaille soigneusement les nouveaux mécanismes d’aide pour que la NCUC remplisse ses obligations dans le cadre de la nouvelle communauté habilitée de l’ICANN ;
      3. clarification des critères d’admissibilité des membres de la NCUC – en particulier la définition des organisations membres et les questions des organismes non admissibles ;
      4. Élargissement des dispositions obligeant les membres de la NCUC à divulguer les cas de soutien de l’ICANN ou de certaines parties de la communauté de l’ICANN ;
      5. approfondissement des spécifications du comité exécutif de la NCUC y compris : ajout de détails sur les obligations et les attentes des représentants régionaux au sein du comité exécutif de la NCUC ; élargissement des dispositions permettant la révocation de fonctionnaires de la NCUC ; création d’une nouvelle fonction de la vice-présidence – remplacer la fonction du secrétaire-trésorier ; et spécifications supplémentaires concernant la fonction de trésorier de la NCUC.

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

      Outre les discussions communautaires exhaustives menées au sein de la NCUC, les modifications proposées ont fait l’objet d’une période de consultation publique de 41 jours (24 août au 3 octobre 2017). À l’issue de cette période, le 4 octobre 2017, l’ICANN org a rédigé un rapport de synthèse soumis à l’examen de la communauté et de l’OEC du Conseil d’administration.

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

      Les membres du conseil d’administration ont examiné les amendements proposés à la charte, une copie de la version surlignée des modifications proposées à la charte suivant l’examen initial par le personnel avant la procédure de consultation publique, et une copie du rapport de synthèse du personnel résumant les observations de la communauté.

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

      La NCUC, l’organisation de l’ICANN et le Comité du conseil d’administration chargé de l’efficacité opérationnelle (OEC) ont suivi toutes les étapes du processus et ont notamment précisé que les propositions d’amendement de la charte n’auront aucune répercussion financière ou en termes de responsabilité sur l’organisation de l’ICANN et les modifications ont été publiées pour révision et commentaires de la communauté. L’OEC a recommandé au Conseil d’administration d’approuver les amendements à la charte de la NCUC.

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

      La NCUC a modifié sa charte afin de s’adapter à l’évolution de sa composition et de gérer plus efficacement ses responsabilités en matière d’élaboration de politiques.

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

      On ne prévoit aucun impact financier sur l’organisation de l’ICANN ou sur les membres de la communauté de par les modifications proposées. Les modifications proposées sont dans la ligne de la mission de l’ICANN et répondent à l’intérêt public en mettant à jour les documents de gouvernance fondamentaux pour l’une des unités constitutives reconnues par le Conseil d’administration de l’ICANN.

      Existe-t-il des problèmes de sécurité, stabilité et résilience liés au DNS ?

      Cette décision ne devrait avoir aucun impact sur la sécurité, la stabilité et la résilience du système 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 ?

      Les amendements proposés ont fait l’objet d’une période de consultation publique de 41 jours (du 24 août au 3 octobre 2017).

    4. Nouveaux seuils de vote de la GNSO pour résoudre la question des rôles et responsabilités post-transition de la GNSO comme participant-décideur de la communauté habilitée — Modifications proposées aux statuts constitutifs de l’ICANN

      Attendu que, lors de sa réunion du 30 janvier 2018, le Conseil de l’Organisation de soutien aux extensions génériques (GNSO) a résolu de recommander au Conseil d’administration l’adoption des modifications proposées à l’article 11.3.i des statuts constitutifs de l’ICANN afin d’incorporer les nouveaux seuils de vote de la GNSO, qui diffèrent des seuils actuels fixés à la majorité simple des voix de chaque Chambre (voir https://www.icann.org/en/system/files/files/proposed-revisions-bylaws-article-11-gnso-redline-19jun17-en.pdf [PDF, 39 Ko]).

      Attendu que, l’addition de seuils de vote à l’article 11.3.i des statuts de l’ICANN comme proposée par la GNSO constitue un « amendement aux statuts ordinaires » en vertu de l’article 25.1 des statuts constitutifs.

      Attendu que, les statuts constitutifs de l’ICANN exigent que les amendements aux statuts ordinaires soient publiés pour consultation publique avant l’approbation par le Conseil, et que le15 mars 2018 le Conseil d’administration a demandé la publication de ces amendements proposés pour commentaire public.

      Attendu que, la période de commentaire public s’est ouverte le 26 mars 2018 et s’est terminée le 5 mai 2018.

      Attendu que, après avoir analysé les commentaires, le Conseil d’administration a examiné les amendements proposés pour adoption.

      Il est résolu (2018.05.13.05) que, le Conseil d’administration approuve l’amendement aux statuts de l’ICANN [PDF, 106 ko] pour y inclure les modifications proposées à l’article 11.3.i des statuts constitutifs de l’ICANN, y compris la reformulation aux fins de clarté proposée par le groupe des représentants des opérateurs de registres, pour refléter les seuils de vote supplémentaires de la GNSO, différents du seuil actuel d’un vote à la majorité simple de chaque Chambre pour aborder tous les droits nouveaux ou supplémentaires et les responsabilités en ce qui concerne la participation de la GNSO comme participant-décideur de la communauté habilitée.

      Fondements de la résolution 2018.05.13.05

      L’action approuvée aujourd’hui est l’amendement aux statuts constitutifs de l’ICANN pour incorporer les modifications à l’article 11.3.i des statuts de l’ICANN pour y refléter des seuils de vote supplémentaires, qui diffèrent des seuils actuels fixés à la majorité simple des voix de chaque Chambre (voir https://www.icann.org/en/system/files/files/proposed-revisions-bylaws-article-11-gnso-redline-19jun17-en.pdf [PDF, 39 Ko]). Ces seuils de vote supplémentaires visent à tenir compte des responsabilités et droits nouveaux ou supplémentaires associés au rôle de participant-décideur de la GNSO dans la communauté habilitée, ainsi qu’à mettre en œuvre ces droits et responsabilités nouveaux ou supplémentaires, tels qu’ils apparaissent dans les procédures opérationnelles révisées de la GNSO, publiées le 30 janvier 2018 (voir https://gnso.icann.org/en/council/op-procedures-30jan18-en.pdf [PDF, 1,68 Mo]). Le chapitre 2 de l’annexe D des statuts de l’ICANN indique que l’approbation des amendements aux statuts ordinaires par le Conseil prévoit ensuite de donner à la communauté habilitée l’occasion d’examiner si elle initiera une mesure de rejet.

      Ces amendements aux statuts constitutifs sont le résultat d’un processus qui a débuté lorsque, le 27 mai 2016 le Conseil d’administration de l’ICANN a adopté un ensemble de nouveaux statuts de l’ICANN qui reflètent des modifications nécessaires à la mise en œuvre de la proposition de transition du rôle de supervision des fonctions IANA. À la suite de l’achèvement de cette transition, le Conseil de la GNSO a reconnu que des modifications devraient peut-être être apportées aux procédures opérationnelles actuelles de la GNSO et mécanismes connexes, ainsi qu’aux statuts de l’ICANN. L’objectif était de rendre applicable ces nouvelles fonctions et obligations de la GNSO selon les nouveaux statuts de l’ICANN, y compris, mais sans s’y limiter la participation de la GNSO dans la communauté habilitée.

      Le Conseil de la GNSO a chargé l’équipe de rédaction des droits et obligations de la GNSO en vertu de la version modifiée des statuts de mettre en avant des recommandations pour modifier les statuts de l’ICANN et les procédures opérationnelles de la GNSO pour permettre une participation efficace de la GNSO dans les activités de l’ICANN. Le Conseil de la GNSO a accepté les recommandations de l’équipe de rédaction, qui ont été traduites en modifications des procédures opérationnelles de la GNSO et des seuils de vote supplémentaires dans l’article 11.3.i des statuts constitutifs de l’ICANN. Au cours de sa réunion du 30 janvier 2018, le Conseil de la GNSO a décidé à l’unanimité (https://community.icann.org/display/gnsocouncilmeetings/Motions+30+January+2018) de recommander l’adoption par le Conseil d’administration des amendements proposés aux statuts constitutifs de l’ICANN.

      Le 15 mars 2018, le Conseil d’administration a demandé à l’organisation de l’ICANN de publier pour consultation publique, pendant une période d’au moins 40 jours, l’amendement proposé aux statuts ordinaires, comportant les ajouts proposés à l’article 11.3.i des statuts de l’ICANN afin d’établir des seuils de vote supplémentaires pour la GNSO (voir https://features.icann.org/new-gnso-voting-thresholds-address-post-transition-roles-and-responsibilities-gnso-decisional.)

      L’organisation de l’ICANN a mis en place un forum public le 26 mars 2018. À la fin de la période de consultation publique le 5 mai 2018, selon le rapport de l’organisation de l’ICANN [PDF, 364 Ko] sur les commentaires publics, cinq commentaires ont été reçus. Selon ces commentaires, le groupe des représentants des opérateurs de registres (RySG), le groupe des représentants des bureaux d’enregistrement (RrSG), le groupe des représentants des entités non commerciales (NCSG), l’unité constitutive des représentants des utilisateurs commerciaux (BC), et l’unité constitutive des représentants de la propriété intellectuelle (IPC) soutiennent la proposition d’ajouts à l’article II.3.i. Bien que la BC ait réaffirmé sa position selon laquelle « le conseil de la GNSO ne permet pas de manière appropriée à la GNSO d’exercer les droits et responsabilités d’une communauté habilitée », et que l’IPC ait émis une réserve en ce qui concerne l’application du seuil électoral en dehors du champ d’application du processus d’élaboration de politiques, la BC déclare qu’elle soutient les seuils de vote recommandés et les modifications apportées aux statuts » et l’IPC déclare qu’elle « est en faveur de la résolution du Conseil de la GNSO de faire les modifications nécessaires à l’article 11.3.j des statuts de l’ICANN, et demande instamment l’adoption de cette proposition par le Conseil d’administration de l’ICANN. » Le RySG a également suggéré une reformulation mineure de l’article II.3.i afin d’en améliorer la clarté.

      Les commentaires publics traités, le conseil examine maintenant l’amendement proposé pour adoption. En prenant cette mesure, le Conseil d’administration a examiné l’amendement aux statuts de l’ICANN transmis par le conseil de la GNSO, les commentaires publics, et le rapport d’analyse des commentaires publics produit par l’organisation de l’ICANN.

      L’adoption des modifications proposées aux statuts n’aura aucune incidence financière prévue. L’approbation de la résolution n’aura pas d’impact sur la sécurité, la stabilité ou la résilience du nom de domaine. Cette action est compatible avec la mission de l’ICANN et sert l’intérêt public en soutenant l’efficacité et l’amélioration continue des structures de gouvernance et de responsabilité de l’ICANN.

    5. Report de la transition vers la mise en œuvre de la politique du WHOIS détaillé

      Attendu que, la politique de consensus relative au WHOIS détaillé impose à VeriSign de commence à accepter les données d’enregistrement sous forme « détaillée » fournies par les bureaux d’enregistrement à compter du 28 mai 2018, tous les nouveaux enregistrements de nom de domaine doivent être soumis au registre sous forme « détaillée » au plus tard le 28 octobre 2018 et la migration de l’ensemble des données d’enregistrement pertinentes relatives aux noms de domaine existants du WHOIS « résumé » au WHOIS « détaillé » doit être effectuée d’ici au 31 juillet 2019.

      Attendu que, dans le cadre de sa préparation de déploiement de l’acceptation des données WHOIS détaillées, Verisign a proposé des modifications aux contrats entre registres et bureaux d’enregistrement pour les domaines .COM et .NET.

      Attendu que, le groupe des représentants des bureaux d’enregistrement et Verisign ont exprimé des préoccupations sur les modifications proposées 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.

      Attendu que, l’organisation de l’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 de modifications des contrats entre registres et bureaux d’enregistrement visant à mettre en œuvre la politique de consensus relative au WHOIS détaillé.

      Attendu que, Verisign et le Groupe des représentants des bureaux d’enregistrement sont dans une impasse et 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 de consensus relative au WHOIS détaillé.

      Attendu que, le report du délai de mise en conformité permettra également à l’organisation ICANN de poursuivre le dialogue avec les autorités européennes (y compris le groupe de travail Article 29 de l’Union européenne, les agences de protection des données, les parties contractantes ainsi que d’autres parties prenantes concernées afin de mieux comprendre les aspects pertinents du RGPD et le lien qu’il peut y avoir avec le travail de l’ICANN, les politiques de l’organisation et les contrats avec les registres et bureaux d’enregistrement, y compris la politique relative au WHOIS détaillé.

      Il est résolu (2018.05.13.06) que le président-directeur général ou son représentant, est autorisé à reporter l’application de la mise en conformité de la politique de consensus WHOIS détaillé pour six mois, jusqu’au 30 novembre 2018, 30 avril 2019 et le 31 janvier 2020, respectivement, afin de laisser plus de temps aux registres et Verisign de parvenir à un accord sur les amendements nécessaires aux contrats registre-bureau d’enregistrement visés pour mettre en œuvre la politique.

      Fondements de la résolution 2018.05.13.06

      La politique de consensus relative au WHOIS détaillé exige de Verisign qu’il commence à accepter des bureaux d’enregistrement les données d’enregistrement « détaillées » à compter du 28 mai 2018, des bureaux d’enregistrement qu’ils soumettent aux registres .COM, .NET, et .JOBS les données d’enregistrements détaillées pour tous les nouveaux enregistrements de noms de domaine à partir du 28 octobre 2018, et la migration de toutes les données d’enregistrement de noms de domaine existants de « résumées » à « détaillées » d’ici le 31 juillet 2019. Afin de parachever le déploiement visant à accepter des données du WHOIS détaillé, Verisign, opérateur de registre pour .COM et .NET et fournisseur des services de registre back-end pour .JOBS, a proposé des amendements des contrats entre registres et bureaux d’enregistrement pour .COM et .NET de façon à établir un cadre juridique qui permettrait à Verisign de commencer à accepter la transmission de données détaillées des bureaux d’enregistrement vers le registre. 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, ne demande pas d’amendements au contrat entre registres et bureaux 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 conformément à la politique d’Employ Media.

      L’organisation de l’ICANN a suivi sa procédure d’amendement des contrats entre opérateurs de registre et bureaux d’enregistrement et a transmis les propositions d’amendements au groupe des représentants des bureaux d’enregistrement à des fins d’examen. Le groupe des représentants des bureaux d’enregistrement a exprimé des préoccupations quant à l’adoption des propositions d’amendements en raison de certaines questions relatives au Règlement général sur la protection des données (RGPD) de l’Union européenne qui entrera en vigueur le 25 mai 2018. De ce fait, l’étape suivante prévue dans la procédure consiste pour l’organisation ICANN à mener des consultations avec l’opérateur de registre et le groupe des représentants des bureaux d’enregistrement de façon à dissiper ces préoccupations.

      L’organisation de l’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 tel accord. De plus, l’organisation de l’ICANN tâche de détecter d’éventuels problèmes de conformité de ces contrats entre opérateurs de registre et bureaux d’enregistrement au Règlement général sur la protection des données (« RGPD ») de l’Union européenne. L’organisation de l’ICANN collabore avec des registres, des bureaux d’enregistrement et diverses parties prenantes afin de comprendre ces éventuels problèmes de conformité. Selon les premiers examens et communications, notamment avec certaines agences de protection des données, l’organisation de l’ICANN sait désormais que la mise en conformité au RGPD aura un impact sur le système WHOIS.

      Le 29 juin 2017, l’organisation de l’ICANN a approuvé la demande de Verisign de report de la date facultative prévue par la politique à partir de laquelle les bureaux d’enregistrement peuvent commencer à soumettre volontairement des données détaillées au registre. Ce report a été accordé pour donner davantage de temps à Verisign, à l’ICANN et au groupe des représentants des bureaux d’enregistrement afin qu’ils puissent poursuivre le dialogue visant à trouver un terrain d’entente tout en prenant des mesures raisonnables pour respecter la politique. Cette date facultative, à savoir le 1er août 2017, a été ensuite reportée au 29 novembre 2017.

      Afin de donner davantage de temps aux bureaux d’enregistrement et à Verisign de parvenir à un accord sur les amendements requis pour les contrats entre registres et bureaux d’enregistrement visant à mettre en œuvre la politique, le Conseil d’administration prend actuellement des mesures afin d’autoriser le président-directeur général de l’ICANN à reporter de six mois la mise en conformité à la politique relative au WHOIS détaillé. Le report du délai de mise en conformité permettra également à l’organisation de l’ICANN de poursuivre le dialogue avec les autorités européennes, y compris le groupe de travail Article 29 de l’Union européenne, les agences de protection des données, les parties contractantes ainsi que d’autres parties prenantes concernées afin de mieux comprendre les aspects pertinents du RGPD liés aux activités, aux politiques et aux contrats de l’ICANN avec les registres et bureaux d’enregistrement, notamment la politique de consensus relative au WHOIS détaillé.

      Suite aux mesures prises par le Conseil d’administration, l’organisation de l’ICANN commencera à mettre en œuvre les critères prévus par la politique afin que les bureaux d’enregistrement soumettent au registre toutes les données d’enregistrement des nouveaux noms de domaine sous forme détaillée à compter du 30 avril 2019 et toutes les données d’enregistrement des noms de domaine existants devant, elles, faire la migration du WHOIS résumé au WHOIS détaillé d’ici au 31 janvier 2019. La date limite facultative à partir de laquelle les bureaux d’enregistrement peuvent commencer à soumettre volontairement au registre des données détaillées sera le 30 novembre 2018.

      Lors de cette période de report de la mise en conformité, l’organisation de l’ICANN continuera à collaborer avec Verisign et le groupe des représentants des bureaux d’enregistrement afin de faciliter les discussions sur les propositions d’amendements. L’organisation de l’ICANN tiendra également la communauté informée de l’avancée de la conformité à la politique de consensus relative au WHOIS détaillé. Lors de cette période de report, le groupe des représentants des bureaux d’enregistrement a indiqué [PDF, 43 Ko] qu’il « poursuivra le dialogue avec l’ICANN et Verisign eu égard aux modifications des RRA, au rôle de l’ICANN en vertu du RGPD et aux mesures requises afin de mettre en œuvre la transition vers le WHOIS détaillé ».

      Les délibérations du Conseil d’administration sur cette question ont tenu compte, entre autres, des documents suivants :

      L’action du Conseil ne devrait pas avoir un impact fiscal sur l’ICANN au-delà de ce qui est déjà prévu dans le budget actuel. Cette résolution relève d’une fonction administrative et organisationnelle qui ne nécessite pas de consultation publique. Cette décision 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 et relève de la mission de l’ICANN.

    6. Approbation du contrat d’agent d’entiercement de données des bureaux d’enregistrement

      Attendu que, les membres de la communauté des bureaux d’enregistrement ont exprimé le besoin d’un nouvel agent d’entiercement de données des bureaux d’enregistrement désigné par l’ICANN avec des capacités de soutien régional au sein de l’Union européenne.

      Attendu que, la division des domaines mondiaux de l’ICANN a l’intention de fournir un nouvel agent d’entiercement de données des bureaux d’enregistrement désigné par l’ICANN et pouvant offrir un soutien régional au sein de l’Union européenne et une compréhension du règlement général sur la protection des données (RGPD) de l’Union européenne.

      Attendu que, l’organisation de l’ICANN a publié un appel à propositions pour identifier un nouvel agent d’entiercement de données des bureaux d’enregistrement.

      Attendu que, l’ICANN org a terminé l’appel à propositions et déterminé que DENIC eG avait démontré sa capacité à soutenir des services d’entiercement de données des bureaux d’enregistrement et qu.il est le fournisseur privilégié.

      Il est résolu (2018.05.13.07), que le Conseil autorise le président-directeur général ou son représentant, de conclure et de faire des décaissements dans le cadre d’un nouveau contrat avec DENIC eG pour une durée de 36 mois et un le coût total ne devant pas excéder [ÉDITÉ] USD.

      Il est résolu (2018.05.13.08), que les éléments spécifiques de cette résolution restent 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 détermine que les informations confidentielles puissent être divulguées.

      Fondements des résolutions 2018.05.13.07 à 2018.05.13.08

      L’organisation de l’ICANN comprend, sur la base des commentaires de la communauté des bureaux d’enregistrement, la nécessité de renforcer le programme RDE et de fournir un agent RDE supplémentaire désigné par l’ICANN offrant un soutien régional au sein de l’Union européenne.

      L’ICANN org a publié un appel à propositions le 17 août 2017 afin d’identifier un ou plusieurs autres agents de type RDE désigné par l’ICANN avec la capacité d’offrir un large soutien à l’échelle mondiale ou plurirégionale. Au cours de ce processus, l’ICANN org a identifié des domaines de service qui pourraient être améliorés par un agent RDE supplémentaire désigné par l’ICANN et examiné ceux présents dans l’évaluation RFP.

      En conséquence, l’ICANN org a identifié DENIC eG comme ayant une compréhension claire des besoins de la communauté des bureaux d’enregistrement et la capacité de fournir les niveaux de service appropriés. En outre, DENIC eG a une vaste compréhension de l’industrie actuelle et du modèle multipartite de l’ICANN.

      Cet engagement remplit la mission de l’ICANN et sert l’intérêt public pour garantir que l’ICANN org utilise les bons fournisseurs tiers et qu’elle maximise les ressources disponibles de manière efficace et à un prix avantageux. Cette action bénéficiera à la mission de l’ICANN de garantir la sécurité, la stabilité et la résilience du système des noms de domaine.

      Cette action aura un impact financier sur l’organisation, parce que chaque nouvel agent RDE désigné par l’ICANN entraîne un coût fixe supplémentaire, mais elle fournira à l’ICANN org des agents RDE désignés par l’ICANN qui amélioreront la diversité et la concurrence.

    7. Obtenir des commentaires supplémentaires sur le nouveau plan de roulement de la KSK

      Attendu que, l’organisation de l’ICANN a mis à jour les documents de planification complets en réponse aux suggestions de la communauté et créé une « mise à jour du plan de continuation du roulement de la KSK de la zone racine » (publié sur <Https://www.icann.org/resources/pages/ksk-rollover-operational-plans>) ;

      Attendu que, le Conseil d’administration demande souvent les avis du comité consultatif sur le système de serveur racine (RSSAC) sur les questions liées à la stabilité de la zone racine, et demande souvent les avis du Comité consultatif pour la sécurité et la stabilité (SSAC) sur les questions se rapportant à la sécurité et à la stabilité du système des noms de domaine (DNS) et demande souvent les avis du comité de révision de l’évolution de la zone racine (RZERC) sur les modifications architecturales du contenu de la zone racine DNS

      Il est résolu (2018.05.13.09) que le Conseil d’administration demande au RZERC, au RSSAC et au SSAC de lui fournir des avis sur la « mise à jour du Plan pour la poursuite du roulement de la KSK de la zone racine » et les documents de plan associés et de faire rapport au Conseil d’ici le 10 août 2018 si possible.

      Fondements de la résolution 2018.05.13.09

      Le plan de roulement de la KSK de la zone racine du DNS a été temporairement interrompu le 27 septembre 2017 en raison d’apports inattendus qui ont amené la communauté à se demander l’état de préparation des résolveurs validants pour le roulement qui arrivait quelques semaines plus tard. Pendant les quelques mois suivants, l’ICANN org a analysé les données devenues disponibles ayant causé la pause temporaire et a conclu que la poursuite du processus de roulement de la KSK de la zone racine serait justifiée.

      Suivant le résultat de cette recherche, l’ICANN org a demandé à la communauté technique de recommander un plan d’action. L’ICANN devait, selon la suggestion de cette communauté, procéder à la procédure de roulement de la KSK de façon ordonnée.

      Munie de cet apport, l’ICANN org a créé un plan de synthèse intitulé « plan pour la poursuite du roulement de la KSK de la zone racine » pour effectuer le roulement de la KSK de la zone racine 11 octobre 2018. L’ICANN org a publié le plan de synthèse pour examen par la communauté le 1er février 2018 (voir <Https://www.icann.org/public-comments/ksk-rollover-restart-2018-02-01-en>). Le temps imparti pour formuler les commentaires a été prolongé au-delà de la durée normale de 45 jours pour permettre la présentation du plan à l’ICANN 61 à San Juan et l’IETF 101 à Londres et la demande d’une plus grande participation de la communauté au sein de ces instances.

      La réponse de la communauté reçue au 2 avril 2018 était fortement en faveur du plan publié (avec quelques suggestions de sensibilisation supplémentaires que l’ICANN org pourrait faire avant octobre 2018). En se fondant sur la réponse de la communauté, l’ICANN a créé la « mise à jour de la poursuite du plan de roulement de la KSK de la zone racine » et a également révisé les documents du plan de roulement de la KSK original pour montrer quelles mesures avaient déjà été prises, et quelles mesures devaient encore être prises aux dates révisées. Ces documents de plan sont disponibles sur <Https://www.icann.org/resources/pages/ksk-rollover-operational-plans>.

      Les contributions de la communauté sur le plan proposé provenaient d’une variété de comités consultatifs, groupes de parties prenantes, d’organisations et de particuliers, mais aucun commentaire n’est parvenu du RSSAC ou du SSAC. Le RSSAC est un conseiller respecté sur la stabilité de la zone racine et le SSAC un conseiller respecté sur les questions portant sur la sécurité et la stabilité du DNS. Le Conseil d’administration prend actuellement des mesures pour demander les contributions du RSSAC et du SSAC au sujet de la mise à jour du plan pour la poursuite du roulement de la KSK de la zone racine afin que ces dernières puissent être prises en compte dans le cadre des délibérations du Conseil sur la question de l’approbation ou non de la mise à jour du plan.

      La demande de contribution auprès du RSSAC ou du SSAC ne devrait pas avoir d’impact financier sur l’organisation de l’ICANN qui n’ait déjà été intégré aux ressources budgétaires nécessaires pour un soutien continu du RSSAC et du SSAC.

      Cette décision est conforme à l’intérêt public et à la mission de l’ICANN, car elle soutient les travaux de l’ICANN org pour assurer des opérations de sécurité et de stabilité des systèmes d’identificateurs uniques de l’Internet.

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

  2. Ordre du jour principal :

    1. Options pour aborder la demande du groupe des représentants des opérateurs de registres (RySG) de remboursement des frais d’accès au mécanisme de protection des droits du registre TMCH

      Attendu que, le centre d’échange d’information sur les marques (TMCH) est un référentiel global de données sur les marques déposées établi par l’ICANN org en mars 2013.

      Attendu que, la nécessité du TMCH était prévue lors de l’élaboration du programme des nouveaux gTLD et du guide de candidature (AGB).

      Attendu que, les frais du TMCH pour les registres sont définis à l’article 6.4 du contrat de registre (RA), qui stipule qu’un registre doit payer une somme uniques de 5 000 USD pour les mécanismes de protection des droits (RPM) ainsi qu’une taxe transactionnelle de 0,25 USD par enregistrement pendant la période d’enregistrement prioritaire ou par enregistrement de revendication de marque.

      Attendu que, en octobre 2017, le RySG a demandé un remboursement des frais uniques d’accès de 5 000 USD pour chaque registre ayant accédé au TMCH, à prendre dans les fonds du programme des nouveaux gTLD restants.

      Attendu que, le Conseil d’administration de l’ICANN a déterminé que bien que le concept du TMCH était prévu dans l’AGB, sa tarification et les frais n’y apparaissaient pas. Les frais de 5 000 USD ont été définis pour la première fois dans la version de 2013 du RA, et n’a pas été spécifié dans la version du RA inclus avec l’AGB ou la version communiquée avant la période de candidature.

      Attendu que, le programme des nouveaux gTLD est presque terminé, et la disponibilité des fonds restants du programme des nouveaux gTLD est plus visible, mais plusieurs années supplémentaires pourraient être nécessaires pour que tous les risques et responsabilités soient entièrement connus et quantifiés.

      Il est résolu (2018.05.13.10) que le Conseil d’administration de l’ICANN demande au président-directeur général ou son représentant de prendre toutes les mesures nécessaires pour assurer un remboursement de 5 000 USD, dès que possible, aux registres ou opérateurs de registre sous contrat (y compris ceux qui ont rompu leur contrat ou dont la délégation de TLD a été révoquée) qui ont payé à l’ICANN les frais uniques d’accès aux RPM tels que définis dans l’article 6.4 du RA.

      Fondements de la résolution 2018.05.13.10

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

      En octobre 2017, le groupe des représentants des opérateurs de registres (RySG) a demandé un remboursement des frais d’accès aux RPM de 5 000 USD pour chaque registre. Le RySG soutient que « [t]ous les autres systèmes et programmes relatifs du programme des nouveaux gTLD ont été financés par les frais de candidature. Le TMCH n’avait pas à être différent et il n’y avait aucune raison de « facturer deux fois » les registres pour ce seul projet du programme. » Le RySG soutient également que ces frais uniques d’accès aux RPM n’étaient pas stipulés dans l’AGB [tel que publié avant l’ouverture de la période de candidature] et que « l’ICANN a ajouté [ces frais] de lui-même après que toutes les demandes ont été acceptées et sans contribution de la communauté ».1 Sur cette base, le RySG demande le remboursement de cette « surfacturation » en la prélevant sur les autres fonds du programme des nouveaux gTLD.2

      Quelles sont les options à l’étude ? Quels sont les facteurs que le Conseil a trouvés significatifs ?

      En examinant la demande du RySG, le Conseil a envisagé une gamme d’options, dont le maintien du statu quo (pas de remboursement), le remboursement immédiat ou le report de l’examen de la demande jusqu’à la fin du programme des nouveaux gTLD. En évaluant ces options, le Conseil a examiné un certain nombre de facteurs, y compris : fournir un remboursement est-il conforme avec l’AGB ou le RA ? est-ce cohérent avec les autres approches de financement du programme des nouveaux gTLD ? fournir un remboursement immédiat permet-il à l’ICANN org de tenir compte d’autres risques/coûts ?

      En ce qui concerne l’absence de remboursement, le Conseil a estimé que les provisions pour les frais liés au TMCH visaient à couvrir les coûts associés à la fourniture de ces services TMCH. En effet, le principal argument en faveur de cette approche est que le concept de TMCH était prévu dans l’AGB, et le RA, accepté par les registres, contient des dispositions couvrant ces frais liés au TMCH.

      Toutefois, le Conseil a également considéré que, bien que le concept du TMCH soit prévu dans l’AGB, la tarification et les frais ne l’étaient pas. Les frais de 5 000 USD ont été définis pour la première fois dans la version de 2013 du RA, et n’a pas été spécifié dans la version du RA inclus avec l’AGB ou la version communiquée avant la période de candidature. En outre, financer le TMCH par la collecte de frais répercutés auprès des opérateurs de registre n’est pas cohérent avec l’approche utilisée pour financer d’autres services opérationnels à l’appui des opérations du programme des nouveaux gTLD. D’autres aspects du programme ont été payés directement par les frais de candidature.

      Cela étant, le Conseil a examiné l’option de restitution, et si celle-là pouvait être réalisée dès maintenant ou devait attendre la fin de programme des nouveaux gTLD. Le Conseil a considéré qu’il serait peut-être prudent d’attendre la fin du programme des nouveaux gTLD pour examiner cette demande. Cette option permet d’attendre la fin de l’évaluation des risques et la quantification des efforts en cours, avant la restitution aux registres. Si, à la fin du programme des nouveaux gTLD il a été déterminé que tous les risques et autres dépenses ont été comptabilisés, alors le Conseil pourra examiner à ce moment-là la possibilité d’un remboursement des frais d’accès aux RPM de 5 000 USD à tous les registres. Le Conseil a également estimé que de nombreuses demandes de remboursement ou de frais compensatoires ont été et/ou seront reçues et que d’autres aspects des opérations du programme des nouveaux gTLD de l’ICANN org pourraient nécessiter des fonds supplémentaires au cours des prochaines années.

      Toutefois, le Conseil a également estimé que le programme des nouveaux gTLD est en grande partie achevé, et il y a déjà plus de clarté sur la disponibilité des fonds du programme des nouveaux gTLD et il se pourrait que plusieurs années supplémentaires soient nécessaires avant que tous les risques et responsabilités soient entièrement connus et quantifiés. Le Conseil a également pris en compte, comme noter ci-dessus que ces frais ont été définis pour la première fois dans la version de 2013 du RA, et non dans la version du RA incluse dans l’AGB ou mise à disposition avant la période de candidature. En outre, rembourser ces frais est également compatible avec l’approche utilisée pour financer d’autres services opérationnels en soutien au programme des nouveaux gTLD, en utilisant les frais de candidature pour couvrir le coût du TMCH pour les registres. Pour ces raisons, le Conseil a déterminé que l’option de rembourser ces frais aux registres était la plus raisonnable.

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

      Pour adopter cette résolution, le Conseil d’administration a examiné, en plus des options fournies par l’ICANN org, divers matériaux, y compris, mais non limités aux :

      Cela a-t-il des impacts fiscaux ou des répercussions sur l’ICANN ?

      L’action du Conseil aura un impact fiscal sur l’ICANN. Le financement de la restitution devrait provenir de la portion inutilisée des frais du programme des nouveaux gTLD. Le montant estimé des fonds de ce programme des nouveaux gTLD restants disponibles pour couvrir pour des coûts « difficiles à prévoir » (y compris les risques), en plus des dépenses évaluées restant à être engagées, devrait se situer à 81 609 000 USD, résultat des dernières projections établies dans le cadre de la version préliminaire du plan opérationnel et budget EF19. Le montant total du remboursement de 6 210 000 USD viendrait réduire d’autant le montant estimé des fonds restants disponibles pour couvrir ces coûts « difficiles à prévoir ».

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

      Cette action participe à la mission de l’ICANN d’assurer le fonctionnement stable et sécurisé des systèmes d’identificateurs uniques de l’Internet. Cette action bénéficie à la communauté de l’ICANN, car elle assure la transparence concernant l’utilisation des fonds restants du programme des nouveaux gTLD.

    2. Examen de la spécification temporaire relative aux données d’enregistrement des gTLD (mise en œuvre du modèle intérimaire en matière de conformité au RGPD)

      Attendu que, le règlement général sur la protection des données (RGPD) de l’Union européenne est un ensemble de règles adoptées par le Parlement européen, le Conseil européen et la Commission européenne qui impose de nouvelles obligations à toutes les entreprises et organisations qui recueillent et conservent des « données à caractère personnel » des résidents de l’Union européenne, telles que définies en vertu de la loi de protection des données de l’UE. Le RGPD entrera pleinement en vigueur le 25 mai 2018.

      Attendu que, le RGPD a donné une nouvelle importance et urgence au long débat en cours sur le service WHOIS, la protection des données et la confidentialité.

      Attendu que, au cours des derniers mois l’ICANN org a consulté les parties prenantes communautaires, les parties contractantes, les autorités européennes de protection des données, les experts juridiques et les gouvernements intéressés afin de comprendre l’impact potentiel du RGPD sur les données personnelles que les participants dans l’écosystème des noms de domaine gTLD recueillent, affichent et traitent (notamment les registres et bureaux d’enregistrement) conformément aux contrats et politiques de l’ICANN. Les politiques de l’ICANN sont définies par sa communauté.

      Attendu que, par le biais d’un processus itératif et grâce aux commentaires de la communauté, l’ICANN org a élaboré un projet de modèle intérimaire sur la façon dont l’ICANN et les registres et bureaux d’enregistrement des gTLD pourraient continuer à se conformer aux exigences contractuelles de l’ICANN et aux politiques élaborées par la communauté au sujet du RGPD (le « modèle intérimaire de conformité proposé »).

      Attendu que, l’ICANN org a demandé et reçu des directives du groupe de travail Article 29 concernant le modèle intérimaire de conformité proposé, y compris dans les domaines où l’ICANN a reçu des avis gouvernementaux et des contributions reflétant des opinions divergentes.

      Attendu que, le GAC a fourni un avis au conseil d’administration dans son communiqué de San Juan (15 mars 2018) concernant le modèle intérimaire de conformité proposé. L’avis a fait l’objet d’un échange entre le Conseil d’administration et le GAC pour clarifier la compréhension par le Conseil de l’avis.

      Attendu que, l’ICANN org a communiqué avec les autorités européennes de protection des données et a demandé un temps suffisant pour les registres et bureaux d’enregistrement de gTLD mettent en œuvre le modèle intérimaire de conformité proposé une fois que les éclaircissements supplémentaires provenant des autorités de protection des données auront été incorporés dans le modèle intérimaire de conformité proposé.

      Attendu que, l’ICANN continue de discuter avec la communauté de l’ICANN des modèles d’accréditation proposés.

      Attendu que, pour être en conformité avec le modèle intérimaire de conformité proposé, l’ICANN org a rédigé une spécification temporaire en utilisant la procédure des politiques temporaires établie dans le contrat de registre et le contrat d’accréditation de bureau d’enregistrement (la « spécification temporaire pour les données d’enregistrement des gTLD » ou « spécification temporaire »). Un projet de spécification temporaire a été partagé avec le Conseil et la Communauté le 11 mai 2018.

      Attendu que, l’adoption d’une spécification temporaire peut contribuer à la défense par le conseil d’administration de l’intérêt public mondial. Sans une solution politique unifiée en place à la date de mise en œuvre du RGPD, il existe un risque réel de la fragmentation dans la collecte, le traitement, et la disponibilité des données d’enregistrement des gTLD dans la mesure où les opérateurs de registre et les bureaux d’enregistrement prendront des chemins différents pour se mettre en conformité avec la loi. Une spécification temporaire énonce au contraire la façon unifiée par laquelle les opérateurs de registre et les bureaux d’enregistrement sont censés recueillir, traiter, afficher et fournir l’accès à ces données. L’ICANN org peut alors faire respecter la conformité dans le cadre de ses contrats au cas où les conditions nécessaires ne seraient pas remplies. Un système fragmenté serait contraire à la pratique actuelle du WHOIS et risquerait de causer des dommages.

      Attendu que le Conseil, dans son atelier de Vancouver, a entrepris un examen important et robuste de plus de deux jours sur le projet de spécification temporaire, y compris l’identification de questions et d’améliorations éventuelles, et souhaite partager avec la communauté les mises à jour du projet de spécification temporaire résultant de l’examen à ce jour du Conseil.

      Attendu que, au cours de mai 2018, le Conseil d’administration a reçu plusieurs lettres de diverses parties de la communauté de l’ICANN concernant le contenu d'une spécification temporaire préliminaire.

      Attendu que le Conseil a communiqué au GAC qu’il avait fait une détermination préliminaire stipulant que son approche de projet de spécification temporaire était incompatible ou pouvait être considérée comme incompatible avec certains éléments de l’avis du GAC dans le Communiqué de San Juan. Le Conseil d’administration a fourni une fiche de suivi reflétant les points de l’avis du GAC qu’il pouvait être amené à rejeter pour cette raison.

      Attendu que l’ICANN org continue à collaborer avec le groupe de travail Article 29 pour éclaircir l’avis fourni par ce groupe sur le modèle intérimaire de conformité proposé.

      Il est résolu (2018.05.13.11) que le Conseil a l’intention de prendre une décision sur l’adoption d’un projet de spécification temporaire sur les données d’enregistrement des gTLD (conformément aux procédures du contrat de registre et du contrat d’accréditation de bureau d’enregistrement concernant l’établissement de politiques temporaires) le ou vers le 17 mai 2018. Le Conseil d’administration désire utiliser ce délai supplémentaire pour s’assurer que les modifications appropriées ont été incorporées dans un projet de spécification temporaire avant d’en envisager l’adoption. Après adoption, un projet de spécification temporaire sera en place pour une période de 90 jours à compter du 25 mai 2018, et le Conseil réaffirmera cette adoption temporaire tous les 90 jours civils pour une période ne dépassant pas un an.

      Il est résolu (2018.05.13.12) que les considérations initiales du Conseil d’administration à propos du projet de spécification temporaire sont axées sur les éléments suivants :

      1. si dans un projet de spécification temporaire, les modifications visent des exigences existantes concernant le traitement des données à caractère personnel dans l’enregistrement des données et sont justifiées, une mise en place immédiate d’un projet de spécification temporaire est nécessaire pour maintenir la stabilité ou la sécurité des services aux bureaux d’enregistrement, les services aux registres, le DNS ou l’Internet.
      2. si un projet de spécification temporaire est taillé étroitement sur mesure pour atteindre l’objectif qui consiste à maintenir la stabilité ou la sécurité des services aux bureaux d’enregistrement, services aux registres, le DNS ou l’Internet.

      Il est résolu (2018.05.17.05) que la mise en œuvre d’une politique unifiée régissant les données d’enregistrement gTLD vise à servir l’intérêt public lors de l’entrée en vigueur du RGPD.

      Il est résolu (2018.05.13.14) que le Conseil demande au président-directeur général de l’ICANN, ou son représentant de continuer de le soutenir dans ses discussions avec l’ensemble de la communauté de l’ICANN concernant les améliorations apportées avant l’examen par le Conseil du projet de spécification temporaire pour adoption. Le Président-directeur général de l’ICANN, ou son représentant devra partager avec la communauté de l’ICANN les mises à jour du projet de spécification temporaire générées par son examen à ce jour.

      Fondements des résolutions 2018.05.13.11 à 2018.05.13.14

      Le Règlement général sur la protection des données (RGPD) de l’Union européenne entrera en vigueur le 25 mai 2018. Le RGPD est un ensemble de règles adoptées par le Parlement européen, le Conseil européen et la Commission européenne qui impose de nouvelles obligations à toutes les entreprises et organisations qui recueillent et conservent des « données personnelles » de résidents de l’Union européenne, telles que définies en vertu de la loi de protection des données de l’UE. Le RGPD a un impact sur la façon dont les données personnelles sont collectées, affichées et traitées par les participants à l’écosystème de nom de domaine gTLD (y compris les registres et bureaux d’enregistrement) conformément aux contrats et politiques de l’ICANN. Les modifications doivent être effectuées avant le 25 mai pour permettre à l’ICANN ainsi qu’aux registres et bureaux d’enregistrement gTLD de continuer à se conformer aux exigences contractuelles de l’ICANN et aux politiques élaborées par la communauté en ce qui concerne le RGPD. Bien que des efforts considérables aient été déployés dans l’ensemble de la communauté de l’ICANN afin de parvenir à un modèle de conformité, les politiques adoptées par l’ICANN doivent être mises à jour pour être en conformité avec le RGPD. Une politique de plein consensus élaborée par la communauté n’est pas encore disponible. Sans une politique applicable unifiée, il y aura une fragmentation dans la manière dont les parties contractantes de l'ICANN mettront en place leurs propres programmes de conformité en lien avec les données d'enregistrement gTLD. Pour ces raisons, une politique unifie disponible doit être en place avant le 25 mai 2018, et cette démarche est dans l’intérêt public. On ne sert pas l’intérêt public si le Conseil d’administration de l’ICANN ne parvient pas à prendre des mesures sur cette question critique.

      Les contrats de l’ICANN org avec les registres et bureaux d’enregistrement doivent être en conformité avec les politiques ou spécifications temporaires adoptées par le Conseil d’administration. Pour élaborer une politique ou spécification temporaire, deux tiers au moins du conseil d’administration doit voter pour approuver la spécification temporaire, et les modifications de ces spécifications doivent être justifiées et « nécessaire pour maintenir la stabilité ou la sécurité des services aux bureaux d’enregistrement, des services aux registres, du DNS ou de l’Internet. » Cette spécification ou politique temporaire devra être la mieux adaptée possible pour atteindre ces objectifs.

      L’ICANN org, en consultation avec le Conseil, a exploré la possibilité d’une politique ou spécification temporaire comme mécanisme pour mettre en œuvre le modèle intérimaire de conformité au RGPD. Une version préliminaire d’une spécification temporaire relative aux données d’enregistrement des gTLD (« Spécification temporaire ») a été publiée à l’adresse du Conseil d’administration et de la communauté le 11 mai 2018. Ce projet de spécification temporaire est rédigé pour établir les obligations temporaires visant à permettre à l’ICANN et aux opérateurs de registre et bureaux d’enregistrement des gTLD de respecter les exigences contractuelles de l’ICANN et les politiques définies par la communauté à la lumière du RGPD.

      Le Conseil d’administration a travaillé en atelier depuis le 11 mai 2018, et a utilisé le temps écoulé depuis la publication de la spécification temporaire proposée pour participer à une importante discussion avec l’ICANN, celle-ci ayant entraîné d’autres propositions de modification. De plus, depuis la publication du 11 mai 2018, le Conseil d’administration de l’ICANN a reçu des lettres provenant de l’ensemble de la communauté, concernant la version préliminaire de la spécification temporaire.

      Le Conseil d’administration a déterminé qu’en raison de l’importance donnée à son approbation d’une spécification temporaire, il lui semble approprié de prendre davantage de temps avant cette adoption, à la fois pour l’examen par le Conseil d’administration et l’occasion de discuter avec la communauté de l’ICANN sur le contenu de la spécification temporaire proposée. Le Conseil d’administration a également compris que prendre des mesures sur une spécification temporaire est dans l’intérêt public, vu la nécessité d’une politique mise en place uniformément pour être en conformité avec le RGPD. Il est important qu’une spécification temporaire soit adoptée afin qu’elle puisse être en vigueur le 25 mai 2018.

      Le travail d’élaboration d’une spécification temporaire est conforme à la mission de l’ICANN « [...] d’assurer le fonctionnement stable et sécurisé des systèmes d’identificateurs uniques de l’Internet […] » Comme l’un des principaux rôles de l’ICANN est d’être responsable de l’administration des plus hauts niveaux des identificateurs de l’Internet, faciliter la capacité d’identifier les détenteurs de ces identificateurs est une fonction de base de l’ICANN.

      La mission de l’ICANN d’assurer le fonctionnement stable et sécurisé des systèmes d’identificateurs uniques de l’Internet a conduit aux obligations associées à la prestation qui sont de fournir au WHOIS des données qui sont le résultat de politiques de consensus et de contrats que l’ICANN entretient avec les registres et bureaux d’enregistrement. Ces politiques et obligations contractuelles régissent la collecte, la conservation, l’entiercement, le transfert et l’affichage des données d’enregistrement WHOIS, qui comprennent les coordonnées des personnes physiques et morales ainsi que les renseignements techniques associés à un nom de domaine. Grâce à ces politiques et contrats, l’ICANN définit les exigences minimales pour le service WHOIS, garantissant la disponibilité des informations WHOIS pour limiter les attaques qui menacent le fonctionnement stable et sécurisé de l’Internet et ainsi bénéficier à l’utilisation par le public.

      Le WHOIS n’est pas une base de données unique, gérée de façon centrale. Au contraire, les données d’enregistrement sont conservées dans divers emplacements et administrées par plusieurs registres et bureaux d’enregistrement. Ceux-ci ont chacun leur propre convention pour le service WHOIS, conforme aux exigences minimales établies par leur contrat avec l’ICANN.

      De nombreux registres et bureaux d’enregistrement des gTLD sont préoccupés par l’idée de savoir si les politiques et contrats de l’ICANN les obligeant à recueillir, créer, conserver, entiercer, et publier une variété d’éléments de données liés à des opérations de registre/bureau d’enregistrement, des enregistrements de noms de domaine, et aux titulaires de nom de domaine sont en conflit avec le RGPD.

      Pour garantir la disponibilité continuelle autant que possible du service WHOIS et d’autres traitements de données d’enregistrement de gTLD en respectant le RGPD, et éviter la fragmentation du service WHOIS, la spécification temporaire proposée fournira un modèle provisoire unique et uniforme pour assurer un cadre commun aux services d’annuaire de données d’enregistrement. Pour continuer ce service public et de maintenir la sécurité et la stabilité de l’Internet, la spécification temporaire proposée permettra de continuer à fournir des services WHOIS grâce aux contrats de l’ICANN avec les registres de noms de domaine et les bureaux d’enregistrement accrédités.

      Comme nécessaire lorsqu’une politique ou spécification temporaire est adoptée, dès son adoption, le Conseil d’administration doit également prendre des mesures pour mettre en œuvre le processus d’élaboration de politiques de consensus. Le Conseil consultera le conseil de la GNSO sur les voies possibles de développement (p. ex. processus accéléré d’élaboration de politiques) pour examiner un projet de spécification temporaire dans un processus d’élaboration de politiques de consensus qui devra être conclu sur la période d’une année.

      Le Conseil est conscient que certains groupes de la communauté de l’ICANN ont commencé à travailler pour définir un modèle d’accréditation donnant l’accès aux données à caractère personnel figurant dans les données d’enregistrement. Le Conseil encourage la communauté à continuer ce travail, en tenant compte de tous les conseils et orientations que le groupe de travail article 29 ou le conseil européen sur la protection des données pourraient fournir à ce sujet.

      Le Conseil d’administration prend également aujourd’hui des mesures pour s’assurer qu’il continuera d’aller de l’avant avec les réunions de consultation sur les statuts constitutifs avec le GAC pour tenir compte des éléments de la spécification temporaire proposée qui sont incompatibles ou pourraient être considérés comme incompatibles avec les points de l’avis du GAC présents dans le communiqué de San Juan. 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, » Les statuts constitutifs prévoient que le Conseil tienne compte de l’avis du GAC en matière de politique publique pour la formulation et l’adoption de politiques. Au cas où le Conseil d'administration déciderait d’agir contrairement à l’avis du GAC, il est tenu d'en avertir ce dernier en indiquant les raisons pour lesquelles il a décidé de ne pas suivre son avis. 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. Prendre des mesures pour aller de l’avant avec le processus de consultation prévu dans les statuts constitutifs entre le Conseil d’administration et le GAC aura un impact positif sur la communauté, car cela aidera à résoudre l’avis du GAC sur les l’approche de l’ICANN pour imposer la conformité des contrats conclus avec les registres et bureaux d’enregistrement à propos du RGPD.

      L’action du Conseil réalisée aujourd’hui est destinée à soutenir le maintien de la sécurité, la stabilité ou la résilience du DNS, en assurant à la communauté de l’ICANN une sorte de certitude qu’une spécification temporaire sera en place avant le 25 mai 2018. Dès son adoption, la spécification temporaire proposée aidera à maintenir le service WHOIS dans la mesure du possible pendant que la communauté travaille à élaborer une politique de consensus. Bien que n’ayant pas été lancé par la décision d’aujourd’hui, le travail ciblé de développement de politique de consensus sur le projet de spécification temporaire, dont le lancement est prévu, devrait avoir une incidence sur les ressources financières au fur et à mesure de l’avancement de la recherche et des travaux. Si le besoin en ressources dépassait les prévisions du budget actuel pour réaliser le travail sur les questions liées au WHOIS et au RGPD, le directeur général présentera le besoin de toute ressource supplémentaire au comité des finances du Conseil, conformément aux pratiques de demande de fonds de prévoyance existantes.

      Il s’agit d’une fonction administrative organisationnelle du Conseil d’administration qui ne nécessite pas de consultation publique cependant, le modèle intérimaire de conformité proposé devant être mis en œuvre par le biais du projet de spécification temporaire a fait l’objet de commentaires de la communauté au cours des derniers mois (Https://www.icann.org/resources/pages/gdpr-legal-analysis-2017-11-17-en). Les actions du Conseil approuvées aujourd’hui sont dans l’intérêt public et répondent à l’exigence des statuts de l’ICANN « d’évaluer l’efficacité du service actuel d’annuaire de données d’enregistrement de gTLD et de vérifier si sa mise en œuvre répond aux besoins légitimes d’application de la loi, favorise la confiance du consommateur et protège les données des titulaires de nom de domaine. » [Statuts constitutifs art. 4.6(e)(ii)]

    3. Examen de la demande de réexamen 17-5

      Attendu que, DotKids Foundation (le requérant) a déposé la demande de réexamen 17-5 (demande 17-5) contestant la décision de l’organisation de l’ICANN de supprimer la candidature au domaine de premier niveau générique (gTLD) communautaire .KIDS de sa liste d’attente avant que la révision du processus d’évaluation de la priorité communautaire (CPE) soit achevée.3

      Attendu que, le Conseil d’administration demande au Président-directeur général ou son ou ses représentants, de mener une révision du « processus par lequel l'organisation de l’ICANN a interagi avec le fournisseur de la CPE (évaluation de la priorité communautaire), en général et plus particulièrement en ce qui concerne les rapports CPE émis par le fournisseur de la CPE ». (Voir https://www.icann.org/resources/board-material/resolutions-2018-03-15-en#2.a.)

      Attendu que, le comité de gouvernance du conseil d’administration (BGC) a déterminé que la révision doit également inclure : (i) une évaluation pour savoir si les critères de la CPE ont été appliqués uniformément dans chaque rapport CPE ; et (ii) une compilation de la recherche invoquée par le fournisseur CPE dans la mesure où de telles recherches existent pour les évaluations qui font l’objet de demandes de réexamen en cours relatives au processus de CPE (collectivement, la révision du processus de CPE). (Voir https://www.icann.org/resources/board-material/minutes-bgc-2016-10-18-en.)

      Attendu que, le BGC a déterminé que les demandes de réexamen en cours concernant le processus de CPE seraient en attente jusqu’à la fin de la révision du processus de CPE. (Voir https://www.icann.org/en/system/files/correspondence/disspain-letter-review-new-gtld-cpe-process-26apr17-en.pdf [PDF, 405 Ko].)

      Attendu que, le requérant n’avait pas de mécanisme de responsabilité en cours au sujet du processus de CPE au moment de la révision de ce processus et par conséquent, sa candidature et l’ensemble conflictuel .KID/.KIDS étaient libres de procéder par le biais d’une candidature et du processus de résolution des conflits selon le guide de candidature.

      Attendu que, le 15 mars 2018, dans les résolutions 2018.03.15.08 à 2018.03.15.11, le Conseil d’administration : a reconnu et accepté les constatations énoncées dans les rapports de révision du processus de la CPE ; a déclaré que la révision du processus de la CPE était terminée ; a conclu que, sur la base des constatations provenant des rapports de révision du processus de la CPE il n’y aurait aucune révision ou modification du processus de CPE pour la série actuelle du programme des nouveaux gTLD ; et a chargé le comité du Conseil d’administration chargé des mécanismes de responsabilité (BAMC) d’aller de l’avant en reprenant l’examen du reste des demandes de réexamen relatives au processus CPE qui avaient été mises en attente jusqu’à l’achèvement de la révision du processus de CPE.

      Attendu que, le BAMC a déterminé précédemment que la demande 17-5 était suffisamment fondée et a envoyé la demande à l’ombudsman pour révision et prise en compte conformément au chapitre 4, article 4.2(j)) et (k) des statuts constitutifs de l’ICANN.

      Attendu que, l’Ombudsman s’est récusé sur ce sujet, conformément au chapitre 4 article 4.2(l)(iii) des statuts constitutifs.

      Attendu que, le BAMC a soigneusement examiné le bien-fondé de la demande 17-5 et tous les documents pertinents, et a recommandé que la demande 17-5 soit rejetée au motif que le requérant a reçu la réparation demandée, rendant la demande 17-5 sans objet parce que la révision du processus de la CPE est terminée ; et que les demandes du requérant sont dénuées de fondement parce que l’organisation de l’ICANN a adhéré aux politiques et aux procédures établies lorsqu’elle a retiré l’ensemble conflictuel .KID/.KIDS de la liste d’attente après la résolution de tous les mécanismes de responsabilité touchant l’ensemble conflictuel. Le Conseil d’administration acquiesce.

      Attendu que, le requérant n’a pas présenté une réplique à la recommandation du BAMC concernant la demande 17-5 dans le délai imparti en vertu du chapitre 4, article 4.2(q) des statuts constitutifs.

      Il est résolu (2018.05.13.15) que le Conseil d’administration adopte la recommandation du BAMC concernant la demande 17-5 [PDF, 146 Ko].

      Fondements de la résolution 2018.05.13.15

      1. Bref récapitulatif

        Le requérant a présenté une candidature communautaire pour .KIDS (candidature .KIDS), qui a été placée dans un ensemble conflictuel avec une autre candidature .KIDS et une candidature pour .KID (ensemble conflictuel .KID/.KIDS).4 Le requérant a participé à la CPE, mais ne l’a pas emporté. Le requérant avait déjà contesté l’évaluation de sa candidature communautaire par le fournisseur CPE dans sa demande de réexamen 16-6 (demande 16-6). Le dépôt de la demande 16-6 a affecté le statut de l’ensemble conflictuel .KID/.KIDS, qui a été mis en attente en attendant la résolution de la demande 16-6.5 Le comité de gouvernance du Conseil de l’ICANN (BGC) a rendu une décision définitive rejetant la demande 16-6 le 21 juillet 2016,6 après quoi l’ensemble conflictuel .KID/.KIDS a été retiré de la liste d’attente.7

        Le Conseil d’administration a demandé au Président-directeur général ou son ou ses représentants, de mener une révision du « processus par lequel l'organisation de l’ICANN a interagi avec le fournisseur de la CPE (évaluation de la priorité communautaire), en général et plus particulièrement en ce qui concerne les rapports CPE émis par le fournisseur de la CPE » dans le cadre de la supervision par le Conseil d'administration du programme des nouveaux gTLD (Champ d'application 1).8 L’action du Conseil a fait partie des discussions en cours concernant divers aspects de la CPE.

        Par la suite, le BGC a déterminé que la révision devait également inclure : (I) une évaluation du fait de savoir si les critères CPE ont été appliqués uniformément dans chaque rapport de la CPE (champ 2) ; et (ii) une compilation de la recherche invoquée par le fournisseur CPE dans la mesure où de telles recherches existent pour les évaluations qui font l’objet de demandes de réexamen en cours relatives au processus de la CPE (champ 3).9 L’action du Conseil a fait partie des discussions en cours concernant divers aspects de la CPE. Le BGC a déterminé que les demandes de réexamen en cours suivantes seraient en attente jusqu’à ce que la révision du processus de la CPE soit terminée : 14-30 (.LLC),10 14-32 (.INC),11 14-3312 (.LLP), 16-3 (.GAY), 16-5 (.MUSIC), 16-8 (.CPA), 16-11 (.HOTEL) et 16-12 (.MERCK).13 Le requérant n’avait pas de demande de réexamen en cours attendant une révision du processus de CPE lorsque cette dernière a commencé et, par conséquent, sa candidature et l’ensemble conflictuel .KID/.KIDS a suivi le processus de candidature classique et n’a pas été mis en attente.

        Le 2 octobre 2017, l’organisation de l’ICANN a invité le requérant à participer aux enchères de l’ICANN pour l’ensemble conflictuel .KID/.KIDS.14 Entre octobre et décembre 2017, l’organisation de l’ICANN a envoyé au requérant plusieurs rappels concernant les informations nécessaires à fournir avant le 8 décembre 2017, date limite pour participer aux enchères facilitées par l’ICANN.

        Le 6 décembre 2017, deux jours avant la date limite de dépôt des documents nécessaires aux enchères de l’ICANN, le requérant a déposé une demande de réexamen 17-5 (demande 17-5) contestant la décision de l’organisation de l’ICANN de supprimer de la liste d’attente la candidature du requérant pour le gTLD .KIDS avant que la révision du processus de CPE soit achevée.15 Le dépôt de la demande 17-5 a affecté l’ensemble conflictuel .KID/.KIDS, qui a été mis en attente de la résolution de cette demande 17-5 et qui s’est traduit par l’annulation de la vente aux enchères par l’ICANN de l’ensemble conflictuel .KID/.KIDS.16

        Le 13 décembre 2017, l’organisation de l’ICANN a publié trois rapports sur la révision du processus de CPE.17

        Le 15 mars 2018, le Conseil a reconnu et accepté les constatations énoncées dans les rapports de révision du processus de CPE, a déclaré que la révision du processus de la CPE était terminée et a conclu que, sur la base des constatations dans les rapports de révision du processus de CPE, il n’y aurait aucune révision ou modification du processus de CPE pour ce cycle en cours du programme des nouveaux gTLD. Il a ordonné au comité chargé des mécanismes de responsabilité (BAMC) d’aller de l’avant avec l’examen du reste des demandes de réexamen relatif au processus de CPE qui avaient été mises en attente jusqu’à l’achèvement de la révision du processus de CPE.18

        Le 5 avril 2018, le BAMC a évalué la demande 17-5 et tous les documents pertinents et a recommandé au Conseil de rejeter la demande 17-5 parce que : (1) le requérant a reçu la réparation demandée et par conséquent la demande 17-5 est sans objet, car la révision du processus de CPE est terminée ; et (2) l’organisation de l’ICANN a respecté les politiques établies lorsqu’il a retiré l’ensemble conflictuel .KID/.KIDS de la liste d’attente après la résolution de tous les mécanismes de responsabilité touchant l’ensemble conflictuel. (Voir larecommandation du BAMC [PDF, 146 Ko] jointe en tant qu’annexe C aux documents de référence.)

      2. Faits et recommandation

        L’ensemble des faits sont exposés dans la recommandation du BAMC [PDF, 146 Ko] que le Conseil d’administration a examinée et prise en compte et qui est jointe aux présentes.

        Le 5 avril 2018, le BAMC a recommandé que la demande 17-5 soit rejetée au motif que : (1) le requérant a reçu la réparation demandée et en conséquence la demande 17-5 est sans objet parce que la révision du processus de la CPE est terminée ; et (2) l’organisation de l’ICANN a respecté les politique(s) établie(s) lorsqu’elle a supprimé l’ensemble conflictuel .KID/.KIDS de la liste d’attente après la résolution de tous les mécanismes de responsabilité touchant l’ensemble conflictuel et en conséquence la demande 17-5 ne présente pas une base appropriée de réexamen pour les raisons énoncées dans la recommandation du BAMC [PDF, 146 Ko], qui est jointe aux présentes.

      3. Problématiques

        Les problématiques devant être réexaminées sont les suivantes :

        • la demande 17-5 est-elle sans objet puisque les rapports de révision du processus de CPE sont complets et publié ; et
        • l’organisation de l’ICANN a-t-elle respecté les engagements applicables, les valeurs fondamentales et les principes établis lorsqu’elle a supprimé l’ensemble conflictuel .KID/.KIDS de la « liste d’attente » et reprit le traitement de l’ensemble conflictuel conformément au programme des nouveaux gTLD en programmant une enchère de l’ICANN après que la demande de réexamen !6-6 du requérant a été refusée en juillet 2016.
      4. Normes applicables pour évaluer les demandes de réexamen

        Les articles 4.2 (a) et (c) du chapitre 4 des statuts constitutifs de l’ICANN établissent que toute entité peut soumettre une demande « de réexamen ou révision d’une action ou inaction de l’ICANN dans la mesure où elle a subi des effets négatifs par :

        1. au moins une action ou inaction du Conseil d’administration ou du personnel qui serait contraire à la mission, aux engagements, aux valeurs fondamentales et/ou aux politiques établies de l’ICANN ;
        2. au moins une action ou inaction du Conseil d’administration ou du personnel adoptée ou dont l’adoption a été refusée sans tenir compte d’informations importantes, sauf si le requérant n’a pas soumis ces informations, alors qu’il aurait pu le faire, au Conseil d’administration ou au personnel à des fins d’examen au moment où l’action ou l’inaction a été décidée ; ou
        3. au moins une action ou inaction du Conseil d’administration ou du personnel décidée sur la base d’informations importantes fausses ou inexactes.

        (Chapitre 4, articles 4.2(a) et (c) des statuts constitutifs de l’ICANN, 22 juillet 2017.) Conformément au chapitre 4 article 4.2(k) des statuts constitutifs, si le BAMC estime que la demande est suffisamment fondée, la demande est envoyée à l’ombudsman à des fins d’examen et de traitement. (Statuts constitutifs § 4.2(l).) Si l’Ombudsman s’abstient de prendre part aux discussions relatives à cette question, le BAMC examine la demande sans son intervention et transmet une recommandation au Conseil d’administration. (Statuts constitutifs § 4.2(l)(iii).) Le requérant peut envoyer une réfutation à la recommandation du BAMC à condition que la réfutation : (i) « se limite à remettre en question ou contredire les problèmes soulevés dans la recommandation du BAMC ; et (ii) ne comporte pas de nouvelles données venant étayer un argument présenté dans la demande de réexamen originale du requérant et que le requérant aurait pu fournir lorsqu’il a soumis sa demande de réexamen originale. » (Statuts constitutifs § 4.2(q).) Le refus d’une demande de réexamen sur une action ou inaction de l’ICANN est approprié si le BAMC recommande et le Conseil d’administration détermine que la partie requérante n’a pas satisfait aux critères de réexamen énoncés dans les statuts constitutifs. (Statuts constitutifs § 4.2(e)(vi), (q), (r).)

      5. Analyse et fondements

        Le Conseil d’administration a dûment examiné et pris en compte la demande 17-5 ainsi que l’ensemble des documents pertinents, dont la recommandation du BAMC [PDF, 146 Ko]. Le Conseil d’administration estime que l’analyse contenue dans la recommandation du BAMC [PDF, 146 Ko], jointe aux présentes, a été menée avec sérieux.

        1. Le requérant a reçu la réparation demandée, la demande 17-5 est donc sans objet.

          Le BAMC conclut et le Conseil acquiesce, que le requérant a reçu la réparation demandée dans la requête, ce qui rend la demande 17-5 sans objet et son réexamen inutile. (Recommandation du BAMC [PDF, 146 Ko], p. 13-14.)

          Le requérant a demandé à l’organisation de l’ICANN de « placer la candidature [.KIDS] en attente jusqu’à ce que les rapports de révision de la CPE soient terminés et publiés. »19 C’est précisément ce que l’organisation de l’ICANN a fait. Immédiatement après la réception de la demande 17-5, l’organisation de l’ICANN a annulé les enchères de l’ensemble conflictuel .KID/.KIDS, et placé l’ensemble conflictuel .KID/.KIDS en attente, car les ensembles conflictuels de chaînes ne peuvent être mis aux enchères que si, entre autres choses, il n’y a pas de mécanisme de responsabilité de l’ICANN en attente correspondant à la chaîne.20

          Le 13 décembre 2017, tandis que l’ensemble conflictuel .KID/.KIDS était en attente de la résolution de la demande 17-5, l’organisation de l’ICANN a publié trois rapports dans le cadre de la révision du processus de CPE.21 Le 15 mars 2018, le Conseil d’administration de l’ICANN a reçu et accepté les résultats présentés dans les trois rapports de révision du processus de CPE, et a déclaré la révision du processus de CPE terminée.22 En conséquence, la réparation demandée dans la demande 17-5 a été rendue sans objet en vertu de la résolution du conseil 2018.03.15.10 déclarant que la révision du processus de CPE était terminée..

        2. L’ICANN a honoré ses engagements lorsqu’elle est allée de l’avant en replaçant l’ensemble conflictuel .KID/.KIDS dans la voie des enchères.

          Le requérant a suggéré que d’autres candidats communautaires « pas explicitement identifiés dans la révision du processus de CPE (p. ex. .SPA CEP/IRP par Donuts) ont été mis en attente pour ce que nous croyons être la révision en cours du processus CPE, » tels que le requérant affirme que supprimer sa candidature et l’ensemble conflictuel .KID/.KIDS de la liste d’attente avant que la révision du processus de CPE soit terminée « allait donc à l’encontre des processus établis. »23 Comme détaillée dans la recommandation du BAMC [PDF, 146 Ko], qui est incorporée aux présentes, la position du requérant confond différents problèmes et s’appuie sur des faits inexacts. De plus, le requérant n’indique pas quels « processus établis » il considère avoir été violés par l’organisation de l’ICANN lorsqu’elle a supprimé l’ensemble conflictuel .KID/.KIDS de la liste d’attente à la suite de la résolution de la demande 16-6 en juillet 2016,24pas plus qu’il ne fournit la preuve d’une telle violation de processus parce qu’il n’y en a pas.

          Contrairement à la demande du requérant et conformément à son engagement de « [p]rendre des décisions en appliquant les politiques consignées systématiquement, de manière neutre, objective et équitable, »25l’organisation de l’ICANN a traité la candidature du requérant .KIDS et l’ensemble conflictuel .KID/.KIDS de la façon qu’il a traité les autres candidatures gTLD et les autres ensembles conflictuels qui n’avaient pas de mécanisme de responsabilité en cours lorsque la révision du processus de CPE a commencé. Le Conseil d’administration estime que l’analyse contenue dans la recommandation du BAMC [PDF, 146 Ko], jointe aux présentes, a été menée avec sérieux. (Voir la recommandation du BAMC [PDF, 146 Ko], p. 17-18.)

          En fin de compte, le requérant n’a identifié aucun élément de la mission, des engagements, des valeurs fondamentales ou des politiques établies de l’ICANN qui aurait été violé par l’Organisation de l’ICANN dans sa correspondance avec le demandeur, puisqu’aucun n’a été violé. En conséquence, le réexamen n’est pas justifié.

          Conformément au chapitre 4, article 4.2(q), le requérant avait 15 jours à compter de la réception de la recommandation du BAMC concernant la demande 17-5 de contester, délai qui a expiré le 20 avril 2018. Le 16 avril 2017, le requérant a indiqué qu’il avait l’intention de déposer une réfutation. (Voir l’annexe D des documents de référence.) Toutefois, aucune réfutation n’avait été déposée à la date limite du 20 avril 2018 et aucune n’a été déposée à ce jour.

          Alors que les statuts précisent que la décision finale du Conseil d’administration doit être prise dans les 135 jours de la réception initiale de la demande de réexamen par le BMAC, dans ce cas, le délai de 135 jours a expiré le jour même de la date limite fixée au requérant pour présenter une réfutation. Le Conseil devait précédemment étudier la demande 17-5 lors d’une réunion le 17 avril 2017, avant l’échéance de 135 jours. Toutefois, comme le requérant a indiqué qu’il entendait présenter une réfutation, le Conseil n’a pas examiné ce point lors de la réunion du 17 avril 2018, puisqu’il était important de rendre une décision définitive sur un dossier complet et permettre au demandeur la possibilité de présenter sa réfutation. Ainsi donc, ceci est la première occasion possible que le Conseil d’administration a d’examiner ce sujet.

          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 l’ICANN soit responsable vis-à-vis de la communauté de mener 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.

    4. Divers

      Aucune résolution adoptée.

Publié le 14 mai 2018.


1 Pour la version préliminaire de janvier 2012 de l’AGB,voir : https://newgtlds.icann.org/en/applicants/agb/guidebook-full-11jan12-en.pdf [PDF, 3,8 Mo].

2 Voir : https://www.icann.org/en/system/files/correspondence/diaz-to-atallah-03oct17-en.pdf [PDF, 127 Ko].

3 Demande 17-5,  2, p. 2.

4 https://gtldresult.icann.org/application-result/applicationstatus/stringcontentionstatus:viewcontentionsetimage/215?_csrf=2fa3a5b7-ca97-4722-bb10-02acbf6ac234.

5 Mise à jour sur l’état d’une candidature et des ensembles conflictuels, disponible sur Https://newgtlds.icann.org/en/applicants/advisories/application-contention-set-14mar14-en.

6 Avant le 22 juillet 2017, le comité de gouvernance (BGC) était chargé d’examiner et de tenir compte des demandes de réexamen en vertu de l’article 4.2 du chapitre 4 des statuts constitutifs. Voir les statuts constitutifs de l’ICANN, 1er octobre 2016, chapitre 4, § 4.2(e), disponibles sur https://www.icann.org/resources/pages/bylaws-2016-09-30-en#article4.

7 Pièce jointe 1, p. 1-3.

8 https://www.icann.org/resources/board-material/resolutions-2016-09-17-en#1.a.

9 https://www.icann.org/resources/board-material/minutes-bgc-2016-10-18-en.

10 La demande de révision 14-30 a été retirée le 7 décembre 2017. Voir https://www.icann.org/en/system/files/files/reconsideration-14-30-dotregistry-request-redacted-07dec17-en.pdf [PDF, 600 KB].

11 La demande de révision 14-32 a été retirée le 11 décembre 2017. Voir https://www.icann.org/en/system/files/files/reconsideration-14-32-dotregistry-request-redacted-11dec17-en.pdf [PDF, 626 KB].

12 La demande de révision 14-33 a été retirée le 15 février 2017. Voir https://www.icann.org/en/system/files/files/reconsideration-14-33-dotregistry-request-redacted-15feb18-en.pdf [PDF, 42 KB].

13 Id.

13 Pièce jointe 1, p. 3.

15 Demande 17-5,  2, p. 2.

16 Mise à jour sur l’état d’une candidature et des ensembles conflictuels, disponible sur Https://newgtlds.icann.org/en/applicants/advisories/application-contention-set-14mar14-en.

17 Voir https://www.icann.org/news/announcement-2017-12-13-en.

18 https://www.icann.org/resources/board-material/resolutions-2018-03-15-en#2.a.

19 Demande 17-5, § 8, p. 6.

20 Voir les détails de la candidature, « état de l’a candidature », disponible sur Https://gtldresult.icann.org/applicationstatus/applicationdetails/161 ; voir aussi http://newgtlds.icann.org/en/applicants/auctions.

21 Voir https://www.icann.org/news/announcement-2017-12-13-en.

22 https://www.icann.org/resources/board-material/resolutions-2018-03-15-en#2.a.

23 Demande 17-5, § 7, p. 6.

24 Voir id.

25 Chapitre 1, article 1.2(a) et (v) des statuts constitutifs de l’ICANN, 22 juillet 2017.

26 Demande 17-5, § 4, p. 2.

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