Skip to main content
Resources

Résolutions adoptées par le Conseil d'administration | 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 : http://www.icann.org/en/groups/board/documents/resolutions-07feb14-en.htm

 

  1. Ordre du jour approuvé
    1. Approbation des procès-verbaux du Conseil d'administration
    2. Nomination de Joe Abley au comité consultatif sur la sécurité et la stabilité
    3. Révisions des statuts du groupe de liaison technique
    4. Résolutions du Comité du programme des nouveaux gTLD
  2. Ordre du jour principal
    1. Protection des identifiants IGO-INGO dans tous les gTLD PDP
    2. Formation d'un Groupe de travail du Conseil d'administration sur le processus de recrutement et de sélection du comité de nomination ainsi que sa taille et sa composition
    3. Recommandations du GNSO sur le processus de développement de la politique du Whois « détaillé » démarre

 

  1. Ordre du jour approuvé :

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

      Résolu (2014.02.20.04), le Conseil d'administration approuve le compte-rendu des réunions du Conseil d'administration de l'ICANN des 8, 16, 17, 20, 21 novembre 2012.

    2. Nomination de Joe Abley au comité consultatif sur la sécurité et la stabilité

      Attendu que, le Comité consultatif sur la sécurité et la stabilité (SSAC) fait une révision de ses membres et, de temps en temps, fait des ajustements.

      Attendu que, le Comité des membres du SSAC, au nom du SSAC, demande que le Conseil nomme Joe Abley au SSAC.

      Résolu (2014.02.07.02), le Conseil d'administration nomme Joe Abley au SSAC.

      Fondements de la résolution 2014.02.07.02

      Le SSAC est un groupe diversifié de personnes dont l'expertise dans des sujets spécifiques permet de satisfaire aux objectifs de sa charte et d'exécuter 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é qui sont décisifs pour la sécurité et la stabilité du système des noms de domaine d'Internet.

      Cette décision relève d'une fonction administrative organisationnelle qui ne nécessite pas de consultation publique.

      Le fonctionnement continu du SSAC en tant qu'entité compétente dépend de la participation soutenue d'experts en la matière qui ont consenti à consacrer un peu de leur temps et énergie pour mener à bien la mission du SSAC. Joe Abley a participé au SSAC de par ses fonctions de Directeur des opérations DNS à l'ICANN. Il a maintenant rejoint Dyn, en tant que Architecte Principal. Joe Abley nous apporte son expérience dans les opérations DNS et une compréhension technique importante concernant le DNS et les problèmes techniques liés au DNS.

    3. Révisions des statuts du groupe de liaison technique

      Attendu que le statuts de l'ICANN demande actuellement que le groupe de liaison technique (TLG) désigne un agent de liaison au Conseil d'administration de l'ICANN de même qu'un délégué avec droit de vote au comité de nomination (NomCom)

      Attendu que le statuts définit les domaines de responsabilités pour les entités comprenant le TLG, y compris la nomination d'experts auprès desquels le Conseil d'administration de l'ICANN peut conseil sur les sujets appropriés ; ces experts non jamais été nommés.

      Attendu que, en 2011, l'ICANN a commandité une révision du TLG qui a identifié que l'attention devait porter sur l'établissement de mécanismes efficaces qui permettent de donner au Conseil les avis techniques qui peuvent être nécessaires, remarquant que la façon actuelle de fonctionner du TLG ne permettait pas de la faire.

      Attendu que les révisions des statuts proposés visent à permettre aux entités composant le TLG de recentrer leur énergie sur leurs fonctions consultatives.

      Attendu que, en résolution 2013.09.28,15, le Conseil d'administration a demandé au président du Conseil de l'ICANN, en coordination avec le Président et CEO, d'initier des communications adressées aux entités composant le TLG de faciliter l'identification d'experts dans le respect du Chapitre XI-A, Article 2, paragraphe 6 des statuts de l'ICANN et le renforcement qui en résulte du mécanisme consultatif du TLG.

      Attendu que, en résolution 2013.09.28.16, le Conseil a donné des instructions au Président et CEO de publier pour consultation publique les révisions des statuts proposées liées à la liaison TLG au Conseil et la nomination d'un membre avec droit de vote au Comité de nomination.

      Attendu que, les amendements proposés ont été publiés pour consultation publique le 30 octobre 2013.

      Attendu que le personnel a donné au Conseil un résumé et une analyse des commentaires publics reçus.

      Attendu que le Conseil a revu et considéré le résumé et l'analyse des commentaires publics et a déterminé que les révisions des statuts nommés ci-joint dans les documents de référence annexe A, résolvent les problèmes discutés ci-dessus.

      Résolu (2013.02.07.03), le Conseil approuve les révisions des statuts telles que postées pour consultation publique au http://www.icann.org/en/news/public-comment/bylaws-amend-tlg-30oct13-en.htm, sous réserve de deux changements sans substance réalisés uniquement pour clarification.

      Fondements de la résolution 2014.02.07.03

      Rappel sur le TLG

      Le groupe de liaison technique (TLG) est un des mécanismes consultatifs créés par le statuts de l'ICANN. Une des fonctions clé que les entités du TLG sont censées accomplir comprend l'identification et la nomination d'experts auprès de qui l'ICANN peut poser les questions techniques. Jusqu'à ce jour, les experts n'ont pas été nommés. Le TLG comporte quatre organisations : (i) l'Institut européen des normes de télécommunication (ETSI), (ii) le Secteur de la normalisation des télécommunications de l'Union internationale des télécommunications (ITU-T), (iii) le Consortium mondial du Web (W3C) et (iv) le Conseil d'architecture de l'Internet (IAB). Le TLG a principalement centré ses efforts sur la nomination d'un agent de liaison auprès du Conseil d'administration de l'ICANN et d'un délégué avec droit de vote au Comité de nomination de l'ICANN (NomCom) Le besoin d'un recentrage du TLG a fait l'objet d'une conversation continue avec l'ICANN, telle qu'indiqué dans la révision organisationnelle du TLG qui avait été commanditée par l'ICANN en 2010 (disponible à l'adresse http://www.icann.org/en/groups/reviews/tlg), qui a formulé des recommandations visant à un changement dans la structure du TLG.

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

      Le Conseil d'administration de l'ICANN a récemment revu la question fondamentale de la façon d'obtenir les avis dont il a besoin. Une partie essentielle de ce travail vise à résoudre la façon dont le Conseil reçoit les avis dont il a besoin et la façon dont les avis, émis au travers des mécanismes consultatifs de l'ICANN, sont suivis. Les avis techniques sont une des parties-clés où les mécanismes consultatifs existants du TLG ne correspondent pas aux besoins du Conseil ou à sa mission telle que définie dans les statuts. L'action du Conseil aujourd'hui, en traitant de la question de l'amélioration de la fonction consultative du TLG, fait partie de la concentration renouvelée du Conseil sur la façon d'organiser et renforcer ses activités.

      Quelle est la proposition à l'étude ?

      L'action envisagée aujourd'hui est d'adopter les révisions des statuts liées au TLG qui ont été publiées pour consultation publique. Les effets de ces révisions sont l'arrêt de la nomination par le TLG d'un agent de liaison au Conseil d'administration, comme celle d'un délégué avec droit de vote au NomCom de l'ICANN. La fin de ces obligations de nomination devrait permettre aux entités de se concentrer sur la partie conseil à l'ICANN, plutôt que sur la nomination d'individus qui ne sont pas autorisés à représenter l'éventail de vue de ces entités à l'intérieur du TLG. Au lieu de concentrer leurs efforts sur la nomination d'un agent de liaison ou un délégué pour NomCom, la tâche principale de chaque entité TLG sera de travailler sur la nomination d'experts auxquels le Conseil d'administration peut demander conseil.

      Le rôle d'agent de liaison n'offre pas cet accès plus global à l'expertise, car le rôle d'agent de liaison tourne chaque année et aucun agent de liaison n'est capable d'offrir un avis reprenant une position représentative de l'ensemble des entités TLG.

      Les révisions des statuts ne représentent pas de changement dans le rôle du TLG qui est de "réunir et faire connaître les information et de guider le Conseil d'administration et les autres entités ICANN." Pas plus qu'il n'y a de changement au sein des quatre entités du TLG. Ce changement proposé vise à simplifier le rôle des entités TLG en anticipation de l'évolution et des améliorations permettant à ces entités d'offrir un avis technique au Conseil d'administration.

      Quelles parties intéressées ou autres ont été consultées ?

      Le 30 octobre 2013, l'ICANN a initié une consultation publique sur la proposition de ces révisions du statuts. (Voir http://www.icann.org/en/news/public-comment/bylaws-amend-tlg-30oct13-en.htm.) La période de consultation publique s'est achevée le 20 décembre 2013. Le Conseil d'administration a pris en compte les commentaires de la communauté pour l'adoption de cette résolution.

      Quelles sont les préoccupations ou les questions soulevées par la communauté ?

      L'ICANN a reçu une réponse substantielle pendant cette période de consultation publique. Les commentateurs ont exprimé leur soutien à l'idée d'augmenter la disponibilité pour des avis techniques au Conseil d'administration et l'efficacité du TLG. Les commentateurs recommandent que l'élimination de l'agent de liaison TLG ne se fasse pas jusqu'à ce qu'à ce qu'un mécanisme permettant au moins régulièrement de demander un avis du TLG soit en place. Les commentateurs sont opposés à la suppression du délégué TLG auprès de NomCom en jugeant que cette suppression présente des risques d'empêcher la communauté NomCom d'atteindre les communautés techniques. (Voir http://forum.icann.org/lists/comments-bylaws-amend-tlg-30oct13/msg00002.html.)

      En ce qui concerne le renforcement du mécanisme permettant le rôle de conseil du TLG, le conseil note que cette problématique a déjà été traitée par le Conseil le 28 septembre 2013 dans la résolution 2013.09.28.15.

      En ce qui concerne l'inquiétude envers la capacité d'atteindre les communautés techniques, le conseil note que chacune des quatre organisations qui constituent le TLG sont déjà engagées dans des efforts pour atteindre les communautés. La suppression du délégué TLG auprès de NomCom n'empêche pas ces organisations de continuer leurs efforts d'information.

      On attend de cette action qu'elle ait un impact financier positif sur l'ICANN. La suppression de l'agent de liaison auprès du conseil et de NomCom procurera des économies financières à l'ICANN. Ces économies devront être examinées dans le contexte plus large des coûts additionnels qui peuvent être associés à l'engagement du Conseil à renforcer le mécanisme de conseil et le rôle accru des entités membres du TLG à identifier les experts qui procureront à l'ICANN les conseils techniques tels que dans le statuts.1 De plus, l'évolution et l'amélioration anticipées du processus permettant à l'ICANN de recevoir des conseils techniques pourrait avoir un impact sur la façon dont l'ICANN gère les questions lies à la sécurité, la stabilité ou la résilience du DNS.

      Les révisions proposées pour les statuts ont été publiées pour consultation publique à l'adresse http://www.icann.org/en/news/public-comment/bylaws-amend-tlg-30oct13-en.htm du 30 octobre 2013 au 20 décembre 2013. Les statuts adoptés contient deux changements sans substance dans le chapitre XI, Article 2.5, dans un but de clarification qui ne nécessitent pas de nouvelle consultation publique.

      Cette décision relève d'une fonction administrative organisationnelle qui ne nécessite pas de consultation publique.

    4. Résolutions du Comité du programme des nouveaux gTLD

      Attendu que le 10 avril 2012 le Conseil d'administration a créé le Comité du programme des nouveaux gTLD auquel il a délégué toute l'autorité légale et décisionnelle du Conseil concernant le Programme des nouveaux gTLD tel qu'il est établi dans sa charte, qui exclut tout ce que le Conseil d'administration n'a pas le droit de déléguer en vertu de la loi, ou conformément à l'Article XII, Section 2 des Statuts de l'ICANN.

      Attendu que le sous-comité du comité de gouvernance du conseil, en charge des conflits et de l'éthique pour les nouveaux gTLD a déterminé que Steve Crocker n'a plus de conflit d'intérêts en ce qui concerne le programme des nouveaux gTLD et que cette détermination a été acceptée par le Conseil.

      Résolu (2014.02.06.10), que Steve Crocker soit par la présente approuvé en tant que membre avec droit de vote du Comité du programme des nouveaux gTLD. Les nouveaux membres du NGPC sont ci-dessous :

      • Cherine Chalaby (Président)
      • Fadi Chehadé
      • Steve Crocker
      • Chris Disspain
      • Heather Dryden (Liaison)
      • Bill Graham
      • Bruno Lanvin
      • Olga Madruga-Forti
      • Erika Mann
      • Gonzalo Navarro
      • Ray Plzak
      • George Sadowsky
      • Mike Silber
      • Jonne Soininen (Liaison)
      • Kuo-Wei Wu

      Fondements de la résolution 2014.02.07.04

      Le Conseil d'administration réaffirme les fondements de ses résolutions 2012.04.10.01-2012.04.10.04, cités dans leur intégralité : Dans le but que les réunions soient efficaces et que des mesures appropriées soient prises concernant le programme des nouveaux gTLD pour la série du programme en cours et tel qu'il est établi dans le Guide de candidature, le Conseil a décidé la création du « Comité du programme des nouveaux gTLD » conformément à l'article XII des statuts, et a délégué l'autorité de prise de décisions liées au programme des nouveaux gTLD au comité pour la série en cours du programme qui a commencé en janvier 2012 et pour le guide de candidature applicable à la série en cours.

      Avoir établi que le comité du programme des nouveaux gTLD (NGPC) ne présente pas de membres ayant un conflit d'intérêt, et s'en remettant à sa décision pour faire autorité, a procuré quelques avantages distincts, y compris l'aide pour éliminer les membres du Conseil présentant un conflit d'intérêt en ce qui concernant la présence aux réunions et les ateliers du Conseil puisque les sujets du programme des nouveaux gTLD peuvent être gérés au niveau du comité. De plus, cela donnera à la communauté une vision transparente de l'engagement du Conseil d'administration en matière de gestion des conflits actuels, potentiels ou perçus.

      Le sous-comité de gouvernance du conseil (BGC) pour les conflits et l'éthique sur les nouveaux gTLD a d'abord évalué les déclarations d'intérêt liés aux nouveaux gTLD de tous les membres du conseil quand la liste des membres du NGPC a été établie pour la première fois. Le sous-comité continue l'examen de chaque déclaration d'intérêt liée aux nouveaux gTLD de chaque nouveau membre du Conseil ainsi que tout changement concernant les déclarations d'intérêts pour déterminer si un membre quelconque du Conseil (y compris les Directeurs dotés du droit de vote et les agents de liaison sans droit de vote) a un conflit d'intérêts actuel, potentiel ou perçu pour qu'il ne soit pas nommé au NGPC.

      Lorsque le sous-comité a évalué pour la première fois sa déclaration d'intérêts, il a déterminé que Steve Crocker avait un conflit. Dr Crocker a récemment soumis quelques changements à sa déclaration d'intérêts liée aux nouveaux gTLD et le sous-comité a soigneusement examiné ces changements. Le sous-comité a déterminé que Steve Crocker n'avait plus de conflit lié aux nouveaux gTLD. Ainsi, le sous-comité a recommandé l'adhésion du Dr Crocker comme membre avec droit de vote du NGPC. Le Conseil d'administration a accepté.

      Cette résolution devrait avoir un impact positif sur la communauté et l'ICANN dans son ensemble, en particulier l'augmentation du nombre de membres du Conseil qui participent aux décisions concernant le programme des nouveaux gTLD.

      Cette action n'est pas censée avoir d'impact fiscal ni tout autre impact sur la sécurité, la stabilité et la résilience du système des noms de domaine.

      Cette décision relève d'une fonction administrative organisationnelle qui ne nécessite pas de consultation publique.

  2. Ordre du jour principal :

    1. Protection des identifiants IGO-INGO dans tous les gTLD PDP.

      Attendu que le 17 octobre 2012, le conseil de la GNSO a lancé un processus de développement de politiques (PDP) sur la protection des identifiants IGO-INGO dans tous les gTLD, traitant des questions mises en avant dans la Charte du groupe de travail PDP à l'adresse http://gnso.icann.org/en/issues/igo-ingo-charter-15nov12-en.pdf [PDF, 189 KB].

      Attendu que le PDP a suivi les étapes prévues dans les statuts du PDP comme indiquées dans le statuts de l'ICANN et le Manuel PDP de la GNSO et a abouti à un rapport final remis au conseil de la GNSO le 10 novembre 2013.

      Attendu que le groupe de travail sur la protection des identifiants IGO-INGO dans tous les gTLD (IGO-INGO WG) a obtenu un consensus sur vingt-cinq recommandations sur ces questions énoncées dans la Charte.

      Attendu que le Conseil GNSO a revu, et discuté ces recommandations du IGO-INGO WG et adopté les recommandations obtenues par consensus du WG par un vote unanime pendant sa réunion du 20 novembre 2013 (voir http://gnso.icann.org/en/council/resolutions#20131120-2).

      Considérant que, après le vote du Conseil de la GNSO, une période de commentaires publics de 30 jours sur les recommandations approuvées a été établie, et que les commentaires ont été résumés et publiés à l'adresse (http://www.icann.org/en/news/public-comment/igo-ingo-recommendations-27nov13-en.htm).

      Attendu que le GAC a recommandé au Conseil de l'ICANN dans son communiqué de Buenos Aires qu'il reste engagé dans la continuation du dialogue avec le NGPC pour finaliser les modalités pour une protection permanente des acronymes des OIG au deuxième niveau, et que le NGPC travaille activement sur la problématique.

      Résolu (204.02.07.05), le Conseil prend acte des recommandations unanimes sur la protection des identifiants IGO-INGO dans tous les gTLD tels que définis dans le rapport final du WG IGO-INGO (voir http://gnso.icann.org/fr/issues/igo-ingo-final-10nov13-fr.pdf [PDF, 707 KB]), et demande un supplément de temps pour examiner les recommandations pour pouvoir prendre en compte l'avis du GAC sur le même sujet.

      Résolu (2014.02.10.01), le Conseil demande au comité du programme des nouveaux gTLD du Conseil de l'ICANN de : (1) prendre en considération les recommandations de politiques de la GNSO qui continue activement de développer une approche répondant à l'avis du GAC sur la protection des OIG ; et (2) de développer une proposition complète pour prendre en compte l'avis du GAC et les recommandations de politiques de la GNSO pour considération par le Conseil d'administration lors d'une réunion future.

      Fondements des Résolutions 2014.02.07.05 et 2014.07.06 :

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

      En réponse à l'avis du GAC sur la protection des identifiants du CRCR, COI et OIG dans le programme des nouveaux gTLD, le Conseil a chargé le GNSO de développé une politique en réponse à l'avis du GAC. Dans ses délibérations, le conseil de la GNSO a déterminé qu'un processus de développement de politiques (DPD) était obligatoire pour résoudre les problèmes sur les protections spécifiques des chaînes au sommet et au second niveau pour les organisations internationales. En octobre 2012, le conseil de la GNSO a approuvé la création d'un PDP sur la question. Le groupe de travail du PDP a publié son rapport initial pour consultation publique le 14 juin 2013 suivi par son rapport final le 10 novembre 2013. Le rapport final inclut plus de vingt recommandations consensuelles du WG et les déclarations minoritaires des représentants des CRCR, OIG et OING qui participaient au WG, du groupe des parties prenantes non commerciales de la GNSO et le Comité consultatif d'At-Large de l'ICANN. Toutes les recommandations obtenues par consensus du WG ont été approuvées unanimement par le conseil de la GNSO

      Suite à la clôture de la période de consultation publique de ces recommandation et l'adoption par le conseil de la GNSO d'un rapport de recommandation pour le Conseil de l'ICANN, la prochaine étape, tel que prévu dans l'annexe A des statuts de l'ICANN, est l'examen des recommandations par le Conseil d'administration de l'ICANN des recommandations de la GNSO. Les statuts obligent le Conseil à se réunir pour discuter les recommandations de la politiques de la GNSO, ceci le plus tôt possible et de préférence pas après la deuxième réunion après réception du rapport du Conseil du chef de l'équipe.

      En outre, selon le chapitre XI Article 2.1 des statuts de l'ICANN, le GAC a le droit de « soumettre directement des questions à la considération du Conseil d'administration, soit par le biais de commentaires ou d'avis préliminaires, soit en recommandant la mise en place d'actions, le développement de nouvelles politiques ou la révision des politiques existantes ». Le GAC a fait part de son avis au Conseil sur le programme des nouveaux gTLD par le communiqué de Beijing daté du 11 avril 2013, du communiqué de Durban daté du 18 juillet 2013 et du communiqué de Buenos Aires daté du 20 novembre 2013. Les statuts de l'ICANN prévoient que le Conseil d'administration tienne compte de l'avis du GAC en matière de politique publique pour la formulation et l'adoption de politiques. Au cas où le Conseil d'administration de l'ICANN déciderait d'agir contrairement à l'avis du GAC, il est tenu d'en avertir ce dernier, en précisant les raisons pour lesquelles l'avis n'a pas été suivi. Le Conseil d'administration et le GAC tenteront ensuite, en toute bonne foi, de trouver une solution réciproquement acceptable. Si une solution ne peut pas être trouvée, le Conseil d'administration expliquera dans sa décision finale les raisons qui l'ont amené à ne pas suivre l'avis du GAC.

      Quelle est la proposition à l'étude ?

      Avant de considérer la résolution des questions substantielles concernant les recommandations de politique du GNSO, le Conseil a examiné la façon dont il préférerait procéder sur ce sujet en terme de procédure.

      La GNSO a adopté par unanimité les recommandations de politiques dans le rapport final sur les PDP IGO-INGO. Les recommandations de politique ont été transmises au Conseil pour examen et considération suivant les statuts de l'ICANN. Le GAC a lui aussi émis un avis pour le Conseil sur la protection des OIG dans le contexte du programme des nouveaux gTLD – le plus récemment dans le Communiqué de Buenos Aires. Parce que cet avis concerne le programme des nouveaux gTLD, le Comité du programme des nouveaux gTLD (NGPC) du Conseil de l'ICANN a examiné l'avis du GAC. Le NGPC n'a pas encore finalisé sa proposition pour prendre en compte l'avis du GAC lié à la protection des OIG mais travaillé activement sur cette question.

      En règle générale, les recommandations de la GNSO sont largement en accord avec l'avis soumis par le GAC au Conseil de l'ICANN. Toutefois, il existe des recommandations de politiques spécifiques de la GNSO qui diffèrent de l'avis du GAC. Pour l'instant, le Conseil envisage de reconnaître les recommandations de politiques de la GNSO dans son rapport final sur les IGO-INGO PDP mais demande un délai supplémentaire pour examiner les recommandations puisque le NGPC travaille actuellement à l'examen de l'avis du GAC sur le même sujet. Le Conseil envisage de prendre une approche holistique dans l'examen des recommandations de politiques de la GNSO et de l'avis du GAC en demandant aux NGPC de (1) examiner les recommandations de politique de la GNSO car elle développe continuellement et activement une approche pour répondre aux avis du GAC sur la protection des OIG et (2) développer une proposition globale qui prend en compte l'avis du GAC et les recommandations de politique du GNSO qui sera examinée par le Conseil lors d'une prochaine réunion.

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

      Le Conseil a révisé le rapport du conseil de la GNSO au Conseil d'administration, ainsi que la synthèse des commentaires publics et le rapport final du Groupe de Travail. Le Conseil a aussi révisé le Communiqué du GAC de Beijing, le Communiqué de Durban et le Communique de Buenos Aires.

      Les inquiétudes et les problèmes soulevés par la communauté et les parties prenantes sur les recommandations de politiques et l'avis du GAC seront discutés dans le même temps que l'examen de la substance des recommandations de politique de la GNSO et l'avis du GAC. Le Conseil examinera alors aussi les impact financiers ou les conséquences sur l'ICANN et la communauté. Aucun problème de sécurité, de stabilité ou de résilience lié au DNS n'est à prévoir suite à l'approbation par le Conseil des recommandations proposées.

      Cette décision est prise selon un processus de développement des politiques qui a été soumis à un processus de consultation publique.

    2. Formation d'un Groupe de travail du Conseil d'administration sur le processus de recrutement et de sélection du comité de nomination ainsi que sa taille et sa composition.

      Attendu que le Conseil a reçu auparavant le rapport final du groupe de travail sur la révision de la finalisation de NomCom le 12 mars 2010 qui demande une revue dans les trois ans des problèmes liés à la composition, la taille et fonction de recrutement du comité de nomination.

      Attendu que le comité des améliorations structurelles (SIC) signifie qu'il est temps de faire le travail de suivi anticipé dans le rapport final et qu'un groupe de travail du Conseil soit créé dans ce but.

      Résolu (2014.02.07.07), le Conseil approuve l'établissement d'un groupe de travail sur le comité de nomination (BWG-NomCom) selon la charte recommandée par le SIC, sa composition étant revue par le comité de gouvernance du Conseil.

      Fondements de la résolution 2014.02.07.0

      Le Conseil règle la question du processus de recrutement et de sélection de NomCom ainsi que la taille et la composition de NomCom, parce que NomCom joue un rôle clé dans les mécanismes de responsabilité de l'ICANN. À cause des lacunes perçues de la structure actuelle de NomCom et les changements dans la composition des parties prenantes de l'ICANN, il est opportun de résoudre ces problèmes critiques maintenant.2 Le groupe de travail proposé doit considérer les sujets significatifs pour la communauté, et par ainsi démontrer la responsabilité de l'ICANN dans la conduite du processus de nomination d'individus qualifiés pour les poste de direction clés d'une manière transparent et éprouvée. Le Groupe de travail suivra les recommandations faites dans une révision organisationnelle précédente mandatée par les statuts de l'ICANN, conformément à la direction du groupe de travail sur la finalisation de la révision (recommandation Nº 10) pour définir la taille et la composition et les fonctions de recrutement et de sélection du NomCom.

      En considérant cette action, le Conseil a revu les documents référencés ci-dessous et les recommandations offertes par le SIC, y compris la charte pour les groupes de travail et a considéré l'option d'ajouter des membres ne faisant pas partie du Conseil au groupe de travail pour une perspective communautaire supplémentaire.

      Il n'y a pas d'impact financier anticipé de cette décision, et il n'y aura pas d'impact sur la sécurité, la stabilité et la résilience du système des noms de domaine suite à cette action.

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

      Documents référencés :

    3. Recommandations du GNSO sur le processus de développement de la politique du Whois « détaillé » démarre

      Attendu que, le 13 mars 2012, le conseil de la GNSO a lancé un processus de développement des politiques (PDP) sur l'utilisation du Whois détaillé pour tous les registres gTLD, à la fois existants et futurs (voir la charte PDP WG, défini à l'adresse https://community.icann.org/x/vIg3Ag).

      Attendu que le PDP a suivi les étapes prévues dans les procédures PDP données dans les statuts et la procédure régulière, qui ont donné lieu au rapport final délivré le 21 octobre 2013 ;

      Attendu que le groupe de travail WG PDP du Whois détaillé a atteint un consensus total sur les recommandations concernant les questions énoncées dans la Charte ;

      Considérant que le Conseil de la GNSO a révisé et discuté les recommandations du groupe de travail PDP du Whois détaillé, et qu'il a adopté les recommandations le 31 octobre 2013 par un vote à la majorité qualifiée et à l'unanimité (voir : http://gnso.icann.org/en/council/resolutions#20131031-1).

      Attendu que le vote du conseil de la GNSO dépassait le nombre de votes requis, tels que définis dans les statuts de l'ICANN pour imposer des politiques consensuelles nouvelles sur les parties contractantes de l'ICANN.

      Attendu que le conseil de la GNSO réunira une équipe de révision de la mise en œuvre du Whois détaillé pour aider le personnel de l'ICANN dans l'élaboration des détails de mise en œuvre de la nouvelle politique si celle-ci est approuvée par le Conseil d'administration de l'ICANN.

      Considérant que, après le vote du Conseil de la GNSO, une période de commentaires publics de 30 jours sur les recommandations approuvées a été établie, et que les commentaires ont fortement soutenu les recommandations (http://www.icann.org/en/news/public-comment/thick-whois-recommendations-06nov13-en.htm).

      Résolu (2014.02.07.08), le Conseil adopte les recommandations politiques du conseil de la GNSO pour une nouvelle politique consensuelle sur le Whois détaillé comme défini dans l'article 7.1 du rapport final (voir http://gnso.icann.org/fr/issues/whois/thick-final-21oct13-fr.pdf [PDF, 703 KB]).

      Résolu (2014.02.07.09), le Conseil d'administration demande au Président et CEO de développer et d'exécuter un plan d'implantation pour une politique du Whois détaillé en ligne avec le guide offert par le Conseil de la GNSO. Le Président et CEO est autorisé et enjoint de travailler avec l'équipe de révision de l'implémentation pour développer les détails de mise en œuvre de la politique, et de continuer la communication avec la communauté concernant ces travaux.

      Fondements des Résolutions 2014.02.07.08 et 2014.02.07.09 :

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

      L'ICANN spécifie les exigences du service Whois pour les opérateurs de registre des domaines de premier niveau génériques (gTLD) au moyen du contrat de registre (RA) et du contrat d'accréditation des bureaux d'enregistrement (RAA). Les registres et les bureaux d'enregistrement satisfont à leurs obligations à l'aide de deux différents modèles de service. Les deux modèles les plus répandus sont ceux du Whois « résumé » et du Whois « détaillé ». La distinction est basée sur la manière dont les deux ensembles différents de données sont gérés. Un ensemble de données est associé au nom de domaine, et le deuxième ensemble de données est associé au titulaire du nom de domaine.

      • Un registre « résumé » fait le stockage et s'occupe seulement de la gestion des informations associées au nom de domaine. Cet ensemble contient les données suffisantes pour identifier le bureau d'enregistrement responsable du parrainage, le statut de l'enregistrement, les dates de création et d'expiration de chaque enregistrement, les données du serveur de noms, le dernier enregistrement mis à jour dans le stockage de données Whois et l'URL pour le service Whois du bureau d'enregistrement.
      • Pour les registres « résumés », les bureaux d'enregistrement gèrent le deuxième ensemble de données associées au titulaire du domaine et fournissent le service via leurs propres services Whois, conformément à l'article 3.3 du RAA pour les domaines sponsorisés. .COM et .NET sont des exemples de registres « résumés ».
      • Les registres « détaillés » maintiennent et fournissent les deux ensembles de données (nom de domaine et titulaire de nom de domaine) via le Whois. .INFO et .BIZ sont des exemples de registres « détaillés ».

      Pour explorer les bénéfices possibles d'obliger tous les registres gTLD à donner des Whois détaillés, le conseil de la GNSO a initié un processus de développement de politiques de la GNSO le 14 mars 2012. Le groupe de travail du PDP a été formé et instruit de considérer les sujets suivants dans ses délibérations :

      • Cohérence de la réponse
      • Stabilité
      • Accès aux données du Whois
      • Impact sur la confidentialité et la protection des données
      • Implications financières
      • Synchronisation / migration
      • Autorité
      • Concurrence entre les services de registre
      • Applications actuelles du Whois
      • Dépôt de données
      • Exigences d'enregistrement du port 43 du Whois

      Le groupe de travail a publié son rapport initial pour consultation publique le 21 juin 2013, suivi par son rapport final le 21 octobre 2013 qui a reçu le soutien unanime consensuel du PDP WG ainsi que du consensus de la GNSO. Une période de consultation publique a suivi le vote du conseil de la GNSO, comme spécifiée dans les statuts de l'ICANN. Les commentaires ont montré un fort soutien des recommandations de la GNSO sans aucune opposition ou problèmes soulevés par un groupe des parties prenantes ou une unité constitutive. En conséquence, cette question et les recommandations de la GNSO sont mûres pour la considération par le Conseil de l'ICANN.

      Quelle est la proposition à l'étude ?

      Les options suivantes sont prises en considération :

      1 : La fourniture de services de Whois détaillé, avec un étiquetage et un affichage cohérents suivant le modèle décrit dans la spécification 3 du RAA 20133 , devrait devenir une exigence pour tous les registres de gTLD, actuels et futurs.

      De plus, le conseil de la GNSO a recommandé que :

      2 : Suite à l'adoption du rapport final et des recommandations formulées par le conseil de la GNSO, le forum de commentaires publics subséquent (avant l'examen par le Conseil d'administration) et la notification du Conseil de l'ICANN au GAC, il soit demandé spécifiquement un avis sur toutes considérations liées à la transition du Whois résumé au Whois détaillé qui devraient être prises en compte dans le cadre de la mise en œuvre.

      3 : Comme une partie du processus de mise en œuvre, une révision légale de la législation applicable à la transition des données d'un modèle résumé à un modèle détaillé qui n'a pas encore été considérée dans le mémo du groupe de travail d'experts (EWG)4 est en cours ; une attention spéciale est portée aux problèmes potentiels de confidentialité qui pourraient résulter des discussions sur la transition du Whois résumé au Whois détaillé : cela comprend, par exemple, une orientation sur la manière dont l'exigence contractuelle de longue date pour les bureaux d'enregistrement de prévenir chaque titulaire de nom de domaine – et d'obtenir son consentement – pour toute utilisation de données personnelles identifiables présentées par le titulaire du nom de domaine devrait être appliquée aux enregistrements concernés par la transition. Si des problèmes de confidentialité issus de ces discussions sur la transition n'ayant pas été anticipés par le groupe de travail et exigeant une considération de la politique supplémentaire se présentaient, l'équipe de révision de la mise en œuvre est censé les communiquer au conseil de la GNSO afin de prendre les mesures pertinentes.

      Quelles parties intéressées ou autres ont été consultées?

      En supplément des mises à jour régulières du conseil de la GNSO, des ateliers ont été organisés pour informer et solliciter la contribution de la communauté de l'ICANN lors de réunions de l'ICANN (voir par exemple http://durban47.icann.org/node/39777 et http://beijing46.icann.org/node/37029).

      Les déclarations de unités constitutives/parties prenantes ont été exigées de même que l'avis des autres organisations de soutien et des comités consultatifs de l'ICANN lors d'une étape précédente du processus. Presque tous les groupes des représentants et les unités constitutives de la GNSO ont offert un avis, en complément du comité consultatif At-Large (voir https://community.icann.org/x/WIRZAg).

      Le groupe de travail a ouvert un forum de consultation publique sur le rapport initial le 15 mars 2013.

      Tous les commentaires reçus sur le rapport initial ont été revus et pris en considération par le groupe de travail DPD du Whois détaillé (voir article 6 du rapport final).

      En outre, le rapport final a fait l'objet d'une demande de commentaires à la suite de l'approbation du conseil de la GNSO et avant d'être considéré par le Conseil de l'ICANN (voir http://www.icann.org/en/news/public-comment/thick-whois-recommendations-06nov13-en.htm).

      De plus, le Conseil a averti [PDF, 815 KB] le GAC de la soumission proche de cette question et à la demande du conseil de la GNSO le GAC a été spécifiquement encouragé à donner leur avis lié à la transition du Whois résumé au Whois détaillé qui doit être pris en compte dans le processus de mise en œuvre (aucun avis n'a été reçu au moment de la soumission de ce papier).

      Quelles sont les préoccupations ou les questions soulevées par la communauté ?

      Aucune inquiétude n'a été manifestée par la communauté concernant le rapport final et ses recommandations. Tous les autres commentaires reçus avec la publication du rapport final ont été révisés et abordés par le PDP WG comme souligné dans l'article 6 du rapport final et sont reflétés dans les recommandations finales du groupe de travail.

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

      Le Conseil a révisé le rapport du conseil de la GNSO au Conseil d'administration, ainsi que la synthèse des commentaires publics. Le Conseil a aussi observé que bien que l'équipe de révision du Whois n'ait pas fait de recommandations spécifiques au moment du rapport final [PDF, 696 KB] comme il n'existait aucune politique spécifique du Whois détaillé pouvant être révisée, elle a recommandé que "le Service Internet soit remanier pour offrir un facilité d'utilisation améliorée pour les consommateurs, y compris l'affichage des données complètes du titulaire pour tous les noms de domaine gTLD qui sera obtenue en exigeant que tous les gTLD fonctionnent sur le modèle de Whois détaillé.

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

      Les recommandations ont été élaborées selon le processus d'élaboration des politiques de la GNSO, telle que décrit dans l'annexe A des statuts de l'ICANN et ont reçu l'appui unanime du conseil de la GNSO. Comme indiqué dans les statuts de l'ICANN, le soutien unanime à cette motion par le Conseil (majorité qualifiée) oblige le Conseil à adopter la recommandation, sauf si, par un vote de plus de 66 %, le Conseil détermine que la politique concernée n'est pas dans le meilleur intérêt de la communauté de l'ICANN ou de l'ICANN.

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

      De nombreux bénéfices sont attendus en résultat de l'exigence du Whois détaillé pour tous les registres gTLD, comme souligné dans le rapport final PDP du Whois détaillé (voir http://gnso.icann.org/fr/issues/whois/thick-final-21oct13-fr.pdf [PDF, 703 KB]). Toutefois, il faut reconnaître qu'une transition des registres gTLD résumés actuels affectera plus de 120 millions d'enregistrements. En conséquence, le personnel a l'intention de procéder prudemment et de mettre en œuvre la transition recommandée du Whois résumé au Whois détaillé. Le personnel s'attend à ce qu'il y ait des impacts financiers légers associés à la transition telle que couverte par l'article 5.6 du rapport final – Implications financières. Spécifiquement, la transition du Whois résumé en un Whois détaillé aura un coût ponctuel, mais le personnel croit qu'il est possible de gérer pour minimiser ces coûts. De plus, reconnaissant que la plupart des bureaux d'enregistrement enregistre déjà avec le TLD résumé et que les seuls registres fonctionnant actuellement en gTLD résumés (Verisign) fonctionnent aussi en gTLD détaillés, les parties contractantes affectées ne devraient pas avoir une courbe d'apprentissage importante ou de nouveaux systèmes de logiciels pour faire cette transition.

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

      En addition à tous les changements nécessaires dans le processus pour les bureaux d'enregistrement et les registres gTLD tels que soulignés dans la section précédente, il y aura vraisemblablement des impacts financiers liés à la mise en œuvre de cette politique par exemple en relation à la révision légale demandées sur les questions potentielles de confidentialité pouvant naître des discussions sur la transition de Whois résumé à Whois détaillé, mais ces coûts sont anticipés être dans les limites du budget actuel et/ou seront anticipés pour la prochaine année fiscale commençant en juillet 2014.

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

      Il n'y a aucune implication sur la sécurité, la stabilité et la résilience du DNS si le Conseil d'administration approuve les recommandations proposées, puisque le Whois détaillé a déjà été mis en œuvre pour d'autres registres gTLD et est exigé des nouveaux gTLD. De plus, l'ICANN a l'expérience de la gestion de transitions similaires comme lorsque le registre .org est passé d'un registre résumé à un registre détaillé en 2004.

      Cette décision est prise selon un processus de développement des politiques qui a été soumis à un processus de consultation publique.


1 La logique de la résolution 2014.02.07.03 a été mise à jour le 18 février 2014 pour montrer que les impacts financiers nés de l'adoption de cette résolution doivent être considérés dans le contexte des coûts additionnels pouvant être associés au renforcement des mécanismes de conseil du TLG, établi dans le statuts.

2 ERRATA : Le fondement pour la résolution 2014.02.07.07 a été mise à jour le 18 février 2014 pour clarifier le fait que la décision du Conseil de créer un groupe de travail NomCom a été faite pour résoudre les déficiences structurelles de NomCom – et non la composition de NomCom. Le texte original disait, "À cause des inquiétudes exprimées sur les déficiences réelles et perçues de l'actuel NomCom et les changements dans la composition des parties prenantes de l'ICANN, il est opportun de résoudre certains problèmes critiques maintenant".

3 http://www.icann.org/fr/resources/registrars/raa/approved-with-specs-27jun13-fr.htm#whois

4 voir http://forum.icann.org/lists/gnso-thickwhoispdp-wg/pdfLtpFBYQqAT.pdf [PDF, 146 KB]

resolutions-07feb14-fr.pdf  [262 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."