Skip to main content
Resources

Procès-verbal | Réunion spéciale 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/minutes/minutes-28jul11-en.htm

Une réunion extraordinaire du Conseil d'administration de l'ICANN a eu lieu le 28 juillet 2011 à 11:00:00 UTC.

Le président Steve Crocker a rapidement rappelé la séance à l'ordre.

Outre le président, les administrateurs suivants ont participé à toute ou une partie de la réunion : Rod Beckstrom (président et PDG), Sébastien Bachollet, Cherine Chalaby, Bertrand de la Chapelle, Chris Disspain, Bill Graham, Gonzalo Navarro, Ray Plzak, R. Ramaraj, George Sadowsky, Mike Silber, Bruce Tonkin (Vice président), Katim Touray, et Kuo-Wei Wu.

Erika Mann a envoyé des excuses.

Les agents de liaison suivants du Conseil ont participé à toute ou une partie de la réunion : Heather Dryden, liaison du GAC ; Ram Mohan, liaison du SSAC ; Thomas Narten, liaison de l'IETF ; Reinhard Scholl, liaison de TLG et Suzanne Woolf, liaison du RSSAC.

  1. Ordre du jour approuvé
  2. Réception du cadre de sécurité, stabilité et résilience pour l'exercice fiscal 2012
  3. Nomination d'un nouveau médiateur
  4. Rapport du PDG
  5. Questions diverses

  1. Ordre du jour approuv

    Le président du Conseil d'administration a introduit l'ordre du jour et a proposé la résolution de l'ordre du jour approuvé.

    Le Conseil a ensuite pris les décisions suivantes:

    Résolu, les résolutions suivantes de cet ordre du jour sont approuvées:

    1.1. Approbation du procès verbal de la réunion du Conseil de l'ICANN du 20 juin 2011

    Résolu (2011.07.28.01), le Conseil approuve les procès-verbaux de la Réunion du Conseil de l'ICANN du 20 juin 2011.

    1.2. Approbation du procès verbal de la réunion du Conseil de l'ICANN du 24 juin 2011

    Résolu (2011.07.28.02), le Conseil approuve les procès-verbaux de la Réunion du Conseil de l'ICANN du 24 juin 2011

    1.3. Approbation du procès verbal de la réunion organisationnelle du Conseil de l'ICANN du 24 juin 2011

    Résolu (2011.07.28.03), le Conseil approuve les procès-verbaux de la réunion du Conseil de l'ICANN du 24 juin 2011.

    1.4. Approbation du procès verbal de la réunion du Conseil de l'ICANN du 25 juin 2011

    Résolu (2011.07.28.04), le Conseil approuve les procès-verbaux de la Réunion du Conseil de l'ICANN du 25 juin 2011

    1.5. Approbation de la redélégation du domaine .om qui représente l'Oman

    Attendu que .OM est le code de pays de deux lettres correspondant à Oman dans la liste ISO 3166-1.

    Considérant que l'ICANN a reçu une demande de redélégation de .OM en faveur de l'autorité de régulation des télécommunications ;

    Considérant que l'ICANN a examiné la demande et a déterminé que la redélégation proposée répond aux intérêts des communautés Internet locales et mondiales ;

    Il est Résolu (2011.07.28.05), que la redélégation proposée du domaine de premier niveau .OM à l'autorité de régulation des télécommunications est approuvée.

    Fondements de la résolution 2011.07.28.05

    Pourquoi le Conseil aborde-t-il cette question maintenant ?
    Le personnel soumet à la considération du Conseil les requêtes de délégation et redélégation des domaines de code de pays. Après avoir satisfait les demandes du personnel en fournissant une candidature suffisamment complète, le candidat a une probabilité raisonnable d'obtenir l'approbation du Conseil. Conformément aux engagements de l'ICANN visant à effectuer de manière efficiente le traitement des demandes liées à la fonction IANA et, notamment, à la zone racine DNS, le Conseil de l'ICANN cherche à évaluer ces demandes lors de sa prochaine assemblée extraordinaire.

    Quelles sont les propositions à l'étude ?
    Il est proposé d'approuver la demande à l'IANA de changer ou de désigner l'organisation de parrainage (connue également sous le nom de gestionnaire ou administrateur) d'un domaine de premier niveau de code de pays.Conformément à la pratique établie, le Conseil de l'ICANN est impliqué dans la décision de procéder à de telles demandes comme une étape de ce processus multi- étapes.

    Quelles parties intéressées ou autres ont été consultées?
    Dans le cadre de l'évaluation d'une demande de délégation, le personnel de l'ICANN consulte le candidat, l'opérateur actuel (le cas échéant), et d'autres parties directement concernées. Conformément à la pratique de l'ICANN de maintenir la confidentialité des demandes de modification de la zone racine, l'ICANN n'a pas effectué de consultation ouverte sur cette question.

    Quelles sont les préoccupations ou les questions qui ont été soulevées par la communauté ?
    Quelques préoccupations ou questions concernant cette action ont été soulevées dans le rapport public qui sera bientôt publié. Ce rapport, qui sera publié au site Web de l'IANA (http://www.iana.org/) est censé mener à bonne fin le traitement définitif des demandes de modifications de la zone racine, normalement 1 ou 2 mois après la décision du Conseil.

    Quels sont les documents importants qui ont été révisés par le Conseil ?
    Le Conseil participe à l'évaluation de demandes impliquant une diversité de critères d'intérêt public. Ce critère vise à établir l'éligibilité des codes de pays (par exemple, énumérés dans la norme ISO 3166-1) ; à établir la proposition d'un administrateur soutenu par la communauté Internet locale ; la compétence opérationnelle et technique de l'opérateur proposé ; l'opération de l'administrateur proposé depuis une base locale et en vertu de la loi locale ;à établir qu'il opère de manière juste et équitable ; à ce que, au cas où il y aurait un transfert des opérations, un plan approprié soit mis en place pour préserver la continuité de la stabilité du domaine ; et à établir que l'action soit compatible avec toutes lesrèglementations et les lois locales applicables. Lors du processus de compilation du personnel, le candidat est prié de fournir une variété de documents à l'appui de ces différents aspects. Toute information pertinente sur ces documents fournis et d'autres recherches du personnel est adressée au Conseil et publiée dans un rapport public à la fin de la mise en œuvre d'une demande approuvée.Demande

    Quels sont les facteurs que le Conseil a trouvés significatifs ?
    Le Conseil tient compte des facteurs décrits dans le rapport public, à l'égard des principes fondamentaux de délégation de domaine de code de pays décrits précédemment.

    Cela a-t-il des effets positifs ou négatifs pour la communauté ?
    L'approbation en temps opportun des administrateurs de noms de domaine de code de pays répondant aux divers critères d'intérêt public est positive vis-à-vis de la mission globale de l'ICANN et les communautés locales, dont les domaines de premier niveau de code de pays sont désignés pour desservir.

    Cela a-t-il un impact au niveau fiscal sur l'ICANN (plan stratégique, plan opérationnel, budget), la communauté ou le public ?
    La gestion de délégations des codes de pays dans la zone racine du DNS fait partie des fonctions de l'IANA, et le processus de délégation ne devrait pas produire une variation significative des dépenses prévues. L'ICANN n'est pas censé évaluer l'impact financier des opérations internes des domaines de premier niveau de code de pays au sein d'un pays ; l'ICANN doit seulement assurer que l'opérateur réside dans le pays et qu'il possède les mécanismes appropriés pour permettre à la communauté Internet locale de surveiller correctement la continuité de ses opérations de domaine.

    Y a-t-il des questions de sécurité, de stabilité ou de résilience concernant le DNS ?
    Pour les délégations de domaine de premier niveau de code de pays, l'ICANN cherche à approuver les demandes qui abordent de façon satisfaisante les préoccupations raisonnables, et puisque le nouvel administrateur proposé a fait preuve de ses compétences opérationnelles et techniques, ces préoccupations devraient être peu significatives.

    Résolutions 2011.07.28.01, 2011.07.28.02, 2011.07.28.03, 2011.07.28.04, et 2011.07.28.05 ont été approuvés en un seul vote approuvant l'ordre du jour convenu.  Tous les membres du conseil présents ont approuvé ces résolutions à l'unanimité. Erika Mann et Mike Silber n'étaient pas disponibles pour voter ces résolutions.

  2. Réception du cadre de sécurité, stabilité et résilience pour l'exercice fiscal 2012

    Jeff Moss, l'officier en chef, a présenté un rapport concernant le cadre SSR, y compris une discussion de la manière dont les considérations de la communauté sur les cadres SSR précédents ont été incorporées au cadre de l'exercice fiscal 2012.  Jeff a expliqué que, en vertu des commentaires reçus à Cartagena, ce rapport est maintenant plus rationnalisé et fait une distinction plus poussée des secteurs où l'ICANN a le contrôle opérationnel, comme par exemple DNSSEC et les opérations de la zone racine, des secteurs où l'ICANN est collaborateur et coordinateur , et des secteurs où l'ICANN est plutôt un observateur des activités menèes par d'autres groupes.  Le Cadre SSR 2012 a été révisé avec le SSAC et At-Large, et il a fait l'objet de commentaires publics.  Le cadre a été discuté avec plusieurs regroupements lors de la réunion à Singapour et, en général, les commentaires sur les changements ont été positifs. 

    Jeff a signalé que la communauté attend toujours que l'ICANN la tienne mieux au courant sur le fonctionnement et la mise en place des cadres SSR précédents et qu'il en fournisse plus de détails sur l'aspect budgétaire. En vue de répondre à cette inquiétude, l'équipe de révision de l'Affirmation des engagements se penche actuellement sur les questions de Sécurité et Stabilité. Des actions sont en cours pour répondre à ces préoccupations.

    Le président a confirmé que l'on a demandé au Conseil d'accuser réception du Cadre.  Par la suite, le président a manifesté son opinion sur le cadre 2012. Il a dit qu'il est amélioré par rapport aux cadres présentés auparavant, et il a remercié Patrick Jones et le personnel pour ce travail.  Le président a également signalé qu'aucun plan ne doit avoir des critères permettant l'évaluation des objectifs mesurables  et que ce cadre fournit une meilleure base pour les rapports que les cadres précédents.  L'utilisation de ce cadre est la ligne de base ; le président a signalé qu'aller plus loin, faire des rapports contre le cadre serait un processus simple.

    Jeff a confirmé que la transparence et la capacité de faire des commentaires contre le plan a été très important pour sa conception.  Jeff s'est également demandé si le Conseil souhaite, lors d'une prochaine étape, faire évoluer le plan SSR.

    Ram Mohan a confirmé que lui-même et Ray Plzak, à travers leur travail au sein du comité de gouvernance du Conseil, ont la tâche de recommander les membres pour un groupe de travail DNS dont l'objectif sera de surveiller l'exécution des plans SSR ; cela devra être disponible pour la considération du Conseil lors de sa prochaine réunion.  La charte et la portée du groupe de travail devront également être définies, à savoir, entre autres, s'il s'agira d'un groupe permanent.

    Par la suite, le président a demandé au PDG son opinion sur l'objectif du groupe de travail.

    Le PDG a confirmé que le groupe de travail en question aura pour objectif de développer un processus pour la révision et la supervision du système de gestion des risques du DNS  ; la supervision du plan SSR y est incluse.  Le PDG a signalé que le caractère ciblé de la tâche à accomplir par ce nouveau groupe de travail devrait conduire, en temps utile, à des résultats et à des progrès dans ce domaine.

    Le Président a rappelé les inquiétudes exprimées par le PDG par rapport à la modification de la Charte du SSAC visant l'élimination de la responsabilité du cadre de sécurité sans qu'aucune activité compensatoire ne soit prévue, alors que le maintien de la sécurité, la stabilité et la résilience du DNS figurent parmi les obligations majeures de l'ICANN. Le Président a demandé au PDG si la tâche envisagée par le nouveau groupe de travail en cours de création était satisfaisante à ses yeux.

    Le PDG s'est dit satisfait de cette initiative, d'autant plus que le traitement des questions de sécurité, stabilité et résilience du DNS sous le leadership du Conseil d'administration permettra à l'ICANN d'être plus proactif et rigoureux en matière de mesure et de vigilance du risque. Le PDG a commenté qu'il existe un intérêt croissant chez les experts externes pour établir des relations stratégiques avec l'ICANN afin d'apporter des idées pouvant contribuer au développement de cadres en matière de risque.

     Le Président a par la suite demandé de passer au vote et le Conseil d'administration a pris la décision suivante :

    Attendu que le cadre de sécurité, stabilité et résilience (SSR) pour l'exercice fscal 2012  a été publié en ligne pour la consultation publique du 2 mai au 7 juin 2011.

    Attendu que le résumé et l'analyse des commentaires publics ont été réalisés et publiés le 8 juin 2011.

    Attendu que le personnel a organisé une séance d'information destinée à la communauté lors de la conférence de Singapour et incorpore actuellement les remarques et les retours d'information reçus à cette occasion-là dans les priorités opérationnelles décrites dans le cadre SSR, y compris les analyses comparatives, les objectifs, les étapes importantes et un mécanisme permettant d'évaluer le succès des activités SSR.

    Résolu (2011.07.28.06), que le Conseil accuse la réception du cadre SSR pour l'exercice fiscal 2012.

    Fondements de la résolution 2011.07.28.06

    Selon l'affirmation d'engagements signée par l'ICANN et le Ministère du Commerce des États-Unis le 30 septembre 2009, préserver la sécurité, la stabilité et la résilience du DNS constitue un engagement clé. L'affirmation reconnaît dans sa section 9.2 que l'ICANN a adopté un plan de sécurité, stabilité et résilience (SSR) qui sera régulièrement actualisé afin de refléter les menaces naissantes pour le DNS, y compris les identifiants unique. Les plans SSR précédents ont été publiés en 2009 et 2010, et le Conseil d'administration de l'ICANN en a accusé la réception à l'occasion des conférences internationales de Sydney en Australie (juin 2009) et de Carthagène en Colombie (décembre 2010).

     Cette dernière version du cadre SSR, actualisée en un format plus simplifié et accessible, a été publiée en mai 2011 afin de faire coïncider la présentation de la documentation de base de l'ICANN sur les SSR avec la publication du plan opérationnel et budget de l'ICANN pour l'exercice fiscal 2012. Ce document informe la communauté sur le rôle de l'ICANN en matière de SSR, décrit les domaines dans lesquels l'ICANN a une responsabilité opérationnelle, les domaines dans lesquels l'ICANN a un rôle de collaboration, facilitation et contribution, et les domaines dans lesquels l'ICANN est un observateur des activités menées par d'autres au sein de l'écosystème. Les remarques de la communauté reçues au cours de la période de consultation publique étaient en général en faveur du format révisé, et demandaient plus de spécificité et de précision dans les définitions.

     Un document du Conseil comprenant les détails du cadre SSR et une annexe fournissant des informations relatives aux commentaires reçus entre le 2 mai et le 7 juin 2011 ont été remis au Conseil d'administration. 

     Le document est distinct du Plan opérationnel et budget de l'ICANN et nul impact fiscal découlant de cette décision n'est prévu. Le cadre fournit des informations sur les activités prévues par l'ICANN en matière de SSR pour le prochain exercice budgétaire.

    La Résolution 2011.07.28.06 a été par tous les membres présents du Conseil à l'unanimité. Erika Mann et Mike Silber n'étaient pas disponibles pour voter cette résolution.

  3. Nomination d'un nouveau médiateur

    John Jeffrey, avocat-conseil et secrétaire, a présenté au Conseil un rapport sur le travail accompli par le Comité de rémunération et le Conseil d'administration pour identifier un candidat au poste de médiateur de l'ICANN.  Le Conseil a identifié deux candidats finaux et leur a fait passer une ensemble d'entretiens pendant la Réunion de l'ICANN à Singapour. Le Comité de rémunération a recommandé un des candidats. Le Comité de rémunération et l'avocat-conseil se sont penchés sur la rémunération proposée, et au nom du Conseil, l'avocat-conseil en a discuté avec le candidat retenu.

    Bruce Tonkin a confirmé que le Comité de rémunération, tel qu'il était intégré avant la fin de la Réunion de Singapour [Peter Dengate Thrush, Rita Rodin Johnston, R. Ramaraj et Bruce] a rencontré un certain nombre de candidats, et que les entretiens avec les candidats finaux étaient ouverts à tous les membres du Conseil.

    Bertrand de La Chapelle a demandé à ce que ce type de procédures soient formalisées ou précisées dans l'avenir, de manière à ce que l'ensemble du Conseil soit au courant de la démarche à suivre pour ce type d'élections.

    Katim Touray a suggéré d'autres formats d'entretien pour les candidats, susceptibles de permettre à un plus grand nombre de membres du Conseil d'examiner et d'évaluer de manière générale les candidats.

    Les qualités des candidats ont été discutées et sur la base de la recommandation du Comité de rémunération , la motion ci-dessus a été présentée par Bruce Tonkin et soutenue par R. Ramaraj :

    Attendu que le 31 janvier 2011, le médiateur de l'ICANN s'est engagé dans d'autres projets.

    Attendu que depuis le 1er février 2011, un médiateur intérimaire accomplissait toutes les fonctions et remplissait les responsabilités du médiateur.

    Attendu que l'ICANN a procédé à une recherche approfondie et mondiale d'un nouveau médiateur.

    Attendu que le Conseil a identifié un nouveau médiateur qui a accepté le poste.

    Il est résolu (2011.07.28.07), conformément à l'article V, section 1.2 des règlements de l'ICANN, que le Conseil nomme par la présente Chris LaHatte médiateur de l'ICANN pour un mandat initial de deux ans, entrant en vigueur le 28 juillet 2011 et ce jusqu'au 27 juillet 2013, et autorise l'avocat-conseil et le secrétaire à signer un accord avec M. LaHatte.

    Fondements proposés de la résolution 2011.07.28.07 :

    Les règlements de l'ICANN exigent que l'ICANN maintienne un bureau de médiateur. Voir Article V du Règlement à l'adresse http://www.icann.org/fr/general/bylaws-fr.htm#V. Pour l'ICANN, la fonction de médiateur a un impact positif sur la transparence et la responsabilité de l'ICANN, cette fonction étant l'un des trois mécanismes principaux de responsabilité au sein de l'ICANN Étant donné qu'il existe un budget pour un médiateur de l'ICANN depuis 2004 lorsque le premier médiateur a été nommé, remplacer le médiateur intérimaire actuel aura un impact financier minime sur l'ICANN. La nomination d'un nouveau médiateur n'aura pas d'impact négatif sur la sécurité, la stabilité et la résilience systémiques du système de noms de domaine.

    Onze membres du Conseil d'administration ont voté en faveur de la résolution 2011.07.28.07. Sébastien Bachollet, Bertrand de La Chapelle et Katim Touray se sont abstenus de voter sur la résolution et Erika Mann and Mike Silbern'étaient pas disponibles pour voter. La résolution a été adoptée.

  4. Rapport du PDG

    Le PDG a présenté au Conseil un rapport sur les activités et les réalisations de l'organisation depuis la réunion de Singapour. Il a félicité Cherine Chalaby et Ray Plzak pour les résultats de leurs visites aux bureaux de Marina del Rey ainsi que pour leur contribution aux questions d'ordre financier. Il a également abordé les activités de formation du Conseil et d'autres questions opérationnelles. Le PDG a également fait référence à son travail avec le nouveau Président pour la préparation du prochain atelier du Conseil, ainsi que le travail accompli avec l'équipe exécutive afin d'établir des cibles et des objectifs chiffrés pour les points prévus dans le plan stratégique.

    Le PDG a remercié les membres du Conseil pour leur contribution à l' élaboration de la réponse FNOI de l'ICANN au Département de Commerce.

    Le PDG a également attiré l'attention sur le travail d'intégration et de renforcement du groupe de sécurité accompli par Jeff Moss.

    Le PDG a par la suite commenté l'ordre du jour actualisé pour la réunion du mois d'octobre à Dakar, Sénégal, y compris les points concernant la participation à distance. Le Président ainsi que d'autres membres du Conseil ont confirmé leur support à la tenue de la réunion à Dakar.

    Le PDG a terminé son rapport avec des informations concernant le recrutement, y compris le recrutement d'un nouveau Directeur financier et d'un Directeur général pour la région Afrique, ainsi que la dotation du groupe des nouveaux gTLD. Le PDG a également signalé le travail accompli au sein de l'ICANN pour planifier tous les détails du programme pour les nouveaux gTLD, y compris le support au groupe de travail commun sur l'aide au candidat aux nouveaux gTLD. Finalement, le PDG a indiqué que les données financières pour l'exercice budgétaires 2012 sont meilleures que prévu.

    Bertrand de La Chapelle a fait des remarques sur le rapport du PDG, a demandé au Conseil à être présenté aux nouveaux salariés lors de l'atelier à Marina del Rey, et a suggéré la correction d'un point concernant le Forum pour la gouvernance de l'Internet (FGI). Bertrand a aussi demandé plus d'informations sur l'état d'avancement de la refonte du site Web icann.org et du plan de communication pour les nouveaux gTLD, y compris des analyses du personnel sur la portée de la communication du programme à ce jour.

    Le PDG a attiré l'attention sur l'extension et la difficulté du processus de planification nécessaire pour gérer la logistique du plan de communications après l'approbation du programme par le Conseil à Singapour. Il a signalé que des consultants externes peuvent s'avérer nécessaires à ce stade pour réaliser les analyses demandées par Bertrand, étant donné que l'équipe se focalise sur la planification des conférences et des événements. Il est clair, toutefois, qu'il est nécessaire d'inclure dans le programme la mesure de l'impact des événements et de la communication. En ce qui concerne le site Web, le long délai nécessaire pour achever sa refonte est lié à l'ampleur du site lui même.  Le PDG a proposé de tenir une réunion informelle du Conseil sur ce sujet.

    Sébastien Bachollet a fait des commentaires sur le point concernant le JAS et a remercié le PDG pour sa présentation à ce propos. Sébastien a aussi posé des questions sur le programme de communication et a signalé l'importance pour les membres du Conseil d'avoir des messages à faire passer auprès de la communauté. Sébastien a demandé la tenue d'une réunion d'information du Conseil sur ce sujet.

    Le PDG a confirmé qu'une réunion informative pourrait couvrir les trois sujets, à savoir : La refonte du site Web, les communications du Conseil sur les nouveaux gTLD et le Plan de communications en général.

  5. Questions diverses

    Le Président a demandé aux membres du Conseil s'il y avait d'autres points à traiter sous la rubrique « divers ».

    Sébastien Bachollet a souhaité connaître l'état d'avancement du travail sur la recommandation 5 de l'ATRT concernant la rémunération des membres du Conseil d'administration.

    Bertrand de la Chapelle a demandé des informations sur la délégation qui assistera au FGI à Nairobi.

    Le Président a confirmé que des messages seraient envoyés au Conseil pour répondre à tous ces points.

    Le président a ensuite levé l'assemblée.

minutes-28jul11-fr.pdf  [167 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."