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-2016-09-15-en

  1. Ordre du jour approuvé :
    1. Mise en œuvre des recommandations du RSSAC 003 concernant la validité de la signature de la KSK
    2. Délégation du domaine .বাংলা (« bangla ») représentant Bangladesh en script bengali
    3. Conclusion du contrat pour le lieu de la réunion de l’ICANN d’octobre 2018
    4. Nomination du président et du président élu du comité de nomination 2017
  2. Ordre du jour principal :
    1. Contrat des fonctions IANA relatives au nommage entre l'ICANN et la PTI
    2. Contrat de services entre l'ICANN et la PTI
    3. Amendement au contrat de registre .COM
    4. Éléments de gouvernance de la PTI - Adoption des statuts constitutifs de la PTI ; Nomination des premiers administrateurs du Conseil d’administration de la PTI ; Nomination du président de la PTI
    5. Examen approfondi de la déclaration finale de l'IRP pour Dot Registry
    6. Examen du rapport du médiateur concernant la candidature dotgay LLC pour .GAY
    7. Demande de réexamen 16-3 (dotgay LLC )
    8. Divers

 

  1. Ordre du jour approuvé :

    1. Mise en œuvre des recommandations du RSSAC 003 concernant la validité de la signature de la KSK

      Attendu que, le 16 septembre 2015, le Comité consultatif du système des serveurs racine (RSSAC) a publié le RSSAC0003 : rapport sur les TTL de la zone racine.

      Attendu que, dans le RSSAC003, le rapport recommande que les partenaires de la gestion de la zone racine augmentent la période de validité de la signature pour les signatures générées à la fois par la clé de signature de clé (KSK) et la clé de signature de zone (ZSK). Le rapport recommande en outre que la validité de la signature KSK soit augmentée d'au moins 21 jours, que la validité de la signature ZSK soit augmentée d'au moins 13 jours et qu'il n'y ait pas de changement pour les TTL de la zone racine.

      Attendu que, à la réception du RSSAC003, le personnel de l'ICANN a mené une analyse des coûts et de la faisabilité de l'augmentation de la validité de la signature KSK, et a créé un plan de mise en œuvre de la KSK devant être examiné par le Conseil d’administration.

      Attendu que, le Conseil d’administration a pris en considération l'avis du RSSAC dans le RSSAC003, en plus du coût et de la faisabilité de la mise en œuvre de l'avis relatif à la KSK. Le Conseil d’administration comprend que le responsable de la maintenance de la zone racine prend également en considération les recommandations du RSSAC003 relatif à la ZSK.

      Il est résolu (2016.09.15.01) que le Conseil d’administration adopte l'avis du RSSAC pour la validité de la signature KSK présent dans le RSSAC003, et demande au Président-directeur général de l'ICANN ou son représentant, de procéder à la mise en œuvre des recommandations KSK prévues dans le RSSAC003 en collaboration avec les partenaires de gestion de la zone racine.

      Fondements de la résolution 2016.09.15.01

      Le 16 septembre 2015, le Comité consultatif du système des serveurs racine (RSSAC) a publié le RSSAC0003 : rapport sur les TTL de la zone racine. Dans ce rapport, le RSSAC étudie les TTL (valeurs de « Temps à vivre » du DNS) pour la zone racine et la mesure dans laquelle les TTL actuels de la zone racine sont toujours appropriés dans l'environnement Internet d'aujourd'hui.

      Le rapport a identifié deux problèmes potentiels en lien avec l'interaction entre la valeur à terme du SOA de la zone racine et la période de validité de signature de la zone racine qui existent, et recommande qu'ils soient traités par la communauté en charge des opération du DNS. Le RSSAC recommande notamment aux partenaires de la gestion de la zone racine d'augmenter la période de validité de la signature pour les signatures générées à la fois par la clé de signature de clé (KSK) et la clé de signature de zone (ZSK). La validité de la signature KSK devrait être augmentée d'au moins 21 jours. La validité de la signature ZSK devrait être augmentée d'au moins 13 jours.

      Les conditions dans lesquelles les problèmes de validité de signature surviennent sont très rares, n'ont pas encore eu lieu jusqu'à maintenant, et il est peu probable que les utilisateurs finaux soient impactés à ce stade. Ainsi, le RSSAC pense que cette question n'est pas urgente et qu'elle devrait être traitée dans un délai raisonnable à la suite d'une mise à jour des documents de procédure nécessaires et d'un essai de logiciel.

      À la réception du RSSAC003, le personnel de l'ICANN a mené une analyse des coûts et de la faisabilité de la mise en œuvre de la recommandation KSK du rapport RSSAC003, et a créé un plan de mise en œuvre de la KSK avec un calendrier et des étapes clés importantes, le tout devant être examiné par le Conseil d’administration.

      Le Conseil d’administration a pris en considération l'avis du RSSAC dans le rapport RSSAC003, ainsi que la faisabilité et le coût de mise en œuvre de l'avis relatif au KSK et adopte l'avis du RSSAC pour la validité de signature KSK du RSSAC003. Le Conseil d’administration demande également à l'ICANN de procéder à la mise en œuvre des recommandations KSK du RSSAC003 en collaboration avec les partenaires de la gestion de la zone racine.

      Il s’agit d’une question opérationnelle qui ne nécessite pas de consultation publique. Aucun impact fiscal n’est prévu. L'approbation et la mise en œuvre des recommandations du RSSAC vont améliorer la sécurité, la stabilité et la résilience du système des noms de domaine.

      Le Conseil d’administration prend note que la NTIA s'est déjà mise d'accord avec Verisign, en tant que responsable de la maintenance de la zone racine, pour que celui-ci modifie la période de validité de la signature pour la ZSK et que cette mission doit avoir lieu en septembre 2016.

    2. Délégation du domaine .বাংলা (« bangla ») représentant Bangladesh en script bengali

      Il est résolu (2016.09.15.02) que dans le cadre de ses responsabilités en vertu du contrat des fonctions IANA, l'ICANN a examiné et évalué la demande de délégation du domaine de premier niveau géographique .বাংলা auprès du département du ministère chargé des postes, des télécommunications et des technologies de l'information du Bangladesh. La documentation montre que cette demande a suivi les procédures appropriées pour son évaluation.

      Il est résolu (2016.09.15.03) que le Conseil d’administration demande, en vertu du chapitre III article 5.2 des statuts constitutifs de l’ICANN, que certaines parties des fondements n’étant pas appropriées pour la distribution publique des résolutions, du rapport préliminaire ou des procès-verbaux en ce moment à cause des obligations contractuelles, soient exemptées jusqu’à ce que la publication soit autorisée conformément aux obligations contractuelles.

      Fondements des résolutions 2016.09.15.02 – 2016.09.15.03

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

      Conformément au contrat des fonctions IANA, le personnel de l’ICANN a évalué la demande de délégation des ccTLD et présente son rapport au Conseil d’administration pour révision. Ce dernier est chargé via cette révision de s’assurer que le personnel de l’ICANN ait bien suivi les procédures appropriées.

      Quelle est la proposition à l’étude ?

      Il est proposé d’approuver une demande soumise à l'IANA visant à créer un domaine de premier niveau géographique et confier le rôle d'organisation de parrainage (connue également sous le nom de gestionnaire ou administrateur) au département du ministère chargé des postes, des télécommunications et des technologies de l'information du Bangladesh.

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

      Lors de l’évaluation d’une demande de délégation, le personnel de l’ICANN consulte le candidat et d’autres parties intéressées. Dans le cadre du processus de candidature, le candidat doit expliquer quelles consultations ont été effectuées dans le pays au sujet du ccTLD en question et dans quelle mesure celles-ci s’appliquent à la communauté Internet locale.

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

      Le personnel n’est pas informé des questions ou des inquiétudes soulevées par la communauté concernant cette demande.

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

      [Censuré– Informations sensibles relatives à une délégation]

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

      Le Conseil d’administration n’a identifié aucun facteur d’inquiétude concernant cette demande.

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

      L’approbation en temps voulu des gestionnaires de noms de domaine géographiques répondant aux critères d’intérêt public a un effet positif sur la mission de l’ICANN et les communautés locales auxquelles des domaines de premier niveau géographiques sont attribués, et correspond aux obligations de l’ICANN en vertu du contrat des fonctions IANA.

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

      La gestion des délégations des extensions géographiques dans la zone racine du DNS fait partie des fonctions IANA et le processus de délégation ne devrait pas avoir de répercussion majeure sur les dépenses prévues. Le rôle de l’ICANN n’est pas celui d’évaluer les répercussions financières des activités relatives aux ccTLD dans un pays.

      Y a-t-il des implications en termes de sécurité/stabilité/résilience du DNS ?

      L’ICANN estime que cette demande ne représente aucun risque significatif pour la sécurité, la stabilité ou la résilience du DNS. Il s’agit d’une fonction administrative organisationnelle qui ne nécessite pas de consultation publique.

    3. Conclusion du contrat pour le lieu de la réunion de l’ICANN d’octobre 2018

      Attendu que, l’ICANN souhaite organiser sa troisième réunion publique de 2018 en Europe.

      Attendu que, le personnel a examiné avec attention tous les lieux proposés pour tenir sa réunion en Europe et estime que le lieu le plus approprié serait Barcelone en Espagne.

      Il est résolu (2016.09.15.04) que le Conseil d’administration autorise le Président-directeur général, ou son (ses) représentant(s), à gérer et à faciliter tous les aspects indispensables liés aux contrats et aux déboursements pour le centre de convention qui accueillera la réunion publique de l’ICANN d’octobre 2018 à Barcelone en Espagne, jusqu’à concurrence de [À REMPLIR APRÈS NÉGOCIATIONS], et que la réunion publique de l’ICANN d’octobre 2018 soit qualifiée de réunion générale annuelle 2018.

      Il est résolu (2016.09.15.05) que les détails de cette résolution resteront confidentiels à des fins de négociation, conformément au chapitre III, article 5.2 des statuts constitutifs de l’ICANN, jusqu’à ce que le Président-directeur général en autorise la divulgation.

      Fondements des résolutions 2016.09.15.04 et 2016.09.15.05

      Dans le cadre de son calendrier de réunions publiques, l’ICANN organise trois réunions par an dans des régions géographiques différentes (tel que décrit dans ses statuts constitutifs). La 63e réunion de l’ICANN, prévue du 20 au 26 octobre 2018 doit avoir lieu en Europe. Un appel à recommandations concernant le lieu de la réunion en Europe a été publié le 23 mars 2015. Diverses parties ont envoyé une proposition à l'ICANN. Le personnel a examiné avec attention les propositions, de même que d'autres endroits. Il a ensuite rédigé un document afin de déterminer quels sites remplissaient les critères de sélection du lieu de réunion (voirhttps://meetings.icann.org/en/host). Sur la base des propositions et de cet examen, l’ICANN a décidé que la 63e réunion de l’ICANN aurait lieu à Barcelone en Espagne.

      Le Conseil d’administration a examiné la présentation du personnel quant au lieu de la réunion publique de l’ICANN d’octobre 2018, à savoir Barcelone en Espagne, le respect par la proposition des principales conditions établies dans les critères de sélection du lieu de réunion ainsi que les coûts liés au lieu choisi.

      L’organisation de la réunion aura un impact financier sur l’ICANN, ainsi que sur la communauté, car cela implique des frais de voyage pour se déplacer jusqu’à l’emplacement de la réunion. Cet impact est à prévoir indépendamment du lieu de la réunion. Cette décision n’aura aucune incidence sur la sécurité ou la stabilité du DNS.

      Le Conseil d’administration remercie tous ceux qui ont recommandé des sites pour la 63e réunion de l’ICANN.

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

    4. Nomination du président et du président élu du comité de nomination 2017

      Attendu que, le 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 2017 (« NomCom »), a examiné les résultats de l'évaluation 360 degrés des dirigeants du NomCom 2016 et a mené des entretiens avec les candidats.

      Attendu que, le BGC a recommandé que Hans Petter Holen soit nommé président du NomCom 2017 et que Zahid Jamil soit nommé président-élu du NomCom 2017.

      Il est résolu (2016.09.15.06) que le Conseil d'administration nomme par les présentes Hans Petter Holen président du Comité de nomination 2017 et Zahid Jamil le président élu du Comité de nomination 2017.

      Fondements de la résolution 2016.09.15.06

      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 chapitre VII article 2.1 et 2.2 sur http://www.icann.org/en/general/bylaws.htm#VII. 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. Voir la charte du BGC sur http://www.icann.org/en/committees/board-governance/charter.htm. Le BGC a publié un appel à manifestation d'intérêt (EOI) le 24 mai 2016 demandant les EOI avant le 10 juin 2016 (voir (https://www.icann.org/news/announcement-2016-05-24-enn). L'appel à manifestation d'intérêt a ensuite été prolongé jusqu'au 30 juillet 2016 (voirhttps://www.icann.org/news/announcement-2016-06-10-en). Le BGC a reçu et examiné plusieurs EOI, a supervisé une évaluation à 360 degrés des dirigeants du NomCom 2016 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 2017. Le Conseil d’administration tient à remercier tous ceux qui ont manifesté leur intérêt à faire partie de l'équipe de dirigeants du NomCom 2017.

      Nommer un président et un président élu du NomCom, identifiés par le biais d'un processus public d'EOI, a un impact positif sur la transparence et la responsabilité de l'ICANN, et soutient l'intérêt public. 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.

  2. Ordre du jour principal :

    1. Contrat des fonctions IANA relatives au nommage entre l'ICANN et la PTI

      Attendu que, l'exécution du contrat des fonctions IANA relatives au nommage <https://www.icann.org/en/system/files/files/proposed-iana-naming-function-agreement-10aug16-en.pdf> [PDF, 283 KB] satisfait une exigence de la série de propositions que le Conseil d’administration a approuvée le 10 mars 2016 pour transférer la supervision des fonctions IANA assurée par la NTIA vers la communauté multipartite mondiale.

      Attendu que, le contrat des fonctions IANA relatives au nommage a été rédigé pour remplir les exigences de la proposition de transition de la supervision de l'IANA du groupe de coordination pour la transition du rôle de supervision des fonctions IANA.

      Attendu que, par le biais du contrat des fonctions IANA relatives au nommage, l'ICANN va conclure un contrat avec les identificateurs techniques publics pour agir en tant qu'opérateur des fonctions de nommage de l'IANA et accomplir les fonctions de l'IANA relatives au nommage.

      Attendu que, l'ICANN a demandé une période de commentaire public sur le contrat des fonctions IANA relatives au nommage proposé, du 10 août 2016 au 9 septembre 2016 <https://www.icann.org/public-comments/iana-naming-function-agreement-2016-08-10-en>.

      Attendu que, le forum de commentaire public sur le contrat des fonctions IANA relatives au nommage proposé a pris fin le 9 septembre 2016, l'ICANN ayant reçu huit commentaires, tant de personnes individuelles que de groupes et organisations. Un résumé ainsi qu'une analyse des commentaires ont été publiés <https://www.icann.org/en/system/files/files/report-comments-iana-naming-function-agreement-15sep16-en.pdf> [PDF, 497 KB] et transmis au Conseil d’administration.

      Il est résolu (2016.09.15.07) que le contrat des fonctions IANA relatives au nommage proposé est approuvé, et le Président-directeur général, ou son ou ses représentants, est autorisé à prendre les mesures qu’il juge appropriées pour conclure et mettre en œuvre ledit contrat.

      Fondements de la résolution 2016.09.15.07

      Pourquoi le Conseil aborde-t-il cette question maintenant ?

      L'exécution du contrat des fonctions IANA relatives au nommage constitue l’une des exigences de la série de propositions que le Conseil d’administration a approuvée le 10 mars 2016 et visant à transférer la supervision des fonctions IANA, jusqu’alors assurée par la NTIA, à la communauté multipartite mondiale. Depuis le 15 juillet 2016, l'ICANN a travaillé avec le CWG-supervision et son conseil extene pour finaliser le contrat des fonctions IANA relatives au nommage. Après avoir intégré les premiers commentaires du CWG-supervision, le contrat a été publié pour une période de consultation publique de 30 jours à partir du 10 août 2016. La période de commentaires de 30 jours a pris fin le 9 septembre 2016 et il a été demandé au Conseil d’administration de prendre en considération le contrat proposé pour approbation.

      Quelle est la proposition à l’étude ?

      Le contrat des fonctions IANA relatives au nommage proposé désigne la PTI en tant qu'opérateur des fonctions de nommage de l'IANA et autorise la PTI à accomplir les fonctions de nommage de l'IANA. Le contrat intègre des attentes de niveau de service pour l'exercice des fonctions de nommage de l'IANA qui ont été approuvées entre l'ICANN et le CWG-supervision. Le contrat entrera en vigueur après la réussite de la transition de la supervision de l'IANA.

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

      L'ICANN a mené une période de consultation publique sur le contrat des fonctions IANA relatives au nommage proposé du 10 août 2016 au 9 septembre 2016. L'ICANN a également travaillé en étroite collaboration avec le CWG-supervision et son conseil externe pour traiter les inquiétudes. Après la période de consultation publique, les commentaires ont été résumés et analysés.

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

      Deux inquiétudes principales ont été soulevées durant le processus de révision du CWG-supervision.

      La première inquiétude a été soulevée par certaines personnes au sein de la communauté ccTLD et elle est liée aux politiques applicables pour la gestion de la zone racine des ccTLD. Après concertation avec la communauté ccTLD et les membres du GAC qui ont participé aux discussions du CWG-supervision, le contrat a été mis à jour afin de refléter le fait que les politiques applicables incluent : (1) celles définies par la ccNSO ; (2) le RFC 1591 (« structure et délégation du système des noms de domaine ») tel qu'interprété par le cadre d'interprétation des politiques et lignes directrices actuelles appartenant à la délégation et la redélégation des noms de domaine de premier niveau géographique, daté d'octobre 2014. En complément de ces politiques, la PTI doit consulter les principes et lignes directrices 2005 du comité consultatif gouvernemental pour la délégation et l'administration des domaines de premier niveau géographique le cas échéant.

      La deuxième inquiétude, également soulevée par certaines personnes au sein de la communauté ccTLD, a été que ces ccTLD qui n'ont pas de contrat avec l'ICANN « ne veulent pas désigner l'ICANN comme responsable de leurs entrées au sein de la zone racine » et ceci devrait être reflété dans le contrat. L'ICANN a fait remarquer qu'au sein de la proposition, le CWG-supervision attend en réalité que les rôles de l'ICANN et du responsable de la maintenance de la zone racine ne soient pas modifiés après la transition. Le paragraphe 1158 de la proposition du CWG-supervision stipule :

      À l'heure actuelle, la mise à jour de la zone racine exige une participation active des trois parties : l'IFO, le responsable de la maintenance de la zone racine et la NTIA. L'IFO reçoit les demandes de changements de diverses sources, les valide, et les envoie au responsable de la maintenance de la zone racine qui, une fois qu'elles sont autorisées par la NTIA, met à jour le fichier de zone racine, le DNSSEC le signe et le distribue aux opérateurs des serveurs racine.

      Après la transition il n'y aura que l'IFO et le responsable de la maintenance de la zone racine. Le CWG-supervision ne recommande pas de changement dans les fonctions exercées par ces deux rôles. Le CWG-supervision recommande que, s'il y a des propositions de changements relatives aux rôles associés à la modification de la zone racine, elles devraient être soumises à une vaste consultation de la communauté.

      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 pris en considération la mesure selon laquelle les commentaires publics ont été intégrés au contrat des fonctions IANA relatives au nommage proposé. L'implication du CWG-supervision est particulièrement importante, ainsi que le recours à un conseil externe, dans la révision et l'identification de changements supplémentaires au contrat des fonctions IANA relatives au nommage. L'accord de l'ICANN face à la prise en charge des modifications générées par le biais du CWG-supervision aide à garantir une cohérence continue avec la proposition de transition de la supervision de l'IANA. Le Conseil d’administration a aussi pris en considérations les conditions du contrat afin de veiller à ce que les fonctions de l'IANA relatives au nommage soient toujours assurées de manière sécurisée, stable et fiable et qu'elles correspondent aux besoins des clients.

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

      Le contrat des fonctions IANA relatives au nommage proposé établi les exigences et obligations de la PTI dans l'exercice des fonctions IANA relatives au nommage de manière sécurisée, stable et fiable. Le contrat intègre également les attentes de niveau de service dans l'exercice des fonctions IANA relatives au nommage. L'approbation par le Conseil d’administration du contrat proposé satisfera l'une des exigences majeures de la proposition développée par la communauté pour le transfert de la supervision IANA que le Conseil d'administration a approuvée le 10 mars 2016 et garantira que les fonctions de l'IANA relatives au nommage soient toujours assurées de manière sécurisée, stable et fiable et qu'elles répondent aux besoins des clients.

      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 n'y a pas de répercussions financières prévues si le Conseil d’administration approuve le contrat des fonctions IANA relatives au nommage proposé. L'ICANN va fournir les services nécessaires à la PTI afin de répondre aux obligations en vertu du contrat proposé. Ces services et les coûts associés sont spécifiés dans un contrat de services séparé entre l'ICANN et la PTI.

      Y a-t-il des implications en termes de sécurité/stabilité/résilience du DNS ?

      L'approbation par le Conseil d’administration du contrat des fonctions IANA relatives au nommage proposé garantirait l'exploitation continue des fonctions de l'IANA relatives au nommage de manière sécurisée, stable, et fiable après la transition.

    2. Contrat de services entre l'ICANN et la PTI

      Attendu que, l'exécution du contrat de services <https://www.icann.org/iana_imp_docs/111-services-agreement-v-14sep16> [DOCX, 47 KB] satisfait une exigence de la série de propositions que le Conseil d’administration a approuvée le 10 mars 2016 pour le transfert de la supervision des fonctions IANA aujourd'hui réalisée par la NTIA vers la communauté multipartite mondiale.

      Attendu que, le contrat de services a été rédigé pour répondre aux exigences de la proposition de transition de la supervision de l'IANA du groupe de coordination pour la transition du rôle de supervision des fonctions IANA ainsi que les obligations de l'ICANN conformément au contrat des fonctions IANA relatives au nommage.

      Attendu que, l'ICANN a consulté le CWG-supervision, son conseil externe, l'IETF et les RIR pour répondre aux inquiétudes et finaliser le contrat.

      Il est résolu (2016.09.15.08) que le contrat de services proposé est approuvé, et le Président-directeur général, ou son ou ses représentants, est autorisé à prendre les mesures qu’il juge appropriées pour conclure et mettre en œuvre ledit contrat.

      Fondements de la résolution 2016.09.15.08

      Pourquoi le Conseil aborde-t-il cette question maintenant ?

      La série de propositions que le Conseil d’administration a approuvée le 10 mars 2016 pour le transfert de la supervision des fonctions IANA aujourd'hui réalisée par la NTIA vers la communauté multipartite mondiale exige que l'ICANN fournisse les services et les ressources nécessaires à la PTI dans le cadre de la réalisation des fonctions IANA. Cette exigence est intégrée dans le contrat des fonctions IANA relatives au nommage entre l'ICANN et la PTI.

      L'ICANN a travaillé de manière intensive avec le CWG-supervision, son conseil externe, l'IETF et les RIR pour finaliser le contrat de services présenté aujourd'hui au Conseil d’administration pour qu'il soit pris en considération et approuvé.

      Quelle est la proposition à l’étude ?

      Par ce contrat, l'ICANN s'engage à fournir les services et ressources nécessaires à la PTI de façon à ce qu'elle accomplisse les fonctions IANA.

      Il s'agira de ressources dédiées dont les employés actuels du département de l'IANA de l'ICANN, qui exécutent directement les services liés aux fonctions IANA. Il s'agira de ressources partagées dont les employés des autres départements de l'ICANN qui réalisent ou participent au processus directement lié à la prestation des fonctions IANA. Il s'agira de services d'assistance dont les services apportés par les départements de l'ICANN afin de soutenir les activités de la PTI (p.ex., les ressources humaines, les finances, les achats, etc.)

      Tous les services et ressources apportés à la PTI seront facturés par l'ICANN à la PTI. La PTI sera également intégralement et exclusivement financée par l'ICANN. On estime que la portée des services représentera un coût de 9 millions de dollars sur une base annuelle (en se basant sur le budget de l'exercice fiscal 2017).

      Dans la mesure où il se rapporte aux ressources dédiées, le contrat prévoit que les employés de l'ICANN actuellement présents au sein du département de l'IANA soient affectés à la PTI. Le contrat prévoit en outre que dans un délai de trois (3) ans à partir de la date d'entrée en vigueur du contrat, la PTI aura les programmes, les processus, et les politiques nécessaires pour offrir un emploi à temps plein aux employés affectés. Si la PTI facilite ce changement d'emploi.

      En vertu du contrat, l'ICANN fournira des efforts raisonnables pour apporter les services, tels que la comptabilité, les communications, et les ressources humaines, établis par l'ICANN pour exercer ses propres activités. Le contrat permet à l'ICANN de modifier, suspendre ou mettre fin à la prestation de services à condition que le changement, la suspension ou la fin n'engendrent pas de risque important pour la sécurité et la stabilité du système des noms de domaine. Par exemple, si l'ICANN réalise un changement dans ses offres d'assurance dentaire, celles-ci sont mises à disposition pour ceux qui travaillent avec la PTI et seront conformes avec l'assurance modifiée.

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

      Comme le contrat représente un engagement détaillé, opérationnel concernant des services et des ressources particulières nécessaires pour aider la PTI, il n'était pas possible de demander des commentaires publics pour ce document. Cependant, l'ICANN a consulté l'IETF et les RIR pour répondre aux inquiétudes et a travaillé de manière intensive avec le CWG-supervision, son conseil externe pour finaliser le contrat.

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

      Aucune question majeure n'a été soulevée par la communauté, étant donné que la plupart des questions étaient de nature juridique concernant le reflet approprié des conditions du contrat.

      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 pris en considération le fait que les exigences du contrat sont conformes aux processus de planification financière de l'ICANN et que le contrat donne au PTI les ressources nécessaires pour exercer les fonctions IANA.

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

      Le contrat garantit que la PTI aura les ressources nécessaires pour exercer les fonctions IANA pour les communautés de noms, de numéros et de paramètres de protocole.

      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 services seront facturés par l'ICANN à la PTI, qui, en retour, est intégralement et exclusivement financée par l'ICANN. On estime que la portée des services représentera un coût de 9 millions de dollars sur une base annuelle (en se basant sur le budget de l'exercice fiscal 2017 que le Conseil d’administration a approuvé) <https://www.icann.org/resources/board-material/resolutions-2016-06-25-en#2.c).

      Y a-t-il des implications en termes de sécurité/stabilité/résilience du DNS ?

      L'approbation par le Conseil d’administration du contrat de services proposé garantirait les ressources nécessaires pour que la PTI poursuive l'exercice des fonctions de l'IANA relatives au nommage de manière sécurisé, stable et fiable après la transition.

    3. Amendement au contrat de registre .COM

      Attendu que, l'ICANN et Verisign ont pris part à des discussions sur un amendement proposé au contrat de registre .COM du 1e décembre 2012 (l'Amendement) et ont accepté de prolonger le terme du contrat au 30 novembre 2024 pour coïncider avec le terme du contrat de services du responsable de la maintenance de la zone racine de façon à garantir la sécurité, la stabilité et la résilience des activités de la zone racine.

      Attendu que, l'amendement proposé exige également que Verisign et l'ICANN coopèrent et négocient en toute bonne foi pour : (1) amender le contrat de registre .COM à la deuxième date d'anniversaire du contrat proposé de façon à préserver et améliorer la sécurité d'Internet ou du TLD ; et (2) ce qui peut être nécessaire pour assurer la conformité avec les changements de l'accord de coopération entre Verisign et le département du commerce des États-Unis. Tous les autres termes et toutes les autres conditions du contrat de registre existant restent inchangés.

      Attendu que, l’ICANN a organisé une période de consultation publique entre le 30 juin 2016 et le 10 août 2016 <https://www.icann.org/public-comments/com-amendment-2016-06-30-en> eu égard à l'amendement proposé. Quatre vingt dix-neuf (99) commentaires ont été publiés à la fois par des personnes individuelles et des organisations/groupes

      Attendu que, le Conseil d’administration a pris en considération les commentaires et le résumé et l'analyse des commentaires par le personnel.

      Attendu que, l'ICANN a mené une révision des résultats récents de Verisign en vertu du contrat de registre .COM actuel et a estimé que Verisign respectait en grande partie ses exigences contractuelles.

      Il est résolu (2016.09.15.09) que l'amendement proposé au contrat de registre .COM <https://www.icann.org/sites/default/files/tlds/com/com-amend-1-pdf-30jun16-en.pdf> [PDF, 100 KB] est approuvé, soumis au RZMA devant être appliqué, et le Président-directeur général ou son (ses) représentant(s) est autorisé à prendre de telles mesures comme il lui semble approprié pour finaliser et mettre en œuvre ledit amendement.

      Fondements de la résolution 2016.09.15.09

      Pourquoi le Conseil aborde-t-il cette question maintenant ?

      Le 1e décembre 2012, l'ICANN et Verisign ont conclu un contrat de registre en vertu duquel Verisign pilote le domaine de premier niveau .COM. Le contrat expirera le 30 novembre 2018. L'ICANN et Verisign ont négocié un amendement proposé, qui a été publié pour une période de consultation publique de 42 jours entre le 30 juin 2016 et le 12 août 2016. À l'heure actuelle, le Conseil d’administration approuve l'amendement proposé pour l'exploitation continue du TLD .COM par Verisign.

      Quelle est la proposition à l’étude ?

      L'amendement proposé : (1) prolonge le terme du contrat de registre .COM au 30 novembre 2024 pour coïncider avec le terme du contrat de service pour la maintenance de la zone racine (RZMA) entre l'ICANN et Verisign ; (2) Verisign et l'ICANN s'engagent à coopérer et à négocier en toute bonne foi pour amender le contrat de registre .COM à la date du deuxième anniversaire de l'amendement proposé de façon à préserver et améliorer la sécurité d'Internet ou du TLD ; (3) Verisign et l'ICANN s'engage à coopérer et à négocier en toute bonne foi pour amender les conditions du contrat de registre .COM et vérifier la conformité des changements du contrat coopératif entre Verisign et le département du commerce des États-Unis. Tous les autres termes et toutes les autres conditions du contrat de registre existant restent inchangés.

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

      L'ICANN s'engage dans des négociations bilatérales avec Verisign pour se mettre d'accord sur les termes de l'amendement proposé. L'amendement proposé a ensuite été publié pour commentaire public du 30 juin 2016 au 12 août 2016. Après la période de consultation publique, les commentaires ont été résumés et analysés.

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

      Il y a eu 99 commentaires provenant de personnes individuelles et de groupes/organisations pendant la période de consultation publique de 42 jours. Les personnes ayant laissé des commentaires ont en général soutenu l'amendement proposé alors que d'autres ont soulevé des inquiétudes. Un résumé et une analyse des commentaires sont fournis ci-dessous et publiés sur <https://www.icann.org/en/system/files/files/report-comments-com-amendment-09sep16-en.pdf> [PDF, 200 KB].

      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 pour l'amendement proposé, ainsi que le résumé et l'analyse de ces commentaires.

      Le Conseil d’administration reconnait que les personnes ayant laissé des commentaires ont été en général favorable à l'amendement proposé et que certaines personnes ont exprimé un soutien général mais ont également demandé à l'ICANN et / ou à Verisign de clarifier la lien entre l'accord de coopération et l'amendement proposé, en particulier en ce qui concerne les prix, et les dispositions ou sujets qui seraient soumis en toute bonne foi aux négociations à partir du deuxième anniversaire de la date de mise en vigueur de l'amendement proposé.

      Alors que le Conseil d’administration prend note des changements suggérés par l'amendement proposé afin de spécifier les dispositions qui seront abordées à l'anniversaire des deux ans dudit amendement, le Conseil d'administration note que la langue telle que rédigée dans l'amendement proposé équilibre et apporte un engagement quant au fait de prendre part aux négociations, tout en donnant une certaine marge afin de prendre en considération de futurs sujets liés à la conservation et au renforcement de la sécurité et de la stabilité d'Internet ou du TLD dans ce paysage en évolution.

      En ce qui concerne le fait d'examiner l'amendement proposé pour tenir compte des changements potentiels, ou l'annulation de l'accord de coopération entre Verisign et le département du commerce, le Conseil d’administration note que l'amendement proposé prend déjà en compte l'accord de coopération. L'amendement proposé inclut la langue, demandant à l'ICANN et à Verisign de prendre part en toute bonne foi aux négociations pour réaliser les changements au contrat de registre .COM pour qu'ils soient en toute conformité avec les changements, ou la résiliation ou l'expiration de l'accord de coopération.

      Le Conseil d’administration reconnait également que certains commentaires ont abordé la question des prix pour les noms de domaine .COM. Certaines personnes ont suggéré que le prix actuel plafonné dans le contrat de registre soit maintenu, alors que d'autres recommandent que le prix soit baissé. Le Conseil d’administration note que l'article 7.3(d) du contrat de registre .COM précise le prix maximum que Verisign peut demander pour les services aux registres. L'amendement proposé ne modifie pas cette disposition.

      Le Conseil d’administration prend également note des commentaires soumis qui s'opposent à la disposition relative au droit au renouvellement présumé dans le contrat de registre .COM et les suggestions visant à dire que ce droit de renouvellement devrait être retiré dans certaines circonstances, tel qu'un manquement grave au contrat de registre. D'autres ont suggéré qu'au lieu d'étendre le contrat de registre .COM, il devrait faire l'objet d'un appel d'offres public pour s'assurer que les titulaires de nom de domaine soient facturés au plus bas prix. Le Conseil d’administration note que le droit de renouvellement présumé dans l'article 4.2 du contrat de registre .COM est une disposition présente dans tous les contrats de registre de l'ICANN. Cette disposition donne à un opérateur de registre le droit de renouveler le contrat à sa date d'expiration, à condition que l'opérateur de registre soit en règle au moment du renouvellement comme établi selon les termes de la disposition relative au renouvellement présumé. Cette disposition de renouvellement présumé est mise en place pour garantir la stabilité, la sécurité et la fiabilité dans le fonctionnement du TLD, c'est-à-dire, encourager un investissement à long terme dans les activités robustes du TLD. Cela a servi l'intérêt public en encourageant l'investissement dans l'infrastructure d'un opérateur de registre TLD et dans les améliorations de la fiabilité des activités du TLD. L'ICANN a précédemment décrit les fondements pour le renouvellement présumé des opérateurs de registre : « Absence de toutes mesures compensatoires, il existe un bénéfice public léger, et des perturbations éventuelles importantes, en cas de modifications régulières d'un opérateur de registre. En outre, la probabilité importante de perte du droit d'exploiter un registre après une courte période créé des motivations négatives pour favoriser un gain à court terme plutôt qu'un investissement à long terme. D'un autre côté, la communauté, agissant par le biais de l'ICANN, doit avoir la capacité de remplacer un opérateur de registre qui ne sert pas suffisamment la communauté dans l'activité d'un registre. »

      Le Conseil d’administration prend note des commentaires sur le fait que le contrat de registre .COM devrait être conforme aux nouvelles sauvegardes et protections de la propriété intellectuelle présentes dans le contrat de registre des nouveaux gTLD. Certaines des personnes ayant apporté un commentaire ont noté que certains opérateurs de registre de gTLD existants ont adopté la forme générale du contrat de registre des nouveaux gTLD (p.ex., .PRO, .CAT, .TRAVEL) avec notamment des améliorations et sauvegardes supplémentaires, et que le .COM devrait faire la même chose. Certains ont affirmé que de ne pas demander au .COM de se soumettre à de nouvelles améliorations, sauvegardes et protections de la propriété intellectuelle dans le contrat de registre des nouveaux gTLD soulève des inquiétudes quant à savoir si l'ICANN respecte ses valeurs fondamentales en lien avec un traitement non-discriminatoire ou préférentiel, en servant l'intérêt public, la transparence et la compétitivité. Le Conseil d’administration note que l'amendement proposé publié pour commentaire public est une extension simple du mandat actuel de l'accord, et passer à un contrat de registre des nouveaux gTLD exigerait de longues discussions et une consultation de la communauté. Proposer un amendement simple à l'heure actuelle pour étendre le mandat du contrat de registre .COM a pour but de maintenir un fonctionnement stable, sécurisé et fiable du TLD .COM.

      Le Conseil d’administration note également que l'amendement proposé prévoit une disposition selon laquelle l'ICANN et Verisign s'engagent à coopérer et négocier en tout bonne foi pour amender le contrat de registre .COM à partir de la deuxième date d'anniversaire de l'amendement proposé de façon à préserver et améliorer la sécurité d'Internet ou du TLD. Cette formulation a été négociée afin de donner l'occasion à de futures discussions potentiellement nécessaires pour aborder les changements éventuels afin de préserver et améliorer la sécurité d'Internet ou du TLD .COM.

      Le Conseil d’administration accepte les commentaires demandant la confirmation que Verisign devra mettre en place des politiques de consensus futures pouvant prévoir des sauvegardes et des améliorations supplémentaires. Le Conseil d’administration note que l'article 3.1(b) du contrat de registre .COM stipule que, « Pendant tout le mandat du contrat et selon les présentes conditions, l'opérateur de registre doit pleinement respecter et mettre en œuvre toutes les politiques de consensus se trouvant sur http://www.icann.org/en/general/consensus-policies.htm, à la date d'entrée en vigueur, et pouvant être développées et adoptées dans le futur conformément aux statuts constitutifs de l'ICANN comme suit. »

      Le Conseil d’administration prend note des commentaires qui se sont opposé au renouvellement prématuré du contrat de registre .COM et du lien avec le contrat de services pour la maintenance de la zone racine (RZMA). Ces commentaires ont noté que l'infrastructure du responsable de la maintenance de la zone racine n'aurait jamais dû devenir « inextricablement liée » aux activités .COM de Verisign. Certains se sont demandé comment le fait de lier les deux contrats pourrait améliorer la sécurité, la stabilité et la résilience des activités de la zone racine et ont déclaré que ce lien représentait une source simple de défaillance. Certaines personnes conseillent au personnel technique de l'ICANN de commencer à étudier la manière dont une certaine séparation pratique entre la zone racine et les fonctionnements techniques du .COM peut avoir lieu si la question est soulevée, et pour garantir que de telles mesures n'engendrent pas de menace à la sécurité et la stabilité du DNS.

      Le Conseil d’administration note que Verisign a fourni des « services d'enregistrement » en vertu de son accord de coopération avec la NTIA depuis de nombreuses années, qui a été largement défini pour inclure la fonction de responsable de la maintenance de la zone racine et les services d'enregistrement du domaine de premier niveau .COM. Étant donné le caractère unifié de ces deux fonctions en vertu de l'accord de coopération, une grande partie de l'infrastructure soutenant la fonction de responsable de la maintenance de la zone racine est « liée » avec le fonctionnement du TLD .COM par Verisign. S'assurer que ces opérations continuent de bénéficier de son association historique avec les activités du .COM a été l'élément clé pour garantir la sécurité des opérations de la zone racine. Cet objectif a été assuré par l'extension simple proposée au contrat de registre .COM afin de coïncider avec le mandat du nouveau RZMA. Bien que les termes des contrats sont liés dans le sens où ils pourraient expirer en même temps, les contrats ne contiennent aucune disposition en lien avec l'exécution des obligations en vertu du contrat de registre .COM et les obligations en vertu du RZMA. En réalité, le contrat de services pour la maintenance de la zone racine (RZMA) approuvé par le Conseil d’administration de l'ICANN le 9 août 2016 prévoit des dispositions qui donnent à la communauté la possibilité, à partir d'un consensus de la communauté et d'un processus mené par la communauté, de demander à l'ICANN le transfert de la fonction de responsable de la maintenance de la zone racine vers un autre fournisseur de services trois ans après la date de mise en vigueur de ce contrat.

      Le Conseil d’administration prend note des commentaires affirmant que de ne pas demander au .COM de se soumettre à de nouvelles améliorations, sauvegardes et protections de la propriété intellectuelle dans le contrat de registre des nouveaux gTLD soulève des inquiétudes quant à savoir si l'ICANN respecte ses valeurs fondamentales en lien avec un traitement non-discriminatoire ou préférentiel, en servant l'intérêt public, la transparence et la compétitivité.

      Le Conseil d’administration note que les statuts constitutifs énumèrent les valeurs fondamentales qui devraient guider les décisions et les mesures prises par l'ICANN en réalisant ses missions, et l'ICANN prend au sérieux son engagement face à ces valeurs. Conformément aux statuts constitutifs, les « valeurs fondamentales » sont délibérément exprimées en termes très généraux pour pouvoir ainsi apporter des conseils utiles et pertinents dans l'éventail le plus complet de circonstances possibles. Et puisque ces valeurs ne représentent pas une norme stricte, le fait qu'elles s'appliquent de manière individuelle ou collective à chaque nouvelle situation va nécessairement dépendre de nombreux facteurs qui ne peuvent être pleinement anticipés ou énumérés ; et comme ce sont des déclarations de principe plus que des mises en pratique, certaines situations vont inévitablement se présenter pour lesquelles une fidélité parfaite et simultanée aux onze valeurs fondamentales n'est pas possible. Lorsqu’un organe de l’ICANN effectue une recommandation ou prend une décision, il lui appartient de juger quelles sont les valeurs fondamentales les plus importantes et comment elles doivent s’appliquer aux circonstances précises du cas en question, ainsi que de déterminer, si nécessaire, un équilibre approprié et justifiable entre les valeurs en concurrence ». Lorsqu'il étudie les commentaires et l'approbation de l'amendement proposé, le Conseil d’administration prend en considération les valeurs fondamentales pertinentes de façon à équilibrer les priorités.

      Le Conseil d’administration approuve les commentaires concernant les questions de concurrence et assurant une certaine égalité des chances. Le chapitre II article 3 des statuts constitutifs de l'ICANN stipule, « l'ICANN ne doit pas appliquer ses normes, politiques, procédures ou pratiques de manière inégalitaire ou choisir une partie en particulier et réaliser un traitement différent à moins que ce ne soit justifié par une raison importante et raisonnable comme la promotion d'une concurrence effective. » Le Conseil d’administration note que le contrat de registre .COM contient beaucoup de termes différents qui ne sont pas présents dans les autres contrats de registre. Ces modalités uniques pourraient être considérées comme favorables ou non selon les points de vue. Par exemple, la disposition relative au contrôle des prix de l'article 7.3 du contrat de registre .COM contrôle largement la capacité de l'opérateur de registre à augmenter les prix d'une manière qui n'est présente dans aucun autre contrat de registre.

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

      L'ICANN a mené une révision des résultats récents de Verisign en vertu du contrat de registre .COM actuel et a estimé que Verisign respectait en grande partie ses exigences contractuelles.

      L'approbation de l'amendement proposé par le Conseil d’administration a pour but d'assurer une exploitation continue stable, sécurisée et fiable du TLD .COM.

      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 n'y a pas de répercussions financières prévues si le Conseil d’administration approuve l'amendement proposé.

      Y a-t-il des implications en termes de sécurité/stabilité/résilience du DNS ?

      Aucun problème de sécurité, de stabilité ou de résilience du DNS n’est à prévoir si le Conseil d'administration approuve l'amendement proposé.

    4. Éléments de gouvernance de la PTI - Adoption des statuts constitutifs de la PTI ; Nomination des premiers administrateurs du Conseil d’administration de la PTI ; Nomination du président de la PTI

      Statuts constitutifs de la PTI

      Attendu que, il est jugé dans le meilleur intérêt pour la PTI en tant qu'organisation publique californienne à but non lucratif que ces statuts constitutifs soient adoptés.

      Attendu que, ces statuts constitutifs initiaux de la PTI ont été développés afin d'être conformes aux exigences de la proposition de l'ICG telle que reçue par le Conseil d’administration de l'ICANN le 10 mars 2016, y compris par le biais de la coordination avec le CWG-supervision et son conseil externe.

      Attendu que, les statuts constitutifs initiaux de la PTI ont été soumis à une période de consultation publique de 30 jours, du 12 juillet 2016 au 11 août 2016 avec quatre commentaires reçus. Le personnel de l'ICANN a développé une analyse récapitulative et a établi un rapport identifiant comment chaque commentaire a été pris en considération et traité, et l'ICANN a collaboré avec le conseil externe du CWG-supervision à propos des révisions.

      Attendu que, le conseiller juridique de l'ICANN a affirmé que les statuts constitutifs de la PTI proposés restent conformes avec la proposition de l'ICG et recommande que l'ICANN en tant que membre unique de la PTI, procède à l'approbation.

      Attendu que, les statuts constitutifs de la PTI n'entreront pas en vigueur avant qu'ils ne soient approuvés à la fois par le Conseil d’administration de la PTI et l'ICANN en tant que membre unique.

      Il est résolu (2016.09.15.10) que le Conseil d’administration de l'ICANN, en tant que membre unique de la PTI, approuve les statuts constitutifs disponibles ici <https://www.icann.org/iana_imp_docs/109-revised-pti-bylaws_18aug16-v-v1> [DOCX, 72 KB] en tant que statuts constitutifs initiaux de la PTI.

      Le président de la PTI

      Attendu que, conformément à l'article 7.2 des statuts constitutifs de la PTI, l'ICANN en tant que membre unique est autorisé à nommer le président de la PTI.

      Il est résolu (2016.09.15.11) que le Conseil d’administration de l'ICANN, en tant que membre unique de la PTI, nomme par la présente Elise Gerich en tant que présidente de la PTI.

      Conseil d’administration de la PTI - Premiers administrateurs

      Attendu que, l'ICANN en tant que membre unique de la PTI a l'obligation de nommer tous les membres du Conseil d’administration de la PTI conformément au chapitre 5 des statuts constitutifs de la PTI.

      Attendu que, les statuts constitutifs de la PTI, à l'article 5.2.1 autorisent le Conseil d’administration de la PTI à avoir cinq administrateurs.

      Attendu que, l'ICANN en tant que membre unique de la PTI, doit nommer quatre premiers administrateurs au Conseil d’administration de la PTI, deux étant des employés de l'ICANN ou de la PTI, et deux étant des candidats identifiés par le groupe de travail intercommunautaire pour développer une proposition de transition de la supervision IANA relative aux fonctions de nommage, conformément à l'article 5.2.2.2 des statuts constitutifs de la PTI.

      Attendu que, l'ICANN en tant que membre unique de la PTI doit nommer le président du Conseil d’administration de la PTI. Elise Gerich a été nommée présidente de la PTI. Le président de la PTI siège au Conseil d’administration de la PTI au titre de membre d'office avec un mandat qui correspond à ses services en tant que président de la PTI.

      Attendu que, l'ICANN recommande que Akram Atallah, président de la division des domaines mondiaux de l'ICANN et David Conrad, directeur de la technologie agissent en tant que premiers administrateurs et employés de l'ICANN ou de la PTI.

      Attendu que, le CWG-supervision recommande que Lise Fuhr et Jonathan Robinson agissent en tant que premiers administrateurs.

      Il est résolu (2016.09.15.12) que l'ICANN, en tant que membre unique de la PTI, nomme Akram Atallah, David Conrad, Lise Fuhr et Jonathan Robinson en tant que premiers administrateurs de la PTI avec des mandats prévus par l'article 5.5 des statuts constitutifs de la PTI.

      Fondateur

      Attendu que, le 9 août 2016, le Conseil d’administration de l'ICANN a approuvé le dépôt d'un acte constitutif pour les identificateurs techniques publics (ou PTI) avec le secrétaire d'état de la Californie.

      Attendu que, pour remplir cette déclaration, l'ICANN a identifié Akram Atallah en tant que fondateur de la PTI dans l'objectif de signer et remplir l'acte constitutif de la PTI.

      Attendu que, l'acte constitutif de la PTI a été reçu par le secrétaire d'état de la Californie le 10 août 2016.

      Attendu que, Akram Atallah n'a réalisé aucun autre acte en tant que fondateur de la PTI et a envoyé une lettre de démission de sa fonction.

      Il est résolu (2016.09.15.13) que toutes les mesures prises jusqu'ici par un agent autorisé pour atteindre ou prouver l'objectif et le but des résolutions susmentionnées, sont, par la présente, approuvées, ratifiées et confirmées en tant qu'actes de la société ou d'une filiale et actes du Conseil d’administration.

      Il est résolu (2016.09.15.14) que le Conseil d’administration de l'ICANN en tant que membre unique de la PTI accepte la démission de Akram Atallah en tant que fondateur de la PTI à partir du choix susmentionné des premiers administrateurs de la PTI.

      Fondements des résolutions 2016.09.15.10 – 2016.09.15.14

      Les résolutions prises ici aujourd'hui s'acquittent des obligations de l'ICANN, en tant que membre de la PTI, pour permettre à cette dernière d'avoir la structure de gouvernance en place et de devenir opérationnelle, prête à accomplir ses tâches après la réussite de la transition de la supervision de l'IANA. Avec l'acceptation de la démission du fondateur, l'ICANN peut alors en toute transparence et d'une manière responsable face à sa communauté, avancer avec l'adoption des statuts constitutifs de la PTI, et avec la nomination du Conseil d’administration de la PTI (y compris le président). Cela va permettre au Conseil d’administration de la PTI de se réunir dans un futur proche pour mener à bien ses activités organisationnelles nécessaires, ce qui va inclure l'acceptation des statuts constitutifs de la PTI, la nomination des administrateurs, l'adoption de documents de gouvernance comme la politique de gestion des conflits d'intérêts. Le Conseil d’administration de la PTI peut également déterminer la façon dont déléguer l'autorité pour l'approbation et l'exécution des contrats nécessaires aux activités de la PTI, comme le contrat des fonctions de nommage, le contrat de services avec l'ICANN ainsi que d'autres contrats de sous-traitance entre la PTI et l'ICANN.

      Ces résolutions n'autorisent pas la PTI à exercer les fonctions de l'IANA avant que la transition de la supervision de l'IANA ne soit totale. C'est également un aspect important de la responsabilité.

      Les statuts constitutifs de la PTI sont le fruit d’un travail de collaboration entre les équipes juridiques internes et externes et d’un travail intense du CWG-Supervision. Les statuts constitutifs de la PTI ont été publiés pour une période de consultation publique de 30 jours et quatre commentaires ont été reçus. Chaque commentaire a été examiné et analysé et une explication a été donnée quant à la nécessité ou non de modifier les statuts constitutifs de la PTI afin de prendre en compte les questions soulevées dans les commentaires. En modifiant les statuts constitutifs de la PTI, l'ICANN a travaillé en étroite collaboration avec le CWG-supervision et leur conseil externe, et les révisions ont été réalisées pour garantir que les administrateurs nommés par la communauté au sein du Conseil d’administration de la PTI seront toujours présents au sein du Conseil d'administration et lors des réunions du comité du Conseil d'administration, et elles ont été reflétées de manière appropriée dans les décisions majeures demandant des seuils plus élevés qu'une simple majorité. Les statuts constitutifs de la PTI comme modifiés restent conformes avec la proposition de transition de l'ICG. Les statuts constitutifs de la PTI doivent encore être adoptés par le Conseil d’administration de la PTI de façon à ce qu'ils entrent en vigueur.

      La nomination du président de la PTI et du Conseil d’administration correspond pleinement aux obligations établies par les statuts constitutifs de la PTI, et dans le respect des recommandations de la communauté sur la composition proposée du Conseil d'administration.

      Le Conseil d’administration a fondé sa décision sur :

      Le Conseil d’administration s’est également fondé sur l’affirmation du conseiller juridique et secrétaire selon laquelle les statuts constitutifs de la PTI reflètent les propositions de transition ainsi que sur les conclusions du conseiller indépendant qui préconisent de rédiger les statuts constitutifs de la PTI en soutien à la proposition de l’ICG.

      Ces décisions confirment la volonté de l’ICANN de mettre en œuvre les propositions de transition et l’ensemble des éléments de ces propositions.

      Aucune des décisions prises aujourd'hui ne devrait avoir un impact sur la sécurité, la stabilité ou la résilience du DNS ; la PTI sera toutefois essentielle aux travaux de l’ICANN en matière de sécurité, de stabilité et de résilience. Il y aura des incidences sur les ressources en soutenant le Conseil d’administration de la PTI, tout comme sur les ressources importantes demandées pour soutenir une nouvelle filiale.

      L'approbation des statuts constitutifs de la PTI est une fonction administrative organisationnelle pour laquelle des commentaires publics ont été reçus.

      L'acceptation de la démission du fondateur, la nomination du président de la PTI et la nomination du Conseil d’administration de la PTI sont des fonctions administratives organisationnelles pour lesquelles des commentaires publics n'ont pas été nécessaires.

    5. Examen approfondi de la déclaration finale de l'IRP pour Dot Registry

      Attendu que, en vertu de l'adoption des conclusions de la majorité du panel affirmant que Dot Registry LLC est la partie gagnante dans la procédure Dot Registry c. le panel de révision indépendant de l'ICANN, le Conseil d’administration a décidé de prendre en considération les étapes suivantes par rapport à la demande de réexamen de Dot Registry ou les nouveaux gTLD pertinents avant que le Conseil d'administration ne prenne d'autres mesures. (Voirhttps://www.icann.org/resources/board-material/resolutions-2016-08-09-en - 2.g.)

      Attendu que, le Conseil d’administration n'a pas noté que la majorité du panel dans l'IRP Dot Registry n'avait pas fait de recommandations spécifiques au Conseil d'administration en vue des étapes suivantes.

      Attendu que, le Conseil d’administration a également pris note des diverses correspondances et commentaires reçus, entre autres, de Dot Registry dans le cadre de cette question.

      Attendu que, la majorité du panel dans l'IRP Dot Registry a déclaré que le comité de gouvernance du Conseil d'administration (BGC) a agi conformément aux statuts et à l'acte constitutif en évaluant les demandes de réexamen 14-30, 14-32 et 14-33. (Voir la déclaration finale, ¶ 151, disponible sur https://www.icann.org/en/system/files/files/irp-dot-registry-final-declaration-redacted-29jul16-en.pdf [PDF, 12.9 MB].)

      Attendu que, la majorité du panel a déclaré que « le Conseil d’administration (agissant par le biais du BGC) n'a pas fait preuve de la diligence raisonnable et de la prudence qui lui auraient permis de disposer d'une quantité raisonnable de faits et n'a pas respecté ses obligations en matière de transparence à la fois en ne rendant pas les recherches disponibles sur lesquelles l'EIU et le personnel de l'ICANN se sont prétendument appuyé et en ne rendant pas public le travail du personnel de l'ICANN sur lequel le BGC s'est appuyé. La majorité du panel a, en outre, conclu que les preuves portées à sa connaissance ne sont pas suffisantes pour déterminer que le Conseil d’administration (agissant via le BGC) a fait preuve d'indépendance dans le rendu des décisions relatives au réexamen. » (Voir id, ¶ 152)

      Il est résolu (2016.09.15.15) que le Conseil d’administration demande au BGC d'évaluer à nouveau les demandes de réexamen 14-30, 14-32 et 14-33 de Dot Registry à la lumière de la déclaration finale de la majorité du panel dans l'IRP Dot Registry ainsi que les questions identifiées dans le cadre des mesures prises par le BGC en évaluant ces demandes de réexamen.

      Fondements de la résolution 2016.09.15.15

      Dot Registry LLC (Dot Registry) a engagé un processus de révision indépendante (IRP) visant à contester le refus du Comité de gouvernance du Conseil d’administration (BGC) d’examiner les demandes de réexamen de Dot Registry eu égard aux rapports du panel d’évaluation de la priorité communautaire (CPE) en vertu desquels les candidatures de Dot Registry pour .INC, .LLC et .LLP, respectivement, n’ont pas été retenues lors de la CPE (IRP Dot Registry).

      Dot Registry a fait une demande d’exploitation des nouveaux domaines de premier niveau .LLC, .INC et .LLP. Dot Registry est l’un des neuf candidats pour .LLC, l’un des onze candidats pour .INC et l’un des quatre candidats pour .LLP. Toutefois, Dot Registry n’est pas le seul candidat ayant soumis des candidatures communautaires pour ces gTLD.

      Les panels de CPE chargés d’évaluer les candidatures de Dot Registry (les panels de CPE) ont déterminé que les candidatures ne respectaient pas les critères requis afin d’être retenues lors de la CPE ne remplissant que cinq des 14 points requis (Rapports de CPE). Dot Registry a déposé les demandes de réexamen 14-30, 14-32 et 14-33 afin que soient réexaminés les rapports de CPE. Le 24 juillet 2014, le Comité de gouvernance du Conseil d’administration (BGC) a rejeté les demandes de réexamen car il estimait que Dot Registry « n’avait pu prouver que les panels avaient agi en violation de la politique ou de la procédure établie en rendant leurs rapports de CPE respectifs »….

      Dot Registry a engagé l'IRP Dot Registry le 22 septembre 2014 en contestant le rejet par le BGC des demandes de réexamen de Dot Registry ainsi que la nomination par l’ICANN de l’Economist Intelligence Unit (EIU) en tant que fournisseur tiers chargé de procéder aux CPE et la réponse du Conseil d’administration à l’avis du Comité de gouvernance du Conseil d’administration de l’ICANN concernant .LLC, .INC et .LLP.

      Dans une décision 2-1, la majorité du panel a déclaré que Dot Registry avait obtenu gain de cause et que « les actions et omissions du Conseil d’administration n’étaient pas conformes à l’acte et aux statuts constitutifs de l’ICANN ». (Voir la déclaration finale à 151.) Plus particulièrement, la majorité du panel a déclaré que « le Conseil d’administration (agissant via le BGC) n’a pas fait preuve de la diligence raisonnable et de la prudence qui lui auraient permis de disposer d’une quantité raisonnable de faits et n’a pas respecté ses obligations en matière de transparence », et que les données portées à la connaissance du panel n’étaient pas suffisantes afin « d’affirmer que le Conseil d’administration (agissant via le BGC) a fait preuve d’indépendance dans le rendu des décisions relatives au réexamen ». (Id. බ 151-152) La majorité du panel a en outre déclaré que l’ICANN « doit verser 235 294,37 USD à Dot Registry au titre des frais, dépenses et honoraires précédemment engagés par Dot Registry, LLC une fois que la preuve que ces frais engagés ont été intégralement payés aura été apportée ». (Id. à 154.)

      Le Conseil d’administration a pris note que la majorité du panel a déclaré que « le panel, afin de dégager ses conclusions, n’a pas évalué si le personnel de l’ICANN ou l’EIU n’avaient eux-mêmes pas respecté les obligations prévues par l’acte et les statuts constitutifs ou le guide de candidature ». (Id. à 152.) En outre, il est également noté que « la majorité du panel a refusé de substituer son jugement à celui du panel de CPE quant au fait de savoir si Dot Registry pouvait ou non se prévaloir de la priorité communautaire ». (Id. à 153.)

      Lors de sa prise en considération initiale de la déclaration finale, le Conseil d’administration a accepté les conclusions de la déclaration finale stipulant : (i) Dot Registry a obtenu gain de cause dans l’IRP Dot Registry, LLC c. ICANN ; et (ii) l’ICANN versera 235 294,37 USD à Dot Registry une fois que la preuve que les frais engagés ont été intégralement payés aura été apportée. (Voir https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.g.)

      Le Conseil d’administration « a pris note des autres conclusions de la déclaration ainsi que des conclusions relatives aux affirmations de la majorité du panel eu égard aux normes de révision pour les demandes de réexamen susmentionnées, et étudiera les prochaines étapes à suivre concernant les demandes de réexamen de Dot Registry ou les nouveaux gTLD concernés avant de prendre toute décision. » Voir id. En outre, le Conseil d’administration a pris note que la majorité du panel n'a pas fait de recommandation spécifique concernant les prochaines étapes à suivre.

      Comme le Conseil d’administration a eu l'opportunité d'évaluer avec soin certaines des autres conclusions de la déclaration finale, il a déterminé que la meilleure approche à l'heure actuelle serait que le BGC évalue de nouveau les demandes de réexamen 14-30, 14-32 et 14-33 de Dot Registry à la lumière de la déclaration finale de la majorité du panel dans l'IRP Dot Registry ainsi que les questions identifiées dans le cadre des mesures prises par le BGC en évaluant ces demandes de réexamen.

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

      • Demande de réexamen 14-30: LLC Dot Registry (25 juin 2014)
      • Demande de réexamen 14-32: LLC Dot Registry (26 juin 2014)
      • Demande de réexamen 14-33: LLC Dot Registry (26 juin 2014)
      • Dot Registry c. le processus de révision indépendante de l'ICANN
      • Lettre [PDF, 1.13 MB] de Steve Crocker à Heather Dryden relative à : la réunion du NGPC du 5 février 2014 (10 février 2014)
      • Lettre [PDF, 148 KB] de Jeffrey W. Bullock au Conseil d’administration de l'ICANN relative à : la déclaration de l'IRP concernant LLC Dot Registry c. ICANN (8 août 2016)
        Lettre [PDF, 1.5 MB] de Shaul Jolles au Conseil d’administration de l'ICANN relative à : la réunion extraordinaire du 9 août 2016 du Conseil d'administration de l'ICANN concernant l'élément à l'ordre du jour Dot Registry LLC c. l'ICANN (01-14-0001-5004), le processus de révision indépendante (IRP), la déclaration du 29 juillet 2016 (6 août 2016)

      Cette mesure ne devrait pas avoir de répercussions financières directes sur l'organisation. Cette décision n’aura aucune incidence sur la sécurité, la stabilité ou la résilience du DNS.

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

    6. Examen du rapport du médiateur concernant la candidature dotgay LLC pour .GAY

      Aucune résolution n’est adoptée.

    7. Demande de réexamen 16-3 (dotgay LLC )

      Aucune résolution n’est adoptée.

    8. Divers

      Aucune résolution n’est adoptée.

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