Skip to main content
Resources

Procès-verbaux | 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-28aug12-en.htm

 

Une réunion extraordinaire par voie téléphonique du Conseil d'administration de l'IACNN s'est tenue le 28 août 2012 à 21 heures 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 : Akram Atallah (PDG intérim), Sébastien Bachollet, Cherine Chalaby, Bertrand de La Chapelle, Chris Disspain, Bill Graham, Erika Mann, Gonzalo Navarro, Ray Plzak, George Sadowsky, Mike Silber, Bruce Tonkin (Vice-président), Judith Vazquez, et Kuo-Wei Wu.

Les agents de liaison suivants du Conseil ont participé à toute ou à une partie de la réunion : Thomas Narten (Liaison IETF) ; Thomas Roessler (Liaison TLG) ; et Suzanne Woolf (Liaison RSSAC).

Heather Dryden (Liaison du GAC), Ram Mohan (Liaison du SSAC) et R. Ramaraj se sont excusés.

  1. Ordre du jour approuvé :
    1. Approbation des procès-verbaux du Conseil d'administration
    2. Confirmation du rapport des actions de consentement écrit
    3. Demande de délégation de مليسيا. (« Maleesya ») qui représente la Malaisie en arabe
      1. Fondements de la résolution 2012.08.28.03
    4. Redélégation de .rw
      1. Fondements de la résolution 2012.08.28.04
    5. Emplacement de la réunion 2013 en Afrique
      1. Fondements de la résolution 2012.08.28.05
  2. Ordre du jour principal :
    1. Recommandation du Comité de Gouvernance du Conseil concernant la demande de reconsidération 12-2
      1. Fondements des résolutions 2012.08.28.06 et 2012.08.28.07
  3. Session exécutive

 

  1. Ordre du jour approuvé :

    Le président a présenté l'ordre du jour approuvé. Le Conseil a ensuite pris les décisions suivantes :

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

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

    2. Confirmation du rapport des actions de consentement écrit

      Résolu (2012.08.28.02) le Conseil d'administration confirme le rapport des actions de consentement écrit d'août 2012.

    3. Demande de délégation de مليسيا. (« Maleesya ») qui représente la Malaisie en arabe.

      Considérant que, ‎مليسيا. (« Maleesya »), encodé sous « xn-mgbx4cd0ab » est une chaîne qui a été jugée pour représenter de manière appropriée la Malaisie lors de la progression du processus IDN accélérée.

      Considérant que l'ICANN a reçu une demande de délégation de ‎مليسيا. à MYNIC Berhad.

      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 ;

      Résolu (2012.08.28.03), la délégation proposée du domaine ‎مليسيا. à MYNIC Berhad est approuvée.

      Fondements de la résolution 2012.08.28.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.

      Quelle est la proposition à 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, l'implication du Conseil de l'ICANN dans la décision portant sur la prise en compte de telles demandes reste 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 soulevées par la communauté ?
      Les inquiétudes ou questions concernant cette demande sont évoquées dans le rapport public qui sera publié en accompagnement de cette décision. Ce rapport, qui sera publié au site Web de l'IANA http://www.iana.org/ est censé mener à bonne fin le traitement définitif de ces demandes de modifications de la zone racine, normalement 1 ou 2 mois après la décision du Conseil.

      Quels sont les documents importants examinés par le Conseil ?
      Le Conseil évalue les demandes sur la base d'un ensemble 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 collecte d'informations réalisé par le personnel, le candidat est prié de fournir un ensemble de documents à l'appui liés à 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.

      Y a-t-il un impact fiscal ou des répercussions à prévoir 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 dans un pays donné ; l'ICANN doit seulement s'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 gestion du domaine.

      Y a-t-il des implications sur la sécurité, la stabilité ou la résilience du DNS ?
      Pour les délégations de domaines de premier niveau de code de pays, l'ICANN cherche à approuver uniquement les demandes dont tout inconvénient raisonnable a été résolu de façon satisfaisante, et dont le nouvel administrateur proposé a fait preuve d'un niveau de compétences opérationnelles et techniques suffisant pour minimiser toute éventuelle difficulté.

    4. Redélégation de .rw

      Attendu que RW est le code de pays de deux lettres correspondant au Rwanda dans la liste ISO 3166-1.

      Considérant que l'ICANN a reçu une demande de redélégation de .RW en faveur de l'association des communications de l'information et la technologie du Rwanda ;

      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 ;

      Résolu (2012.08.28.04), la redélégation proposée du domaine .RW à l'association des communications de l'information et la technologie du Rwanda est approuvée.

      Fondements de la résolution 2012.08.28.04

      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.

      Quelle est la proposition à 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, l'implication du Conseil de l'ICANN dans la décision portant sur la prise en compte de telles demandes reste 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 soulevées par la communauté ?
      Les inquiétudes ou questions concernant cette demande sont évoquées dans le rapport public qui sera publié en accompagnement de cette décision. Ce rapport, qui sera publié au site Web de l'IANA http://www.iana.org/ est censé mener à bonne fin le traitement définitif de ces demandes de modifications de la zone racine, normalement 1 ou 2 mois après la décision du Conseil.

      Quels sont les documents importants examinés par le Conseil ?
      Le Conseil évalue les demandes sur la base d'un ensemble 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 collecte d'informations réalisé par le personnel, le candidat est prié de fournir un ensemble de documents à l'appui liés à 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.

      Y a-t-il un impact fiscal ou des répercussions à prévoir 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 dans un pays donné ; l'ICANN doit seulement s'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 gestion du domaine.

      Y a-t-il des implications sur la sécurité, la stabilité ou la résilience du DNS ?
      Pour les délégations de domaines de premier niveau de code de pays, l'ICANN cherche à approuver uniquement les demandes dont tout inconvénient raisonnable a été résolu de façon satisfaisante, et dont le nouvel administrateur proposé a fait preuve d'un niveau de compétences opérationnelles et techniques suffisant pour minimiser toute éventuelle difficulté.

    5. Emplacement de la réunion 2013 en Afrique

      Considérant que, l'ICANN a l'intention d'organiser sa deuxième réunion de 2013 dans la région Afrique conformément à sa politique.

      Attendu que l'autorité du nom de domaine .za s'est proposée pour accueillir la réunion de l'ICANN en Afrique planifiée pour 2013.

      Considérant que, le personnel a effectué une révision approfondie de la proposition faite par l'Autorité du nom de domaine .za et l'a estimée acceptable.

      Attendu que le Comité des finances du Conseil a approuvé le budget pour la Réunion de l'ICANN 2013 en Afrique, comme proposé.

      Attendu que le comité de participation publique du Conseil d'administration s'occupe de la coordination de la révision de la proposition du personnel et soutient la proposition de l'emplacement de la réunion 2013 de l'ICANN en Afrique.

      Résolu (2012.08.28.05), le Conseil accepte la proposition de l'autorité du nom de domaine .za et approuve que la réunion 2013 de l'ICANN en Afrique ait lieu à Durban, Afrique du sud, du 14 au 19 juillet 2013, avec un budget ne dépassant pas 2 472 000 USD.

      Fondements de la résolution 2012.08.28.05

      Dans le cadre du calendrier de réunions publiques de l'ICANN, l'ICANN organise trois fois par an une réunion dans une région géographique différente (tel que défini dans les statuts de l'ICANN). Exceptionnellement, la troisième réunion de l'exercice fiscal 2013 sera cette fois-ci organisée pendant l'exercice fiscal 2014. La 47ème réunion, prévue du 14 au19 juillet 2013, doit avoir lieu dans la région géographique de l'Afrique. Un appel à recommandations pour établir le lieu de la réunion en Afrique a été publié le 25 avril 2011. De nombreuses propositions ont été reçues.

      Le personnel a soigneusement examiné toutes les propositions et a préparé un document identifiant celles satisfaisant aux critères de sélection du lieu de réunion. Sur la base des propositions et des analyses, le personnel a recommandé que la 47ème réunion de l'ICANN soit tenue à Durban, Afrique du sud.

      Le Conseil a examiné la recommandation du personnel d'organiser la réunion à Durban, Afrique du sud, et a été déterminé que la proposition satisfait aux principales conditions établies dans les critères de sélection du lieu de réunion utilisés pour guider le travail de sélection du site. Outre l'appel aux recommandations, le processus de sélection de sites ne fait pas l'objet d'une consultation publique, étant donné que l'évaluation par le personnel de la faisabilité d'une réunion dans un site donné constitue la principale considération.

      L'organisation de la réunion ainsi que les aides aux frais de déplacement qui pourront s'avérer nécessaires auront un impact financier sur l'ICANN, ainsi que sur la communauté, car cela implique des frais de voyage pour certains participants à la réunion. Cet impact est à prévoir indépendamment du lieu de tenue de la réunion. La tenue de la réunion n'aura aucun impact sur la sécurité ou la stabilité du DNS.

    Les résolutions 2012.08.28.01, 2012.08.28.02, 2012.08.28.03, 2012.08.28.04, et 2012.08.28.05 ont été approuvées à l'unanimité. Treize administrateurs ont voté en faveur des résolutions. Erika Mann, R. Ramaraj et Bruce Tonkin n'étaient pas disponibles pour voter ces résolutions. Les résolutions ont été adoptées.

  2. Ordre du jour principal :

    1. Recommandation du Comité de Gouvernance du Conseil concernant la demande de reconsidération 12-2

      Bruce Tonkin n'a pas participé de la délibération de ce point en raison d'un conflit d'intérêts déclaré.

      Le président a reçu la confirmation que ce point n'était pas inclus dans l'ordre du jour approuvé en raison du conflit d'intérêts déclaré par Bruce Tonkin.

      Bill Graham a présenté l'historique de la demande de reconsidération soumise par le regroupement de la propriété intellectuelle (IPC), et a remarqué qu'après examen du comité de gouvernance du Conseil, il apparaissait qu'une des clauses de « considérant » dans la résolution n'était pas aussi claire qu'elle aurait du l'être. Le comité de gouvernance du Conseil a recommandé une révision pour clarifier la nature de désengagement de l'amendement.

      George Sadowsky a demandé à connaître la nature du conflit avec les lois applicables que .CAT déclarait dans le cadre de sa demande d'amendement.

      Bill Graham a confirmé que l'ICANN comprenait que les conditions ne contreviennent pas la législation nationale, mais que l'amendement reflétait une production Whois, considérée comme étant préférable.

      Bertrand de La Chapelle a émis un commentaire sur demande implicite de l'IPC pour que l'ICANN sollicite activement des commentaires qui soient plus proactifs que la simple organisation d'une consultation publique. Bertrand a demandé que ceci soit gardé à l'esprit dans le cadre de futurs processus de reconsidération et lors du débat du comité de participation publique (PPC) sur l'évolution des commentaires publics.

      Le président a noté que Bertrand soulevait une question pouvant être appropriée pour un examen plus approfondi ; néanmoins cela ne devrait pas constituer la base d'une modification pour un processus existant à ce jour.

      Chris Disspain a demandé une confirmation de ce que la modification de la clause de « considérant » avait corrigé les questions considérées imprécises. Le Conseiller juridique et secrétaire ont confirmé que cela était le cas.

      Ray Plzak a présenté et Erika Mann a soutenu la résolution suivante :

      Attendu que, le Comité de Gouvernance du Conseil a examiné la demande de reconsidération 12-2 soumise par le regroupement de la propriété intellectuelle concernant la décision du Conseil du 6 mai 2012 portant sur la demande du processus d'évaluation des services d'enregistrement de Fundacio Puntcat pour la publication des données Whois de certains enregistrements au sein du Registre .CAT (http://www.icann.org/fr/groups/board/documents/resolutions-06may12-fr.htm#1.2).

      Attendu que le BCG recommande que la demande de reconsidération 12-2 doit être refusée.

      Attendu que la demande de reconsidération 12-2 et la recommandation du comité de gouvernance du Conseil ont été publiés sur le site de l'ICANN à l'adresse http://www.icann.org/en/groups/board/governance/reconsideration.

      Résolu (2012.08.28.06), le Conseil adopte la recommandation du BGC pour que la demande de reconsidération 12-2 soit refusée car la demande n'a pas identifié l'information matérielle dont le Conseil n'aurait pas tenu compte pour prendre la décision du 6 mai 2012.

      Résolu (2012.08.28.07), le Conseil donne des instructions au secrétaire d'amender la clause Attendu que antérieure à la résolution 2012.05.06.02 pour supprimer la suggestion d'une interdiction globale de la publication des données Whois pour les registrants individuels, et pour refléter plus précisément la portée de l'amendement à l'accord du registre .CAT ayant été demandé et approuvé.

      Quatorze administrateurs ont voté en faveur des résolutions 2012.08.28.06 et 2012.08.28.07. Bruce Tonkin s'est abstenu de voter sur les résolutions. Ramaraj n'était pas en mesure de voter pour les résolutions. Les résolutions ont été adoptées.

      Fondements des résolutions 2012.08.28.06 et 2012.08.28.07

      En vertu des statuts de l'ICANN, le Comité de gouvernance du Conseil doit évaluer les demandes de reconsidération et faire des recommandations au Conseil d'administration. Voir article IV, section 3 des statuts. Le Conseil a révisé et analysé en profondeur la recommandation du BGC concernant la demande de reconsidération 12-2 et considère que l'analyse est adéquate.

      Le Conseil croit aussi que, pour la responsabilité et la transparence de l'ICANN, il est essentiel d'assurer que la rédaction des résolutions reflète exactement la portée des décisions prises par le Conseil d'administration. Ici, une clause « attendu que » de la résolution 2012.05.06.02 a été identifiée comme excédant les limites de l'amendement demandé et approuvé par le Conseil. En conséquence, une modification à la clause « attendu que » conformément à l'engagement de l'ICANN vis-à-vis de la responsabilité reflète mieux la portée de l'amendement demandé et obtenu. La modification à la clause « attendu que » n'a aucun impact sur la portée actuelle de la décision du Conseil du 6 mai 2012.

      Le fait d'avoir un processus de reconsidération à travers lequel le BGC effectue une révision et recommande l'approbation du Conseil affecte positivement la transparence et la responsabilité de l'ICANN. Cette approche permet à la communauté de s'assurer que le personnel et le Conseil agissent dans le respect des politiques, des règlementations et des statuts constitutifs de l'ICANN. L'adoption de la recommandation du BGC n'a aucun impact financier sur l'ICANN et n'aura pas d'impact négatif sur la sécurité systémique, la stabilité et la résilience du système de noms de domaine.

  3. Session exécutive

    Le Conseil est entré en session exécutive, en toute confiance. Le Conseiller juridique et secrétaire était présent, et tout le reste du personnel s'est excusé.

    Le Conseil a conduit une partie confidentielle de la réunion pendant laquelle d'autres résolutions ont été votées (2012.08.28.C1 et 2012.08.28.C2). Ces résolutions resteront confidentielles comme une « action concernant la problématique du personnel ou de l'emploi », conformément l'article III, section 5.2 des statuts de l'ICANN.

minutes-28aug12-fr.pdf  [703 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."