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 du Conseil d'administration approuvées | Réunion ordinaire du Conseil d'administration de l'ICANN 16 septembre 2018

  1. Ordre du jour approuvé :
    1. Approbation du procès-verbal
    2. Désignation au sein du Comité consultatif sur la sécurité et la stabilité
    3. Convocation de la première révision des fonctions IANA relatives au nommage
    4. Renouvellement du contrat de registre du TLD .coop
    5. Nomination du président et du président élu du comité de nomination 2019
  2. Ordre du jour principal :
    1. Avis du GAC : Communiqué de Panama (juin 2018)
    2. Stratégie du serveur racine
    3. Procéder au roulement KSK
    4. Examen plus approfondi des candidatures de .AMAZON
    5. Divers

 

  1. Ordre du jour approuvé :

    1. Approbation du procès-verbal

      Il est résolu (2018.09.16.01) que le Conseil d’administration approuve les procès-verbaux des réunions du Conseil d'administration de l'ICANN du 18 juillet et du 21 août 2018.

    2. Désignation au sein du Comité consultatif sur la sécurité et la stabilité

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

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

      Il est résolu (2018.09.16.02) que le Conseil d’administration nomme David Piscitello au SSAC pour un mandat prenant cours immédiatement après l’approbation par le Conseil d’administration et s’achevant le 31 décembre 2020.

      Fondements de la résolution 2018.09.16.02

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

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

      Tout au long de ses 40 ans de carrière, David a acquis une grande expérience dans le domaine du réseautage, de la sécurité, des protocoles Internet et des services. David a été membre du personnel de l'ICANN entre 2005 et 2018, plus récemment en tant que vice-président en charge de la sécurité et de la coordination des TIC, et a soutenu le travail du SSAC pendant de nombreuses années. Il mena des recherches et écrivit des rapports techniques et consultatifs pour le compte du comité, travaillant en collaboration avec le président suivant, Dr. Stephen Crocker. Il a contribué de manière positive à de nombreuses discussions du SSAC.

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

    3. Convocation de la première révision des fonctions IANA relatives au nommage

      Attendu que, les statuts constitutifs de l'ICANN exigent que « Le Conseil d’administration, ou un comité approprié, doit réaliser des révisions spécifiques et/ou périodiques (chaque révision, un « IFR ») de l'exercice par les PTI des fonctions de l'IANA relatives au nommage par rapport aux conditions contractuelles établies dans le contrat des fonctions IANA relatives au nommage ainsi que le SOW (énoncé des travaux) des fonctions IANA relatives au nommage devant être effectuées par une équipe en charge de la révision des fonctions IANA (« IFRT ») créée conformément au chapitre 18 des statuts constitutifs de l'ICANN. »

      Attendu que, l'article 18.2 des statuts constitutifs de l'ICANN exige que le premier IFR périodique soit convoqué au plus tard le 1er octobre 2018.

      Attendu que, l'article 18.7 des statuts constitutifs de l'ICANN précise la composition de l'IFRT et exige que les membres et agents de liaison de l'équipe de révision soient nommés conformément aux règles et procédures des organisations qui procèdent à la nomination.

      Attendu que, certaines des organisations qui procèdent aux nominations ont déjà désigné des membres et agents de liaison de l'IFRT.

      Attendu que, l'article 18.8.c des statuts constitutifs de l'ICANN exige que les organisations qui procèdent aux nominations pour les membres et agents de liaison de l'IFRT travaillent ensemble pour parvenir à une équipe de révision équilibrée en termes de diversité (fonctionnelle, géographique et culturelle) et de compétences, et cherchent à élargir le nombre de personnes participant aux différentes révisions ; à condition que l'équipe de révision inclut des membres de chaque région géographique de l'ICANN, et la ccNSO et le groupe des représentants des opérateurs de registre ne doivent pas nommer plusieurs membres qui sont citoyens de pays provenant de la même région géographique.

      Attendu que, l'article 18.8.e des statuts constitutifs de l'ICANN exige que le Conseil d’administration nomme un membre du personnel de l'ICANN en tant que point de contact afin de favoriser des voies de communication officielles entre l'équipe de révision et l'ICANN.

      Attendu que, l'article 18.3 des statuts constitutifs de l'ICANN précise la portée et les responsabilités de l'équipe de révision.

      Attendu que, l'article 18.3.j des statuts constitutifs de l'ICANN exige que l'équipe de révision « identifie le processus ou les autres domaines d'amélioration de la performance des fonctions de l'IANA relatives au nommage en vertu du contrat des fonctions IANA relatives au nommage et du SOW des fonctions IANA relatives au nommage ainsi que la performance du CSC (comité permanent de clients) et de l'EC (communauté habilitée) dès lors qu'elle se rapporte à la surveillance des PTI. »

      Attendu que, l'article 18.11 des statuts constitutifs de l'ICANN exige que l'organisation de l'ICANN apporte un soutien opérationnel et administratif nécessaire pour que l'équipe de révision s'acquitte de ses responsabilités, notamment en fournissant et en facilitant une participation à distance pour l'ensemble des réunions.

      Il est résolu (2018.09.16.03) que le Conseil d’administration, par la présente, convoque sa première révision des fonctions de l'IANA relatives au nommage et demande au président-directeur général de l'ICANN, ou son (ses) représentant(s), de s'acquitter de ses responsabilités, notamment en fournissant et en facilitant une participation à distance pour l'ensemble des réunions.

      Il est résolu (2018.09.16.04) que le Conseil d’administration demande à ce que les organisations restantes qui procèdent aux nominations achèvent leur processus de désignation des membres et agents de liaison. En outre, les organisations qui procèdent aux nominations doivent collaborer afin de s'assurer que l'équipe de révision respecte les exigences de diversité de l'article 18.8.c des statuts constitutifs de l'ICANN.

      Il est résolu (2018.09.16.05) que l'IFR doit être réalisé conformément au champ d'application de l'article 18.3 des statuts constitutifs de l'ICANN.

      Il est résolu (2018.09.16.06) que pour remplir les obligations du Conseil d’administration de nommer un membre du personnel de l'ICANN en tant que point de contact afin de favoriser des voies de communication officielles entre l'équipe de révision et l'ICANN, le Conseil d'administration demande au président-directeur général de l'ICANN de désigner le membre du personnel approprié pour cette fonction.

      Fondements des résolutions 2018.09.16.03 à 2018.09.16.06

      Le Conseil d’administration convoque la première révision périodique des fonctions IANA relatives au nommage (IFR) afin de respecter les exigences de l'article 18.2 des statuts constitutifs de l'ICANN selon lesquelles la première IFR périodique doit être réalisée au plus tard le 1er octobre 2018. L'IFR est un nouveau mécanisme de responsabilité créé dans le cadre de la transition du rôle de supervision des fonctions IANA afin de garantir que les PTI respectent les besoins et attentes de leurs clients en respectant les conditions contractuelles établies dans le contrat des fonctions IANA relatives au nommage et l'énoncé des travaux des fonctions IANA relatives au nommage [PDF, 626 KB].

      Des mesures ont été déjà prises en nommant des organisations pour désigner les membres et agents de liaison de l'équipe de révision. Le Conseil d’administration demande à ce que les organisations restantes qui procèdent aux nominations achèvent leur processus de désignation des membres et agents de liaison afin que l'équipe de révision composée puisse commencer son travail. Pour garantir que la composition finale de l'équipe de révision respecte les exigences des statuts constitutifs de l'ICANN, le Conseil d’administration demande à ce que les organisations qui procèdent aux nominations collaborent afin de finaliser la composition de l'équipe de révision, conformément à l'article 18.8.c des statuts constitutifs de l'ICANN. Il a été demandé à l'organisation de l'ICANN de désigner un membre du personnel en tant que point de contact afin de soutenir la communication entre l'équipe de révision et l'organisation de l'ICANN.

      Le Conseil d’administration comprend que la portée de l'IFR est bien définie à l'article 18.3 des statuts constitutifs de l'ICANN. Il est possible qu'il ait un double emploi avec la révision actuelle de l'efficacité du CSC, requise par l'article 17.3 des statuts constitutifs, qui énonce : « L'efficacité du CSC doit être examinée deux ans après la première réunion du CSC … Le mode de révision sera déterminé par la ccNSO et la GNSO. » La révision de l'efficacité du CSC doit commencer le 6 octobre 2018, deux ans après la première réunion du Comité permanent de clients. Il y a un double emploi potentiel par rapport à l'équipe de révision IFR concernant la question « Identifier le processus ou les autres domaines d'amélioration de la performance … du CSC … dans le cadre de la surveillance des PTI. » Pour garantir une utilisation efficace et efficiente des ressources de la communauté, le Conseil d’administration encourage l'équipe de révision IFR à considérer en tant que commentaire vis-à-vis de son travail toutes futures conclusions, recommandations, ou méthodologie et critères que la GNSO et la ccNSO adoptent et qui concernent la révision de l'efficacité du Comité permanent de clients.

      Le plan opérationnel et budget annuel de l'ICANN pour l'exercice fiscal 2019 approuvé par le Conseil d’administration contient des ressources prévues pour soutenir l'IFR.

      Cette action relève de la mission de l’ICANN étant donné qu'elle soutient l'ICANN s'acquittant d'une partie de sa mission relative à la coordination de l'allocation et attribution de noms au sein de la zone racine, et soutient directement l'intérêt public. Le Conseil d’administration prend cette mesure conformément aux exigences des statuts constitutifs de l'ICANN. Aucune période de consultation publique n'est nécessaire pour informer de l'action du Conseil d’administration.

    4. Renouvellement du contrat de registre du TLD .coop

      Attendu que, l'opérateur de registre de .coop, DotCooperation LLC, dispose d'un accord avec l'organisation de l'ICANN qui expire le 22 novembre 2018.

      Attendu que, l'organisation de l'ICANN a entamé des négociations avec l'opérateur de registre afin de développer un accord de renouvellement et d'initier une période de consultation publique allant du 11 juin 2018 au 27 juillet 2018 concernant le contrat de renouvellement de registre du TLD .coop proposé, en recevant les commentaires de deux organisations. Un résumé et une analyse des commentaires ont été fournis au Conseil d’administration.

      Attendu que, le Conseil d’administration a examiné les commentaires et a déterminé qu’aucune révision du contrat de renouvèlement de registre de .coop proposé n'était nécessaire après avoir pris en considération les commentaires.

      Attendu que, le contrat de renouvellement de registre de .coop inclut de nouvelles dispositions conformes aux conditions comparables du contrat de registre des nouveaux gTLD.

      Il est résolu (2018.09.16.07) que le renouvèlement du contrat de registre de .coop proposé est approuvé, et le Président-directeur général, ou son représentant, est autorisé à prendre les mesures nécessaires comme cela lui semblera approprié pour conclure et mettre en œuvre ledit contrat.

      Fondements de la résolution 2018.09.16.07

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

      L’ICANN et DotCooperation LLC ont conclu un contrat de registre le 1er juillet 2007 pour l’exploitation du domaine de premier niveau .coop. Le contrat de registre actuel du TLD .coop expire le 22 novembre 2018 et l'opérateur de registre a le droit à un renouvèlement présomptif du contrat existant. Le contrat de renouvellement de registre proposé a été publié pour consultation publique du 11 juin 2018 au 27 juillet 2018. À l’heure actuelle, le Conseil d’administration approuve le contrat de renouvellement de registre proposé pour la poursuite de l’exploitation du TLD .coop par DotCooperation LLC.

      Quelle est la proposition à l’étude ?

      Le projet de renouvellement du contrat de registre .coop est basé sur l’actuel contrat de registre .coop avec des modifications convenues par l’ICANN et par DotCooperation LLC ; il comprend certaines dispositions d’un contrat de registre de base des nouveaux gTLD.

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

      Du 11 juin 2018 au 27 juillet 2018, l’organisation de l’ICANN a mené une période de consultation publique sur la proposition de contrat de renouvellement de registre de .coop. En outre, l’ICANN a lancé des négociations bilatérales avec l’opérateur de registre pour convenir de l’ensemble des termes à inclure dans la proposition de contrat de renouvellement de registre de .coop, publié pour consultation publique.

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

      Le forum de commentaire public sur la proposition de contrat de renouvellement de registre de .coop s’est achevé le 27 juillet 2018, l’organisation ICANN ayant reçu deux (2) commentaires. Les commentaires peuvent se résumer dans les deux catégories énumérées ci-dessous.

      1. L'inclusion de mécanisme de protection des droits (RPM) des nouveaux gTLD et des sauvegardes comme les engagements d'intérêt public au sein des renouvellements de contrat de registre de gTLD historiques : un intervenant a appuyé l’inclusion de certains mécanismes de protection des droits au sein du contrat de renouvellement proposé, comme le système uniforme de suspension rapide (URS), la procédure de règlement de litiges après délégation relatifs à des marques déposées et les engagements d’intérêt public (PIC) (c.-à-d. les sauvegardes) contenus dans le contrat de registre de base des nouveaux gTLD. Inversement, un commentateur a manifesté sa préoccupation quant à l’inclusion des mécanismes de protection de droits des nouveaux gTLD dans le cadre des contrats historiques. Ils ont affirmé que ces dispositions ne devaient pas être ajoutées à la suite de négociations de contrat, mais qu’elles devraient plutôt être abordées à travers le processus d’élaboration de politiques (« PDP ») de la GNSO.
      2. Le processus de négociation pour le renouvellement du contrat de registre proposé pour .coop et les négociations des contrats de registre des gTLD historiques en général : un commentateur s'est réjouit du transfert de .coop vers des spécifications techniques et opérationnelles du contrat de registre de base des gTLD, mais a été déçu de constater que .COM et .NET n'ont pas mis à jour leurs conditions. Un autre commentateur a réitéré son opposition au processus de négociation, déclarant que le personnel de la GDD « établit de manière unilatérale un nouveau statu quo pour les contrats de registre » et substitut son « jugement (GDD) par l'élaboration d'une politique de la GNSO » en outrepassant ses « pouvoirs les sauvegardes prévues pour préserver la transparence et l'inclusion auprès de la communauté multipartite. »

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

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

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

      Le Conseil d’administration a soigneusement examiné les commentaires publics reçus au sujet du contrat de renouvellement de registre de .coop, ainsi que le résumé et l’analyse de ces commentaires. Le Conseil d’administration a également examiné les termes convenus par l’opérateur de registre dans le cadre des négociations bilatérales avec l’organisation de l’ICANN.

      Bien que le Conseil reconnaisse les préoccupations exprimées par certains membres de la communauté concernant l’inscription de l’URS dans le contrat de renouvellement de registre proposé, le Conseil note que cette inclusion dépend des négociations bilatérales entre l’ICANN et l’opérateur de registre, lorsque l’opérateur de registre a manifesté son intérêt de renouveler son contrat de registre pour se conformer aux dispositions du contrat de registre des nouveaux gTLD.

      Le Conseil d’administration note que l’URS a été recommandé par l’équipe chargée de l’élaboration de recommandations pour la mise en œuvre (IRT) comme un mécanisme de protection des droits (RPM) obligatoire pour tous les nouveaux gTLD. Il a été demandé à la GNSO de donner son point de vue concernant les mécanismes de protection des droits recommandés (qui comprenaient l’URS) et leur cohérence avec la politique d’introduction des nouveaux gTLD proposée par la GNSO et s’ils constituaient une option appropriée et effective pour atteindre les principes et les objectifs fixés par la GNSO. L’équipe de révision des problèmes spécifiques aux marques commerciales (STI) a examiné cette question et a conclu que « l’utilisation de l’URS doit être un RPM requis pour tous les nouveaux gTLD ». Autrement dit, la GNSO a déclaré que l’URS n’était incompatible avec aucune de ses recommandations de politique existantes.

      Bien que l’URS ait été développé et peaufiné par le processus décrit ici, y compris une révision publique et une discussion au sein de la GNSO, il n’a pas été adopté comme une politique consensuelle et l’ICANN n’a aucune possibilité de le rendre obligatoire pour des TLD autres que les candidats aux nouveaux gTLD ayant déposé leur candidature au cours de la série de nouveaux gTLD de 2012.

      Par conséquent, l’approbation du contrat de renouvellement de registre par le Conseil d’administration n’est pas une motion pour rendre l’URS obligatoire pour les TLD historiques, et il serait inapproprié de le faire. Dans le cas de .coop, l’inclusion de l’URS a été développée dans le cadre de la proposition au cours des négociations bilatérales entre l’opérateur de registre et l’ICANN.

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

      L’approbation du contrat de renouvellement de registre de .coop par le Conseil d’administration offre des avantages techniques et opérationnels. Par exemple, le contrat de renouvellement de registre de .coop inclut les mêmes services approuvés que le contrat de registre de base des gTLD plus le contenu de la zone TLD - du service du DNS, ainsi que le répertoire de domaines actifs. De plus, DotCooperation LLC devra suivre les mêmes engagements d'intérêt public pour .coop que ceux du contrat de registre de base des gTLD. Cette décision est prise dans l’intérêt public dans la mesure où elle contribue à l’engagement de l’organisation de l’ICANN de renforcer la sécurité, la stabilité et la résilience du DNS.

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

      Aucun impact financier significatif n’est à prévoir suite à la signature du contrat de renouvellement de registre de .coop.

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

      Le contrat de renouvellement de registre de .coop n’est pas censé créer des problèmes liés à la sécurité, la stabilité ou la résilience du DNS. Le contrat de renouvellement de registre de .coop contient des termes destinés à permettre une action plus rapide dans le cas de certaines menaces à la sécurité ou la stabilité du DNS, mais présente aussi d’autres avantages techniques pour assurer la cohérence dans l’ensemble des registres et un environnement plus prévisible pour les utilisateurs finaux.

    5. Nomination du président et du président élu du comité de nomination 2019

      Attendu que le Comité de gouvernance du Conseil d'administration (BGC) a examiné les Manifestations d’intérêt des candidats pour les postes de président et de président élu du Comité de nomination 2019 (« NomCom »), a examiné les résultats de l'examen des pairs des dirigeants du NomCom 2018 et a mené des entretiens avec les candidats.

      Attendu que, le BGC a recommandé que J. Damon Ashcraft soit désigné au poste de président du NomCom 2019, et Cheryl Ann Miller soit nommée au poste de présidente élue du NomCom 2019.

      Il est résolu (2018.09.16.08) que le Conseil d’administration nomme par la présente J. Damon Ashcraft président du Comité de nomination 2019 et Cheryl Ann Miller présidente élue du Comité de nomination 2019.

      Fondements de la résolution 2018.09.16.08

      Les statuts constitutifs de l’ICANN exigent que le Conseil nomme le président du Comité de nomination (NomCom) et le président élu du NomCom. Voir statuts constitutifs de l'ICANN, Chapitre 8, article 8.1. Le Conseil d’administration a délégué la responsabilité de recommander des candidats au poste de président et de président élu du NomCom pour leur approbation par le Conseil au comité de gouvernance du Conseil (BGC). (Voir Charte du BGC sur http://www.icann.org/en/committees/board-governance/charter.htm.) Le BGC a publié un appel à Manifestations d'intérêt (EOI) le 13 juin 2018 demandant les EOI avant le 2 juillet 2018 (voir https://www.icann.org/news/announcement-2-2018-06-13-en). Le BGC a reçu et examiné plusieurs EOI, a supervisé une révision des pairs des dirigeants du NomCom 2018 et a mené des entretiens avec les candidats avant de formuler ses recommandations. Le Conseil a examiné et est d'accord avec la recommandation du BGC pour les postes de président et de président élu du NomCom 2019. Le Conseil d’administration tient à remercier tous ceux qui ont manifesté leur intérêt à faire partie de l'équipe de dirigeants du NomCom 2019.

      La nomination d’un président et d’un président élu NomCom identifiés grâce à un processus de manifestation d’intérêt, et des entretiens de candidats est dans l’intérêt public, car elle influe de manière positive sur la transparence et la responsabilité de l’ICANN. Elle est également pleinement conforme à la mission de l’ICANN.

      L’adoption de la recommandation du BGC n’a aucune répercussion financière sur l’ICANN qui n’ait pas été prévue et n’aura pas d’impact négatif sur la sécurité, la stabilité et la résilience du système des noms de domaine.

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

  2. Ordre du jour principal :

    1. Avis du GAC : Communiqué de Panama (juin 2018)

      Attendu que le Comité consultatif gouvernemental (GAC) s’est réuni lors de l’ICANN62 à Panama City au Panama et a émis un avis adressé au Conseil d’administration de l’ICANN dans un communiqué [PDF, 576 KB] en date du 28 juin 2018 (« Communiqué de Panama »).

      Attendu que, le communiqué de Panama a fait l'objet d'un échange entre le Conseil d’administration et le GAC le 31 juillet 2018.

      Attendu que, dans une lettre [PDF, 160  KB] du 27 juillet 2018, adressée au Conseil d’administration, le conseil de la GNSO a fourni des commentaires concernant l’avis du communiqué de Panama correspondant aux domaines génériques de premier niveau pour informer le Conseil d’administration et la communauté des activités liées aux politiques des gTLD pouvant se rapporter à l’avis donné par le GAC.

      Attendu que, le Conseil d’administration a élaboré une itération de la fiche de suivi pour répondre à l’avis du GAC émis dans le communiqué de Panama, en tenant compte de l’échange qui s’est effectué entre le Conseil d’administration et le GAC ainsi que des informations fournies par le conseil de la GNSO.

      Il est résolu (2018.09.16.09) que le Conseil d’administration adopte la fiche de suivi intitulée « Avis du GAC – Communiqué de Panama : actions et mises à jour (16 septembre 2018) » [PDF 294 KB] en réponse aux éléments de l’avis du GAC émis dans le communiqué de Panama.

      Fondements de la résolution 2018.09.16.09

      Le chapitre 12, article 12.2(a)(ix) des statuts constitutifs de l’ICANN autorise le GAC à « soumettre directement des sujets au Conseil d’administration, par le biais d’un commentaire ou d’un avis préalable, ou en recommandant une mesure spécifique, l’élaboration d’une nouvelle politique ou la révision des politiques actuelles, » Dans son communiqué de Panama (28 juin 2018) le GAC a présenté son avis au Conseil d’administration sur : le Règlement général sur la protection des données (RGPD) et le WHOIS, la protection des noms et acronymes des organisations intergouvernementales (OIG) dans les gTLD, et des codes pays à deux caractères au second niveau. Le GAC a également donné un suivi de l'avis précédent sur les éléments reportés concernant le RGPD et le WHOIS, à partir du communiqué de San Juan. Les statuts constitutifs de l 'ICANN prévoient que le Conseil tienne compte de l'avis du GAC en matière de politique publique pour la formulation et l'adoption de politiques. Au cas où le Conseil d'administration déciderait d’agir contrairement à l’avis du GAC, il est tenu d'en avertir ce dernier en indiquant les raisons pour lesquelles il a décidé de ne pas suivre son avis. Tout avis du GAC approuvé par consensus global du GAC (comme défini dans les statuts constitutifs) ne peut être rejeté que par un vote d’au moins 60 % du Conseil d’administration, et le GAC et le Conseil d’administration doivent ensuite essayer de trouver une solution réciproquement acceptable, en toute bonne foi, en temps voulu et de manière efficace.

      Le Conseil d’administration prend la décision aujourd'hui d'accepter l'ensemble des éléments en lien avec le RGPD et le WHOIS, ainsi que les protections des OIG et reportera l'examen des deux (2) éléments de l'avis en lien avec les codes pays à deux caractères au second niveau qui doivent faire l'objet de plus de discussions avec le GAC. Le Conseil d’administration décidera si d’autres actions sont nécessaires après ces discussions. Les décisions du Conseil d’administration sont décrites dans la fiche de suivi datée du 16 septembre 2018 [PDF, 294 KB].

      En adoptant sa réponse à l’avis du GAC émis dans le communiqué de Panama, le Conseil d’administration a examiné divers documents, y compris, mais sans s’y limiter, les documents suivants :

      L’adoption de l’avis du GAC comme fourni dans la fiche de suivi aura un impact positif sur la communauté, car cela aidera à résoudre les questions posées par l’avis du GAC sur les gTLD ainsi que d’autres problématiques. Aucun impact financier associé à l’adoption de cette résolution n’est prévu. L'approbation de la résolution n'aura pas d'impact sur la sécurité, la stabilité ou la résilience du DNS. L'examen par le Conseil d’administration de l'avis du GAC représente un intérêt public, compte tenu du rôle du GAC comme conseiller en matière de politique publique, et est également conforme à la mission de l’ICANN.

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

    2. Stratégie du serveur racine

      Attendu que, l'approche actuelle de l'ICANN quant au déploiement d'un grand nombre de serveurs individuels (« L-Singles ») et un petit nombre de grandes installations multi-serveurs (« L-Clusters ») a, à ce jour, été une défense appropriée face aux attaques sur le système du serveur racine.

      Attendu que, de nombreuses personnes au sein de la communauté technique considèrent que le système de serveur racine tel qu'il est actuellement déployé risque de ne pas être en mesure de maintenir le rythme face à l'augmentation des attaques et, est ainsi de plus en plus vulnérable face aux attaques, qu'elles soient réalisées par des entités malveillantes ou le résultat de mauvaise configuration, utilisation ou de bugs.

      Attendu que, une attaque réussie contre le système de serveur racine engendrerait un sérieux risque quant à la sécurité et à la stabilité du DNS et poserait un risque existentiel potentiel pour ICANN.org, en tant que facilitateur de la coordination du fonctionnement et de l'évolution du système de serveur racine du DNS.

      Attendu que, une stratégie complète visant à réduire les effets des attaques contre le système de serveur racine devrait prendre en compte plusieurs approches qui exploitent et améliorent les pratiques de l'opérateur de serveur racine existant, intègrent de nouvelles avancées et méthodologies technologiques, et accroissent l'observation et la surveillance du système dans son ensemble.

      Il est résolu (2018.09.16.10) que le Conseil d’administration demande à l'organisation de l'ICANN, en tant qu'opérateur du serveur racine/serveur racine L géré par l'ICANN (IMRS), de travailler avec la communauté afin de finaliser une stratégie pour réduire les effets des attaques sur l'IMRS, et, une fois finalisée, le président-directeur général devra entamer la mise en œuvre de cette stratégie en développant un projet avec des délais et des dépenses éventuelles pour une révision et une approbation ultérieures par le Conseil d'administration.

      Fondements de la résolution 2018.09.16.10

      Au niveau de l'architecture, la racine de l'espace de noms du DNS sert de point unique par lequel la recherche d'un nom doit passer au moins une fois, au sein de cet espace de noms. Cela pose le risque d'un « point de défaillance unique » pour l'ensemble du DNS. À ce jour, ce risque a été atténué en « durcissant » l'infrastructure qui offre le service de noms pour cette racine. Ce renforcement a généralement été mis en œuvre en développant la capacité, que ce soit en augmentant la bande passante des serveurs de noms ou via l'utilisation d'un routage anycast, déployant davantage de serveurs de noms qui répondent aux questions pour la zone racine à travers le monde.

      Cependant, avec l'évolution continue des technologies Internet et des équipements en particulier, le déploiement de l'Internet des objets et une meilleure capacité des réseaux à travers le monde, associés avec le manque regrettable de sécurité au sein de ces appareils et réseaux, les attaquants ont plus de pouvoir pour paralyser l'infrastructure Internet. Plus précisément, l'augmentation de la capacité à réaliser des attaques risque de dépasser le pouvoir de l'opérateur de serveur racine à augmenter la capacité de défense. Bien qu'il est toujours nécessaire continuer à étendre les capacités de défense à court terme, les perspectives à long terme de l'approche traditionnelle paraissent sombres.

      En outre, avec le manque de déploiement de la validation du DNSSEC, les réponses du système de serveur racine continuent d'être exposées au risque d'attaques à l'intégrité. De la même manière, suite aux messages du DNS supposés être envoyés non-chiffrés, les utilisateurs du système de serveur racine (autrement dit, les résolveurs) font l'objet d'attaques relatives à la confidentialité. Même si ces attaques ne sont pas forcément nouvelles, la dépendance de plus en plus croissante au DNS et par conséquent, au système de serveur racine, suggère qu'une nouvelle stratégie doit être envisagée pour réduire l'effet de ces attaques contre le système de serveur racine.

      Pour répondre à cette exigence, l'organisation de l'ICANN a élaboré une stratégie complète pour le serveur racine géré par l'ICANN, qui en plus d'étendre les mécanismes de protection traditionnels existants, consiste à éventuellement tirer profit de l'infrastructure commerciale du cloud et à décentraliser le service racine, à encourager le déploiement de la validation du DNSSEC, à faciliter le développement d'améliorations relatives à la confidentialité pour le DNS, à promouvoir un engagement accru avec la communauté de l'opérateur de serveur racine ainsi que les opérateurs résolveurs, et à améliorer la surveillance du système racine.

      Cette stratégie devrait être finalisée avec la coopération de la communauté, et en particulier le RSSAC. Une fois que la mise en place de la stratégie sera finalisée, il s'agira de commencer à développer un projet détaillé qui inclut des délais, des étapes importantes, et des dépenses anticipées. Une fois le plan de projet terminé, il devra être transmis au Conseil d’administration pour examen et approbation.

      La résolution visant à finaliser la stratégie racine et à développer le plan de projet détaillé nécessitera des ressources de personnel qui sont comprises dans le budget actuel de l'exercice fiscal 2019, aucune demande de budget supplémentaire n'est prévue.

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

    3. Procéder au roulement KSK

      Attendu que, l'organisation de l'ICANN s'est engagé à effectuer le roulement de la KSK « après 5 ans de fonctionnement », tel que documenté dans la « Déclaration de pratique des DNSSEC pour l’opérateur de la KSK de la zone racine ».

      Attendu que, l'organisation de l'ICANN a sollicité une équipe de conception pour préparer un ensemble de plans de mise en œuvre du roulement KSK.

      Attendu que, dans le cadre de la mise en œuvre de ce plan, l'organisation de l'ICANN a collecté certaines données qui ont soulevé des questions concernant l'impact du roulement KSK sur les utilisateurs finaux.

      Attendu que, l'organisation de l'ICANN a suspendu le roulement le 27 septembre 2017 pour comprendre les données collectées.

      Attendu que, l'organisation de l'ICANN, en consultation avec les membres de la communauté technique du DNS, a appris davantage de choses sur les données qui ont été collectées.

      Attendu que, l'organisation de l'ICANN a extrapolé l'impact probable du roulement de la KSK.

      Attendu que, l’organisation de l’ICANN a mis à jour les documents de planification et créé un « Plan actualisé de continuation du roulement de la KSK de la zone racine. »

      Attendu que, le Conseil d’administration a reçu des commentaires du RSSAC, du RZERC et du SSAC sur les documents de planification et ces commentaires indiquent que ces organismes n'ont trouvé aucune raison de ne pas poursuivre le plan actualisé pour le roulement de la KSK et certaines parties de la communauté, en particulier celles au sein de la communauté technique du DNS, ont fait part de leurs inquiétudes concernant l'impact d'un report du roulement de la KSK, en particulier du fait que : ne pas poursuivre le roulement de la KSK ne répondrait pas aux attentes de la communauté ; n'est pas justifié par les données obtenues à ce jour ; pourrait entrainer une confusion ou une perte de l'attention de la communauté vis-à-vis du message relatif au DNSSEC ; pourrait encourager à penser que le roulement de la KSK n'aura jamais lieu car la KSK actuelle risquerait d'être inscrite dans un système difficile à changer ; et/ou réduire la confiance dans le DNSSEC en tant que système fiable.

      Attendu que, le nombre prévu d'utilisateurs finaux impactés de manière négative par le roulement de la KSK est très inférieur au seuil spécifié par la communauté de 0,5 % d'utilisateurs finaux, et l'identification ainsi que la compensation de cet impact négatif devraient être facilités pour les personnes concernées.

      Attendu que, l'ICANN estime que les bénéfices, pour la communauté, de procéder au roulement dans les temps, l'emportent sur les difficultés à quantifier les risques.

      Il est résolu (2019.09.16.11) que le Conseil d’administration demande à l'organisation de l'ICANN de procéder au roulement de la KSK, comme décrit dans le « Plan actualisé de continuation du roulement KSK de la zone racine. »

      Fondements de la résolution 2018.09.16.11

      Le plan de roulement de la KSK de la zone racine du DNS a été mis en pause le 27 septembre 2017 suite à des données inattendues, en particulier des données reçues après les mises en œuvre précoces du RFC 8145, qui ont soulevé des questions pour savoir si les résolveurs validant étaient bien préparés pour le roulement qui était prévu pour le 11 octobre 2017. L'organisation de l'ICANN, entre autres, a analysé les données et a déterminé qu'il n'y avait qu'un petit pourcentage de résolveurs qui étaient susceptibles d'être impactés de manière négative par le roulement de la KSK, toutefois il a également été établi que les données n'étaient pas appropriées pour déterminer le nombre d'utilisateurs finaux impactés.

      Suivant le résultat de cette recherche, l’ICANN org a demandé à la communauté technique de recommander un plan d’action. Même s'il y a eu peu de contestations, la majorité des commentaires de la communauté reposait sur le fait que l'organisation de l'ICANN devait poursuivre la procédure de roulement de la KSK de manière ordonnée.

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

      La réponse consensuelle de la communauté reçue au 2 avril 2018 était en faveur du plan publié, avec quelques suggestions pour une sensibilisation supplémentaire que l'organisation de l'ICANN a déjà réalisé. En se fondant sur la réponse de la communauté, l’organisation de l'ICANN a créé la « Plan actualisé de continuation du roulement de la KSK de la zone racine » et a également examiné les documents du plan de roulement initial de la KSK pour montrer quelles mesures avaient déjà été prises, et quelles mesures devaient encore être prises aux dates révisées. Ces documents de plan sont disponibles sur <Https://www.icann.org/resources/pages/ksk-rollover-operational-plans>.

      Les contributions de la communauté concernant le plan proposé provenaient d’une variété de comités consultatifs, groupes de parties prenantes, d’organisations et de particuliers. Le Conseil d’administration a demandé des commentaires explicites du RSSAC, du RZERC et du SSAC concernant le plan proposé. Voici les réponses à la demande du Conseil d’administration :

      L'organisation de l'ICANN a pris en considération les conclusions tirées de ces trois réponses des comités consultatifs et en particulier celles qui montraient une réticence vis-à-vis de la procédure de roulement. Dans l'ensemble, l'organisation de l'ICANN interprète ces conclusions comme pour indiquer que les risques de perturbation pour un tout petit nombre d'utilisateurs finaux qui ne se sont jamais préparés à un roulement, sont inférieurs aux avantages que créé le roulement de la KSK à l'heure actuelle et de manière quotidienne à l'avenir. Le document de référence joint liste également les principales objections à la procédure connues par l'organisation de l'ICANN ainsi que les réponses à ces objections.

      Le roulement de la KSK n’est pas censé avoir d’impact financier sur l’ICANN n’ayant pas déjà été intégré aux ressources budgétaires nécessaires pour un soutien continu au roulement de la KSK de la zone racine.

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

      Il s’agit d’une fonction administrative et organisationnelle qui ne nécessite pas de consultation publique au-delà de ce qui a déjà été requis.

    4. Examen plus approfondi des candidatures de .AMAZON

      Attendu que, en 2012, Amazon EU S.à r.l. La société Amazon a déposé une candidature pour .AMAZON et deux versions du nom de domaine internationalisé (IDN) pour le mot 'Amazon' (« les candidatures .AMAZON »). Les candidatures .AMAZON ont fait l'objet d'une alerte précoce du GAC (Comité consultatif gouvernemental) déposée par les gouvernements du Brésil et du Pérou (avec l'appui de la Bolivie, de l'Équateur et de la Guyane), qui a averti la société Amazon que ces gouvernements avaient une inquiétude de politique publique concernant les chaînes faisant l'objet des candidatures.

      Attendu que, en juillet 2013, dans le communiqué de Durban, les candidatures .AMAZON étaient l'objet de l'avis consensuel du GAC qui déclarait qu'elles ne devraient pas être retenues. Le 14 mai 2014, le Comité du programme des nouveaux gTLD a accepté cet avis et a demandé à l'organisation de l'ICANN de ne pas donner suite aux candidatures .AMAZON.

      Attendu que, en octobre 2015, la société Amazon a soumis une proposition aux états membres de l’organisation du traité de coopération amazonienne (ACTO) afin de parvenir à une solution qui pourrait bénéficier aux deux parties. Cette proposition a été rejetée.

      Attendu que, en juillet 2017, la société Amazon prévalait dans un processus de révision indépendante (IRP) déposé en 2016. La déclaration de l'IRP recommandait au Conseil d’administration de « réévaluer dans de brefs délais les candidatures d’Amazon » et de « rendre un jugement objectif et indépendant statuant sur l’existence ou non de motifs d’intérêts publics fondés qui justifieraient le rejet des candidatures d’Amazon. »

      Attendu que, le 29 octobre 2017, le Conseil d’administration a demandé au GAC des informations supplémentaires concernant l'avis du GAC sur les candidatures .AMAZON. Dans son communiqué de Abu Dhabi de novembre 2017, le GAC a conseillé au Conseil d’administration de « continuer à faciliter les négociations entre les états membres de l’organisation du traité de coopération amazonienne (ACTO) et la société Amazon, en vue de parvenir à une solution mutuellement acceptable pour permettre l'utilisation du .amazon comme nom de domaine de premier niveau. »

      Attendu que, le 4 février 2018, le Conseil d’administration a accepté l'avis du GAC et a demandé au président-directeur général de l'ICANN « de faciliter les négociations entre les états membres de l’organisation du traité de coopération amazonienne (ACTO) et la société Amazon. »

      Attendu que, la société Amazon a présenté au GAC et à l'ACTO une nouvelle proposition en octobre 2017. Après que la société Amazon a soumis une proposition actualisée en février 2018, les états membres de l'ACTO ont émis une déclaration le 5 septembre 2018, déclarant que « … les pays de la région amazonienne ont conclu que la proposition ne constitue pas un fondement approprié pour sauvegarder leurs droits immanents concernant la délégation du TLD '.amazon'. » Les états membres de l'ACTO ont également déclaré que la délégation de .AMAZON « exige le consentement des pays de la région amazonienne » et qu'ils « ont le droit de participer à la gouvernance du TLD .amazon. »

      Attendu que, les états membres de l'ACTO ont affirmé en octobre 2017, « … que le nom Amazon, dans toutes les langues, représente le patrimoine culturel et l'identité des pays de la région amazonienne, et que son utilisation comme nom de domaine de premier niveau, sauf accord contraire des pays de la région, devrait être réservée à la promotion des intérêts et des droits des peuples d'Amazonie ainsi que leur inclusion dans la société de l'information. »

      Attendu que, le Conseil d’administration est sensible à, et apprécie le travail des états membres de l'ACTO pour servir l'intérêt public de la région amazonienne, notamment grâce à la promotion et à la protection du patrimoine culturel et naturel de la région.

      Il est résolu (2018.09.16.12) qu'il est demandé au président-directeur général de l'ICANN de soutenir le développement d'une solution de délégation des chaînes représentées dans les candidatures .AMAZON qui inclut le partage de l'utilisation de ces domaines de premier niveau avec les états membres de l'ACTO pour soutenir le patrimoine culturel des pays de la région amazonienne.

      Il est résolu (2018.09.16.13) que le Conseil d’administration demande au président-directeur général de l'ICANN, ou son(ses) représentant(s), si possible, de présenter une proposition au Conseil d'administration quant aux candidatures .AMAZON pour permettre au Conseil de prendre une décision sur la délégation des chaînes représentées dans ces candidatures.

      Il est résolu (2018.09.16.14) qu'il est demandé au président-directeur général de l'ICANN, ou son(ses) représentant(s), de fournir des mises à jour régulières et détaillées au Conseil d’administration quant à l'avancement des candidatures .AMAZON.

      Fondements des résolutions 2018.09.16.12 et 2018.09.16.14

      Cette mesure appuie la prise en considération par le Conseil d’administration de l'ICANN des résultats du processus de révision indépendante (IRP) déposé par la société Amazon, ainsi que la prise en considération de l'avis du Comité consultatif gouvernemental sur les candidatures .AMAZON. Le Conseil d’administration prend cette décision aujourd'hui d'examiner davantage la possibilité d'une délégation des candidatures .AMAZON, comme prévu dans la déclaration du panel IRP, tout en reconnaissant les questions de politique publique soulevées par le biais de l'avis du GAC concernant ces candidatures.

      Le Conseil d’administration prend cette décision aujourd'hui d'appuyer la poursuite des travaux qui pourraient déboucher sur une solution qui permettrait aux candidatures .AMAZON d'aller de l'avant tout en s'alignant sur l'avis et les commentaires du GAC sur ce sujet.

      Contexte

      La société Amazon a déposé une candidature pour .AMAZON et deux versions du nom de domaine internationalisé (IDN) pour le mot 'Amazon' (« les candidatures .AMAZON »). En réponse aux candidatures d'Amazon, les gouvernements du Brésil et du Pérou, avec l'appui de la Bolivie, de l'Équateur et de la Guyane, ont envoyé une alerte précoce, via le GAC et conformément au guide de candidature, dans laquelle les gouvernements concernés indiquaient que : « l'octroi de droits exclusifs sur ce gTLD spécifique à une société privée empêcherait l'utilisation de ce domaine aux fins d'intérêt public liés à la protection, la promotion et la sensibilisation au biome amazonien. De même, cela découragerait l'utilisation de ce domaine afin de rassembler les pages Web liées à la population vivant dans cette région géographique. » (L'alerte précoce est disponible sur https://gacweb.icann.org/display/gacweb/GAC+Early+Warnings?preview=/27131927/27197938/Amazon-BR-PE-58086.pdf [PDF, 79 KB].)

      Après avoir indiqué dans le communiqué de Beijing (avril 2013) qu'il devait procéder à un nouvel examen des candidatures d'Amazon, le GAC a fourni un avis consensuel (l'avis du GAC) au Conseil d’administration de l'ICANN dans le communiqué de Durban (18 juillet 2013) selon lequel les candidatures d'Amazon ne devraient pas être retenues (https://gacweb.icann.org/display/GACADV/2013-07-18-Obj-Amazon).

      Le 14 mai 2014, le Conseil d’administration (agissant via le NGPC) a accepté l'avis du GAC et a enjoint à l'ICANN de ne pas retenir les candidatures d'Amazon. (La résolution 2014.05.14.NG03, est disponible sur https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-05-14-en#2.b.)

      Attendu que, en octobre 2015, la société Amazon a soumis une proposition aux états membres de l’organisation du traité de coopération amazonienne (ACTO) afin de parvenir à une solution qui pourrait bénéficier aux deux parties. Cependant, cette proposition a été rejetée par les états membres de l'ACTO. Par la suite, la société Amazon a initié un processus de révision indépendante (IRP) en mars 2016. L'IRP a pris fin en juillet 2017 alors que le panel IRP se trouvait en faveur de la société Amazon. Suite aux résultats de l'IRP et agissant sur l'avis complémentaire du GAC, le Conseil d’administration a chargé l'organisation de l'ICANN de soutenir la société Amazon et les états membres de l'ACTO dans la négociation d'une solution.

      En octobre 2017, lors de la réunion ICANN60 à Abu Dhabi, la société Amazon a présenté au GAC et aux états membres de l'ACTO une nouvelle proposition pour un « compromis pratique ». En février 2018, suite à davantage de négociations facilitées par l'organisation de l'ICANN, la société Amazon a soumis une proposition mise à jour. Le 5 septembre 2018, suite à la révision de la proposition par le groupe de travail de l'ACTO, lors d'une réunion du Conseil de coopération amazonienne, les états membres de l'ACTO ont déclaré que « … les pays de la région amazonienne ont conclu que la proposition ne constitue pas un fondement approprié pour sauvegarder leurs droits immanents concernant la délégation du TLD '.amazon'. »

      Les propositions de la société Amazon

      Depuis octobre 2015, la société Amazon a soumis plusieurs propositions aux états membres de l'ACTO dans un effort visant à parvenir à une solution mutuellement acceptable. La proposition initiale d'octobre 2015 avait été rejetée par les états membres de l'ACTO, entrainant le dépôt d'un IRP par la société Amazon. Suite à la résolution de l'IRP, dans lequel le panel se trouvait en faveur de la société Amazon, lors de la réunion ICANN60 à abu Dhabi, la société Amazon a présenté au GAC une nouvelle proposition pour un « compromis pratique ». En février 2018, suite à des négociations facilitées par l'organisation de l'ICANN entre la société Amazon et les états membres de l'ACTO, la société Amazon a soumis une proposition actualisée. Selon cette proposition, la société Amazon proposait quatre pistes d'action :

      1. aider à la visibilité à l'échelle mondiale de la région amazonienne et de ses populations, et protéger leur patrimoine culturel, en :
        1. établissant un accord mutuellement acceptable sur un domaine de second niveau qui permettrait une visibilité de la région amazonienne. La société Amazon prendrait à sa charge le coût d'un site Web à hauteur de 1 000 000 dollars, et pour une durée de quatre ans ;
      2. Aider à lutter contre les utilisations malveillantes de noms de domaine associés à la région amazonienne et à ses populations, en :
        1. se mettant d'accord pour réserver un nombre important de domaines de second niveau en anglais, espagnol et portugais ;
      3. Créer un comité directeur pour superviser la mise en œuvre de cet accord
      4. S'engager dans des efforts de bonne volonté en fournissant aux états membres de l'ACTO des crédits pour utiliser les services et produits de la société Amazon à hauteur de 5 000 000 dollars.

      De plus, la société Amazon a proposé d'aider les états membres de l'ACTO à créer un programme d'informations pour aider à faire connaître les avantages de cet accord.

      Inquiétudes et réponse de l'ACTO aux propositions d'Amazon

      Les inquiétudes des états membres de l'ACTO concernant l'utilisation du TLD .AMAZON s'articulent autour de la capacité des pays et individus de la région amazonienne à utiliser les noms de domaine à des fins d'intérêt public. Dans l'alerte précoce émise par le Brésil et le Pérou en novembre 2012, les deux pays déclaraient que :

      « l'octroi de droits exclusifs sur ce gTLD spécifique à une société privée empêcherait l'utilisation de ce domaine aux fins d'intérêt public liés à la protection, la promotion et la sensibilisation au biome amazonien. De même, cela découragerait l'utilisation de ce domaine afin de rassembler les pages Web liées à la population vivant dans cette région géographique. »

      En octobre 2017, suite à la déclaration finale du panel IRP sur .AMAZON, les états membres de l'ACTO ont émis une déclaration, réaffirmant :

      « … que le nom Amazon, dans toutes les langues, représente le patrimoine culturel et l'identité des pays de la région amazonienne, et que son utilisation comme nom de domaine de premier niveau, sauf accord contraire des pays de la région, devrait être réservée à la promotion des intérêts et des droits des peuples d'Amazonie ainsi que leur inclusion dans la société de l'information. »

      Finalement, le 5 septembre 2018, suite à la proposition actualisée soumise par la société Amazon en février 2018, avec des clarifications demandées par les états membres de l'ACTO pour bien comprendre la proposition, ces derniers ont envoyé une lettre au Conseil d'administration déclaration que, concernant, la délégation du .AMAZON, celle-ci « exige un consentement des pays de la région amazonienne » et qu'ils « ont le droit de participer à la gouvernance du TLD '.amazon'. » De plus, les états membres de l'ACTO déclarent que «  la proposition ne constitue pas un fondement approprié pour sauvegarder leurs droits immanents concernant la délégation du TLD '.amazon'. »

      Les états membres mentionnent cependant qu'ils sont prêts « à s'engager auprès du Conseil d'administration de l'ICANN … dans l'optique de la sauvegarde de leurs droits d'états souverains. »

      Éléments pris en compte par le Conseil d’administration

      En prenant cette décision, le Conseil d’administration a examiné :

      • les propositions de la société Amazon du 6 octobre 2015 et du 7 février 2018 ;
      • la déclaration du panel IRP dans le processus de révision indépendante du .AMAZON ;
      • la proposition d'octobre 2017 de la société Amazon faite au GAC et aux états membres de l'ACTO ;
      • la décision du 14 mai 2014 du NGPC concernant les candidatures .AMAZON et les décisions du 29 octobre 2017 et du 4 février 2018 du Conseil d’administration concernant les candidatures .AMAZON ;
      • la lettre du 5 septembre 2018 de l'ACTO et les annexes.

      Impacts

      Il est prévu que cette mesure ait un léger impact sur les ressources de l'organisation de l'ICANN au vue des ressources nécessaires pour répondre à la demande du Conseil d’administration. Cependant, l'utilisation de ressources pour parvenir à une solution acceptable est préférable par rapport au fait de traiter les impacts potentiels d'une situation qui resterait dans l'impasse quant à cette question de la délégation des candidatures .AMAZON. Cette action relève de la mission de l’ICANN en ce qu'elle promeut le programme des nouveaux gTLD et l'expansion prévue du DNS. C'est également dans l'intérêt public, dans l'équilibre des valeurs fondamentales d'accroître la concurrence au sein du DNS tout en reconnaissant la formulation d'avis de politique publique par les gouvernements.

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

    5. Divers

      Aucune résolution n’est adoptée.