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-2015-06-25-en

  1. Ordre du jour approuvé :
    1. Approbation des procès-verbaux du Conseil d'administration
    2. Nomination des représentants de l'opérateur du serveur racine B au RSSAC
    3. Rapport consultatif du SSAC sur l'utilisation deTLD statique / listes de suffixes
    4. Adoption du cadre d'interprétation pour la délégation et redélégation des ccTLD
    5. Conclusion du contrat pour le lieu de la réunion de l'ICANN de mars 2016.
    6. Conclusion du contrat pour le lieu de la réunion de l'ICANN d'octobre 2016.
    7. Reconnaissance de la communauté
    8. Remerciements aux sponsors de la 53e réunion de l'ICANN
    9. Remerciements aux interprètes, au personnel, aux équipes de l'hôtel et aux personnes chargées de l'organisation de la 53e réunion de l'ICANN
    10. Remerciement aux hôtes locaux de la 53e réunion de l'ICANN
  2. Ordre du jour principal :
    1. Perfectionnement de la deuxième révision de similarité pour l'évaluation des candidatures ccTLD IDN
    2. Approbation du budget de l'exercice fiscal 2016
    3. Approbation du paiement de certains frais juridiques liés au CWG-supervision.

 

  1. Ordre du jour approuvé :

    1. Approbation des procès-verbaux du Conseil d'administration

      Résolu (2015.06.25.01), le Conseil d'administration approuve le compte-rendu de la réunion du Conseil d'administration de l'ICANN du 26 avril 2015.

    2. Nomination des représentants de l'opérateur du serveur racine B au RSSAC

      Attendu que, les statuts constitutifs de l'ICANN exigent la création d'un comité consultatif du système des serveurs racine (RSSAC) dont le rôle est de donner son avis à la communauté de l'ICANN et au Conseil d'administration sur des questions liées à l'exploitation, l'administration, la sécurité et l'intégrité du système de serveur racine d'Internet.

      Attendu que, les statuts constitutifs de l'ICANN exigent que le Conseil d'administration nomme les membres du RSSAC sur la base des recommandations des présidents du RSSAC.

      Attendu que, les présidents du RSSAC ont recommandé au Conseil d'administration de nommer Wes Hardaker au RSSAC pour représenter l'opérateur du serveur racine B.

      Résolu (2015.06.25.02), le Conseil d'administration nomme Wes Hardaker en tant que représentant de l'opérateur du serveur racine B jusqu'au 31 décembre 2017 au Comité consultatif du système des serveurs racine.

      Fondements de la résolution 2015.06.25.02

      En mai 2013, les opérateurs des serveurs racine (RSO) ont convenu d'être représentés au sein du RSSAC, et chacun a proposé un candidat. En juillet 2013 le Conseil d'administration a approuvé ces premières candidatures, dont les mandats prendront fin à différents moments.

      USC-ISI a nommé un nouveau représentant au nom du serveur racine B, et les co-présidents du RSSAC ont recommandé que ce représentant soit formellement nommé au RSSAC. Le représentant servira pendant un mandat de trois ans, qui a commencé le 1e janvier 2015

      La nomination de ces membres du RSSAC n'est pas censée avoir un impact financier sur l'ICANN, bien que des ressources nécessaires pour le soutien permanent du RSSAC aient été prévues dans le budget.

      Cette résolution est une fonction administrative et organisationnelle pour laquelle aucune consultation publique n'est requise. La nomination des membres du RSSAC contribue à l'engagement de l'ICANN de renforcer la sécurité, la stabilité et la résilience du DNS.

    3. Rapport consultatif du SSAC sur l'utilisation deTLD statique / listes de suffixes

      Attendu que le 28 mai 2015, le Comité consultatif de l'ICANN sur la sécurité et la stabilité (SSAC) a publié le rapport SAC070 [PDF, 955 KB]: Rapport consultatif du SSAC sur l'utilisation deTLD statique / listes de suffixes

      Attendu que, dans le rapport SAC070, l'avis étudie les besoins en sécurité et stabilité entourant l'utilisation grandissante des listes publiques de suffixes (PSL) sur Internet, et propose un ensemble d'actions à court et long terme pour répondre aux compromis clés de la conception des listes publiques de suffixes.

      Attendu que, les recommandations du rapport SAC070 reflètent les actions qui ne relèvent pas de l'ICANN, à mettre en œuvre par des acteurs qui ne font pas forcément partie de la communauté ICANN, mais que ces mesures sont vouées à régler la question des responsabilités globales de la communauté multipartite et à encourager l'ICANN à agir le cas échéant.

      Attendu que, assurer le fonctionnement stable et sécurisé du système d'identificateurs uniques d'Internet est la mission et la priorité stratégique pour l'ICANN ; préserver et améliorer la stabilité, la fiabilité, la sécurité et l'interopérabilité mondiale opérationnelles d'Internet est une valeur fondamentale pour l'ICANN ; et améliorer l'acceptation des TLD est un objectif stratégique pour le programme des gTLD.

      Résolu (2015.06.25.03), le Conseil accuse réception du SAC070 : Rapport consultatif du SSAC sur l'utilisation deTLD statique / listes de suffixes

      Résolu (2015.06.25.04), le Conseil d'administration demande au Président-directeur général et CEO, ou son (ses) représentant(s), d'évaluer l'avis fourni dans le rapport SAC070 et de rédiger une recommandation pour le Conseil d'administration concernant l'acceptation de l'avis, au plus tard 90 jours après l'adoption de la présente résolution.

      Résolu (2015.06.25.05), lorsqu'il est conseillé d'accepter ces recommandations du SSAC, le Conseil d'administration demande au Président-directeur général et CEO de l'ICANN, ou son/ses représentant(s), d'évaluer la viabilité et le coût de la mise en œuvre de ces recommandations, et de fournir un plan de mise en œuvre avec des chronologies et des délais de révision de haut niveau pour le Conseil d'administration, dans les 120 jours à compter de l'adoption de cette résolution.

      Résolu (2015.06.25.06), le Conseil d'administration encourage les registres, bureaux d'enregistrement, l'initiative d'acceptation universelle, et d'autres entités tel que l'IETF, à prendre en considération les recommandations du rapport SAC070 et à travailler en collaboration afin d'améliorer la situation avec l'augmentation de l'utilisation des listes publiques de suffixes.

      Fondements des Résolutions 2015.06.25.03 et 2015.06.25.06

      Un suffixe public est « un domaine sous lequel plusieurs parties qui ne sont pas rattachées au propriétaire du domaine de suffixe public peuvent enregistrer des sous-domaines. » Exemples de domaines avec suffixes publics : org, co.uk, k12.wa.us et uk.com.

      Il n'y a pas de moyen sous forme de programme pour déterminer la limite où une étiquette du DNS modifie la supervision à partir d'un suffixe public, pourtant suivre la limite de manière précise est essentielle pour les questions de sécurité, de confidentialité et d'accessibilité dans beaucoup de systèmes et d'applications modernes tels que les navigateurs Internet.

      Le 28 mai 2015, le SSAC a publié le rapport SAC070 : Rapport consultatif du SSAC sur l'utilisation de TLD statique / listes de suffixes Dans ce rapport consultatif, le SSAC étudie les besoins en sécurité et stabilité entourant l'utilisation des listes publiques de suffixes (PSL) sur Internet. En utilisant la PSL de Mozilla comme un archétype pour étudier le paysage actuel, le SSAC trouve des usages variés des PSL. À partir de l'étude de cas, le SSAC a également extrait plusieurs difficultés potentielles avec les contenus d'une PSL ainsi que des défis opérationnels et administratifs entourant l'utilisation et la maintenance d'une PSL.

      Dans cet avis, le SSAC fait d'abord appel à l'IETF et à la communauté de candidature pour répondre directement à ces compromis clés de conception en créant, standardisant et adoptant des solutions alternatives. Ensuite, étant donné que l'utilisation des PSL aujourd'hui est très fréquente, et sachant le temps qu'il faut à l'IETF pour standardiser des solutions alternatives et à la communauté pour les déployer, le SSAC recommande un ensemble de mesures à court terme pour atténuer les aspects qui présentent les plus hauts risques avec la maintenance et l'utilisation actuelles des PSL.

      L'examen par le Conseil d'administration des recommandations adressées par les organisations de soutien et les comités consultatifs, notamment celles du SAC070, doit bénéficier d'une analyse du contenu de ces recommandations, ainsi que de la viabilité et du coût de leur mise en œuvre jugés acceptable.

    4. Adoption du cadre d'interprétation pour la délégation et redélégation des ccTLD

      Attendu que, le conseil du ccNSO a mis en place le Groupe de travail sur le cadre d'interprétation (FOIWG) en mars 2011 avec le Comité consultatif gouvernemental (GAC) pour développer des directives pour l'ICANN sur la manière dont mettre en œuvre les politiques et les principes en vigueur pour la délégation et la redélégation des ccTLD.

      Attendu que, conformément à la charte, et après un processus de consultation long et intense du FOIWG, de la communauté et des autres, le cadre d'interprétation des recommandations a été finalisé en juin 2014 lors de la réunion publique de l'ICANN à Londres et soumis au ccNSO et au GAC afin d'obtenir leur consentement sur ces recommandations.

      Attendu que, le conseil de la ccNSO a approuvé le cadre d'interprétation lors de sa réunion du 11 février 2015.

      Attendu que, bien que le GAC n'a pas officiellement approuvé le document, il a pris en considération les efforts du FOIWG comme démontré dans son communiqué du 11 février 2015, et n'a identifié aucune recommandation qu'il ne soutient pas.

      Attendu que, la mise en œuvre des recommandations va tirer profit de la participation de la communauté, y compris la ccNSO ainsi que les consultations sur le plan de mise en œuvre.

      Résolu (2015.06.25.07), le Conseil d'administration demande au Président-directeur général et CEO ou son/ses représentant(s) de développer un plan de mise en œuvre des recommandations à prendre en considération par la communauté par le biais de commentaires publics, et de mettre en œuvre le plan lorsqu'il sera finalisé.

      Résolu (2015.06.25.08), le Conseil d'administration demande à la ccNSO de nommer le plus tôt possible une petite équipe d'experts techniques qui restent disponibles pour aider le personnel de l'ICANN sur les questions de mise en œuvre qui surviennent pendant le développement du plan de mise en œuvre et d'informer l'ICANN des nominations.

      Fondements des Résolutions 2015.06.25.07 et 2015.06.25.08

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

      Dans le cadre de son mandat, le Groupe de travail sur le cadre d'interprétation (FOIWG) a développé un cadre d'interprétation des politiques actuelles, pour apporter « un guide clair à l'IANA et au Conseil d'administration de l'ICANN 1» quant à la manière dont l'ICANN devrait interpréter les politiques actuelles dans sa gestion quotidienne. Le travail du FOIWG a entraîné un ensemble de recommandations déterminé par le groupe de travail nécessaires pour apporter plus de clarté aux processus de l'ICANN. Le Conseil d'administration ratifie ces recommandations, faisant suite à l'adoption des recommandations par le conseil de la ccNSO et la non-objection du Comité consultatif gouvernemental (GAC), et la communication officielle des recommandations du Conseil d'administration en mars 2015.

      Quelle est la proposition à l'étude ?

      La ccNSO a recommandé que l'ICANN adopte le cadre d'interprétation et adopte la documentation comme directive précise sur l'interprétation des politiques existantes en vigueur, en particulier dans le cadre de domaines comme l'obtention et la documentation du consentement, provenant de parties intéressées importantes, et des procédures pour les redélégations non consenties.2

      Le conseil de la ccNSO a, de plus, recommandé au Conseil d'administration de l'ICANN que certains documents dont les principes du GAC 2000 (que le GAC a remplacé en 2005), l'ICP-1 de l'ICANN (https://www.icann.org/resources/pages/delegation-2012-02-25-en) et le Mémo de nouvelles 1 (http://www.iana.org/reports/1997/cctld-news-oct1997.html) devraient être archivés et considérés comme plus utilisés par le personnel de l'ICANN.3

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

      Le FOIWG a développé ses recommandations initiales en décembre 2011. Comme exigé par sa charte, ce rapport provisoire et ces recommandations ont été publiés et soumis à commentaire public par la communauté de l'ICANN. La présentation de la publication de documents principaux et de consultations publiques est incluse dans le rapport final du FOIWG (Annexe F) [PDF, 3.44 MB].

      De façon à garder la communauté informée des progrès réalisés, le FOIWG a régulièrement publié des rapports relatifs aux progrès4, a apporté des mises à jour et a présenté ses conclusions à la communauté ccTLD et au GAC pendant les réunions successives depuis mars 2011.

      Pour finir, selon la charte du FOIWG, il serait demandé à la ccNSO et au GAC d'appuyer ou de soutenir chaque recommandation des rapports d'interprétation (au consentement, parties intéressées importantes et révocation). En ce sens, les recommandations d'interprétations sur le « consentement » ont été soumises au Conseil d'administration de l'ICANN en mars 2012. Cependant, en prenant en compte la durée du processus et le besoin d'assurer une cohérence à travers les ensembles de recommandations d'interprétations, la ccNSO et le GAC sont parvenus à un accord sur le fait que le soutien et l'approbation seraient sollicités pour l'ensemble des recommandations (http://ccnso.icann.org/workinggroups/foi-progress-report-02oct12-en.pdf [PDF, 63 KB]). En octobre 2014, le conseil de la ccNSO a exprimé son aide temporaire au travail du FOIWG, jusqu'à ce que le GAC expose une position claire. Il a été demandé aux présidents de la ccNSO et du FOIWG de travailler avec le président du GAC et les membres du GAC intéressés, afin de chercher activement un soutien pour le cadre d'interprétation (http://ccnso.icann.org/workinggroups/foi-adoption-final-20oct14-en.pdf [PDF, 65 KB]). En février 2015, la ccNSO et le GAC ont eu un échange final, constructif de points de vue quant aux questions soulevées par le FOIWG et le GAC a fait remarquer le travail du FOIWG de la ccNSO et leurs efforts pour apporter une clarté d'interprétation au RFC 1591, et il n'a pas déclaré qu'il ne soutenait pas les recommandations. (https://www.icann.org/en/system/files/correspondence/gac-to-board-11feb15-en.pdf [PDF, 113 KB]) Le Conseil d'administration de l'ICANN en a été dûment informé.

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

      Le Conseil d'administration a pris les décisions suivantes :

      Rapport final du FOIWG : http://ccnso.icann.org/workinggroups/foi-final-07oct14-en.pdf [PDF, 3.44 MB]

      Résolution du conseil de la ccNSO 11 février 2015 : http://ccnso.icann.org/workinggroups/foi-final-resolutions-11feb15-en.pdf [PDF, 66 KB]

      Communiqué du GAC, Singapour, février 2015 :https://gacweb.icann.org/download/attachments/27132037/GAC_SINGAPORE52_COMMUNIQUE_FINAL2.pdf?version=1&modificationDate=1423724031000&api=v2 [PDF, 113 KB]

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

      Le Conseil d'administration a noté que selon le contrat des fonctions IANA entre le gouvernement américain et l'ICANN, les questions de mise en œuvre du contrat ou les procédures en lien avec le contrat étaient en dehors de la portée du groupe de travail. Il convient de noter que les recommandations n'amendent pas, ne mettent pas à jour ni ne modifient les politiques actuelles.

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

      Les recommandations devraient avoir un impact positif sur la communauté à travers la mise en œuvre de clarifications souhaitées face aux procédures requises comme le résultat d'une analyse approfondie par le groupe de travail. En particulier, les recommandations apportent des détails spécifiques sur les aspects du traitement qui devraient apporter une clarification à ceux impliqués dans les processus de redélégation et délégation.

      Y a-t-il des impacts financiers ou des répercussions à prévoir sur l'ICANN (plan stratégique, plan opérationnel, budget), la communauté et/ou le public ?

      La mise en œuvre du cadre d'interprétation serait menée par le département IANA de l'ICANN. À la base, elle exigera le développement d'un plan de mise en œuvre. En suivant l'accord sur le processus, la mise en œuvre elle-même exigera le développement d'améliorations des systèmes existants, une documentation interne mise à jour, et la formation et la réalisation de tests de cette documentation et des systèmes examinés parmi le personnel impliqué dans le traitement de telles demandes. Il a également été demandé au personnel de rentrer en contact avec la communauté pour clarifier certains détails de mise en œuvre des recommandations du cadre d'interprétation ; au personnel de développer des logiciels, des outils et des programmes améliorés pour la création de rapports ; et un soutien du département des communications pour aider dans le plan de communication. Certains aspects des recommandations appartiennent au domaine juridique (comme l'obtention d'un consentement valide correctement documenté) et pour cela, le département de l'IANA va demander un dialogue avec l'équipe juridique de l'ICANN et peut-être d'autres experts afin de saisir les détails de mise en œuvre appropriés.

      Il est à noter que certains aspects des recommandations peuvent être éclairés par les développements dans la supervision globale des fonctions IANA. Bien que l'intention soit de développer une mise en œuvre qui correspond à l'environnement général de contrôle par la NTIA, la mise en œuvre peut avoir besoin de réexamen à la lumière des changements au-delà du rôle de transition de supervision de la NTIA.

    5. Conclusion du contrat pour le lieu de la réunion de l'ICANN de mars 2016.

      Attendu que l'ICANN souhaite organiser sa première réunion publique de 2016 en Afrique.

      Attendu que, Marrakech au Maroc a déjà été choisie comme lieu pour la réunion de l'ICANN de mars 2016.

      Résolu (2015.06.25.09), le Conseil d'administration autorise le président-directeur général, ou son ou ses représentant(s), à gérer et faciliter tous les aspects liés aux contrats et aux déboursements pour le lieu d'accueil de la réunion publique de l'ICANN de mars 2016, à Marrakech au Maroc, jusqu'à concurrence de [À REMPLIR APRÈS NÉGOCIATIONS].

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

      Fondements des Résolutions 2015.06.25.09 et 2015.06.25.10

      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 55e réunion de l'ICANN, prévue du 5 au10 mars 2016, doit avoir lieu dans la région géographique de l'Afrique. Étant donné que la réunion publique de l'ICANN de février 2015, initialement prévue à Marrakech au Maroc, s'est finalement tenue à Singapour, l'ICANN a décidé d'organiser la réunion publique de l'ICANN de mars 2016 à Marrakech au Maroc.

      Le personnel a examiné avec attention les endroits possibles afin de s'assurer qu'ils répondent aux éléments principaux des Critères de sélection du lieu de réunion (voir http://meetings.icann.org/location-selection-criteria). À partir de cette analyse, l'ICANN a identifié le lieu pour l'ICANN 55.

      Le Conseil d'administration a examiné la présentation du personnel quant au lieu d'accueil de la réunion publique de mars 2016 qu'est Marrakech au Maroc, et a confirmé que la proposition répondait aux facteurs importants des Critères de sélection du lieu de réunion, ainsi que les coûts liés au lieu choisi.

      Les frais d'organisation de la réunion auront 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 de l'emplacement de la réunion. Cette décision n'aura aucune incidence sur la sécurité ou la stabilité du DNS.

      Il s'agit d'une fonction administrative et organisationnelle de l'ICANN qui ne nécessite pas de consultation publique.

    6. Conclusion du contrat pour le lieu de la réunion de l'ICANN d'octobre 2016.

      Attendu que l'ICANN a l'intention d'organiser sa troisième réunion publique de 2016 dans la région de l'Amérique du nord.

      Attendu que le personnel a effectué une révision approfondie des lieux proposés pour tenir sa réunion en Amérique du nord, et que le site le plus approprié a été identifié à San Juan, Porto-Rico.

      Résolu (2015.06.25.11), le Conseil d'administration autorise le Président-directeur général, ou son/ses représentant(s), à s'engager et faciliter tous les contrats et les déboursements nécessaires pour l'hôtel d'accueil de la réunion publique de l'ICANN d'octobre 2016, à San Juan, Porto-Rico, pour un montant ne devant pas dépasser [À remplir après négociations], et que la réunion publique d'octobre 2016 soit désignée comme réunion annuelle de 2016.

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

      Fondements des Résolutions 2015.06.25.11 et 2015.06.25.12

      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 57e réunion, prévue du 29 octobre 2016 au 4 novembre 2016, aura lieu dans la région géographique Amérique du nord. Un appel à recommandations concernant le lieu de la réunion en Amérique du nord a été publié le 23 mars 2015. L'ICANN a reçu de nombreuses propositions.

      Le personnel a examiné avec attention les propositions, ainsi que d'autres lieux, et a ensuite rédigé un document afin de déterminer quels sites remplissaient les Critères de sélection du lieu de réunion (voir http://meetings.icann.org/location-selection-criteria). Sur la base des propositions et de cet examen, l'ICANN a identifié San Juan, Porto-Rico, comme lieu de la 57e réunion de l'ICANN.

      Le Conseil d'administration a examiné la présentation du personnel quant au lieu de la réunion publique de l'ICANN d'octobre 2016, qu'est San Juan à Porto Rico, et a confirmé que la proposition répondait aux facteurs importants des Critères de sélection du lieu de réunion, ainsi que les coûts liés au lieu choisi.

      Les frais d'organisation de la réunion auront 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 de l'emplacement 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 adressé des propositions de lieux pour la 57e réunion de l'ICANN.

      Il s'agit d'une fonction administrative et organisationnelle de l'ICANN qui ne nécessite pas de consultation publique.

    7. Reconnaissance de la communauté

      Attendu que l'ICANN tient à remercier les membres de la communauté des parties prenantes pour l'énergie et les compétences qu'ils lui apportent ;

      Attendu qu'en reconnaissance de leurs contributions l'ICANN souhaite remercier les membres de la communauté lorsque leur mandat au sein des organisations de soutien et des comités consultatifs s'achève.

      Attendu que le mandat du membre suivant de la communauté At-Large arrive à son terme :

      • Evan Leibovitch – Secrétaire NARALO, Président du groupe de travail des nouveaux gTLD At-large, et co-président du groupe de travail pour les futurs défis At-Large

      Résolu (2015.06.25.13), les services de Evan Leibovitch pendant son mandat lui ont valu la profonde appréciation du Conseil d'administration, qui lui souhaite beaucoup de succès dans ses projets à venir au sein de la communauté de l'ICANN et au-delà.

      Attendu que le mandat du membre suivant du groupe de travail sur la sécurité publique (PSWG) touche à sa fin :

      • Richard "Dick" Leaning – Groupe de travail sur la sécurité publique (PSWG)

      Attendu que, Richard "Dick" Leaning a aidé à la création de la charte du Groupe de travail sur la sécurité publique, un sous-groupe du Comité consultatif gouvernemental (GAC).

      Attendu que, ses efforts ont grandement contribué à rapprocher la communauté en charge de l'application de la loi internationale de l'ICANN.

      Résolu (2015.06.25.14), les services de Richard "Dick" Leaning pendant son mandat lui ont valu la profonde appréciation du Conseil d'administration, qui lui souhaite beaucoup de succès dans ses projets à venir au sein de la communauté de l'ICANN et au-delà.

      Attendu que, le membre suivant du Groupe des représentants des bureaux d'enregistrement au sein de l'Organisation de soutien aux extensions génériques (GNSO) est reconnu pour ses services :

      • Robert "Bob" Connelly – Fondateur du Groupe des représentants des bureaux d'enregistrement

      Résolu (2015.06.25.15), Robert Connelly a gagné la profonde gratitude du Conseil pour ses services.

    8. Remerciements aux sponsors de la 53e réunion de l'ICANN

      Le Conseil tient à remercier les sponsors suivants : Le Conseil tient à remercier les sponsors suivants : Verisign, Inc., NCC Group, le Centre d'échange d'information sur les marques, Uniregistry Corp., LogicBoxes, Centre d'information de réseaux de Chine (CNNIC), Afilias plc, CentralNic, dotAmsterdam BV, Registre d'intérêt public, Neustar, Beijing Internet Institute, Minds + Machines Group, Iron Mountain, Inc., ION Magazine, Radix FZC, et InterConnect Communications Ltd.

    9. Remerciements aux interprètes, au personnel, aux équipes de l'hôtel et aux personnes chargées de l'organisation de la 53e réunion de l'ICANN

      Le Conseil exprime sa gratitude aux transcripteurs, aux interprètes, à l'équipe audiovisuelle, aux équipes techniques et à l'ensemble du personnel de l'ICANN pour les efforts réalisés afin de faciliter le bon déroulement de la réunion.

      Il souhaite également remercier la direction et le personnel de Sheraton Buenos Aires Hotel & Convention Center pour avoir prêté leurs merveilleux locaux pour l'occasion. Un remerciement tout particulier à George Handley, Directeur des ventes, Federico Scoffano, Responsable des ventes Banquet, Mariana Cordiano, Cooridnatrice Banquet, Javier González Alemán, Directeur général, Loreley Ciardonei, Coordinatrice Banquet et Pablo Rago, Coordinateur du groupe. Le Conseil d'administration souhaite également remercier la direction et le personnel du Park Tower Hotel. Remerciements spéciaux également pour María Verónica Rimolo, Responsable événementiel, et Florencia Picca, Responsable des ventes internationales. Pour finir, le Conseil d'administration souhaite également remercier la direction et le personnel du Melia Hotel. Remerciements particuliers pour Estefania Bonofiglio, Responsable des réservations, et Julieta Giusti, Directrice commerciale.

    10. Remerciement aux hôtes locaux de la 53e réunion de l'ICANN

      Le Conseil tient à exprimer ses remerciements à NIC.AR, pour son soutien. Remerciements tout particulier pour Gabriel Brenta, Directrice nationale, Carlos Liuzzi, Directeur, Relations internationales, Lucila Abate, Unité des relations internationales, et le personnel complet de NIC.AR.

      Le Conseil d'administration remercie également M. Anibal Fernandez, Chef de cabinet des ministres d'Argentine, pour son soutien et sa participation à la réunion.

  2. Ordre du jour principal :

    1. Perfectionnement de la deuxième révision de similarité pour l'évaluation des candidatures ccTLD IDN

      Attendu que le Conseil d'administration a approuvé le plan de mise en œuvre de la procédure accélérée ccTLD IDN le 30 octobre 2009(http://www.icann.org/en/minutes/resolutions-30oct09-en.htm#2).

      Attendu que la ccNSO a développé et que le conseil de la ccNSO a approuvé les recommandations pour la politique de sélection des chaînes ccTLD IDN d'inclure un processus à deux panels pour l'évaluation de la similarité des chaînes (http://ccnso.icann.org/node/38787).

      Attendu que l'ICANN a reçu de nombreux commentaires et conseils de la communauté réclamant davantage de transparence et de cohérence dans la démarche d'évaluation de la similarité de chaînes, y compris l'avis du comité consultatif gouvernemental (GAC).

      Attendu que le président de la ccNSO a envoyé au Conseil d'administration de l'ICANN une demande de mise en place d'un processus à deux panels pour évaluer la similarité des chaînes dans la procédure accélérée des ccTLD IDN.

      Attendu que, le Conseil d'administration de l'ICANN a approuvé la mise à jour de la mise en œuvre de la procédure accélérée ccTLD IDN pour mettre en place le processus de deux panels chargé de la révision de la similarité de chaînes au sein du processus accéléré ccTLD IDN le 27 juin 2013(https://www.icann.org/resources/board-material/resolutions-2013-06-27-en#2.a).

      Attendu que, le Conseil d'administration de l'ICANN a approuvé pour toutes les demandes en cours des chaînes ccTLD IDN se trouvant sous la procédure accélérée d'avoir l'option de demander une évaluation au panel chargé du processus étendu de révision de similarité de chaînes (EPSRP), le cas échéant.

      Attendu que, à la demande de tout candidat concerné, les demandes en cours pour les chaînes ccTLD IDN se trouvant sous la procédure accélérée ont été évaluées par l'EPSRP, et celui-ci a rédigé des rapports pour les trois candidatures qui ont été publiées avec les résultats de l'évaluation sur le site Internet de l'ICANN le 14 octobre 2014(https://www.icann.org/resources/pages/epsrp-reports-2014-10-14-en).

      Attendu que, les retours du public ont été reçus pendant la troisième révision annuelle de la procédure accélérée ccTLD IDN sur les questions liées à la méthodologie expérimentale et les résultats ont été rapportés par l'EPSRP le 17 mars 2015 (https://www.icann.org/public-comments/idn-cctld-fast-track-2015-01-15-en).

      Résolu (2015.06.25.16), le Conseil d'administration a demandé à la ccNSO, en consultation avec les autres parties prenantes, dont le GAC et le SSAC, d'apporter plus de conseils et de perfectionnement sur la méthodologie du deuxième processus d'examen de similarité des chaînes, y compris l'interprétation de ses recommandations, à appliquer aux cas appropriés actuels et futurs dans la procédure accélérée ccTLD IDN ainsi que d'éclairer les politiques proposées pour le choix de chaînes ccTLD IDN.

      Fondements de la résolution 2015.06.25.16

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

      Le 5 novembre 2013, l'ICANN a publié une mise à jour du plan de mise en œuvre final pour la procédure accélérée ccTLD IDN [PDF, 851 KB] (le « Plan de mise en œuvre ») avec les changements demandés pour la mise en place d'un processus de révision de similarité de chaînes comportant deux panels, comme résolu par le Conseil d'administration de l'ICANN le 27 juin 2013 conjointement avec les lignes directrices pour le processus étendu du panel de révision de la similarité [PDF, 86 KB] (les « Lignes directrices ») développées par la résolution du Conseil d'administration.

      À partir de la révision, trois candidats à la procédure accélérée ccTLD IDN ont exercé leur option dans le délai prévu de 90 jours, et ont demandé une deuxième révision de similarité par le nouveau panel chargé du processus élargi de révision de similarité de chaînes (EPSRP). Cela comprenait les demandes ccTLD IDN pour Bulgarie (en cyrillique), Union Européenne (en grec) et Grèce (en grec).

      La deuxième révision de similarité de chaînes par l'EPSRP, basée sur les lignes directrices, a été réalisée et le panel a soumis les rapports rapports correspondants à l'ICANN, qui ont également été partagés avec les candidats et publiés sur le site Internet de l'ICANN le 14 octobre 2014, conformément avec le plan de mise en œuvre et les lignes directrices. Pour chaque candidature, le rapport correspondant inclut une description détaillée de la méthodologie et des résultats expérimentaux distincts concernant une confusion avec la chaîne objet de la candidature et la forme des majuscules de la chaîne comme déterminé par le panel, sans recommandation regroupée sur l'acceptation ou le rejet de la chaîne dans le contexte de candidature de procédure accélérée ccTLD IDN, étant donné que la panel a considéré, d'un point de vue purement visuel, que les caractères minuscules et majuscules sont des éléments différents. Là où les recommandations du panel sont divisées, il n'y pas de lignes directrices explicites sur la manière de déduire la recommandation regroupée, étant donné que le panel a considéré la décision finale comme étant une question de politique pour des cas où seulement une majuscule ou minuscule pour une chaîne donnée a été jugée visuellement troublante.

      De plus, durant la révision annuelle de la procédure accélérée ccTLD IDN, l'ICANN a reçu les commentaires publics, qui soulèvent des questions avec la méthodologie suivie par l'EPSRP et les retours sur la manière de répondre aux résultats.

      La méthodologie détaillée et les résultats publiés dans les rapports et les commentaires publics donnent à la communauté une opportunité de perfectionner la méthodologie pour la deuxième révision de similarité pour la procédure accélérée ccTLD IDN et pour la politique proposée ccTLD IDN, conformément à la résolution. Cela va également permettre à l'ICANN de déterminer la manière dont rapprocher la candidature restante pour la procédure accélérée ccTLD IDN avec les résultats rapportés par l'EPSRP.

      Quelle est la proposition à l'étude ?

      Le Conseil d'administration demande aujourd'hui à la ccNSO, en consultation avec d'autres parties prenantes, y compris le GAC et le SSAC de revoir et de perfectionner la deuxième révision de similarité en se basant sur la méthodologie et les résultats rapportés par l'EPSRP ainsi que les commentaires publics reçus. Le processus de perfectionnement doit prendre en considération, entre autres, à la fois l'avis du GAC [PDF, 122 KB] pour un processus transparent qui n'est pas « trop conservateur » ainsi que les questions de sécurité et de stabilité liées à la l'évaluation de la similarité de chaînes.

      Cela va perfectionner la mise en œuvre actuelle de la procédure accélérée ccTLD IDN et également éclairer la politique ccTLD IDN proposée, actuellement à l'étude.

      Quelles parties intéressées ou autres ont été consultées? Quelles sont les préoccupations ou les questions soulevées par la communauté ?

      Le plan de mise en œuvre final pour la procédure accélérée ccTLD IDN [PDF, 851 KB] et les lignes directrices futures pour le panel chargé du processus élargi de révision de similarité de chaînes [PDF, 86 KB] ont été développés à la demande de la ccNSO. La révision a pris en compte l'expérience et les examens de la procédure accélérée ccTLD IDN ainsi que l'avis du GAC [PDF, 122 KB] qui a suggéré d'introduire un deuxième processus de révision de similarité transparent pour les candidatures actuelles et futures de ccTLD IDN.

      La révision annuelle de la procédure accélérée ccTLD IDN est ouverte à la communauté, y compris les parties directement impactées par la deuxième révision de l'EPSRP. Les commentaires publics ont été reçus par l'EURid, qui est l'une des parties affectées.

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

      Le Conseil d'administration a examiné divers documents et facteurs lors de ses délibérations et en prenant ses décisions. Les documents pertinents et importants sont, mais ne se limitent pas à, ce qui suit :

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

      Le processus d'élaboration de politiques ccTLD IDN de la ccNSO a été soumis au Conseil d'administration de l'ICANN. Une des propositions concernant la recommandation de politiques est d'introduire un mécanisme à deux panels pour faire la révision des similarités propices à confusion des chaînes ccTLD IDN demandées. L'un des objectifs de l'introduction de la procédure accélérée ccTLD IDN est d'utiliser une méthodologie pour la sélection des chaînes ccTLD IDN et pouvoir ainsi éclairer le processus d'élaboration de politiques de la ccNSO tout en répondant à la demande à court terme pour l'introduction des ccTLD IDN. Le processus de similarité de chaînes à deux panels, y compris l'EPSRP en tant que second panel, a été introduit au sein de la procédure accélérée pour permettre d'effectuer des tests et de perfectionner le deuxième processus de révision de similarité de chaînes en cas de besoin.

      De plus, bien que les lignes directrices suggèrent que l'EPSRP fournisse une recommandation regroupée, le panel a donné des résultats séparés pour la similarité de la chaîne objet de la candidature et la majuscule comme déterminé par le panel. Le panel n'a pas regroupé ces résultats en une seule recommandation car en se basant sur l'opinion des experts, les caractères majuscules et minuscules sont des éléments visuels différents. Le panel a pris en considération la décision finale comme étant une question de politique.

      Pour finir, les commentaires publics reçus ont soulevé des questions sur la méthodologie suivie par l'EPSRP et la portée de la révision de similarité de chaînes.

      Cela a-t-il des effets positifs ou négatifs pour la communauté ? Y a-t-il des impacts financiers ou des répercussions à prévoir sur l'ICANN (plan stratégique, plan opérationnel, budget), la communauté ou le public ?

      L'action du Conseil d'administration a un impact positif car elle permet à la ccNSO de délibérer parmi les options, en consultation avec d'autres parties prenantes, y compris le GAC et le SSAC, pour perfectionner le deuxième processus de révision de similarité de chaînes. Cette discussion va également éclairer la politique IDN ccTLD proposée. Il n'y a pas d'impact financier supplémentaire en plus de ce qui a déjà été prévu au budget, si le perfectionnement éventuel peut être mis en place de manière interne par l'ICANN.

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

      L'évaluation de la similarité de chaînes provient du WG IDNC et le plan de mise en œuvre accéléré initial [PDF, 497 KB]. Il a été introduit pour minimiser le risque de confusion chez l'utilisateur final à cause d'une similarité de chaînes avec les noms de domaine de premier niveau existants, les codes géographiques à deux lettres au sein de l'ISO 3166-1, et d'autres étiquettes qui ont été appliquées à, ou réservées pour la zone racine, comme discuté dans l'article 5.5 du plan de mise en œuvre. Le rapport final - Processus d'élaboration de politiques IDN de la ccNSO [PDF, 376 KB] propose ce qui suit concernant la similarité propice à la confusion de chaînes ccTLD IDN :

      Une chaîne ccTLD IDN ne devrait pas être propice à une confusion de similarité avec :

      1. Toute combinaison de deux caractères de version basic ISO 646 (ISO 646-BV) (codes lettres [a-z]), ni avec
      2. Des TLD existants ou des noms réservés tel que référencé dans le guide de candidature des nouveaux gTLD

      Les règles supplémentaires suivantes donnent les seuils afin de résoudre toutes questions délicates entre le processus de sélection ccTLD IDN et le processus des nouveaux gTLD :

      • Une candidature de gTLD approuvée par le Conseil d'administration de l'ICANN sera considérée comme un TLD existant sauf en cas de retrait.
      • Une demande validée portant sur un ccTLD IDN sera considérée comme un TLD existant, sauf en cas de retrait.

      Le fait de minimiser les risques de confusion pour l'utilisateur final a au moins deux fonctions distinctes : (i) donner une expérience utilisateur prévisible, où l'utilisateur peut sans ambiguïté utiliser un nom de domaine « dans une police commune, en petite taille sur un écran de résolution normale », et (ii) contribuer à une expérience utilisateur sécurisée, où l'utilisateur est protégé des menaces éventuelles d'usurpation et d'hameçonnage.

      S'agit-il d'un processus d'élaboration de politiques défini au sein des organisations de soutien de l'ICANN ou bien d'une fonction organisationnelle administrative de l'ICANN nécessitant une consultation publique ou ne nécessitant pas de commentaires du public ?

      Le processus EPSRP est introduit dans la procédure accélérée à la demande de la ccNSO et suivant l'avis du GAC, sans préjuger de l'adoption de la politique globale pour le choix de chaînes ccTLD IDN. Tout changement proposé au sein du mécanisme EPSRP est soumis à la même politique de commentaire public que son introduction au sein de la procédure accélérée.

    2. Approbation du budget de l'exercice fiscal 2016

      Attendu que la version préliminaire du plan opérationnel et budget de l'exercice fiscal 2016 a été soumise pour commentaire public le 18 mars 2015, conformément aux statuts constitutifs de l'ICANN, et qu'elle est basée sur des consultations menées lors de l'exercice fiscal actuel auprès de la communauté et de l'ensemble du personnel et du Comité de finances du Conseil d'administration de l'ICANN.

      Attendu que, les commentaires publics reçus du forum de commentaire public ont été discutés par les membres du Conseil d'administration et le personnel pendant plusieurs conférences avec les représentants des organismes de l'ICANN qui les ont soumis afin de s'assurer qu'une compréhension suffisante avait été obtenue et qu'une considération appropriée leur était donnée.

      Attendu que, les commentaires publics reçus ont été pris en compte pour déterminer les révisions demandées du plan opérationnel et budget de l'exercice fiscal 2016.

      Attendu qu'outre le forum de commentaires publics, l'ICANN a activement demandé à la communauté de faire part de ses commentaires et l'a consultée par d'autres moyens, y compris via des conférences téléphoniques en ligne, les réunions à Singapour, et des échanges d'e-mails.

      Attendu que le Comité de finances du Conseil d'administration (BFC) a discuté et informé le personnel de l'élaboration du plan opérationnel et budget de l'exercice fiscal 2016 à chacune de ses récentes réunions, qui se sont tenues à intervalles réguliers.

      Attendu que, le BFC s'est réuni le 12 juin 2015 pour examiner et discuter des changements suggérés suite aux commentaires publics, et du plan opérationnel et budget de l'exercice fiscal 2016, et a recommandé que le Conseil d'administration adopte le plan opérationnel et budget de l'exercice fiscal 2016.

      Attendu que, conformément à l'article 3.9 des contrats d'accréditation des bureaux d'enregistrement de 2001, 2009 et 2013, respectivement, le Conseil d'administration doit établir les frais variables d'accréditation des bureaux d'enregistrement, qui doivent être établis afin d'élaborer le budget annuel.

      Attendu que la description des frais des bureaux d'enregistrement, y compris les frais variables d'accréditation des bureaux d'enregistrement recommandés, correspondant à l'exercice fiscal 2016 a été incluse dans le plan opérationnel et budget de l'exercice fiscal 2016.

      Résolu (2015.06.25.17), le Conseil d'administration adopte le plan opérationnel et budget de l'exercice fiscal 2016 [PDF, 1.74 MB] et, ce faisant, établit les frais variables d'accréditation (par bureau d'enregistrement et par transaction) indiqués dans le plan opérationnel et budget de l'exercice fiscal 2016.

      Fondements de la résolution 2015.06.25.17

      Conformément au chapitre XVI, article 4 des statuts constitutifs de l'ICANN, le Conseil d'administration adopte un budget annuel et le publie sur le site Web de l'ICANN. Le 18 mars 2015, une version préliminaire du plan opérationnel et budget de l'exercice fiscal 2016 a été soumise à commentaire public. Cette version était basée sur les nombreuses discussions avec les membres de l'équipe exécutive et des consultations approfondies tenues avec les organisations de soutien et les comités consultatifs de l'ICANN, ainsi que d'autres groupes de parties prenantes au cours des derniers mois. Les activités pertinentes et les commentaires reçus du forum de consultation publique ont donné lieu à des révisions de la version préliminaire du plan opérationnel et du budget de l'exercice fiscal 2016 du 18 mars 2015. Les activités suivantes ont été réalisées :

      • 9 mars 2015 : Équipe spéciale sur les hypothèses du budget de l'exercice fiscal 2016 (15 membres de la communauté, 1 membre du Conseil d'administration, 4 membres du personnel) - 4 heures de réunion.
      • 6 mai 2015 : Révision/discussion des commentaires publics du groupe de représentants des registres soumis à propos du plan opérationnel et budget de l'exercice fiscal 2016 (membre du Conseil d'administration présent Gonzalo Navarro).
      • 8 mai 2015 : Révision/discussion des commentaires publics de l'ALAC soumis à propos du plan opérationnel et budget de l'exercice fiscal 2016 (membre du Conseil d'administration présent Cherine Chalaby et Rinalia Abdul Rahim)
      • 11 mai 2015 : Révision/discussion des commentaires publics du conseil de la GNSO et de l'IPC/unité constitutive soumis à propos du plan opérationnel et budget de l'exercice fiscal 2016 (membre du Conseil d'administration présent Asha Hemrajani).
      • 11 mai 2015 : Révision/discussion des commentaires publics du conseil de la GNSO et de l'IPC/unité constitutive soumis à propos du plan opérationnel et budget de l'exercice fiscal 2016 (membre du Conseil d'administration présent : Asha Hemrajani).
      • 13 mai 2015 : Révision/discussion des commentaires publics du groupe de travail sur la planification stratégique et opérationnelle (SOP WG) de la ccNSO soumis à propos du plan opérationnel et budget de l'exercice fiscal 2016 (membre du Conseil d'administration présent : Chris Disspain).
      • 19 mai 2015 : Révision/discussion des commentaires publics de l'ISPCP soumis à propos du plan opérationnel et budget de l'exercice fiscal 2016 (membre du Conseil d'administration excusé : Asha Hemrajani).

      Tous les commentaires [PDF, 1.14 MB] reçus, de quelque façon que ce soit, ont été examinés pour élaborer la version finale du plan opérationnel et budget de l'exercice fiscal 2016, et adoptés lorsque cela était possible et approprié.

      Outre les exigences opérationnelles quotidiennes, le plan opérationnel et budget de l'exercice fiscal 2016 comprend les points du budget des nouveaux gTLD de l'exercice fiscal 2016, ainsi que les montants affectés aux diverses demandes de budget de l'exercice fiscal 2016 formulées par les responsables de la communauté. Le budget annuel fait également état des impacts du programme des nouveaux gTLD. Par ailleurs, étant donné que les frais variables d'accréditation des bureaux d'enregistrement sont la clé de l'élaboration du budget, le plan opérationnel et budget de l'exercice fiscal 2016 détermine ces frais, qui sont cohérents avec ceux des dernières années et seront soumis à l'approbation des bureaux d'enregistrement.

      Le plan opérationnel et budget de l'exercice fiscal 2016 aura des effets positifs dans la mesure où il donne un cadre approprié de gestion et de fonctionnement de l'ICANN. Il fournit également la justification pour que l'organisation soit tenue responsable d'une manière transparente. Un impact fiscal est à prévoir sur l'ICANN et sur la communauté. Rien que des effets positifs sont à prévoir sur la sécurité, la stabilité et la résilience du système des noms de domaine (DNS), liés aux financements consacrés à ces aspects du DNS.

      Il s'agit d'une fonction administrative et organisationnelle qui a déjà été soumise à commentaire public.

    3. Approbation du paiement de certains frais juridiques liés au CWG-supervision.

      Attendu que, le Groupe de travail intercommunautaire développe une proposition de transition de la supervision de l'IANA sur les fonctions de nommage (CWG), il a été identifié qu'il lui fallait des conseils externes afin de développer sa proposition en soutien au travail de transition de la supervision de l'IANA et après un processus de sélection détaillé, en mars 2015, Sidley Austin LLP a été choisi pour apporter ces conseils.

      Attendu que, l'ICANN est responsable du paiement des frais pour l'avis de Sidley Austin LLP à qui le groupe de travail intercommunautaire a fait appel au sein de son engagement.

      Attendu que, l'ICANN reçoit une facture de 508 624,98 $ de Sidley Austin LLP pour les services professionnels rendus et les dépenses engendrées au 31 mars 2015 pour le groupe de travail intercommunautaire.

      Attendu que, le Comité de finances du Conseil d'administration recommande que les fonds soient versés à Sidley Austin LLP en paiement de cette facture.

      Attendu que, le Conseil d'administration reste engagé au soutien de la communauté dans l'obtention des conseils dont elle a besoin pour développer les recommandations à l'appui du processus de transition, et note également l'importance d'être certain que les fonds confiés à l'ICANN par la communauté sont utilisés de façon responsable et efficace. Il est encouragé de s'assurer de la continuité des mesures de contrôle des coûts pour les travaux futurs du conseil indépendant.

      Résolu (2015.06.25.18), le Conseil d'administration approuve le paiement de 508 624,98 $ à Sidley Austin LLP pour les services professionnels rendus et les dépenses engendrées au 31 mars 2015 pour le groupe de travail intercommunautaire et demande à l'ICANN de prendre toutes les mesures nécessaires pour réaliser les paiements appropriés.

      Fondements de la résolution 2015.06.25.18

      Dans le cadre du travail visant à développer une proposition de transition de la supervision des fonctions IANA, le groupe de travail intercommunautaire développe une proposition de transition de la supervision de l'IANA sur les fonctions de nommage (CWG) qui exige l'intervention d'un conseiller externe pour donner des conseils sur les aspects de cette proposition. En soutien au processus de proposition de transition, l'ICANN a été d'accord de fournir au CWG les avis d'un conseiller externe. Les membres du CWG ainsi que les membres du département juridique de l'ICANN, ont identifié les compétences nécessaires au CWG, et ont ensuite identifié une liste de cabinets qui ont conservé des compétences de structure et de gouvernance d'entreprise requises. Un groupe d'environ sept cabinets a été identifié, et après avoir pris en considération la disponibilité et les différends, le CWG et l'ICANN se sont mis d'accord pour mener des entretiens avec trois cabinets jouissant d'une réputation nationale sur le territoire américain, ainsi que d'une présence à l'étranger. Après ces entretiens, le CWG et l'ICANN se sont mis d'accord pour retenir Sidley Austin LLP afin qu'il donne des conseils et qu'il consulte uniquement le CWG concernant la gouvernance et le développement de structures et/ou qu'il donne des solutions pour l'amélioration de la responsabilité dans l'exécution des fonctions IANA en lien avec la transition de la supervision de l'IANA. Sidley a accepté de réduire ses frais de 15 % pour ce travail. Sidley a été retenu au début du mois de mars 2015 et a depuis participé au travail du CWG. Suite à cela, Sidley a été retenu également pour apporter ses services au CCWG-Responsabilité. Comme prévu, les frais de lancement ont reflété les factures du CWG étant donné que le cabinet s'acclimatait avec l'ICANN qui aidait à tirer profit de l'expertise de Sidley en travaillant sur la question de responsabilité.

      La facture pour les services professionnels rendus du 31 mars 2015 et les dépenses engendrées est d'un niveau qui nécessite l'approbation du Conseil d'administration, et qui doit rester en accord avec la politique de l'ICANN en matière de contrats et de dépenses. En conséquence, la mesure prise par le Conseil d'administration aujourd'hui est en soutien de la communauté de l'ICANN et des processus, et est conforme à la politique en matière de contrats et de dépenses.

      La facture a été examinée par le personnel afin de s'assurer que les heures facturées et les tarifs étaient en accord avec les termes du contrat. Cette facture sera financée par le budget alloué au travail de transition de la supervision de l'IANA, comme approuvé précédemment par le Conseil d'administration. Bien que ceci représente une certaine somme, le paiement de cette facture appuie les heures de travail de la communauté qui a pu compter sur la contribution du conseiller, et est également en application du soutien de l'ICANN face au travail de la communauté quant au processus de transition. Le travail des avocats se poursuit, davantage de factures sont attendues, et il est toujours important pour l'ICANN de soutenir la communauté en lui apportant les conseils dont elle a besoin à mesure que les recommandations liées à la transition sont développées. Le travail des avocats pour le CWG peut être suivi par le biais des conversations avec le comité de client du CWG, archivées sur http://mm.icann.org/pipermail/cwg-client/; pour le CCWG, le travail de l'avocat peut être suivi par le biais de conversations avec l'équipe juridique, archivées sur http://mm.icann.org/pipermail/ccwg-accountability5/. Étant donné que les fonds dépensés par l'ICANN sont des fonds qui lui sont versés par le public, le Conseil d'administration note à quel point il est important pour tous ceux qui sont impliqués dans le suivi du travail de l'avocat de s'assurer que les fonds de la communauté sont utilisés de manière responsable et efficace. Cette décision n'est censée avoir aucun impact sur la sécurité, la stabilité et la résilience du système des noms de domaine.


1 Langue citée par la charte du FOIWG : http://ccnso.icann.org/workinggroups/foi-final-resolutions-11feb15-en.pdf [PDF, 94 KB]

2 Citations du rapport final du FOIWG.

3 Résolution du conseil de la ccNSO du 11 février 2015 : http://ccnso.icann.org/workinggroups/foi-final-resolutions-11feb15-en.pdf [PDF, 66 KB]

4 Le rapport d'avancement est disponible sur http://ccnso.icann.org/workinggroups/foiwg.htm

resolutions-25jun15-fr.pdf  [169 KB]

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