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:

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-2021-03-25-en

  1. Ordre du jour approuvé :
    1. RSSAC028 : Analyse technique du schéma de nommage utilisé pour les serveurs racine individuels.
    2. RSSAC047 : rapport consultatif du RSSAC sur les indicateurs pour les serveurs racine du DNS et le système des serveurs racine
    3. Nomination des auditeurs indépendants pour l’exercice fiscal 2021
  2. Ordre du jour principal :
    1. Acceptation du rapport final de mise en œuvre de la deuxième révision organisationnelle du Comité consultatif sur la sécurité et la stabilité (SSAC2)
    2. Acceptation de l'étude 1 du projet d'analyse de la collision de noms (NCAP) et poursuite de l'étude 2
    3. Étape de conception opérationnelle du système normalisé d’accès et de divulgation des données d’enregistrement non publiques (SSAD) ;
    4. Divers

  1. Ordre du jour approuvé :

    1. RSSAC028 : Analyse technique du schéma de nommage utilisé pour les serveurs racine individuels.

      Attendu que le 3 août 2017, le Comité consultatif du système des serveurs racine (RSSAC) a publié le document RSSAC028 : Avis sur l’analyse technique du schéma de nommage utilisé pour les serveurs racine individuels..

      Attendu que le travail demandé dans le document RSSAC028 relève de la compétence de l’ICANN pour assurer le fonctionnement stable et sécurisé du système d’identificateurs uniques d’Internet dans le cadre de la mission de l’ICANN.

      Attendu que l’organisation ICANN a évalué la faisabilité des propositions du RSSAC dans le document RSSAC028 et a élaboré des recommandations pour leur mise en œuvre.

      Attendu que le Conseil d’administration a examiné les recommandations pour la mise en œuvre de l’organisation ICANN relatives aux recommandations du document RSSAC028.

      Il est résolu (2021.03.25.01) que le Conseil accepte la Recommandation 1, appelant à ce que le schéma de nommage actuel utilisé dans le système de serveurs racine reste inchangé jusqu’à ce que d’autres études aient été menées.

      Il est résolu (2021.03.25.02) que le Conseil accepte la Recommandation 2, relative à la réalisation d’une étude pour comprendre le comportement actuel des résolveurs du DNS et la manière dont chaque schéma de nommage discuté dans ce document affecterait ces comportements, et charge le Président-directeur général de l’ICANN, ou son ou ses délégués, d’entreprendre une telle étude.

      Il est résolu (2021.03.25.03) que le Conseil accepte la Recommandation 3, relative à la réalisation d’une étude visant à comprendre la faisabilité et l’impact des attaques de la redélégation de nœuds, et charge le Président-directeur général de l’ICANN, ou son ou ses délégués, d’entreprendre une telle étude.

      Fondements des résolutions 2021.03.25.01 à 2021.03.25.03

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

      Le Conseil d’administration prend cette décision à la demande du RSSAC.

      Le RSSAC a pour attribution de conseiller la communauté et le Conseil d’administration de l’ICANN sur des questions liées au fonctionnement, à la gestion, à la sécurité et à l’intégrité du système des serveurs racine de l’Internet. Cela inclut la communication sur les questions relatives au fonctionnement des serveurs racine et de leurs instances multiples avec la communauté technique et l’ICANN ; la collecte et l’articulation des exigences pour offrir à ceux qui sont engagés dans des révisions techniques des protocoles et les meilleures pratiques communes liées au fonctionnement des serveurs DNS ; s’engager dans l’évaluation continue des menaces et l’analyse des risques du système de serveurs racine et recommander toute activité d’audit nécessaire pour évaluer l’état actuel des serveurs racine et de la zone racine.

      Quelle est la proposition à l’étude ?

      Le groupe de travail du Caucus consacré au nommage des serveurs racine du RSSAC a étudié les modifications possibles du schéma de dénomination du serveur racine actuel. Ce système de nommage a bien fonctionné pour les serveurs racine et la communauté Internet dans son ensemble depuis plus de deux décennies. Cependant, compte tenu de l’environnement Internet actuel, le RSSAC a étudié le schéma de nommage utilisé pour les serveurs racine individuels et a examiné les conséquences des modifications.

      Le groupe de travail a conclu qu’il pourrait y avoir un avantage à adopter l’un des autres schémas décrits dans le document RSSAC028 après des recherches plus approfondies, mais il a également été recommandé qu’aucune modification immédiate des noms de serveurs racine ne soit apportée au moment de la publication de l’avis (Recommandation 1).

      Le document recommande aux chercheurs du DNS d’étudier quatre sujets : la taille de réponse acceptable pour l’amorçage des requêtes ; la manière dont les résolveurs réagissent lorsqu’ils reçoivent des réponses avec un ensemble raccourci d’enregistrements de raccord ; la manière dont les résolveurs qui valident les réponses d’amorçage se comportent lorsqu’ils sont confrontés à des réponses interrompues ; et si les listes de recherche affectent le comportement d’amorçage (Recommandation 2).

      En outre, le RSSAC a recommandé qu’une étude soit menée pour comprendre la faisabilité et l’impact des attaques de redélégation de nœuds, car il a été reconnu qu’une recherche plus approfondie est nécessaire pour comprendre les attaques de redélégation de nœuds, les coûts et les avantages de la signature des enregistrements A et AAAA pour les serveurs racine, et les effets de l’augmentation de la taille de la réponse à la requête initiale (Recommandation 3).

      La Recommandation 4 demande au RSSAC d’étudier les réponses d’amorçage envoyées dans des circonstances particulières. Aucune action n’est associée à cette recommandation pour le Conseil d’administration de l’ICANN.

      La Recommandation 5 est qualifiée de « spéculative » et contient des suggestions d’actions qui ne s’appliquent que si les attaques de redélégation de nœuds présentent un risque sérieux devant être atténué. Le 28 septembre 2020, le RSSAC a confirmé que, pour le moment, il n’y avait pas d’action pour le Conseil d’administration de l’ICANN liée à cette recommandation.

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

      Dans le cadre de la mission mentionnée ci-dessus, le RSSAC a formé un Groupe de travail du caucus qui était responsable de la publication de documents menant à et incluant le RSSAC028.

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

      Aucune en ce moment.

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

      Le le 9 juillet 2015, Groupe de travail du caucus a publié son Cahier des charges et portée de l’analyse historique et technique du schéma de nommage utilisé pour les serveurs racine individuels. Ce document a fourni des directives divisées en cinq points clés. Le premier point était « documenter l’histoire technique des noms assignés aux serveurs racine individuels depuis la création du système de serveur racine », ce qui a conduit à l’émission du document RSSAC023 : Histoire du système des serveurs racine Les quatre points restants ont servi de base à cet avis : RSSAC028.

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

      Cette recherche facilite l’évolution continue du système des serveurs racine.

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

      L’organisation ICANN pourrait effectuer l’enquête requise par le RSSAC028 pour aider la communauté à décider s’il est recommandé ou non de modifier le schéma de nommage des serveurs racine.

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

      Les ressources requises pour les études des Recommandations 2 et 3 (il est plus efficace de réaliser les études ensemble) nécessiteront du personnel et du budget n’étant pas actuellement alloués.

      Selon les estimations de l’organisation ICANN, la réalisation de l’étude de la Recommandation 2 prendra environ six mois de travail d’un chercheur à un coût d’environ 150 000 USD, ainsi qu’un soutien administratif et une gestion de projet minimal. Cette étude n’a pas été budgétisée pour l’exercice fiscal 2021.

      L’organisation ICANN estime que la réalisation de cette étude envisagée dans la Recommandation 3 exigerait environ deux mois de travail d’un chercheur à un coût d’environ 50 000 USD, ainsi qu’un soutien administratif et de gestion de projet minimal. Cette étude n’a pas été budgétisée pour l’exercice fiscal 2021.

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

      La recherche recommandée par le RSSAC028 est directement liée à la stabilité future du système de serveurs racine.

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

      Cela relève directement de la déclaration de la mission de l’ICANN, énoncée dans l’article 1.1 des statuts constitutifs. MISSION :

      « (a) La mission de l’ICANN consiste à assurer un fonctionnement stable et sécurisé des identificateurs uniques de l’Internet

      (ii) Facilite la coordination du fonctionnement et de l’évolution du système des serveurs de noms racine du DNS.

      En outre, la mise en œuvre de cet avis est en ligne avec le point « 1.2 renforcer la gouvernance des opérations du serveur racine du DNS en coordination avec les opérateurs du serveur racine du DNS » du Plan stratégique de l’ICANN pour les exercices fiscaux 2021 à 2025.

      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 ?

      L’action recommandée par le RSSAC028 ne nécessite pas de commentaires publics, car il s’agit uniquement d’une recherche. Toutefois, une fois la recherche publiée, il y aura des décisions futures qui nécessiteront de la rétroaction de la communauté.

    2. RSSAC047 : rapport consultatif du RSSAC sur les indicateurs pour les serveurs racine du DNS et le système des serveurs racine

      Attendu que le document RSSAC047, « Avis du RSSAC sur les indicateurs pour les serveurs racine du DNS et le système des serveurs racine », publié le 12 mars 2020, recommande un ensemble d’indicateurs pour les serveurs racine du système des noms de domaine (DNS) ainsi que pour le système des serveurs racine (RSS) et recommande le développement de systèmes pour collecter ces indicateurs.

      Attendu que l’organisation ICANN a développé un prototype de système de mesure pour fournir des données au Caucus RSSAC afin de permettre une recommandation éclairée sur les seuils de mesure, et que le RSSAC et le Caucus RSSAC ont convenu de quatre types d’indicateurs pour mesurer avec la plus grande précision les performances des opérateurs de serveurs racine (RSO).

      Attendu que les recommandations du RSSAC047 relèvent de la compétence de l’organisation ICANN pour assurer le fonctionnement stable et sécurisé des systèmes d’identificateurs uniques de l’Internet ; et que la mise en œuvre des recommandations permettrait de préserver et d’améliorer la stabilité opérationnelle, la fiabilité, la sécurité et l’interopérabilité mondiale de l’Internet et de garantir que de nouveaux gTLD soient introduits de manière sûre et stable.

      Il est résolu (2021.03.25.04) que le Conseil accepte la Recommandation 1, qui prévoit la mise en œuvre d’un prototype de système de mesure pour les RSO, et remercie l’organisation ICANN d’avoir déjà développé un tel système pour aider à définir les indicateurs décrits dans le document RSSAC047.

      Il est résolu (2021.03.25.05) que le Conseil accepte la Recommandation 2 pour mettre en œuvre un système de mesure plus permanent après avoir établi et utilisé le prototype de système de mesure de la Recommandation 1, et charge le Président-directeur général de l’ICANN, ou son´ou ses délégués, de mettre en œuvre un tel système.

      Il est résolu (2021.03.17.04) que le Conseil d’administration charge le Président-directeur général de l’ICANN, ou son ou ses représentants, à mettre en place et opérer le système de mesure décrit dans la Recommandation 2.

      Fondements des résolutions 2021.03.25.04 à 2021.03.25.06

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

      Le Conseil d’administration prend cette décision en réponse à l’avis du RSSAC.

      Quelle est la proposition à l’étude ?

      Le document RSSAC047 définit les mesures, les indicateurs et les seuils auxquels les opérateurs de serveurs racine (RSO) se conforment pour fournir un niveau minimal de performance. Les seuils sont basés sur des indicateurs techniques conçus pour évaluer les performances, la disponibilité et la qualité du service fourni par chaque identificateur de serveur racine (RSI). Les seuils et les indicateurs sur lesquels ils sont basés sont inclus comme contribution du RSSAC dans un processus d’évaluation encore à définir pour les RSO actuels et futurs. Les indicateurs définis dans le RSSAC047 permettent de montrer quand les RSO atteignent ou non des niveaux de performance minimum. Ils fournissent également un moyen de montrer que le RSS dans son ensemble est ou n’est pas conforme au niveau de performance.

      Le document RSSAC047 répertorie trois (3) recommandations :

      La recommandation 1 du RSSAC047 prévoit la mise en œuvre initiale des systèmes de mesure et d’analyse décrits dans l’avis. Ce travail est déjà terminé.

      Les indicateurs sont basés sur une stratégie qui consiste à prendre des mesures externes de chaque identificateur de serveur racine, à collecter ces mesures, puis à les inclure dans des rapports mensuels. Les rapports sont indiqués comme réussite/échec pour chaque indicateur par rapport à un ensemble de seuils répertoriés dans le document.

      La Recommandation 2 de RSSAC047 décrit un service à long terme ultérieur. Les détails opérationnels du service à long terme peuvent être déterminés après une expérience suffisante de la mise en œuvre initiale du prototype décrit dans la Recommandation 1. Sur la base de cette expérience opérationnelle avec le système prototype, l’organisation ICANN peut déterminer comment et quand la mise en œuvre officielle sera mise en place. Il est possible que l’organisation ICANN détermine que le système prototype répond à toutes les exigences décrites dans le RSSAC047 et qu’il est adapté à une utilisation à long terme.

      La Recommandation 3 du RSSAC047 prévoit des travaux supplémentaires à l’avenir, de sorte qu’à l’heure actuelle, le Conseil ne doit prendre aucune décision. Le travail futur serait initié par le RSSAC (ou un organisme successeur à la suite de la mise en œuvre des recommandations du RSSAC038), et serait exécuté en collaboration avec l’organisation ICANN et la communauté Internet.

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

      Le document RSSAC047 a été créé et édité par le Caucus RSSAC, qui est composé d’un grand nombre d’experts de la communauté. Le RSSAC a soumis cet avis dans sa capacité de conseiller la communauté et le Conseil d’administration de l’ICANN sur des questions liées au fonctionnement, à la gestion, à la sécurité et à l’intégrité du système des serveurs racine de l’Internet.

      Il y a eu un fort consensus au sein du Caucus RSSAC sur le fait que les quatre types d’indicateurs identifiés dans le document sont l’ensemble correct pour les mesures externes des RSO.

      L’organisation ICANN a déjà travaillé avec le RSSAC sur un prototype de système de mesure de la performance des RSO pour fournir des données à prendre en considération pour aider à l’élaboration des mesures décrites dans le RSSAC047.

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

      Pas d’inquiétudes manifestées.

      Quels sont les principaux documents examinés par le Conseil ? Quels sont les facteurs que le Conseil a trouvés significatifs ?

      L’élan de ce travail vient du RSSAC037 : un modèle de gouvernance proposé pour le système des serveurs racine du DNS. Bien que ne dépendant pas de la mise en œuvre du RSSAC037, ce travail peut éclairer le travail de mise en œuvre du RSSAC037 de la manière suivante :

      • Une future manifestation de la fonction de surveillance et de mesure de la performance (PMMF) pourrait utiliser les indicateurs techniques et les seuils définis dans le présent rapport comme point de départ pour définir ses règles d’évaluation de la performance, de la disponibilité et de la qualité du service fourni par chaque RSO, ce qui permettrait d’apporter une responsabilité technique aux RSO.
      • Le document RSSAC037 indique que les attentes de niveau de service (SLE) doivent exister entre les parties prenantes qui fournissent le financement et les RSO qui reçoivent le financement. Les indicateurs et les seuils des RSO définis dans le présent rapport peuvent servir de point de départ pour d’autres discussions sur les exigences techniques et de performance des SLE.

      Deuxièmement, bien que ce rapport ne porte que sur des attentes minimales en matière de performance, le RSSAC reconnaît qu’avec l’évolution du modèle de gouvernance, les RSO peuvent conclure de futurs contrats de service qui pourraient inclure des Conventions de service (SLA). Le RSSAC s’attend à ce que les indicateurs définis ici soient utiles dans un contexte des SLA. En se fondant sur des discussions qui ont eu lieu au cours de la préparation de ce rapport, le RSSAC s’attend en outre à ce que les seuils des SLA soient plus stricts (si possible) que ceux fournis ici.

      Troisièmement, les indicateurs et les seuils définis dans ce rapport peuvent également être utilisés par les RSO et d’autres personnes pour identifier les situations où le RSS dans son ensemble se dégrade en matière de performance, et où des mesures doivent être prises collectivement.

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

      L’organisation ICANN a déjà travaillé avec le RSSAC sur un prototype de système de mesure de la performance des RSO pour fournir des données à prendre en considération pour aider à l’élaboration des mesures décrites dans le RSSAC047.

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

      Les indicateurs définis ici permettent à la communauté de déterminer si des RSO ne répondent pas au niveau de performance minimum. La communauté peut ensuite travailler avec le RSSAC ou par l’intermédiaire d’autres mécanismes communautaires pour régler le problème.

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

      La mise en œuvre de la Recommandation 1 et, éventuellement, de la Recommandation 2 nécessite du temps de l’organisation ICANN et un petit montant pour les dépenses opérationnelles courantes. Ces coûts sont incorporés dans le budget de l’OCTO dans le cadre de ses activités habituelles.

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

      Les indicateurs définis ici fournissent un moyen de montrer que le RSS dans son ensemble est, ou n’est pas conforme aux niveaux de performance. La mise en œuvre de cet avis relève de la compétence de l’ICANN, car elle implique la mise en place de systèmes que la communauté peut utiliser pour faire des évaluations du RSS.

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

      Oui. Le document RSSAC047 définit les mesures, les indicateurs et les seuils auxquels les opérateurs de serveurs racine (RSO) se conforment pour fournir un niveau minimal de performance. Cela relève directement de la déclaration de la mission de l’ICANN, énoncée dans l’article 1.1 des statuts constitutifs. MISSION :

      « (a) La mission de l’ICANN consiste à assurer un fonctionnement stable et sécurisé des identificateurs uniques de l’Internet

      (ii) Facilite la coordination du fonctionnement et de l’évolution du système des serveurs de noms racine du DNS.

      En outre, la mise en œuvre de cet avis est en ligne avec le point « 1.2 renforcer la gouvernance des opérations du serveur racine du DNS en coordination avec les opérateurs du serveur racine du DNS » du Plan stratégique de l’ICANN pour les exercices fiscaux 2021 à 2025.

    3. Nomination des auditeurs indépendants pour l’exercice fiscal 2021

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

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

      Il est résolu (2021.03.25.07) que le Conseil d’administration autorise le président et PDG de l’ICANN, ou son ou ses représentants, à prendre toutes les mesures nécessaires pour engager BDO LLP et ses sociétés membres comme cabine(s) d’audit des états financiers pour l’exercice fiscal finissant le 30 juin 2021.

      Fondements de la résolution 2021.03.25.07

      Depuis l’audit de l’exercice fiscal 2014, les cabinets d’audit indépendants de l’ICANN sont des membres du réseau BDO USA, LLP et BDO. En 2019, il y a eu un changement des partenaires et un nouveau partenaire d’audit a été affecté à l’engagement de l’ICANN. Sur la base du rapport de l’organisation et de l’évaluation par le Comité d’audit des travaux réalisés, le comité a recommandé au Conseil d’administration d’autoriser le Président-directeur général de l’ICANN, ou son ou ses représentants, à prendre toutes les mesures nécessaires pour engager les cabinets du réseau BDO USA, LLP et BDO afin de procéder à l’audit financier de l’exercice fiscal 2021 et de remplir toutes les obligations prévues en matière d’audit indépendant annuel dans toute juridiction.

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

      Cette décision aura un impact fiscal sur l’ICANN, qui est pris en compte dans le plan opérationnel et budget de l’ICANN. Elle ne devrait pas avoir d’impact direct sur la sécurité, la stabilité et la résilience du système des noms de domaine.

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

  2. Ordre du jour principal :

    1. Acceptation du rapport final de mise en œuvre de la deuxième révision organisationnelle du Comité consultatif sur la sécurité et la stabilité (SSAC2)

      Attendu que le 12 mars 2020, le Conseil d’administration a accepté le plan de mise en œuvre détaillé de la deuxième révision du SSAC et a enjoint à l’équipe de révision de transmettre régulièrement au Conseil d’administration des rapports sur les activités de mise en œuvre.

      Attendu que le groupe de révision du Comité consultatif sur la sécurité et la stabilité (SSAC2 RWP), avec l’approbation et la surveillance du SSAC, a fourni au Conseil par l’intermédiaire du Comité du Conseil d’administration chargé de l’efficacité organisationnelle (OEC) des mises à jour semestrielles sur les progrès des efforts de mise en œuvre jusqu’au moment où ces derniers ont été terminés.

      Attendu que le 3 décembre 2020, le SSAC2 RWP, a soumis un rapport final de mise en œuvre détaillant l’achèvement de la mise en œuvre des recommandations découlant de la deuxième révision du SSAC et documentant que trois recommandations1 ont des composantes limitées qui ne sont pas encore entièrement mises en œuvre. L’OEC a reconnu que les différentes étapes des travaux de mise en œuvre du SSAC2 étaient soumises à des interdépendances échappant au contrôle du SSAC.

      Attendu que l’OEC recommande que le Conseil accepte le rapport final de mise en œuvre de la révision SSAC2 publié par le SSAC2 RWP et approuvé par le SSAC le 3 décembre 2020, complétant ainsi la deuxième révision du SSAC ; et demande que le SSAC fournisse une mise à jour écrite ou orale à l’OEC avant le 30 juin 2021 sur les trois recommandations avec des composantes limitées pour lesquelles la mise en œuvre n’est pas encore entièrement terminée et, si elle n’est pas terminée d’ici là, tous les six mois par la suite jusqu’à ce que toute la mise en œuvre soit terminée.

      Il est résolu (2021.03.25.08) que le Conseil d’administration accepte le rapport final de mise en œuvre de la deuxième révision du SSAC publié par le SSAC RWP, ce qui marque la conclusion de la révision organisationnelle conformément à l’article 4.4 du chapitre 4 des statuts constitutifs. Le Conseil d’administration encourage le SSAC à continuer de surveiller les répercussions de la mise en œuvre des recommandations de la deuxième révision du SSAC dans le cadre de son processus d’amélioration continue.

      Il est résolu (2021.03.25.09) que le Conseil d’administration salue les travaux de mise en œuvre du SSAC RWP visant à renforcer l’efficacité, la transparence et la responsabilité du SSAC, dans le respect des délais proposés dans le plan de mise en œuvre détaillé de la deuxième révision du SSAC adoptée.

      Il est résolu (2021.03.25.10) que le Conseil demande au SSAC de fournir à l’OEC une mise à jour écrite ou orale de l’état d’avancement des éléments restants des trois recommandations pour lesquels la mise en œuvre n’est pas entièrement terminée. Dans l’hypothèse où la mise en œuvre ne serait pas achevée avant le 31 décembre 2020, le SSAC devra continuer à fournir tous les six mois de telles mises à jour à l’OEC jusqu’à la conclusion des activités de mise en œuvre.

      Fondements des résolutions 2021.03.25.08 à 2021.03.25.10

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

      L’ICANN organise des révisions indépendantes de ses organisations de soutien et comités consultatifs comme prescrit par le chapitre 4 article 4.4 des Statuts de l’ICANN, pour veiller à ce que le modèle multipartite de l’ICANN demeure transparent et responsable, et pour améliorer son rendement.

      Cette action complète la deuxième révision du SSAC et est basée sur le Rapport final de mise en œuvre, tel qu’approuvé par le SSAC.

      Suite à l’évaluation de tous les documents pertinents par le Comité chargé de l’efficacité organisationnelle (OEC), le Conseil d’administration est désormais en mesure d’examiner et d’accepter le rapport final de mise en œuvre.

      Contexte : L’auditeur indépendant a commencé ses travaux en mars 2018 et a publié son rapport final en décembre 2018, y compris 30 recommandations. Le SSAC a publié son évaluation de faisabilité et plan initial de mise en œuvre en mai 2019, le Conseil acceptant les deux et dirigeant la planification de la mise en œuvre à partir de juin 2019. Le Conseil a accepté le plan de mise en œuvre détaillé en mars 2020. À noter que six recommandations et/ou les questions sous-jacentes fournies par l’auditeur indépendant n’ont pas été appuyées par le SSAC et, par conséquent, ces recommandations n’ont pas été incluses dans le plan de mise en œuvre détaillé ni dans le rapport final de mise en œuvre (Recommandations 7, 13, 17, 21, 22, et 23).

      Quelle est la proposition à l’étude ?

      Le SSAC RWP a soumis son rapport final de mise en œuvre à l’OEC le 3 décembre 2020. Le rapport final de mise en œuvre indique que l’ensemble des 24 recommandations acceptées par le Conseil d’administration ont à présent été mises en œuvre , ou intégrées dans les processus du SSAC en cours, comme indiqué dans les procédures opérationnelles du SSAC.

      En particulier, le travail de mise en œuvre de douze recommandations a donné lieu à la modification de plusieurs sections des procédures opérationnelles du SSAC publiées le 12 février 2020 : Sections 2.1.2 (retraits et dissidences)2, 2.3 (sélection des nouveaux membres)3, 2.5 (processus de révision annuel)4, 2.6.1 (affirmation de la confidentialité et de la non-divulgation)5, 2.8.1 (rôles du SSAC – président)6, 2.8.3 (rôles du SSAC – liaisons externes du SSAC)7, 3.1 (procédures de publication du SSAC - proposition, sélection et planification d’un produit de travail)8, 3.2.4 (procédures de publication du SSAC – étude et travail primaire – révision préliminaire)9, 3.4 (publication, promulgation et publicité)10, 3.5 (contrôle, révision, et suivi)11, Appendice B et F12.

      Ces douze recommandations portent sur divers aspects des opérations du SSAC :

      • Documenter les révisions et la rétroaction de l’agent de liaison avec le Conseil (Recommandation 3),
      • Saisir des renseignements dans le registre de demandes d’intervention (ARR) du Conseil d’administration (Recommandation 4),
      • Examiner l’état de mise en œuvre des avis passés et futurs fournis au Conseil d’administration de l’ICANN (Recommandation 5),
      • Formaliser un processus annuel pour établir les priorités de recherche et identifier les menaces liées à la sécurité, la stabilité et la résilience (SSR) (Recommandations 8),
      • Mettre à jour les compétences dans les processus d’adhésion et de recrutement du SSAC (Recommandation 9),
      • Communiquer ses décisions (Recommandation 10),
      • En discutant explicitement quelles seraient les parties concernées qui pourraient figurer dans les séries de documents du SSAC (Recommandation 16),
      • Identifier les lacunes dans les compétences des membres actuels (Recommandation 24),
      • élaborer un processus officiel pour estimer la diversité actuelle et souhaitée (Recommandation 25),
      • Veiller à ce que l’efficacité d’une liaison externe et de la personne qui occupe le poste soit révisée régulièrement (Recommandation 26),
      • Et limiter la direction du SSAC à mandats de deux ou trois ans et n’imposer aucune limite au mandat des membres non dirigeants (Recommandation 27). XXX

      En outre, la mise en œuvre de la Recommandation 28 a donné lieu à une modification des statuts constitutifs pour que le mandat du président du SSAC soit limité. Cela suggère que l’impact de la mise en œuvre de ces recommandations se poursuivra dans le cadre des processus en cours, en soutenant l’orientation d’amélioration continue du SSAC à mesure qu’ils opérationnalisent et continuent de suivre les procédures modifiées sur une base continue.

      Le SSAC RWP a signalé que huit recommandations (1, 2, 11, 14, 15, 19, 20, 30) n’ont pas requis des travaux de mise en œuvre parce que les étapes recommandées font déjà partie des processus et des opérations du SSAC.

      En outre, des composantes limitées du travail de mise en œuvre des recommandations 18, 24 et 25 dépendent de facteurs en dehors du contrôle du SSAC. Les recommandations portent sur la consolidation de l’information en ligne et l’accroissement de la transparence (Recommandation 18), l’identification des lacunes dans les compétences des membres actuels (Recommandation 24), l’élaboration d’un processus officiel pour estimer la diversité actuelle et souhaitée (Recommandation 25) et, bien que des travaux importants aient été mis en œuvre, les composantes de ces recommandations n’ont pas pu être considérées comme pleinement mises en œuvre en raison de la non-publication de photographies des membres du SSAC sur la page Web publique du SSAC (Recommandation 18), et du manque d’opportunités de se réunir en personne en raison des annulations de réunions de l’ICANN à cause du COVID-19 (Recommandations 24, 25). Toutefois, le SSAC prévoit de traiter la dernière composante de la Recommandation 18 une fois que la nouvelle page Web publique du SSAC sera publiée, et il s’approchera également du personnel régional de l’ICANN pour l’aider à faire le point sur la mise en œuvre des Recommandations 24 et 25.

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

      Le Conseil d’administration, par le biais de l’OEC, a consulté le SSAC2 RWP, qui était responsable de la mise en œuvre et a surveillé l’état d’avancement de la révision ainsi que celui de la mise en œuvre des recommandations découlant de la révision.

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

      Les travaux de mise en œuvre menés par le SSAC ont suivi ses normes et meilleures pratiques pour promouvoir la transparence et la responsabilité. Aucune préoccupation n’a été exprimée par la communauté.

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

      Le Conseil a examiné les sections pertinentes des statuts constitutifs, la documentation sur le processus de révision organisationnelle, le plan de mise en œuvre de la révision SSAC2, son premier rapport semestriel sur l’état d’avancement de la mise en œuvre et le rapport final sur la mise en œuvre.

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

      Le Conseil a trouvé plusieurs facteurs significatifs, contribuant à la réalisation effective du travail de mise en œuvre :

      • L’engagement du SSAC à son amélioration continue.
      • La formation d’un groupe dédié chargé de superviser la mise en œuvre des recommandations acceptées par le Conseil d’administration ;
      • Le respect du plan de mise en œuvre comportant un calendrier pour la mise en œuvre, la définition des résultats souhaités et des moyens de mesurer l’état actuel ainsi que les progrès réalisés afin d’atteindre les résultats souhaités.
      • Des rapports détaillés et en temps opportun sur les progrès de la mise en œuvre

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

      Cette décision du Conseil d’administration devrait avoir un impact positif sur la communauté en reconnaissant et en mettant en évidence la mise en œuvre effective des recommandations découlant de la deuxième révision du SSAC2. La mise en œuvre complète de la révision organisationnelle du SSAC2 démontre l’engagement du SSAC à l’égard de l’amélioration continue.

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

      Il est prévu que cette action du Conseil n’aura pas d’impact financier. Le Conseil note que l’exécution de la plupart des recommandations nécessite l’aide du personnel de soutien au SSAC de l’organisation ICANN, ce qui serait fait dans le cadre des tâches habituelles du personnel de soutien. Les conséquences de cette résolution sur l’organisation ICANN, la communauté et le public devraient être positives, dans la mesure où cette décision du Conseil d’administration constitue une étape importante pour les révisions organisationnelles.

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

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

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

      La décision du Conseil est conforme à l’engagement de l’ICANN en vertu de l’article 4.1 du chapitre 4 des statuts constitutifs pour garantir que le modèle multipartite de l’ICANN demeure transparent et responsable, et pour améliorer la performance de ses organisations de soutien et de ses comités consultatifs. Cette décision servira l’intérêt public en respectant l’engagement de l’ICANN à assurer et renforcer sa responsabilité et sa transparence.

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

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

    2. Acceptation de l'étude 1 du projet d'analyse de la collision de noms (NCAP) et poursuite de l'étude 2

      Attendu qu’en 2017, le Conseil d’administration a adopté les résolutions 2017.11.02.29 à 2017.11.02.31 et a posé une série de questions sur les collisions de noms.

      Attendu que, le Comité consultatif sur la sécurité et la stabilité de l’ICANN (SSAC) a répondu par une proposition de trois études destinées à répondre aux questions du Conseil.

      Attendu que le SSAC et le Bureau du directeur de la technologie (OCTO) de l’organisation de l’ICANN ont travaillé ensemble pour produire une proposition révisée mutuellement convenue pour l’étude 1 du NCAP.

      Attendu qu’en avril 2019, le Conseil a demandé à l’organisation ICANN de procéder à l’étude 1 du NCAP et a autorisé les dépenses associées à cette fin.

      Attendu que l’organisation ICANN a engagé Scarfone Cybersecurity, un entrepreneur indépendant, pour effectuer des recherches et rédiger l’étude 1 du NCAP.

      Attendu que le 30 juin 2020, l’organisation ICANN a envoyé la version finale de l’étude 1 du NCAP au Comité technique du Conseil d’administration (BTC) après deux périodes de commentaires publics sur les versions préliminaire et finale du rapport.

      Attendu que l’étude 1 du NCAP recommandait que les études 2 et 3 du NCAP ne se déroulent pas comme prévu actuellement.

      Attendu que, le groupe de discussion du NCAP (DG) a révisé la conception de l’étude 2 du NCAP pour tenir compte des questions soulevées par l’étude 1 du NCAP.

      Attendu que le 5 février 2021, la direction du groupe de discussion du NCAP a présenté la conception révisée de l’étude 2 du NCAP au BTC pour approbation.

      Il est résolu (2021.03.25.11) que le Conseil d’administration de l’ICANN réitère ses remerciements au SSAC pour sa réponse à la résolution de novembre 2017 et pour l’élaboration d’une proposition initiale pour le NCAP et pour les révisions subséquentes de cette proposition.

      Il est résolu (2021.03.25.12) que le Conseil d’administration remercie le groupe de discussion du NCAP pour ses contributions à l’étude 1 du NCAP.

      Il est résolu (2021.03.25.13) que le Conseil affirme la pertinence continue des neuf questions relatives aux collisions de noms présentées dans les résolutions 2017.11.02.29 à 2017.11.02.31 du Conseil, en particulier les questions (7) et (8) concernant les critères d’identification des chaînes sujettes à collision et de détermination de la sécurité de la délégation des chaînes sujettes à collision.

      Il est résolu (2021.03.25.14) que le Conseil ordonne au groupe de discussion du NCAP de procéder à l’étude 2 telle qu’elle a été nouvellement conçue et ordonne au Président-directeur général, ou son ou ses représentants, de participer à l’étude 2 de la manière indiquée dans la proposition nouvellement conçue.

      Fondements des résolutions 2021.03.25.11 à 2021.03.25.14

      Le terme « collision de noms » fait référence à la situation où un nom qui est défini et utilisé dans un espace de noms peut aussi apparaître dans un autre espace de noms. Dans ce contexte, un « espace de noms » fait référence à tous les noms possibles pouvant être résolus, par exemple, l’espace de noms DNS public administré par l’ICANN via les fonctions IANA ou un espace de noms « privé » limité à un réseau d’entreprise. Lorsque des utilisateurs ou des applications censés utiliser un nom dans un espace de noms spécifique tentent de l’utiliser dans un autre espace (généralement de manière accidentelle en raison d’une mauvaise configuration), des comportements inattendus peuvent se produire si l’usage prévu du nom n’est pas le même dans les deux espaces de noms. Un exemple de collision de noms en dehors du DNS serait d’appeler le nom d’une personne ordinaire dans un environnement fermé comme une salle de déjeuner d’entreprise, plutôt que d’appeler ce nom dans un espace public bondé : dans le premier cas, la personne visée est susceptible de répondre alors que dans le deuxième, plusieurs personnes peuvent répondre.

      Le 2 novembre 2017, le Conseil d’administration de l’ICANN a adopté les résolutions 2017.11.02.29 à 2017.11.02.31 demandant au SSAC de mener des études pour présenter des données, des analyses et des points de vue, et de fournir des avis au Conseil d’administration concernant les risques posés aux utilisateurs et aux systèmes finaux si les chaînes .CORP, .HOME, .MAIL devaient être déléguées dans la racine, ainsi que les mesures possibles qui pourraient atténuer les risques identifiés. Le Conseil a également posé neuf questions relatives à la définition de la collision de noms, à l’expérience de l’utilisateur et aux possibles dommages, aux causes des collisions, aux risques potentiels et aux atténuations possibles, entre autres sujets liés à la collision de noms.

      À la suite de la résolution du Conseil, le SSAC a commencé à planifier les projets en décembre 2017 pour les travaux nécessaires afin de répondre aux demandes du Conseil. En janvier 2018, le groupe de travail du NCAP du SSAC (« NCAP WP ») a été formé et a préparé un plan appelant à trois études. L’Administration NCAP (« NCAP Admin »), un groupe plus restreint composé de la direction du NCAP WP et de la direction du SSAC, qui guide l’effort du NCAP à la fois au sein du SSAC et dans la communauté de l’ICANN dans son ensemble, a également été créée.

      En juin 2018, le Président-directeur général de l’organisation ICANN, après la participation du Conseil, a chargé l’OCTO d’achever les études du NCAP, car le SSAC ne disposait ni de l’infrastructure administrative ni des ressources nécessaires pour entreprendre et gérer un projet aussi important.

      En septembre 2018, le SSAC a publié la «proposition du SSAC pour le projet d’analyse de la collision de noms», qui a proposé trois études consécutives pour répondre à la demande du Conseil d’administration. L’OCTO a proposé des modifications mineures à la proposition et, après discussion entre le SSAC et l’OCTO, une version mise à jour de la proposition a été publiée en février 2019.

      En avril 2019, le groupe de discussion du NCAP a été formé pour permettre aux membres intéressés de la communauté de l’ICANN de participer également à l’effort du NCAP. Le groupe de discussion du NCAP est composé à la fois du SSAC NCAP WP et de tous les membres de la communauté intéressés.

      En raison de contraintes de ressources, l’OCTO a choisi d’externaliser l’achèvement de l’étude 1 à un entrepreneur. Un appel à propositions pour le travail a été publié le 9 juillet 2019 et, en septembre 2019, Scarfone Cybersecurity a été sélectionné conformément aux processus de passation de marchés normalisés de l’organisation ICANN. L’étude 1 est le résultat d’un effort de collaboration entre Scarfone Security, l’équipe de discussion du NCAP et l’organisation ICANN. Chaque version préliminaire de l’étude au cours de chaque procédure de consultation publique a été accueillie avec divers commentaires et points de discussion avant la publication du rapport final. Le rapport final de l’étude 1 a été publié le 19 juin 2020.

      Les principales conclusions de l’étude 1 peuvent être résumées comme suit :

      1. Les collisions de noms sont un problème connu depuis des décennies, mais les travaux publiés n’ont commencé à apparaître qu’à partir de 2012. Le seul travail connu sur les collisions de nom au cours des dernières années a été effectué au sein de la communauté ICANN par le groupe de discussion du NCAP et le groupe de travail sur les procédures pour des séries ultérieures de nouveaux gTLD (« SubPro WG »).
      2. Peu de cas de collisions de noms ont été signalés à l’ICANN ou rendus publics depuis l’instauration d’une interruption contrôlée. Un seul des rapports à l’ICANN a nécessité une action par un registre, et aucun des rapports publics étudiés n’a mentionné un préjudice majeur pour des individus ou des organisations.
      3. Il existe plusieurs causes profondes de collisions de nom, mais elles ont généralement été trouvées en recherchant un TLD spécifique ayant fait l’objet d’une fuite, et non en examinant des ensembles de données.
      4. Aucune lacune ni aucun autre problème n’ont été identifiés lors de l’accès aux ensembles de données qui seraient nécessaires pour les études 2 et 3.

      L’étude 1 affirme que :

      Compte tenu de ces conclusions, la recommandation est que les études 2 et 3 ne devraient pas être effectuées comme prévu actuellement. En ce qui concerne l’étude 2, il est peu probable que l’analyse des ensembles de données permette d’identifier les causes profondes des collisions de noms qui n’ont pas encore été identifiées. De nouvelles causes de collisions de nom sont beaucoup plus susceptibles d’être trouvées en enquêtant sur les candidats aux TLD pour une délégation potentielle au cas par cas. En ce qui concerne l’étude 3, l’interruption contrôlée a déjà prouvé une stratégie d’atténuation efficace, et il ne semble pas nécessaire d’identifier, d’analyser et de tester des alternatives pour la grande majorité des candidats aux TLD. (Résumé exécutif, p. v)

      En réponse aux conclusions de l’étude 1, le groupe de discussion du NCAP a nouvellement conçu l’étude 2 et a apporté plusieurs changements importants : (1) la suppression de deux objectifs initiaux de l’étude, (2) l’expansion et le détail ajouté d’autres objectifs de l’étude, et (3) le fait que le groupe de discussion du NCAP a entrepris la plupart des travaux qui ont été prévus pour les entrepreneurs rémunérés dans la version originale de la proposition de l’étude 2. Ces modifications réduisent considérablement la portée, le niveau d’effort, les coûts totaux et les ressources nécessaires à l’exécution de l’étude 2.

      Le groupe de discussion du NCAP entreprendra une partie importante du travail dans l’étude 2 nouvellement conçue, tandis que l’ICANN fournira un soutien à la gestion de projet et engagera un rédacteur technique et un chercheur technique pour aider à la préparation de l’étude. Les coûts estimés pour l’organisation ICANN pour l’étude 2 nouvellement conçue tombent en dessous du seuil requis pour l’approbation du Conseil d’administration et ne sont donc pas décrits plus loin dans ces présentes.

      Le BTC affirme que les questions relatives aux collisions de nom posées dans les résolutions 2017.11.02.29 à 2017.11.02.31 du Conseil sont toujours pertinentes. Le BTC souligne l’importance particulière des questions (7) et (8) concernant les critères d’identification des chaînes sujettes à collision et la détermination de la sécurité de la délégation des chaînes sujettes à collision.

      La décision du Conseil est censée avoir un impact positif sur la sécurité, la stabilité et la résilience du DNS de l’Internet, étant donné qu’elle a été conçue pour continuer à étudier la collision de noms. Cette décision s’inscrit dans la mission de l’ICANN consistant à assurer le fonctionnement stable et sécurisé des systèmes d’identificateurs uniques de l’Internet. Cette résolution sert l’intérêt public dans le sens où elle est conforme aux principales valeurs de l’ICANN de préservation et d’amélioration de l’administration du DNS et de stabilité opérationnelle, fiabilité, sécurité, interopérabilité mondiale, résilience et ouverture du DNS et d’Internet.

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

    3. Étape de conception opérationnelle du système normalisé d’accès et de divulgation des données d’enregistrement non publiques (SSAD) ;

      Attendu que le 24 septembre 2020, le conseil de la GNSO a voté en faveur de l’approbation de toutes les recommandations de son rapport final sur le processus accéléré d’élaboration de politiques concernant l’étape 2 de la spécification temporaire relative aux données d’enregistrement des gTLD (EPDP).

      Attendu que le Conseil a commencé ses délibérations pour examiner si les recommandations du rapport final de l’étape 2 de l’EPDP sont dans le meilleur intérêt de la communauté de l’ ICANN ou de l’ICANN.

      Attendu que le Conseil souhaite utiliser le nouveau processus de l’étape de conception opérationnelle pour évaluer les recommandations et recueillir plus d’information dans le cadre de ses délibérations.

      Attendu que le Conseil d’administration note que le 5 mai 2020, un document de travail : Le coût estimé pour le système normalisé d’accès et de divulgation proposé par l’équipe de l’étape 2 de l’EPDP fourni par l’organisation ICANN au groupe de travail de l’étape 2 du processus accéléré d’élaboration de politiques (EPDP) pour les données d’enregistrement des gTLD comprenait une estimation des coûts associés au démarrage et aux opérations continues liées aux exigences du système proposé par l’équipe au cours du processus d’élaboration de politiques.

      Il est résolu (2021.03.25.15) que le Conseil d’administration ordonne au Président-directeur général, ou son ou ses représentants, de procéder à l´’étape de conception opérationnelle (ODP) des recommandations approuvées par le conseil de la GNSO (Recommandations 1 à 18) du rapport final de l’étape 2 de l’EPDP sur le système normalisé d’accès et de divulgation.

      Il est résolu (2021.03.25.16) que le Conseil d’administration ordonne au Président-directeur général, ou son ou ses représentants, de mener l’étape de conception opérationnelle en tenant compte des questions décrites dans le document de cadrage de l’étape de conception opérationnelle du système normalisé d’accès et de divulgation des données d’enregistrement non publiques et que l’évaluation finale de la conception opérationnelle soit remise au Conseil six mois à compter de la date de la demande du Conseil, à condition qu’il n’y ait pas de questions juridiques ou autres imprévues qui pourraient avoir une incidence sur le calendrier. En cas de circonstances imprévues, le Conseil d’administration ordonne au Président-directeur général, ou son ou ses représentants, d’en aviser le Conseil, d’en discuter avec lui et de lui fournir un calendrier mis à jour pour les prochaines étapes appropriées concernant l’évaluation de la conception opérationnelle.

      Il est résolu (2021.03.25.17) que le Conseil d’administration ordonne au Président-directeur général, ou son ou ses représentants, d’examiner le document de discussion sur l’estimation des coûts de l’organisation de l’ICANN du 5 mai 2020 pendant l’étape de conception opérationnelle des recommandations approuvées par le conseil de la GNSO (Recommandations 1 à 18) du rapport de l’étape 2 de l’EPDP sur le système normalisé d’accès et de divulgation.

      Fondements des résolutions 2021.03.25.15 à 2021.03.25.17

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

      Étant donné la complexité du projet et l’investissement en ressources nécessaire pour mettre en œuvre les recommandations de politiques liées au SSAD de manière prévisible et opportune, le lancement d’un ODP est essentiel pour éclairer les délibérations du Conseil d’administration et en particulier de savoir si les recommandations sont dans le meilleur intérêt de la communauté ou de l’ICANN. Le travail de l’ODP permettra d’évaluer les risques potentiels, les coûts prévus, les besoins en ressources, les échéanciers et d’autres questions liées à la mise en œuvre des recommandations liées au SSAD. Il fournira également au Conseil, de façon transparente, des renseignements pertinents sur les recommandations à l’appui de l’obligation du Conseil d’agir sur les recommandations de la GNSO conformément aux statuts constitutifs. En outre, le conseil de la GNSO, dans sa lettre du 22 janvier 2021 , a recommandé au Conseil d’administration de revoir le « document de travail original sur l’estimation des coûts » publié par l’organisation ICANN le 20 mai 2020, et a ensuite demandé une consultation avec le Conseil d’administration de l’ICANN pour discuter « si une analyse des coûts-avantages supplémentaire devait être menée avant que le Conseil d’administration de l’ICANN ne considère toutes les recommandations liées au SSAD pour adoption ». Le lancement de l’étape de conception opérationnelle contribuera à la consultation du Conseil d’administration avec le conseil de la GNSO.

      Quelle est la proposition à l’étude ?

      Le Conseil d’administration prend actuellement des mesures pour lancer l’ODP et demande à l’organisation ICANN de préparer une évaluation des exigences opérationnelles et de l’impact des recommandations liées au SSAD, conformément au champ d’application spécifié par le Conseil d’administration, afin de l’informer de ses délibérations sur les recommandations.

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

      L’équipe de l’étape 2 de l’EPDP a publié son rapport initial sur les recommandations de priorité 1 le 7 février 2020 et l’addenda au rapport initial, qui porte sur les recommandations de priorité 2, le 26 mars 2020. Tant le rapport initial que l’addenda au rapport initial ont fait l’objet d’une consultation publique. Un rapport final a été présenté au conseil de la GNSO le 31 juillet. Les déclarations de la minorité des groupes de parties prenantes ont été acceptées jusqu’au 24 août 2020, et toutes les déclarations reçues avant la date butoir ont été incorporées dans le rapport final.

      Dans sa lettre du 29 octobre 2020 transmettant les recommandations de l’équipe de l’étape 2 de l’EPDP au Conseil d’administration, le conseil de la GNSO a demandé une consultation avec le Conseil de l’ICANN au sujet des Recommandations 1- à 18, qui décrivent la politique pour le SSAD. Dans sa lettre du 1er décembre 2020, le Conseil a « reconnu la demande du conseil de la GNSO pour une consultation sur les recommandations relatives au SSAD » et a pris note de son plan visant à « lancer une étape de conception opérationnelle pour évaluer l’impact opérationnel des recommandations consensuelles approuvées par le conseil de la GNSO ». Le 8 février 2021, le Conseil a lancé le forum de consultation publique sur les recommandations relatives au SSAD. La période de consultation publique s’est achevée le 30 mars 2021.

      De plus, l’OPD est un nouveau processus qui a été élaboré avec la participation de la communauté. La première itération du concept ODP a été publiée le 1er octobre 2020. La communauté et l’organisation ICANN ont discuté du contenu du document de réflexion au cours de l’ICANN69. La deuxième version de l’ODP a été publiée le 17 décembre 2020. L’organisation ICANN a organisé un séminaire en ligne communautaire le 13 janvier 2021 pour faciliter une discussion sur les mises à jour fournies dans la version préliminaire ultérieure de l’ODP et pour recevoir des commentaires supplémentaires de la communauté.

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

      La communauté a fourni une rétroaction approfondie au sujet du SSAD, y compris ses répercussions financières. Les préoccupations suivantes ont été partagées dans les commentaires publics et les déclarations de la minorité sur le rapport final de l’étape 2 de l’EPDP, ainsi que dans la correspondance reçue par l’organisation ICANN et dans d’autres contextes :

      • La SSAD ne répond pas aux besoins de la communauté en donnant accès à des données précises et non publiques en temps opportun et de façon prévisible.
      • La SSAD supporte des coûts opérationnels importants et manque de flexibilité pour s’assurer qu’il soit adapté.
      • La SSAD ne répond pas à la question concernant la sécurité, la stabilité et la fiabilité du DNS.
      • La SSAD comprend des mécanismes insuffisants pour l’évolution.
      • La SSAD peut perturber un mécanisme d’accès stable, prévisible et réalisable pour l’information non publique du WHOIS.

      La communauté a également fait part de ses commentaires au cours de l’élaboration de l’ODP en soulevant les préoccupations suivantes :

      • L’ODP pourrait permettre aux groupes de parties prenantes de rouvrir ou de réexaminer les questions de politique ayant déjà été réglées au cours du processus d’élaboration de politiques.
      • L’ODP modifierait les rôles et responsabilités de l’organisation ICANN et de l’équipe de révision de la mise en œuvre formée après que les recommandations du conseil de la GNSO aient été adoptées par le Conseil d’administration.
      • L’ODP modifierait le rôle du conseil de la GNSO en tant que gestionnaire du processus d’élaboration de politiques.

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

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

      • Le document de discussion sur l’analyse des coûts du 5 mai 2020, produit par l’organisation ICANN pour l’équipe de l’étape 2 de l’EPDP, qui fournit une estimation des coûts associés au démarrage et aux opérations en cours liées aux exigences du système proposé.
      • La résolution du conseil de la GNSO du 24 septembre 2020 sur les recommandations du rapport final de l’étape 2 de l’EPDP.
      • Le rapport final de l’étape 2 de l’EPDP, reçu du conseil de la GNSO, qui comprend les Recommandations 1 à 18 qui traitent du système normalisé d’accès et de divulgation (SSAD).
      • La correspondance du conseil de la GNSO du 29 octobre 2020, demandant une consultation avec le Conseil d’administration et le conseil de la GNSO avant les délibérations du Conseil sur les recommandations de politique générale.
      • La lettre du 22 janvier 2021 du conseil de la GNSO recommandait au Conseil d’administration d’examiner et de mettre à jour le document de discussion original sur l’estimation des coûts ainsi que les sujets suggérés pour l’évaluation de l’impact opérationnel.

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

      Le Conseil d’administration a examiné les facteurs décrits dans l’analyse de l’estimation des coûts et la complexité des recommandations relatives au SSAD, dans la mesure où ils proposent un nouveau système pour l’ICANN. Le Conseil d’administration comprend qu’il y a des préoccupations de la communauté concernant les répercussions financières et le coût par rapport aux avantages du SSAD. Le Conseil comprend également, de la part des utilisateurs potentiels du SSAD dans la communauté, qu’il existe des préoccupations sur le fait que ce système soit efficace pour son but déclaré et qu’il soit largement utilisé. L’effort de collecte d’information comprendra l’examen de l’efficacité du SSAD et des mesures visant à en assurer l’adoption et l’utilisation à grande échelle. Si les recommandations sont approuvées par le Conseil d’administration, le SSAD est un nouveau système que l’organisation de l’ICANN construira et exploitera potentiellement. La mise en œuvre et le fonctionnement du SSAD nécessiteront des investissements et des ressources considérables. En outre, les lois sur la protection des données, telles que le Règlement général sur la protection des données (RGPD), ont eu un impact significatif sur l’organisation ICANN et les données d’enregistrement du WHOIS. Il est possible que d’autres lois et incertitudes juridiques puissent apparaître pendant la période de l’ODP, ce qui pourrait également avoir un impact significatif sur l’organisation ICANN et les données d’enregistrement du WHOIS. Ainsi, l’organisation ICANN doit s’assurer que le SSAD soit conçu d’une manière qui respecte toutes les lois et soutienne le DNS à l’échelle mondiale.

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

      L’organisation ICANN intègrera des mécanismes de rétroaction tels que des webinaires pour communiquer avec la communauté sur les progrès de l’ODP, améliorant ainsi la transparence de l’examen par le Conseil des recommandations politiques approuvées par le conseil de la GNSO. L’OPD fournira également plus de clarté sur les recommandations de politique, ce qui réduira probablement le temps que l’organisation de l’ICANN et l’équipe de révision de la mise en œuvre consacreront à la conception des processus pendant l’étape de mise en œuvre.

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

      Cette résolution impliquera de consacrer d’importantes ressources organisationnelles à l’achèvement de l’ODP pendant la période indiquée dans le document de cadrage. La communauté sera invitée à présenter des commentaires tout au long de cette période.

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

      L’ODP tiendra compte de l’impact que le SSAD peut avoir sur la sécurité, la stabilité ou la résilience du DNS.

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

      Dans son évaluation, le Conseil examinera quelles sont, le cas échéant, les considérations d’intérêt public dans le cadre des recommandations de l’étape 2 de l’EPDP. Le mécanisme de détermination de l’intérêt public pertinent sur une recommandation donnée sera le cadre de procédure de l’intérêt public mondial que le Conseil gère pour l’exercice fiscal 2021. Le cadre sera uniquement utilisé comme outil d’évaluation pour les recommandations ayant des considérations d’intérêt public.

      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 qui ne nécessite pas de consultation publique, mais il convient de noter que le rapport final des recommandations de politique et le cadre de l’ODP ont fait l’objet de commentaires publics, comme il a été mentionné ci-dessus. De plus, l’ODP lui-même est un processus ouvert et transparent et il est prévu que le public pourra fournir des commentaires et leur rétroaction tout au long de l’étape de conception.

    4. Divers

      Aucune résolution n'a été adoptée.


1 Recommandations 18, 24 et 25

2 Recommandation 29

3 Recommandations 24, 25, 29

4 Recommandation 29

5 Recommandation 29

6 Recommandation 27

7 Recommandation 26

8 Recommandations 8, 9, 10

9 Recommandation 16

10 Recommandation 3

11 Recommandations 4, 5

12 Recommandation 29

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