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-02-12-en

  1. Ordre du jour approuvé
    1. Approbation des procès-verbaux
    2. Délégation à Reliable Software Inc. du domaine en cyrillique бел (« bel ») représentant le Bélarus
    3. Suppression du domaine de premier niveau .TP représentant le Timor portugais
    4. Recommandations du Conseil de la GNSO sur la Politique de transfert de noms entre bureaux d'enregistrements, Partie D
    5. Recommandations sur le recueil d'éléments pour le programme des nouveaux GTLD en vue de la prochaine révision de l'AoC sur la concurrence, la confiance et le choix du consommateur
    6. Renouvellement du mandat des membres du Comité consultatif sur la sécurité et la stabilité (SSAC)
    7. Nomination de Geoff Huston au Comité consultatif sur la sécurité et la stabilité (SSAC)
    8. Remerciements à l'attention des membres sortants
    9. Remerciements à l'attention des partenaire de la 52e réunion de l'ICANN
  2. Ordre du jour principal
    1. Déblocage des codes à deux lettres au deuxième niveau des gTLD

  1. Ordre du jour approuvé

    1. Approbation des procès-verbaux

      Il est résolu (2012.02.12.01) que le Conseil d'administration de l'ICANN approuve les procès-verbaux de ses réunions du 17 novembre et du 3 décembre 2014.

    2. Délégation à Reliable Software Inc. du domaine en cyrillique бел (« bel ») représentant le Bélarus

      Il est résolu (2015.02.12.02) que dans le cadre de sa mission en vertu du Contrat sur les fonctions IANA, l'ICANN a étudié la demande de délégation à Reliable Software Inc. du domaine de premier niveau géographique бел. Il a été démontré que les procédures appropriées avaient bien été appliquées lors de l'évaluation de cette requête ;

      Il est résolu (2015.02.12.03) qu'au vu de certains passages des fondements de cette décision qui ne peuvent pas être, pour l'heure, rendus publics dans le cadre d'une résolution, d'un rapport préliminaire ou d'un procès-verbal en raison de certaines obligations contractuelles, le Conseil d'administration invoque le chapitre III, article 5.2 des Statuts constitutifs de l'ICANN pour demander la non-diffusion des passages en question jusqu'à ce que lesdites obligations contractuelles n'en permettent la publication.

      Fondements des résolutions 2015.02.12.02 et 2015.02.12.03

      Pourquoi le Conseil aborde ce sujet maintenant ?

      Conformément au Contrat pour les fonctions IANA, le personnel de l'ICANN a étudié une demande de délégation d'un ccTLD et rédigé un rapport qu'il a soumis pour révision au Conseil d'administration. Ce dernier est ainsi chargé de s'assurer que le personnel de l'ICANN a bien suivi les procédures appropriées.

      Quelle est la proposition à l'étude ?

      Il est proposé d'accepter une demande soumise à l'IANA, visant à créer un domaine de premier niveau géographique et à confier le rôle d'organisation de parrainage (ou gestionnaire/administrateur) à Reliable Software Inc.

      Quelles parties prenantes ou autres entités 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 concerné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'a pas connaissance de questions ou inquiétudes soulevées par la communauté concernant cette demande.

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

      [RÉVISÉ – Informations sensibles relatives à une délégation]

      Quels sont les facteurs jugés significatifs par le Conseil ?

      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 de gestionnaires de noms de domaine géographiques répondant aux critères d'intérêt public a un impact positif sur la mission globale de l'ICANN et les communautés locales que les domaines de premier niveau géographiques sont censés servir, et correspond aux obligations de l'ICANN en vertu du Contrat pour les fonctions IANA.

      Y a-t-il des incidences 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. L'ICANN n'a pas pour rôle d'évaluer l'incidence financière des opérations relatives aux domaines de premier niveau géographiques au sein d'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. Suppression du domaine de premier niveau .TP représentant le Timor portugais

      Attendu que le code à deux lettres « TP » a été supprimé de la norme ISO 3166-1 et remplacé par le code « TL » représentant le Timor oriental ;

      Attendu que le nom de domaine .TL a été délégué en 2005 pour remplacer le nom de domaine .TP et qu'une transition sur plusieurs années a été effectuée pour permettre aux titulaires de .TP de migrer vers le nouveau domaine de premier niveau géographique ;

      Attendu que l'ICANN a reçu la confirmation du gouvernement du Timor oriental en faveur de la suppression définitive de .TP de la zone racine du DNS ;

      Il est résolu (2015.02.12.04) que .TP est supprimé de la zone racine du DNS.

      Fondements de la résolution 2015.02.12.04

      Pourquoi le Conseil aborde ce sujet maintenant ?

      Le domaine de premier niveau .TP doit être supprimé de la zone racine du DNS avant le 28 février 2015. Le gouvernement du Timor oriental, en sa qualité d'opérateur de .TP, a confirmé accepter cette mesure.

      Quelle est la proposition à l'étude ?

      Il est proposé d'accepter une demande soumise à l'IANA, visant à supprimer le domaine de premier niveau .TP (Timor portugais) de la zone racine du DNS.

      Quelles parties prenantes ou autres entités 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 suppression, l'opérateur actuel doit décrire la procédure suivie pour garantir que la suppression du domaine de premier niveau n'aura pas de conséquence négative imprévue sur la stabilité d'Internet.

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

      Le personnel n'a pas connaissance de questions ou inquiétudes soulevées par la communauté concernant cette demande. Le gouvernement du Timor oriental a confirmé que le domaine de premier niveau .TP n'était plus utilisé.

      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.

    4. Recommandations du Conseil de la GNSO sur la Politique de transfert de noms entre bureaux d'enregistrements, Partie D

      Attendu que le 17 janvier 2013, le Conseil de la GNSO a lancé un processus d'élaboration de politiques (PDP) sur la Politique de transfert de noms de domaine entre bureaux d'enregistrement, Partie D (IRTP, Partie D) abordant les six questions énoncées dans la Charte, disponible sur https://community.icann.org/display/ITPIPDWG/3.+WG+Charter.

      Attendu que le PDP a suivi les étapes prévues par les Statuts constitutifs de l'ICANN et qu'un rapport final a été présenté le 25 septembre 2014 ;

      Attendu que le Groupe de travail sur l'IRTP, Partie D a atteint un consensus total sur les recommandations relatives à chacune des six questions énoncées dans la Charte ;

      Attendu que le Conseil de la GNSO a révisé et évoqué les recommandations du Groupe de travail sur l'IRTP, Partie D, qu'il a adoptées à l'unanimité le 15 octobre 2014 (http://gnso.icann.org/en/council/resolutions#20141015-1).

      Attendu que le vote du Conseil de la GNSO a dépassé le nombre de voix nécessaires (majorité qualifiée) pour imposer de nouvelles obligations aux parties contractantes de l'ICANN ;

      Attendu qu'après le vote du Conseil de la GNSO, une période de consultation publique a été lancée au sujet des recommandations approuvées, et que les commentaires reçus ont été résumés et étudiés (https://www.icann.org/public-comments/irtp-d-recommendations-2014-10-20-en).

      Il est résolu (2015.02.12.05) que le Conseil d'administration adopte les Recommandations du Conseil de la GNSO relatives à la modification de la Politique de transfert de noms entre bureaux d'enregistrements, Partie D, disponible sur http://www.icann.org/en/transfers/policy-en.htm et de la Politique de règlement de litiges relatifs au transfert (TDRP), disponible sur https://www.icann.org/resources/pages/tdrp-2012-02-25-en.

      Il est résolu (2015.02.12.06) que le Conseil d'administration invite le président et PDG de l'ICANN, ou son/ses représentant(s), à élaborer un programme complet de mise en œuvre de ces Recommandations, et à continuer de communiquer et de coopérer avec la communauté et l'Équipe de la GNSO chargée de la révision de la mise en œuvre à cette fin.

      Fondements des résolutions 2015.02.12.05 et 2015.02.12.06

      Pourquoi le Conseil aborde ce sujet maintenant ?

      La Politique de transfert de noms de domaine entre bureaux d'enregistrement (IRTP) est une politique consensuelle adoptée en 2004 qui offre aux titulaires de noms de domaine un processus simple leur permettant de transférer les noms de domaine entre bureaux d'enregistrement. Le Conseil de la GNSO a créé cinq groupes de travail (pour les Parties A à D) pour envisager une révision de cette politique.

      Le PDP de l'IRTP, Partie D est le quatrième et dernier d'une série de PDP visant à améliorer la politique existante.

      Le rapport final sur le PDP de l'IRTP, Partie D a reçu l'approbation de l'ensemble du Groupe de travail sur l'IRTP, Partie D et du Conseil de la GNSO. Après la clôture de la période de consultation publique, la prochaine étape consistera pour le Conseil d'administration à étudier ces recommandations, comme prévu dans l'annexe A aux Statuts de l'ICANN.

      Quelle est la proposition à l'étude ?

      Les recommandations suivantes ont été adoptées :

      Recommandation 1 - Le Groupe de travail recommande que les exigences en termes de rapports soient intégrées à la TDRP. Toutes les décisions des Fournisseurs de services de règlement de litiges (DRSP) 1 doivent être publiées sur les sites internet desdits fournisseurs, sauf cas exceptionnel, conformément aux pratiques en vigueur en vertu de la Politique uniforme de règlement de litiges (UDRP). Les exceptions réclamées par les DRP sont accordées au cas par cas par le département de l'ICANN chargé de la conformité contractuelle. Le Groupe de travail recommande que la publication des rapports suive l'exemple du Centre asiatique de règlement de litiges relatifs à des noms de domaine (ADNDRC).2 Ces rapports doivent inclure, au moins :

      1. le nom de domaine faisant l'objet du litige ;
      2. les informations pertinentes relatives aux parties en conflit ;
      3. l'intégralité de la décision rendue dans l'affaire ;
      4. la date de l'application de la décision.

      Il ne sera pas nécessaire de publier les décisions rendues en vertu de la TDRP avant la mise en œuvre de cette recommandation.

      Recommandation 2 - Le Groupe de travail recommande que la TDRP soit modifiée pour s'aligner sur la version révisée de l'UDRP :

      « Le Fournisseur de services de règlement de litiges concerné devra rendre compte des décisions prises pour régler un litige en matière de transfert en vertu de la TDRP. Toutes les décisions rendues dans le cadre de cette politique seront publiées dans leur intégralité sur Internet, sauf si le panel composé de Fournisseurs décide exceptionnellement de réviser certains passages de sa décision. Dans tous les cas, tout passage d'une décision indiquant qu'une plainte a été déposée de mauvaise foi devra être publié ».

      Recommandation 3 - Le Groupe de travail recommande que la TDRP soit modifiée comme suit ou de manière équivalente : « Les transferts depuis un bureau d'enregistrement qui prendra en charge la gestion des noms gTLD vers un bureau d'enregistrement tiers et tout autre transfert ultérieur seront invalidés si le premier bureau d'enregistrement a obtenu le parrainage du bureau d'enregistrement agréé par le biais d'un transfert invalide, tel que déterminé par la procédure de règlement de litiges établie dans la Politique de règlement de litiges relatifs au transfert ».

      Recommandation 4 - Le Groupe de travail recommande, au cas où il est établi par le biais d'une procédure TDRP qu'un transfert de nom de domaine non conforme à l'IRTP a été réalisé, que ce nom de domaine soit renvoyé directement au bureau d'enregistrement et au titulaire de nom de domaine qui en étaient responsables juste le transfert non conforme.

      Recommandation 5 - Le Groupe de travail recommande que le délai de prescription pour lancer une TDRP soit étendu de six à 12 mois à partir du transfert initial.

      Cela donnerait aux titulaires de noms de domaine la possibilité de prendre connaissance des transferts frauduleux même s'ils ne reçoivent plus la notification annuelle de leur bureau d'enregistrement concernant la politique de vérification des données WHOIS (WDRP).

      Recommandation 6 - Le Groupe de travail recommande, au cas où une demande d'exécution serait présentée dans le cadre de la TDRP, que le domaine concerné soit « verrouillé » pour empêcher d'autres transferts en attendant la mise en œuvre de la demande d'exécution. Par conséquent, une « mesure TDRP » et une « mesure URS » (Système uniforme de suspension rapide) doivent être ajoutées au deuxième point de la liste des motifs de refus dans le cadre de l'IRTP (article 3). L'IRTP et la TDRP doivent être modifiées en conséquence,3de même que les directives applicables aux bureaux d'enregistrement, aux registres et aux Fournisseurs de services de règlement de litiges. Le Groupe de travail fait remarquer que le verrouillage doit être effectué comme prévu par l'UDRP une fois le processus lancé.

      Recommandation 7 - Le Groupe de travail recommande d'ajouter une liste de définitions (Annexe F au Rapport final) à la TDRP pour rendre ce document plus clair et plus accessible.

      Recommandation 8 - Le Groupe de travail recommande de ne pas élaborer des options de règlement de litiges pour les titulaires de noms de domaine dans le cadre de la TDRP actuelle.

      Recommandation 9 - Le Groupe de travail recommande que le personnel, en collaborant étroitement avec l'Équipe de révision de la mise en œuvre de l'IRTP, Partie C, veille à l'application des recommandations relatives aux transferts entre titulaires de noms de domaine dans le cadre de l'IRPT, Partie C, et détermine si des mécanismes de règlement de litiges sont nécessaires pour les Cas d'utilisation en Annexe C au Rapport final Une fois cette politique en vigueur, son fonctionnement devrait être surveillé de près et si nécessaire, un rapport thématique devra être rédigé pour évaluer le besoin d'une politique de règlement de litiges relatifs au transfert entre titulaires de noms de domaine. Voir aussi les recommandations 17 et 18 ci-dessous.

      Recommandation 10 - Le Groupe de travail recommande que la TDRP soit modifiée afin d'en supprimer le premier niveau (registres).

      L'ICANN doit surveiller l'utilisation de la TDRP. Si la suppression du niveau des registres en tant que premier Fournisseur de services de règlement de litiges semble entraver ce mécanisme de règlement de litiges, il sera nécessaire de modifier la politique. Voir aussi la recommandation 17 ci-dessous.

      Recommandation 11 - Le Groupe de travail recommande à l'ICANN de prendre les mesures nécessaires pour afficher de façon visible sur son site internet les informations concernant les transferts non conformes contestés, et de s'assurer qu'elles soient présentées de manière simple, claire et accessible pour les titulaires de noms de domaine.

      Cette recommandation va de pair avec la recommandation 12 (ci-dessous).

      Recommandation 12 - Le Groupe de travail recommande à l'ICANN de créer et d'entretenir un site internet unique et convivial contenant toutes les informations utiles sur les transferts contestés et les solutions éventuelles pour les titulaires de noms de domaine. Un tel site doit être facilement accessible depuis la page des Avantages et responsabilités des titulaires de noms de domaine de l'ICANN (https://www.icann.org/resources/pages/benefits-2013-09-16-en), y être intégré ou autre solution similaire.

      Ce site devrait inclure :

      • des informations pour encourager les titulaires à contacter leur bureau d'enregistrement pour résoudre les transferts contentieux au niveau du bureau d'enregistrement avant de faire appel au département de l'ICANN chargé de la conformité contractuelle ou des tiers en lançant une TDRP;
      • des améliorations du site de l'ICANN en ce qui concerne l'actualisation régulière des informations sur l'IRTP et la TDRP (voir 5.2.3.3 ci-dessus) ;
      • des liens vers les informations utiles aux titulaires concernant le site de l'ICANN affichés clairement sur la page d'accueil de l'ICANN, ce qui contribuera à améliorer la visibilité et le contenu des pages du site de l'ICANN visant à aider les titulaires confrontés à des problèmes de transfert ;
      • des indications claires de la part du département de la conformité contractuelle sur sa page FAQ/Aide concernant les cas où il peut intervenir auprès des titulaires confrontés à des problèmes de transfert, notamment les cas où ces derniers peuvent lui demander d'encourager un bureau d'enregistrement à prendre des mesures en leur nom ;
      • des améliorations en termes d'accessibilité et de convivialité des pages suivantes :

      Les liens vers ces sites d'aide aux titulaires doivent également être clairement affichés sur internic.net et iana.org de façon à garantir que les titulaires puissent accéder facilement aux informations.

      Recommandation 13 - Le Groupe de travail recommande, comme bonne pratique, que les bureaux d'enregistrement accrédités par l'ICANN affichent clairement sur leur site un lien vers le site d'assistance de l'ICANN aux titulaires de noms de domaine. Les bureaux d'enregistrement devraient aussi encourager fortement tous les revendeurs à afficher clairement ce type de liens. En outre, le Groupe de travail recommande que cette information soit communiquée à tous les bureaux d'enregistrement accrédités par l'ICANN.

      Les bureaux d'enregistrement peuvent choisir d'ajouter ce lien aux pages de leur site internet contenant déjà des données pertinentes pour les titulaires, comme les droits et les responsabilités de ces derniers, des informations sur le WHOIS et/ou d'autres liens utiles réclamés par l'ICANN, comme indiqué dans l'article 3.16 du Contrat d'accréditation de bureau d'enregistrement (RAA) de 2013.

      Recommandation 14 - Le Groupe de travail recommande qu'aucune sanction supplémentaire ne soit ajoutée à l'IRTP ou à la TRDP pour l'heure.

      Recommandation 15 - Comme ligne directrice pour les futurs processus d'élaboration de politiques, le Groupe de travail recommande d'éviter tant que possible les sanctions spécifiques. Celles-ci doivent plutôt être cohérentes dans toutes les politiques en vigueur et être régies par les dispositions applicables du RAA.

      Recommandation 16 - Le Groupe de travail ne recommande pas l'élimination des formulaires d'autorisation (FOA). Toutefois, au vu des problèmes engendrés par ces derniers, tels que les transferts en masse et les fusions de bureaux d'enregistrement et/ou de revendeurs, le Groupe recommande que l'opérabilité des FOA ne soient pas limitée aux courriels. Des améliorations pourraient être apportées, comme la transmission des FOA par SMS ou l'obtention d'une autorisation sur des sites web interactifs. Toutefois, ces innovations doivent avoir des capacités de contrôle puisque cela demeure l'une des fonctions clés des FOA.

      Le Groupe de travail fait remarquer que la mise en œuvre de la présente recommandation ne devrait pas subir l'influence des transferts, qu'ils soient réalisés au préalable (pour certains transferts en masse) ou en temps réel.

      Recommandation 17 - Le Groupe de travail recommande, une fois toutes les recommandations pour l'IRTP appliquées (y compris pour l'IRTP, Partie D et d'autres éléments restants de la Partie C), que le Conseil de la GNSO et le personnel de l'ICANN créent un comité destiné à recueillir, discuter et analyser des données pertinentes afin de déterminer si ces modifications perfectionnent le processus de l'IRPT et les mécanismes de règlement de litiges, et d'identifier les éventuels inconvénients persistants.

      Si après 12 mois de révision, la GNSO et le personnel de l'ICANN concluent qu'il n'y a pas d'amélioration, le Groupe de travail recommande d'entreprendre une réévaluation descendante du processus de transfert, le but étant de créer une politique plus simple, plus rapide et plus sécurisée qui soit plus facilement compréhensible et accessible pour les titulaires de noms de domaine.

      Il est également conseillé de faire appel à un expert en sécurité pour faire partie du prochain groupe de travail pour le cas où, par exemple, une authentification à deux facteurs réels serait requise, afin qu'elle soit mise en œuvre conformément aux normes du secteur.

      Recommandation 18 - Le Groupe de travail recommande que les parties contractantes et l'ICANN commencent à recueillir toutes les données qui seront utiles à une future équipe de révision de l'IRTP, notamment sur les sujets énoncés dans les observations du Rapport final (4.2.7.1).

      Pour faciliter la collecte de ces informations, l'Équipe de révision de la mise en œuvre devrait collaborer étroitement avec le personnel de l'ICANN pour assurer un accès rapide aux données nécessaires.

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

      Les parties prenantes ont régulièrement été consultées lors de ce PDP. Plus d'informations sont disponibles sur la Liste des contributions (Annexe B au Rapport final).

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

      Aucune inquiétude n'a été manifestée par la communauté concernant le Rapport final et ses recommandations.

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

      Le Conseil d'administration a étudié le Rapport final, les recommandations qui lui ont été adressées par le Conseil de la GNSO, ainsi que la synthèse des commentaires publics et des réponses à ces commentaires.

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

      Les recommandations ont été élaborées selon le PDP de la GNSO, tel que décrit dans l'Annexe A aux Statuts constitutifs de l'ICANN, et ont reçu l'appui unanime du Conseil de la GNSO. Comme indiqué dans les Statuts, le vote de cette motion à la majorité qualifiée du Conseil de la GNSO oblige le Conseil d'administration à adopter la recommandation, à moins qu'il ne détermine, par un vote de plus des deux tiers de ses membres, que la politique concernée n'est pas dans l'intérêt de la communauté ICANN ou de l'ICANN.

      En outre, les problèmes de transfert représentent le deuxième sujet de plaintes selon les données du département de la conformité contractuelle. Les améliorations de l'IRTP peuvent éventuellement réduire le nombre de plaintes et offrir davantage de clarté et de prévisibilité aux titulaires de nom de domaine et aux bureaux d'enregistrement.

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

      Les améliorations de l'IRTP et de la TDRP peuvent éventuellement réduire le nombre de plaintes et offrir davantage de clarté et de prévisibilité aux titulaires de nom de domaine et aux bureaux d'enregistrement. L'adoption de ces recommandations demandera des modifications significatives des processus concernant les bureaux d'enregistrement, si bien que leur mise en œuvre nécessitera du temps et des ressources, éléments indispensables pour résoudre les problèmes liés à ce PDP. Ces recommandations, si elles sont appliquées, devraient aider à clarifier et renforcer l'IRTP et la TDRP, ce qui profitera à toutes les parties concernées.

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

      Outre les changements qui s'avèrent nécessaires dans les processus concernant les bureaux d'enregistrement évoqués ci-dessus, l'application de cette politique aura probablement une incidence financière, notamment due à la mise à jour du site internet de l'ICANN, mais ces coûts sont prévus dans le budget des départements concernés.

      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 les recommandations qui lui sont soumises.

    5. Recommandations sur le recueil d'éléments pour le programme des nouveaux GTLD en vue de la prochaine révision de l'AoC sur la concurrence, la confiance et le choix du consommateur

      Attendu que dans son Affirmation d'engagements (AoC), l'ICANN s'est engagée à organiser une révision, lorsque les nouveaux gTLD auront été lancés depuis un an, pour examiner dans quelle mesure le programme des nouveaux gTLD aura encouragé la concurrence, la confiance et le choix du consommateur ;

      Attendu que le 10 décembre 2010, le Conseil d'administration a demandé au Comité consultatif At-Large (ALAC), au Comité consultatif gouvernemental (GAC), à l'Organisation de soutien aux extensions génériques (GNSO) et à l'Organisation de soutien aux extensions géographiques (ccNSO) de lui soumettre leurs propositions afin d'établir la définition, les mesures et une cible de trois ans pour la concurrence, la confiance et le choix du consommateur dans le cadre du système des noms de domaine. En 2013, le Conseil d'administration a reçu les commentaires du Conseil de la GNSO [PDF, 352 KB] et de l'ALAC [PDF, 491 KB], chacun proposant des recommandations sur des éléments spécifiques ;

      Attendu que le Conseil d'administration, dans ses résolutions 2013.07.18.05 – 2013.07.18.07 et 2013.09.28.13 – 2013.09.28.14a invité le président et PDG de l'ICANN à rassembler des volontaires (formant le Groupe consultatif de mise en œuvre sur la concurrence, la confiance et le choix du consommateur – IAG-CCT) avant de créer une Équipe de révision de l'AoC sur la concurrence, la confiance et le choix du consommateur, et ce pour plusieurs raisons. Ce groupe sera notamment chargé d'évaluer la viabilité, l'utilité et le coût de l'adoption des recommandations du Conseil de la GNSO et de l'ALAC, et de faire un rapport au Conseil d'administration ;

      Attendu que le 1er octobre 2014, l'IAG-CCT a présenté au Conseil d'administration son rapport final sur ses recommandations relatives à la collecte de données visant à guider la révision sur la concurrence, la confiance et le choix du consommateur ;

      Il est résolu (2015.02.12.07) que le Conseil d'administration remercie l'IAG-CCT pour son travail et ses recommandations prévoyant de recueillir des données visant à guider la révision sur la concurrence, la confiance et le choix du consommateur dans l'espace des gTLD ;

      Il est résolu (2015.02.12.08) que le président et PDG de l'ICANN, ou son/ses représentant(s), est invité par les présentes à commencer sans délai à recueillir les données disponibles sur les éléments soulignés dans le rapport final de l'IAG-CCT, en donnant la priorité aux plus urgents ;

      Il est résolu (2015.02.12.09) que le président et PDG de l'ICANN, ou son/ses représentant(s), est invité par les présentes à recueillir les données disponibles sur les éléments indiqués dans le Tableau 4 du rapport final de l'IAG-CCT [DOCX, 105 KB], en tenant compte du fait que ces données pourront être recueillies ultérieurement, en attendant qu'une réunion de l'Équipe de révision soit fixée.

      Fondements des résolutions 2015.02.12.07 à 2015.02.12.09

      Pourquoi le Conseil d'administration aborde ce sujet ?

      Cette résolution s'inscrit dans la lignée des résolutions du Conseil d'administration (2013.07.18.05 – 2013.07.18.07 et 2013.09.28.13 – 2013.09.28.14) relatives à l'évaluation des éléments que la communauté a suggéré d'utiliser lors d'une prochaine révision, aux termes de l'AoC, de l'impact des nouveaux gTLD sur la concurrence, la confiance et le choix du consommateur. Elle repose aussi sur les résolutions du Conseil d'administration (2014.03.27.22 - 2014.03.27.26) relatives à l'adoption de recommandations provisoires adressées par l'IAG-CCT concernant un sondage des consommateurs et une étude économique.

      Quelle est la proposition à l'étude ?

      La résolution du Conseil d'administration signifie que l'ICANN doit commencer sans délai à recueillir des données sur les éléments soulignés par l'IAG-CCT. La résolution approuve la majorité des recommandations de l'IAG-CCT et permet à l'Équipe de révision d'évaluer le coût et l'utilité de certains éléments en étudiant les données disponibles.

      Ce travail devrait commencer sous peu et implique de laisser au personnel le temps de recueillir les données nécessaires, qu'il pourra notamment obtenir de quelque manière que ce soit auprès des tiers concernés, y compris les parties contractantes de l'ICANN.

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

      Le Conseil d'administration a étudié le rapport final de l'IAG-CCT du 1er octobre 2014 (https://community.icann.org/download/attachments/48349551/IAGCCT%20Final%20report.docx?version=1&modificationDate=1418863127000&api=v2), les documents d'information présentés par le personnel, les résolutions adoptées en mars 2014 approuvant le financement d'un sondage des consommateurs et d'une étude économique, et les avis à ce sujet envoyés auparavant par l'ALAC [PDF, 491 KB] et la GNSO [PDF, 352 KB], y compris une version de ces avis mise à jour pour tenir compte des recommandations actuelles de l'IAG-CCT.

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

      Le Conseil d'administration estime que les données à recueillir pour cette évaluation sont essentielles en vue d'un examen précis visant à déterminer dans quelle mesure l'introduction des gTLD favorise la concurrence, la confiance et le choix du consommateur. En menant ces activités maintenant, l'ICANN s'engage à garantir que les données pertinentes soient disponibles pour la future équipe de révision et l'ensemble de la communauté en vue de la révision future du programme des nouveaux gTLD aux termes de l'AoC. Cette résolution appelle à un travail de mise en œuvre visant à faciliter la révision de l'AoC en temps voulu.

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

      Les fonds nécessaires pour mettre en œuvre cette résolution sont prévus dans le budget de l'exercice fiscal 2015 et dans le budget prévisionnel de l'exercice fiscal 2016.

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

      Cette résolution n'a pas d'incidence sur la sécurité, la stabilité ou la résilience du DNS.

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

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

    6. Renouvellement du mandat des membres du Comité consultatif sur la sécurité et la stabilité (SSAC)

      Attendu que le chapitre XI, article 2.2 des Statuts constitutifs de l'ICANN régissent le Comité consultatif sur la sécurité et la stabilité (SSAC) ;

      Attendu que le Conseil d'administration a approuvé, par le biais de sa résolution 2010.08.05.07, les modifications des Statuts qui prévoient des mandats de trois ans pour les membres du SSAC ainsi qu'un échelonnement des mandats, et engagent le président du SSAC à recommander le renouvellement total ou partiel du mandat de tous les membres actuels du SSAC afin d'appliquer les modifications apportées à ce document ;

      Attendu que le Conseil a nommé, par le biais de sa résolution 2010.08.05.08, les membres du SSAC pour des mandats allant d'un à trois ans à compter du 1er janvier 2011 et jusqu'au 31 décembre 2011, 2012 ou 2013 respectivement ;

      Attendu qu'en juin 2014, le Comité des membres du SSAC a lancé une évaluation annuelle des membres du SSAC dont les mandats arrivaient à terme le 31 décembre 2014 et soumis au SSAC ses recommandations pour des renouvellements de mandat ;

      Attendu que le 24 novembre 2014, les membres du SSAC ont approuvé ces renouvellements de mandat ;

      Attendu que le SSAC recommande au Conseil de renouveler le mandat des membres du SSAC suivants pour une période de trois ans : Greg Aaron, Don Blumenthal, KC Claffy, Lyman Chapin, Steve Crocker, Mark Kosters, Russ Mundy, Rod Rasmussen et Mark Seiden ;

      Il est résolu (2015.02.12.10) que le Conseil d'administration accepte la recommandation du SSAC et renouvelle le mandat des membres du SSAC suivants pour un mandat de trois an, du 1er janvier 2015 au 31 décembre 2017 : Greg Aaron, Don Blumenthal, KC Claffy, Lyman Chapin, Steve Crocker, Mark Kosters, Russ Mundy, Rod Rasmussen et Mark Seiden.

      Fondements de la résolution 2015.02.12.10

      Le SSAC est un groupe diversifié composé de personnes dont l'expertise dans des sujets spécifiques lui permet de satisfaire aux objectifs de sa charte et de remplir sa mission. Depuis sa création, le SSAC a invité des personnes ayant une connaissance et une expérience approfondies dans les domaines techniques et de sécurité fondamentaux pour la sécurité et la stabilité des systèmes de nommage et d'adressage d'Internet. Les personnes mentionnées ci-dessus fournissent au SSAC l'expertise et l'expérience nécessaires pour que celui-ci puisse respecter sa charte et remplir sa mission.

    7. Nomination de Geoff Huston au Comité consultatif sur la sécurité et la stabilité (SSAC)

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

      Attendu que le Comité des membres du SSAC, au nom du SSAC, demande au Conseil d'administration de nommer Geoff Huston au SSAC ;

      Il est résolu (2015.02.12.11) que le Conseil nomme Geoff Huston au SSAC.

      Fondements de la résolution 2015.02.12.11

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

      Le fonctionnement continu du SSAC en tant qu'organe compétent dépend de l'ensemble des experts dans des domaines donnés qui consentent à consacrer une partie de leur temps et de leur énergie pour mener à bien la mission du SSAC. Geoff Huston apporte des compétences précieuses au SSAC en tant que directeur scientifique de l'APNIC. Il participe généralement à des projets portant sur des éléments de mesure et le réseau. Récemment, il a étudié de près l'épuisement de la réserve d'adresses IPv4 non allouées, le lancement de l'IPv6, la mesure du DNS et le lancement des DNSSEC, ainsi que la conception et la stabilité opérationnelle de l'Infrastructure de gestion de clés publiques (RPKI). Le SSAC estime que Geoff Huston a beaucoup à lui apporter.

    8. Remerciements à l'attention des membres sortants

      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 que pour saluer ces contributions, l'ICANN souhaite remercier les membres de la communauté au terme de leur mandat au sein des organisations de soutien et des comités consultatifs ;

      Attendu que le mandat du membre suivant du Comité consultatif du système des serveurs racine (RSSAC) touche à sa fin :

      • Jun Murai – Premier président du RSSAC ;

      Il est résolu (2015.02.12.12) que Jun Murai mérite la profonde gratitude du Conseil d'administration pour son travail et que le Conseil lui souhaite beaucoup de succès dans ses projets futurs, au sein de la communauté ICANN et ailleurs ;

      Attendu que le mandat des membres suivants du Comité consultatif sur la sécurité et la stabilité (SSAC) touche à sa fin :

      • Rodney Joffe,
      • Jason Livingood,
      • Bruce Tonkin,
      • Stefano Trumpy,
      • Paul Vixie,

      Il est résolu (2015.02.12.13) que Rodney Joffe, Jason Livingood, Bruce Tonkin, Stefano Trumpy et Paul Vixie méritent la profonde gratitude du Conseil d'administration pour leur travail et que le Conseil leur souhaite beaucoup de succès dans leurs projets futurs, au sein de la communauté ICANN et ailleurs ;

      Attendu que le mandat du membre suivant de l'Organisation de soutien aux extensions génériques (GNSO) touche à sa fin :

      • Kristina Rosette – Présidente de l'Unité constitutive des représentants de la propriété intellectuelle ;

      Il est résolu (2015.02.12.14) que Kristina Rosette mérite la profonde gratitude du Conseil d'administration pour son travail et que le Conseil lui souhaite beaucoup de succès dans ses projets futurs, au sein de la communauté ICANN et ailleurs ;

      Attendu que le mandat des membres suivants du Comité consultatif gouvernemental (GAC) touche à sa fin :

      • Tracy Hackshaw – Vice-président du GAC,
      • Peter Nettlefold – Vice-président du GAC ;

      Il est résolu (2015.12.15) que Tracy Hackshaw et Peter Nettlefold méritent la profonde gratitude du Conseil d'administration pour leur travail et que le Conseil leur souhaite beaucoup de succès dans leurs projets futurs, au sein de la communauté ICANN et ailleurs.

    9. Remerciements à l'attention des partenaire de la 52e réunion de l'ICANN

      Le Conseil tient à remercier les partenaires suivants : VeriSign, Inc., Public Interest Registry, Afilias Limited, CentralNic, le Centre de recherche technique de Pékin sur le système de noms de domaine (ZDNS), Neustar, NCC Group, le Centre d'échange d'information sur les marques, Uniregistry Corp., Minds + Machines Group, Iron Mountain, Inc., ION Magazine, Radix FZC, ICANNWIKI, InterConnect Communications Ltd et Sedo GmbH.

      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 Fairmont Singapore et du Swissôtel The Stamford pour avoir prêté leurs merveilleux locaux pour l'occasion. Le Conseil remercie tout particulièrement :

      Mme Dawn Ng, responsable des conférences au Conseil du tourisme de Singapour ; Ng Pei Sze, directeur commercial en chef chargé des réunions, des conférences et des expositions ; Ng Sok Hia, adjointe de direction chargée des ventes et du marketing ; et Joanne Kaeli Phua, directrice des services de conférence au Centre de conférences de Raffles City.

  2. Ordre du jour principal

    1. Déblocage des codes à deux lettres au deuxième niveau des gTLD

      Attendu que le Contrat de registre pour les nouveaux gTLD prévoit deux méthodes de déblocage des noms de domaine à deux caractères : 1) l'opérateur de registre parvient à un accord avec le gouvernement et le gestionnaire de code pays concernés ; ou 2) l'opérateur de registre peut proposer le déblocage de ces noms sur la base de l'application de mesures afin d'éviter toute confusion avec les codes pays correspondants, sous réserve de l'approbation de l'ICANN ;

      Attendu que le 16 octobre 2014, le Conseil d'administration a invité le personnel de l'ICANN à élaborer et mettre en œuvre une procédure efficace permettant à l'ICANN d'étudier les demandes de déblocage de noms à deux caractères, en tenant compte de l'avis du GAC formulé dans son communiqué de Los Angeles [PDF, 127 KB] du 16 octobre 2014 ;

      Attendu que l'ICANN a publié et mis en place cette procédure à partir du 1er décembre 2014 ;

      Attendu que le 26 janvier 2015, le président du GAC a envoyé une lettre [PDF, 215 KB] au Conseil d'administration de l'ICANN dans laquelle il exprimait des craintes au nom de certains membres du GAC utilisateurs de cette procédure, et que le GAC a fourni une liste de suggestions de solutions possibles pour répondre à ces craintes ;

      Attendu que le 11 février 2015, le GAC a adressé un avis au Conseil d'administration dans son communiqué [PDF, 264 KB] concernant le déblocage de codes à deux lettres au deuxième niveau des gTLD. Le GAC a recommandé au Conseil de modifier la procédure actuelle afin d'instaurer un mécanisme de notification efficace permettant aux gouvernements concernés d'être informés de la présentation de ces requêtes. Les commentaires des gouvernements concernés devront être étudiés minutieusement. Le GAC a également recommandé au Conseil d'étendre la période de consultation publique à 60 jours. Une liste des membres du GAC qui souhaitent accepter toutes les demandes sans recevoir de notifications sera publiée sur le site internet du GAC ;

      Il est résolu (2015.02.12.16) que le Conseil accepte l'avis du GAC formulé dans son communiqué du 11 février 2015 concernant le déblocage de codes à deux lettres au deuxième niveau des gTLD. Le Conseil invite le président et PDG de l'ICANN, ou son/ses représentant(s), à revoir la procédure d'autorisation du déblocage d'étiquettes ASCII à deux caractères et à prendre les mesures suivantes sans délai :

      • appliquer les modifications apportées à la procédure pour alerter les gouvernements concernés des demandes formulées. Les commentaires des gouvernements concernés devront être étudiés minutieusement ;
      • étendre la période de consultation publique à 60 jours pour les demandes récentes ;
      • étendre ou relancer la période de consultation publique pour les demandes en cours ou pour lesquelles une décision a été rendue, afin que chacune d'elles fasse l'objet d'une période de consultation publique de 60 jours.

      Fondements de la résolution 2015.02.12.16

      Le Conseil décide d'accepter l'avis du GAC formulé dans le communiqué du GAC du 11 février 2015 [PDF, 264 KB] concernant le lancement de codes à deux lettres au deuxième niveau des gTLD. Le chapitre XI, article 2.1 des Statuts constitutifs de l'ICANN autorise le GAC à « soumettre directement des sujets au Conseil, par le biais d'un commentaire ou d'un avis préalable, ou en recommandant une mesure spécifique, l'élaboration d'une nouvelle politique ou la révision des politiques actuelles ». Les Statuts prévoient que le Conseil tienne compte de l'avis du GAC en matière de politique publique pour la formulation et l'adoption de politiques. Si le Conseil décide d'agir contrairement à l'avis du GAC, il doit en avertir ce dernier en indiquant son raisonnement. Le Conseil et le GAC tenteront alors, en toute bonne foi, de trouver une solution acceptable pour les deux parties. S'ils ne parviennent à aucun accord, le Conseil devra expliquer dans sa décision finale les raisons qui l'ont amené à ne pas suivre l'avis du GAC.

      La décision prise aujourd'hui par le Conseil d'accepter l'avis du GAC s'inscrit dans la lignée de sa résolution du 16 octobre 2014, dans laquelle il autorisait le président et PDG de l'ICANN à élaborer et mettre en pratique une procédure efficace de déblocage des domaines à deux caractères actuellement réservés, conformément au Contrat de registre pour les nouveaux gTLD, en tenant compte de l'avis du GAC formulé dans son communiqué de Los Angeles [PDF, 127 KB].

      L'ICANN a élaboré la procédure d'autorisation du déblocage d'étiquettes ASCII à deux caractères afin de mettre en pratique la résolution du Conseil. Le 12 novembre 2014, l'ICANN a publié un article de blog expliquant le fonctionnement de la nouvelle procédure de déblocage de domaines à deux caractères, qu'elle a également fourni au GAC. Cette procédure est entrée en vigueur le 1er décembre 2014. Le 26 janvier 2015, le président du GAC a envoyé une lettre [PDF, 215 KB] au Conseil, dans laquelle il exprimait des craintes au nom de certains membres du GAC utilisateurs de cette procédure. Le GAC a également fourni une liste de suggestions de solutions possibles pour répondre à ces craintes.

      À ce jour, l'ICANN a reçu les demandes de plus de 300 registres. À la suite de la décision prise aujourd'hui par le Conseil, l'ICANN va étendre la période de consultation publique prévue par la procédure à 60 jours pour chaque demande, ce qui signifie qu'elle prolongera ou relancera la période de consultation publique pour les demandes en cours ou pour lesquelles une décision a été rendue. Ainsi, la période de consultation publique initiale de 30 jours sera prolongée de la même durée si elle est en cours, ou relancée pour 30 jours si elle est terminée. Toutes les nouvelles demandes feront directement l'objet d'une période de consultation publique de 60 jours.

      Le Conseil a examiné plusieurs documents et facteurs significatifs lors des discussions relatives à la décision prise, notamment :

      L'impact global sur la communauté devrait être positif dans la mesure où de nouvelles possibilités de diversification et de concurrence au sein de l'espace des noms des gTLD sont proposées, et aucun risque de confusion dans l'esprit des utilisateurs n'a été identifié. La mise en œuvre de la décision du Conseil ne devrait pas avoir d'incidence financière sur l'ICANN, la communauté ou le grand public. Comme l'a indiqué le Panel d'évaluation technique des services de registre de l'ICANN dans un rapport du 4 décembre 2006 sur la proposition de déblocage de domaines à deux caractères dans le gTLD .name, cette mesure ne met pas en péril la stabilité et la sécurité d'Internet. La décision du Conseil ne constitue ni un processus politique défini au sein des organisations de soutien de l'ICANN, ni une fonction organisationnelle administrative de l'ICANN nécessitant une consultation publique.


1 Le Groupe de travail recommande, dans la question C de la Charte, de supprimer les registres en tant que premiers Fournisseurs de services de règlement de litiges dans la TDRP. Par conséquent, malgré la formulation de la question A, le présent document ne fait pas mention des exigences en termes de rapports pour les registres.

2 Consultez les quatre rapports de l'ADNDRC sur les décisions de la TDRP : http://www.adndrc.org/mten/TDRP_Decisions.php?st=6

3 https://www.icann.org/resources/pages/policy-transfers-2014-07-02-en

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