Logo
ICANN
ICANN
Filtered Search

Are you sure you want to sign out from http://www.icann.org?

If you want to sign out from both http://www.icann.org and ICANN Account, click here.

Activités et réunions du Conseil d’administration

Consulter les mesures et les décisions prises par le Conseil d’administration de l’ICANN lors de ses plus récentes réunions et activités.

Résolutions approuvées par le Conseil d’administration | Réunion extraordinaire du Conseil d’administration de l’ICANN 24 février 2022

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-2022-02-24-en

  1. Ordre du jour approuvé :
    1. RZERC003 : Ajout de protections des données de zone à la zone racine
  2. Ordre du jour principal :
    1. Plan opérationnel et budget de l’IANA pour l’exercice fiscal 2023
    2. Recommandation supplémentaire de la GNSO sur la Recommandation 12 de l’étape 1 de l’EPDP
    3. Divers

  1. Ordre du jour approuvé :

    1. RZERC003 : Ajout de protections des données de zone à la zone racine

      Attendu qu’en février 2021, le Groupe de travail de génie Internet (IETF) a produit le document RFC 8976 qui présente une nouvelle technique de vérification du contenu des fichiers de zone du Système des noms de domaine (DNS) : Digest de messages pour les zones DNS (appelé « ZONEMD »).

      Attendu que le 16 septembre 2015, le Comité de révision de l’évolution de la zone racine (RZERC) a publié le document RZERC003 : Ajout de protections des données de zone à la zone racine contenant trois recommandations à l’ICANN pour la mise en œuvre du protocole ZONEMD dans la zone racine du DNS.

      Attendu que le Comité technique du Conseil d’administration (BTC) a examiné l’évaluation de faisabilité du document RZERC003 et l’évaluation de faisabilité de l’organisation ICANN sur la mise en œuvre des recommandations et a constaté que la mise en œuvre des recommandations serait conforme aux objectifs stratégiques de l’​ICANN ​et à sa mission d’assurer le fonctionnement stable et sécurisé des systèmes d’identificateurs uniques de l’Internet.

      Il est résolu (2022.02.24.01) que le Conseil accepte la Recommandation 1 en demandant à l’organisation ICANN de s’engager avec le responsable de la maintenance de la zone racine et les opérateurs de serveurs racine pour s’assurer que l’ajout d’un enregistrement de ressource ZONEMD à la zone racine n’aura pas d’impact négatif sur la distribution des données de la zone racine au sein du système des serveurs racine et demande au Président-directeur général de l’ICANN, ou son ou ses représentants, de mettre en œuvre cette recommandation.

      Il est résolu (2022.02.24.02) que le Conseil accepte la Recommandation 2 en demandant à l’organisation ICANN de s’engager avec les organismes techniques pertinents pour sensibiliser le public au plan de déploiement de ZONEMD dans la zone racine, et demande au Président-directeur général de l’ICANN, ou son ou ses représentants, de mettre en œuvre cette recommandation.

      Il est résolu (2022.02.24.03) que le Conseil d’administration accepte la Recommandation 4 en demandant à l’organisation ICANN de développer un plan de déploiement de ZONEMD dans la zone racine avec ses contractants et de mettre le plan à la disposition du RZERC pour examen, et demande au Président-directeur général de l’ICANN, ou son ou ses représentants, de mettre en œuvre cette recommandation.

      Fondements des résolutions 2022.02.24.01 à 2022.02.24.03

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

      Le Conseil d’administration prend des mesures sur les conseils du RZERC. Le RZERC examine les changements architecturaux proposés au contenu de la zone racine du DNS, aux systèmes incluant le matériel et logiciel utilisés pour modifier la zone racine du DNS et aux mécanismes utilisés pour la distribution de la zone racine du DNS. La considération du Conseil d’administration sur cet avis fait partie du processus de Registre de demandes d’intervention afin d’assurer une gestion uniforme, efficace et transparente des demandes de la communauté adressées au Conseil d’administration et à l’organisation ICANN.

      Quelle est la proposition à l’étude ?

      En février 2021, le Groupe de travail de génie Internet (IETF) a élaboré le document RFC 8976 qui présente une nouvelle technique de vérification du contenu des fichiers de zone du DNS, appelés Digest de message pour les zones DNS, ou ZONEMD. La RZERC a examiné une proposition de mise en œuvre de ZONEMD dans la zone racine à la demande du responsable de la maintenance de la zone racine et a publié le document RZERC003 le 12 février 2021. Le document RZERC003 contient quatre recommandations pour la mise en œuvre du protocole ZONEMD dans la zone racine du DNS :

      • Recommandation 1 : Le responsable de la maintenance de la zone racine et les opérateurs de serveurs racine doivent vérifier et confirmer que l’ajout d’un enregistrement de ressource ZONEMD n’aura aucun impact négatif sur la distribution des données de la zone racine dans le RSS.

      • Recommandation 2 : Les communautés Internet et du DNS doivent être informées des plans d’utilisation de ZONEMD dans la zone racine et avoir la possibilité de faire part de ses commentaires. Il peut s’agir de présentations techniques lors de réunions organisées par l’ICANN, le Centre d’analyse et de recherche pour les opérations DNS (DNS-OARC), le Groupe des opérateurs de réseau nord-américains (NANOG), les Réseaux IP européens (RIPE), etc.

      • Recommandation 3 : Les développeurs de logiciels de serveur de noms sont encouragés à mettre en place ZONEMD et à envisager de l’activer par défaut lorsque le logiciel est configuré pour servir localement les données de zone racine. Le Conseil d’administration ne prend pas de décision sur la Recommandation 3, car elle ne s’adresse pas à l’ICANN.

      • Recommandation 4 : Les identificateurs techniques publics (PTI) et le RZM devraient élaborer conjointement un plan de déploiement de ZONEMD dans la zone racine, et rendre ce plan disponible pour révision par le RZERC.

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

      Le document RZERC003 a été créé et édité par les membres du RZERC. Le RZERC se compose de représentants des groupes suivants :

      • Groupe de travail de génie Internet (IETF)
      • Organisation de soutien à l’adressage (ASO)
      • Organisation de soutien aux extensions géographiques (ccNSO)
      • Conseil d’administration de l’ICANN
      • Identificateurs techniques publics (PTI)
      • Groupe des représentants des opérateurs de registres (RySG) de l’Organisation de soutien aux extensions génériques
      • Comité consultatif du système des serveurs racine (RSSAC)
      • Comité consultatif sur la sécurité et la stabilité (SSAC)
      • Verisign en tant que responsable de la maintenance de la zone racine

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

      Aucune préoccupation ou question n’ont été soulevées.

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

      La mise en œuvre devrait avoir des répercussions positives sur la communauté en mettant en œuvre des mécanismes de sécurité supplémentaires pour la diffusion de la zone racine du DNS. Aucun impact négatif n’a été identifié.

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

      Le Conseil a examiné le document RZERC003 élaboré par le RZERC et le document RFC 8976 élaboré par l’IETF. En outre, pour chaque recommandation présentée dans cette résolution, le Conseil a considéré la compréhension de la recommandation par l’organisation ICANN comme confirmée par l’évaluation de faisabilité de la mise en œuvre du RZERC et de l’organisation ICANN.

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

      Le coût pour l’organisation ICANN devrait être faible et comprend les dépenses associées à la gestion de projet, à l’administration et aux efforts de sensibilisation. Ces coûts sont incorporés au budget du Bureau du directeur de la technologie (OCTO) dans le cadre des activités normales.

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

      ZONEMD est une nouvelle technique de vérification du contenu des fichiers de zone DNS. Si elle est déployée dans la zone racine, ZONEMD devrait fournir des protections supplémentaires de l’intégrité des données, notamment pour les applications émergentes telles que la distribution hyperlocale de la zone racine.

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

      Cette décision relève de la mission de l’ICANN et sert l’intérêt public mondial, car la mise en œuvre devrait fournir des protections supplémentaires de l’intégrité des données dans la zone racine.

      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 administrative organisationnelle de l’ICANN nécessitant ou non une consultation publique ?

      Cette décision ne nécessite pas de consultation publique.

  2. Ordre du jour principal :

    1. Plan opérationnel et budget de l’IANA pour l’exercice fiscal 2023

      Attendu que la version préliminaire du plan opérationnel et budget de l’IANA pour l’exercice fiscal 2023 a été publiée à des fins de consultation publique le 15 septembre 2021 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é de finances du Conseil d’administration (BFC) pour examen et considération. En outre, tous les commentaires publics ont été pris en considération, et lorsque cela a approprié et faisable, ont été intégrés dans la version finale du plan opérationnel et budget de l’IANA pour l’exercice fiscal 2023.

      Attendu que conformément à l’article 22.4(b) du chapitre 22 des statuts constitutifs de l’ICANN la société demandera à la PTI de lui présenter son budget en tant que contribution dans le but de l’inclure dans le plan opérationnel et le budget de l’ICANN avant son élaboration. Le budget de la PTI adopté pour l’exercice fiscal 2023 est inclus comme entrée dans le plan opérationnel et le budget de l’IANA.

      Attendu qu’en vertu 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.

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

      Fondements de la résolution 2022.02.24.04

      Conformément à l’article 22.4 du chapitre 22 des statuts constitutifs de l’ICANN, le Conseil d’administration doit adopter le budget annuel de l’IANA et le publier sur le site Web de l’ICANN. Le 15 septembre 2022, les versions préliminaires du plan opérationnel et budget de la PTI pour l’exercice fiscal 2023 et du plan opérationnel et budget de l’IANA pour l’exercice fiscal 2023 ont été publiées à des fins de consultation publique. Le 13 décembre 2021, le Conseil d’administration de la PTI a approuvé le plan opérationnel et budget de la PTI pour l’exercice fiscal 2023, et ledit budget a servi de base au plan opérationnel et budget de l’IANA pour l’exercice fiscal 2023.

      Les versions préliminaires du plan opérationnel et budget de la PTI et du plan opérationnel et budget de l’IANA pour l’exercice fiscal 2023 sont basées sur de nombreuses discussions menées avec les membres de la communauté de l’ICANN et de l’organisation ICANN, notamment de vastes consultations auprès des organisations de soutien et comités consultatifs de l’ICANN ainsi que d’autres groupes de parties prenantes, tout au long des mois précédents. En juillet 2021, des consultations préliminaires ont été menées auprès des parties prenantes sur les priorités de l’exercice fiscal 2023 pour les identificateurs techniques publics (PTI). Ces engagements ont pris la forme de discussions avec les organismes de soutien et les comités consultatifs, ainsi qu’avec le Groupe des représentants des opérateurs de registres gTLD, les Registres Internet régionaux et la direction de l’IETF. En outre, deux séminaires Web communautaires ont eu lieu le 27 juillet 2021.

      Tous les commentaires reçus à travers la procédure de consultation publique ont été considérés en relation avec le plan opérationnel et budget de l’IANA pour l’exercice fiscal 2023. 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 2023 proposée à des fins d’adoption.

      L’adoption du plan opérationnel et budget de l’IANA pour l’exercice fiscal 2023 aura un impact positif sur l’ICANN du fait que ce plan fournit un cadre adéquat pour la gestion des services IANA et fournit également la base permettant à l’organisation d’être tenue responsable de manière transparente.

      Cette décision sert l’intérêt public et s’inscrit dans la mission de l’ICANN car elle est pleinement conforme aux plans stratégiques et opérationnels de l’ICANN, et car 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. Elle devrait avoir un impact positif 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.

    2. Recommandation supplémentaire de la GNSO sur la Recommandation 12 de l’étape 1 de l’EPDP

      Attendu que le 20 février 2019, l’équipe responsable de l’étape 1 du processus accéléré d’élaboration de politiques (EPDP) a publié son Rapport final1 sur la spécification temporaire relative aux données d’enregistrement des gTLD.

      Attendu que le 4 mars 2019, le conseil de la GNSO a approuvé les 29 recommandations finales du PDP, comme documentées dans le rapport final de l’étape 1 du groupe de travail de l’équipe responsable de l’EPDP.

      Attendu que le 29 mars 2019, le conseil de la GNSO a transmis son rapport sur les recommandations mandatées par les statuts constitutifs au Conseil d’administration de l’ICANN, recommandant à ce dernier d’adopter toutes les recommandations politiques de l’étape 1.

      Attendu que le 4 mars 2019, le rapport final de l’étape 1 a été publié pour consultation publique afin d’informer le Conseil d’administration des mesures prises à ce sujet, conformément aux statuts constitutifs.

      Attendu que le 15 mai 2019, le Conseil a adopté les recommandations de l’étape 1 de l’EPDP, à l’exception de l’objectif 2 de la Recommandation 1 et de la Recommandation 12, que le Conseil n’a pas adoptées intégralement. Le Conseil a expliqué les raisons pour lesquelles il n’a pas adopté la Recommandation 12 portant sur la possibilité de supprimer des données dans le champ « Organisation » de sa fiche de suivi intitulée « Fiche de suivi : recommandations de l’étape 1 de l’EPDP ».

      Attendu que le Conseil d’administration de l’ICANN a choisi de ne pas adopter l’avis de mise en œuvre 2(b) de la Recommandation 12, étant donné que la suppression du contenu dans le champ « Organisation » pourrait entraîner la perte d’informations d’identification sur le nom du titulaire de nom de domaine et pourrait ne pas être cohérente avec la mission de l’ICANN ou dans l’intérêt public mondial.

      Attendu que selon les exigences des statuts constitutifs, le conseil de la GNSO a examiné la déclaration du Conseil d’administration et a entamé une discussion avec le Conseil d’administration de l’ICANN.

      Attendu que le 14 octobre 2019, le Conseil d’administration a suggéré au conseil de la GNSO que l’inclusion d’une sauvegarde supplémentaire, similaire à celle appliquée en ce qui concerne le champ du contact administratif, dans le cadre d’une recommandation supplémentaire pourrait constituer une voie à suivre pour l’adoption de la Recommandation 12 par le Conseil.

      Attendu que le 19 décembre 2019, le conseil de la GNSO a adopté la Recommandation 12 à la majorité qualifiée, modifiant le texte de la Recommandation 12 de manière à préciser que « avant d’éliminer les champs « contact et organisation », tous les bureaux d’enregistrement DOIVENT s’assurer que chaque enregistrement contient les coordonnées du titulaire de nom enregistré » (Recommandation supplémentaire 12).

      Attendu que le Conseil a examiné la Recommandation complémentaire 12 et a entretenu une correspondance avec le conseil de la GNSO tout au long de 2020 et 2021. Le 23 octobre 2021, le Conseil d’administration a partagé sa compréhension de l’intention et de l’impact de la Recommandation 12 une fois que la politique sur les données d’enregistrement a été mise en œuvre avec le conseil de la GNSO pour plus de précisions.

      Attendu que le 14 décembre 2021, le Conseil d’administration et le conseil de la GNSO ont discuté en détail de la compréhension du Conseil.

      Attendu que le 21 janvier 2022, le conseil de la GNSO a confirmé que le Conseil avait compris l’intention et l’impact de la Recommandation 12, une fois mise en œuvre, comme cela était signalé dans sa lettre du 21 janvier 2022 .

      Il est résolu (2022.02.24.05) que le Conseil d’administration adopte la Recommandation supplémentaire du conseil de la GNSO sur la Recommandation 12 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 (EPDP) concernant la suppression des données dans le champ « Organisation », car elle traite de la préoccupation primordiale du Conseil en matière de perte de données essentielles et qu’il devrait y avoir toujours le besoin de contacter le titulaire du nom enregistré et cela est dans le meilleur intérêt de l’ICANN et de la communauté de l’ICANN.

      Il est résolu (2022.02.24.06) que le Conseil d’administration charge Président-directeur général de l’ICANN, ou son ou ses représentants, d’inclure les directives appropriées comme décrites dans la correspondance de la GNSO du 21 janvier 2022 dans le cadre de la mise en œuvre de la politique relative aux données d’enregistrement.

      Fondements des résolutions 2022.02.24.05 à 2022.02.24.06

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

      Le 20 février 2019, l’équipe responsable de l’étape 1 du processus accéléré d’élaboration des politiques (EPDP) a publié son rapport final sur la spécification temporaire relative aux données d’enregistrement des gTLD. Le 4 mars 2019, le conseil de la GNSO a adopté le rapport final à la majorité qualifiée et l’organisation ICANN a par la suite lancé une période de consultation publique. Le Conseil d’administration a résolu d’adopter les recommandations, à quelques exceptions près, le 15 mai 2019. Le Conseil n’a pas adopté intégralement la Recommandation 12 en ce qui concerne l’avis de mise en œuvre de la recommandation 2(b) qui permet la suppression des données d’enregistrement dans le champ « Organisation ». La Recommandation 12 porte sur la publication ou la suppression de données dans le champ « Organisation ». Le Conseil d’administration de l’ICANN a choisi de ne pas adopter l’avis de mise en œuvre 2(b) de la Recommandation 12, où les parties contractantes ont la possibilité de supprimer des données dans le champ « Organisation », car il craint que cela entraîne la perte des informations nécessaires si un titulaire de nom de domaine ne répond pas à l’enquête d’un bureau d’enregistrement. Le Conseil a expliqué les raisons pour lesquelles il n’a pas adopté la Recommandation 12 portant sur la possibilité de supprimer des données dans le champ « Organisation » de sa fiche de suivi intitulée « Fiche de suivi : recommandations de l’étape 1 de l’EPDP ». Dans la fiche de suivi, le Conseil d’administration a souligné son inquiétude quant à la perte des informations nécessaires si un titulaire de nom de domaine ne répond pas à l’enquête d’un bureau d’enregistrement. Par la suite, le Conseil a publié une déclaration du Conseil d’administration adressée au président du conseil de la GNSO demandant une discussion conformément aux exigences des statuts constitutifs (annexe A-1, article 6.c).

      Quelle est la proposition à l’étude ?

      En vertu de l’article 9.d de l’annexe A des statuts constitutifs de l’ICANN, le Conseil d’administration prend actuellement des mesures pour adopter la recommandation supplémentaire du conseil de la GNSO sur la Recommandation 12 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 (EPDP), concernant le champ « Organisation ».

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

      Le conseil de la GNSO a examiné ce sujet lors de ses réunions tenues les 28 mai 2019, 26 juin 2019, 18 juillet 2019, 22 août 2019, 24 octobre 2019 et 6 novembre 2019, et avec le Conseil d’administration de l’ICANN lors de ses sessions conjointes à l’ICANN65 et l’ICANN66, respectivement le 24 juin 2019 et le 3 novembre 2019. Le conseil de la GNSO a également sollicité des informations supplémentaires de la part de l’équipe responsable de l’EPDP pour préparer la prochaine discussion avec le Conseil d’administration de l’ICANN. La communication initiale du conseil de la GNSO avec l’équipe responsable de l’étape 2 de l’EPDP sur ce sujet a eu lieu le 16 mai 2019 pour informer l’équipe de la décision du Conseil d’administration de reporter l’adoption de l’objectif 2 de la Recommandation 1 pour mener un examen plus approfondi lors de l’étape 2 de l’EPDP, et la non-adoption de l’aspect de la Recommandation 12 qui a permis la suppression du champ de données « Organisation » du titulaire de nom de domaine, ce qui a donné lieu à un dialogue entre le Conseil d’administration et le conseil de la GNSO.

      Le 9 juin 2019, le président de l’étape 2 de l’EPDP a correspondu avec le président du conseil de la GNSO en identifiant un contexte supplémentaire pour les fondements de la Recommandation 12 de l’équipe responsable de l’EPDP ; toutefois, à ce stade, il n’y a pas eu d’accord sur la question de savoir si la non-adoption du Conseil devait être appuyée ou non. Le 24 juin 2019, le conseil de la GNSO a tenu sa session de travail à l’ICANN65 à Marrakech, au Maroc, et a examiné la Recommandation 12 en réponse à la demande du conseil de la GNSO à l’équipe responsable de l’EPDP de faire des commentaires de fond sur la décision du Conseil. Le 31 octobre 2019, le président du conseil de la GNSO a écrit à l’équipe responsable de l’EPDP pour lui indiquer que le conseil avait pour objectif de conclure la discussion entre le Conseil d’administration et la GNSO sur la base des commentaires reçus par le Conseil d’administration. Le 3 novembre 2019, le conseil de la GNSO s’est réuni avec le Conseil d’administration et les membres de l’équipe responsable de l’EPDP au cours de la réunion publique ICANN66 pour discuter des prochaines étapes possibles, ce qui a permis au conseil de la GNSO de résoudre les directives supplémentaires de mise en œuvre.

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

      À la suite de l’approbation par le conseil de la GNSO de la recommandation supplémentaire relative à la Recommandation 12, l’Unité constitutive des utilisateurs commerciaux (BC) a publié une déclaration publique appuyant l’orientation supplémentaire fournie par le conseil de la GNSO pour répondre à une préoccupation semblable à celle du Conseil d’administration concernant la suppression de données.

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

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

      • La déclaration du Conseil d’administration du 15 mai 2019 sur l’adoption de 27 des 29 recommandations.

      • La lettre du conseil de la GNSO du 9 septembre 2019 mettant à jour le Conseil d’administration sur le processus de consultation de l’étape 1 de l’EPDP.

      • La lettre du 14 octobre 2019 du Conseil d’administration se félicitant des fondements de la Recommandation 12 qui ont été fournis lors de la réunion du Conseil d’administration et du conseil de la GNSO à l’ICANN65.

      • La lettre du conseil de la GNSO du 23 décembre 2019 informant le Conseil d’administration de son adoption à la majorité qualifiée des directives supplémentaires de la Recommandation 12.

      • La lettre du Conseil d’administration du 11 décembre 2020 faisant part de sa préoccupation du fait que les données soient conservées quelque part, à titre de sauvegarde plutôt que d’être supprimées.

      • La lettre du conseil de la GNSO du 4 mars 2021 clarifiant la préoccupation du Conseil d’administration concernant le fait que les données publiées dans le WHOIS ou RDAP ne sont pas les données sur lesquelles le bureau d’enregistrement s’appuie principalement pour maintenir le contact avec le titulaire de nom de domaine.

      • La lettre du Conseil d’administration du 7 mai 2021 accusant réception de la correspondance du conseil de la GNSO concernant la clarification du conseil sur la directive supplémentaire de la Recommandation 12 de l’étape 1 de l’EPDP.

      • La lettre du 23 octobre 2021 du Conseil d’administration fait part de sa compréhension de l’impact et de l’intention de la Recommandation 12 une fois mise en œuvre dans la politique relative aux données d’enregistrement.

      • La lettre du conseil de la GNSO du 21 janvier 2022 confirmant avec le Conseil d’administration les hypothèses sur l’intention et l’impact de la Recommandation 12 une fois mise en œuvre.

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

      Le Conseil d’administration comprend, d’après la lettre du conseil de la GNSO, qu’il « existe un héritage important d’utilisations et d’objectifs mixtes dans ce champ. Il n’y a pas de normalisation chez les bureaux d’enregistrement dans la façon dont ce champ est traité ». Ainsi, ​​le Conseil d’administration estime que l’intention de la Recommandation 12 de l’étape 1 de l’EPDP est de fournir des exigences pour normaliser la façon dont le champ « Organisation » du titulaire de nom de domaine. Le Conseil d’administration reconnaît également la déclaration du conseil de la GNSO selon laquelle « les données publiées dans le WHOIS ou RDAP ne sont pas les seules données stockées ni les données sur lesquelles le bureau d’enregistrement s’appuie principalement pour maintenir le contact avec le titulaire de nom de domaine » et comprend que pour les enregistrements existants, les valeurs supprimées sur les modifications apportées aux informations WHOIS pour la durée du parrainage du nom de domaine par le bureau d’enregistrement et pour une période supplémentaire de 2 ans devront continuer à être maintenues dans l’enregistrement du bureau d’enregistrement, conformément à l’article 1.1 de la spécification relative à la conservation des données du RAA de 2013. Pour les nouveaux enregistrements, les bureaux d’enregistrement seront tenus de demander la confirmation pour publier la valeur dans le champ « Organisation » du titulaire de nom de domaine. Si le titulaire de nom de domaine refusait de publier la valeur, celle-ci restera expurgée, mais les données ne seront pas supprimées.

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

      L’adoption de la recommandation supplémentaire adoptée par le conseil de la GNSO sur la Recommandation 12 de l’EPDP concernant la suppression des données aura un impact positif sur l’ICANN et la communauté car elle établit des mécanismes de sauvegarde pour éviter que des données essentielles des titulaires de nom de domaine ne soient perdues, si jamais il était nécessaire de contacter le propriétaire du domaine.

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

      La mise en œuvre des recommandations de l’étape 1 de l’EPDP devrait avoir un impact opérationnel, financier et/ou autre sur les opérateurs de registre et les bureaux d’enregistrement qui mettront en œuvre de nouvelles exigences pour normaliser la façon dont le champ « Organisation » du titulaire de nom de domaine est traité.

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

      Aucune en ce moment.

      Cette décision sert-elle l’intérêt public et la mission de l’ICANN ?

      Cette décision relève de la mission et du mandat de l’ICANN et sert l’intérêt public, car le rôle de l’ICANN est de coordonner l’élaboration et la mise en œuvre de politiques à travers un processus multipartite ascendant, basé sur le consensus, et conçu pour assurer le fonctionnement stable et sécurisé des systèmes de noms uniques de l’Internet.

      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 ?

      Il s’agit d’une fonction administrative organisationnelle de l’ICANN qui ne nécessite pas de consultation publique, mais il convient de noter que le rapport final des recommandations de politique a fait l’objet de commentaires publics, comme il a été mentionné ci-dessus.

    3. Divers

1GNSO et organisation ICANN (20 février 2019), Rapport final du processus accéléré d’élaboration de politiques sur la spécification temporaire relative aux données d’enregistrement des gTLD, https://gnso.icann.org/sites/default/files/file/field-file-attach/epdp-gtld-registration-data-specs-final-20feb19-en.pdf p.15.