Skip to main content
Resources

Procès-verbal | Réunion Extraordinaire 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/minutes-07feb12-en.htm

Une réunion extraordinaire du Conseil d'administration de l'ICANN a eu lieu le 7 février 2012 à 4h30, heure locale à Los Angeles, Californie.

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, Ray Plzak, R. Ramaraj, George Sadowsky, Mike Silber, Bruce Tonkin (Vice président), Kuo-Wei Wu et Judith Vazquez.

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 ; Thomas Roessler, liaison de TLG et Suzanne Woolf, liaison du RSSAC.

Gonzalo Navarro et Erika Mann ont envoyé des excuses.

  1. Ordre du jour approuvé
  2. Délégation du domaine .қаз (“kaz”) représentant le Kazakhstan en cyrillique
  3. Postage de la consultation publique : Modification des statuts pour le PDP révisé
  4. Réaffirmation de la deuxième étape des candidatures du programme des nouveaux gTLD

  1. Ordre du jour approuvé

    Le président a présenté l’ordre du jour approuvé.   Ray Plzak a demandé l’élimination du point concernant le PDP de la GNSO pour résoudre un problème de formulation.  Sébastien Bachollet a demandé l’élimination du point concernant la délégation des IDN ccTLD pour résoudre un problème de formulation.

    Par la suite, le Président a demandé de passer au vote et le Conseil d’administration a pris la décision suivante :

    Il est résolu que les résolutions suivantes de cet ordre du jour sont approuvées :

    1.1. Approbation du compte-rendu de la réunion extraordinaire du Conseil d’administration de l'ICANN du 8 décembre 2011

    Il est résolu (2011.02.07.01), que le Conseil approuve les procès-verbaux de la réunion ordinaire du Conseil de l’ICANN du 8 décembre.

    1.2. Redélégation du domaine .BY correspondant à la Biélorussie en faveur de Reliable Software Inc.

    Attendu que BY est le code de pays de deux lettres correspondant à Biélorussie dans la liste ISO 3166-1.

    Considérant que l'ICANN a reçu une demande de redélégation de .BY en faveur de Reliable Software Inc. ;

    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.02.07.02), que la redélégation proposée du domaine .BY en faveur de Reliable Software Inc. est approuvée.

    Fondements de la résolution 2011.02.07.02

    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 ayant é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 ayant é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’admissibilité des codes de pays (p. ex. é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 les rè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.

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

    Les résolutions 2012.02.07.01 et 2012.02.07.02 ont été votées à l’unanimité.  Quatorze membres du Conseil d’administration ont voté en faveur des résolutions.  Erika Mann et Gonzalo Navarro n’étaient pas disponibles pour voter ces résolutions.   La résolution a été adoptée.

  2. Délégation du domaine .қаз (“kaz”) représentant le Kazakhstan en cyrillique

    Sébastien Bachollet a demandé des précisions par rapport à la formulation utilisée dans la résolution concernant les intérêts de la communauté Internet locale et globale et a demandé si l’ICANN tenait à mettre en place ladite évaluation et à utiliser cette formulation.

    Elise Gerich, VP du Département IANA, a signalé que le libellé de la résolution coïncide avec les libellés utilisés pour d'autres questions relatives à la délégation.

    Le Président a confirmé qu'en vertu de la RFC 1591, l’ICANN est tenu de considérer le soutien de la communauté locale dans l'évaluation des demandes de délégation, si bien que même si le libellé changeait, l'exigence par rapport à l'évaluation ne serait pas modifiée.

    Kuo-Wei Wu a signalé qu’il faut être extrêmement prudent lorsqu'on change le libellé utilisé dans les résolutions de délégation et être prêt à expliquer tout changement, d'autant plus que l'on suit la RFC 1591.

    Le Président a indiqué que le Conseil d'administration pourrait considérer qu’une discussion plus poussée est encore nécessaire sur ce point.  Vu les conséquences inattendues pouvant découler d'un changement introduit à ce stade du débat, le Président a recommandé que le libellé reste inchangé et que les discussions se poursuivent dans l'avenir.  Le Président a demandé d’inclure cette question dans la procédure de suivi du Conseil d’administration.

    Par la suite, le Président a demandé de passer au vote et le Conseil d’administration a pris la décision suivante :

    Considérant que, .қаз (“kaz”), codé comme « xn--80ao21a » est une chaîne qui a été jugée à juste titre représentant le Kazakhstan lors de la progression de la procédure IDN accélérée ;

    Attendu que l'ICANN a reçu une demande de délégation du .қаз à l'association des sociétés IT du Kazakhstan.

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

    Il est résolu (2012.02.07.03), que la délégation proposée du nom de domaine .қаз de l'association des sociétés IT du Kazakhstan soit approuvée.

    Quatorze membres du Conseil d’administration ont voté en faveur de la résolution 2012.02.17.03.  Erika Mann et Gonzalo Navarro n’étaient pas disponibles pour voter cette résolution.   La résolution a été adoptée.

    Fondements de la résolution 2012.02.07.03

    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 ayant é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 ayant é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’admissibilité des codes de pays (p. ex. é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 les rè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.

    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 domaines 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.
  3. Postage de la consultation publique : Modification des statuts pour le PDP révisé

    Ray Plzak a demandé de modifier la résolution afin d'assurer que les besoins de la GNSO y soient pris en compte.

    Sans discussions ultérieures, le Président a demandé de passer au vote et le Conseil d’administration a pris la décision suivante :

    Attendu que, le 27 septembre 2011, le Conseil de la GNSO a adopté le rapport final mis à jour (http://gnso.icann.org/improvements/updated-final-report-pdpwt-28sep11.pdf [PDF, 1.51 MB]) du groupe de travail pour le processus d’élaboration des politiques (Policy Development Process Working Team - PDP-WT), établissant la nouvelle Annexe A proposée pour les statuts de l’ICANN et un processus manuel d’élaboration des politiques (PDP), conformément une directive pour développer un PDP plus efficace et plus réactif aux besoins de la GNSO.

    Considérant que le Conseil d’administration a adopté la nouvelle Annexe le 8 décembre 2011 et a donné des instructions pour la transition vers le nouveau PDP.

    Attendu que, des révisions supplémentaires aux statuts sont nécessaires pour mettre en place le nouveau PDP, y compris la définition des nouveaux seuils de vote établis dans le rapport final du PDP-WT mis à jour.

    Il a été résolu (2012.02.07.04) que le Conseil d'administration de l’ICANN approuve la publication pour commentaires publics des futures révisions des statuts de l’ICANN nécessaires pour la mise en place du nouveau PDP. 

    Quatorze membres du Conseil d’administration ont voté en faveur de la résolution 2012.02.17.04.  Erika Mann et Gonzalo Navarro n’étaient pas disponibles pour voter cette résolution.   La résolution a été adoptée.

    Fondements de la résolution 2012.02.07.04

    La révision ultérieure des statuts de l’ICANN est nécessaire pour compléter la documentation de la transition vers le nouveau PDP tel qu’approuvé par le Conseil de la GNSO et le Conseil d’administration de l’ICANN.   Afin d’assurer la responsabilité à la communauté de l’ICANN, la publication pour commentaires publics des modifications proposées aux statuts permettra les commentaires de la communauté et la transparence des étapes de mise en place.   Cette action n’aura d’impact ni sur les ressources de l’ICANN ni sur la sécurité et la stabilité du DNS.

  4. Réaffirmation de la deuxième étape des candidatures du programme des nouveaux gTLD

    Avant de traiter cette question, les membres du Conseil suivants et les liaisons ayant des conflits d’intérêts potentiels par rapport au programme des nouveaux gTLD ont été dispensés d’assister à la réunion : Sébastien Bachollet, Bertrand de La Chapelle, Steve Crocker, Ram Mohan, Thomas Narten, Bruce Tonkin et Suzanne Woolf.

    Le Conseil d’administration a confirmé la présence des Directeurs et des Agents de liaison ci-dessous par appel des présences : Rod Beckstrom, Cherine Chalaby, Chris Disspain, Heather Dryden, Bill Graham, Ray Plzak, R. Ramaraj, Thomas Roessler, George Sadowsky, Mike Silber, Judith Vasquez et Kuo-Wei Wu.

    Cherine Chalaby a été nommé Président intérimaire et a rempli cette fonction pendant le reste de la réunion.

    Le Président intérimaire a examiné avec le Conseil d’administration la résolution proposée, indiquant que celle-ci faisait suite aux discussions entretenues entre les membres du Conseil identifiés comme n’ayant pas de conflit à l’égard du programme des nouveaux gTLD.  Les membres du Conseil d'administration ont eu l'occasion d'étudier et de commenter la résolution avant la réunion.  Le Président intérimaire a évoqué la possibilité de poursuivre les discussions, le cas échéant.

    Vu qu'une discussion plus approfondie ne s'avérait pas nécessaire, Ray Plzak a proposé la résolution suivante, soutenu par Kuo-Wei Wu :

    Attendu que, la période de présentation de candidatures au programme des nouveaux gTLD ouvrira le 12 janvier 2012 et que sa clôture est prévue pour le 12 avril 2012.

    Attendu que, les recommandations sur les politiques de la GNSO acceptées par le Conseil d’administration le 26 juin 2008 stipulaient que l’ICANN introduirait les nouveaux gTLD par séries.

    Attendu que, lors du processus de formation du programme des nouveaux gTLD, l’ICANN s’est engagée à entreprendre certains travaux avant le début de la deuxième série d’une période de candidatures pour le programme des nouveaux gTLD. 

    Il est résolu (2012.02.07.05), que l’ICANN s’engage à ouvrir une deuxième période de candidatures pour le programme des nouveaux gTLD aussi rapidement que possible.

    Il est résolu (20112.02.07.06), que le Conseil donne des instructions au PDG de publier un document décrivant le plan de travail requis avant le début de la deuxième période de candidatures pour le programme des nouveaux gTLD  ; plus spécifiquement aborder les exigences du GAC pour évaluer la protection des marques, l’opération de la zone racine et l’identification des autres conditions requises pour la prochaine série des nouveaux gTLD. 

    Il est résolu (2012.02.07.07) que le Conseil donne des instructions au PDG de continuer à travailler avec la communauté de l’ICANN afin de perfectionner le plan de travail et d’aborder les conditions requises pour ouvrir une deuxième série pour les nouveaux gTLD.

    Rod Beckstrom, Cherine Chalaby, Chris Disspain, Bill Graham, Ray Plzak, R. Ramaraj, George Sadowsky, Mike Silber, Judith Vasquez et Kuo-Wei Wu ont voté en faveur des résolutions 2012.02.07.05, 2012.02.07.06, et 2012.02.07.07. Sébastien Bachollet, Bertrand de La Chapelle, Steve Crocker, Gonzalo Navarro, Erika Mann et Bruce Tonkin n’étaient pas disponibles pour voter ces résolutions.  Les résolutions ont été adoptées.

    Fondements des résolutions 2012.02.07.05 – 2012.02.07.07

    En réponse aux appels continus de la communauté concernant la manière dont l’ICANN abordera les séries supplémentaires des candidatures aux nouveaux gTLD, le Conseil a décidé cette action pour réaffirmer l’engagement de l’ICANN vis-à-vis des recommandations de politiques de la GNSO sur l’introduction des nouveaux gTLD. Ces recommandations signalent que les nouveaux gTLD devraient être introduits en séries.  L’ICANN a accordé d’entreprendre des études et des travaux avant l’ouverture d’une autre période de candidatures ; l’ICANN travaille également pour se tenir responsable vis-à-vis des recommandations de politiques de la GNSO ainsi que des engagements pour les travaux et les études ultérieurs.  Ces pré-conditions incluent spécifiquement la défense des exigences du GAC visant à évaluer la protection des marques et l’opération de la zone racine.   Bien qu’il ne soit pas possible d’identifier une date précise pour l’ouverture de la deuxième série de candidatures au programme des nouveaux gTLD, il est important d'informer la communauté sur les travaux spécifiques requis.

    L’action décidée dans cette résolution n’aura pas d’impact sur les ressources de l’ICANN.  En outre, l’action décidée dans cette résolution n’aura pas d’impact sur la sécurité et la stabilité du DNS.  Bien entendu, une partie de l’engagement continu de l’ICANN concernant le monitorage de l’impact de l’introduction des nouveaux gTLD inclut l’impact sur la sécurité et la stabilité du DNS.

    Après le vote, le Conseil Général et le Secrétariat ont indiqué que les membres du Conseil d’administration et les Agents de liaison identifiés comme ayant des conflits d’intérêts potentiels recevraient le texte de la résolution en même temps que le public.

    Ray Plzak a demandé à ce qu'on confirme si la résolution ferait l'objet d'une annonce et d'un communiqué de presse concernant la décision du Conseil d'administration, et a sollicité des informations sur la stratégie de communication.

    Le Président et le PDG ont confirmé que l’équipe de communication était déjà en train de coordonner l'annonce qui serait diffusée en même temps que la résolution.

    La séance a par la suite été levée.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."