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-28feb13-en.htm

 

Une réunion extraordinaire par voie téléphonique du Conseil d'administration de l'Icann s'est tenue le 28 février 2013 à 21 heures UTC.

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

Outre le vice-président, les administrateurs suivants ont participé à toute ou à une partie de la réunion: Sébastien Bachollet, Fadi Chehadé (président et PDG), Bertrand de la Chapelle, Chris Disspain, Bill Graham, Olga Madruga-Forti, Erika Mann, Gonzalo Navarro, Ray Plzak, George Sadowsky, Mike Silber, Bruce Tonkin (vice-président), et Kuo-Wei Wu. Judith Vazquez a fait parvenir ses excuses.

Les agents de liaison suivants du Conseil ont participé à toute ou à une partie de la réunion: Heather Dryden, agent de liaison du GAC; Ram Mohan, agent de liaison du SSAC; et Suzanne Woolf, agent de liaison du RSSAC. Francisco da Silva (agent de liaison TLG), et Thomas Narten (agent de liaison d'IETF) se sont excusés.

Les membres suivants du personnel de l'ICANN ont participé à toute ou à une partie de la réunion: Akram Atallah, directeur des opérations; John Jeffrey, conseiller juridique et secrétaire; David Olive, vice-président, soutien au développement stratégique; Geoff Bickers, Megan Bishop, Michelle Bright, Samantha Eisner, Kim Davies, Elise Gerich, Dan Halloran, Jamie Hedlund, Jeff Moss, et Diane Schroeder.

  1. Ordre du jour approuvé
    1. Approbation des procès-verbaux du Conseil d'administration
    2. Action du comité des rémunérations du Conseil d'administration
  2. Ordre du jour principal
    1. Proposition de l'Institut arabe de résolution des litiges pour collaborer en tant que fournisseur UDRP
    2. Redélégation du domaine .ML qui représente le Mali
      1. Fondements de la résolution 2013.02.28.03
    3. Délégation du domaine .укр qui représente l'Ukraine
      1. Fondements de la résolution 2013.02.28.04
    4. Nouvelle approche pour le processus des délégations et redélégations des ccTLD
    5. Mise à jour des informations de la réunion de Beijing
    6. Questions diverses

 

  1. Ordre du jour approuvé

    Le Président a présenté au Conseil un bref aperçu de l'ordre du jour. Le président a ajouté des questions à traiter dans l'ordre du jour et a demandé de voter. Le Conseil a ensuite pris les décisions suivantes:

    Résolu, les résolutions ci-dessous correspondant au présent ordre du jour sont approuvées:

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

      Résolu (2013.02.02.01), le Conseil d'administration approuve le compte-rendu de la réunion extraordinaire du Conseil d'Administration de l'ICANN du 2 février 2013.

    2. Action du comité des rémunérations du Conseil d'administration

      Attendu que, pour les opérations de l'ICANN il est essentiel de retenir le personnel de haut niveau et que l'ICANN souhaite garantir à son personnel des salaires compétitifs.

      Attendu que le Conseil a récemment nommé David Olive comme directeur de l'ICANN (voir http://www.icann.org/fr/groups/board/documents/resolutions-02feb13-fr.htm#1.e).

      Attendu que les données indépendantes du marché fournies par des consultants externes indiquent que la rémunération actuelle de David Olive, vice-président de l'ICANN, soutien du développement stratégique, est en dessous de la cible établie par l'ICANN, comprise entre le 50e et le 75e centile, conformément aux données du marché fournies par les consultants spécialisées en rémunérations de l'ICANN.

      Attendu que le comité de rémunération et le Conseil d'administration dans son intégralité ont confirmé ne pas avoir de conflit vis-à-vis du programme de rémunération du vice-président comme soutien du développement stratégique.

      Résolu (2013.02.28.02), que le Conseil adopte la rémunération actuelle du représentant David Olive, vice-président du développement stratégique, qui se base raisonnablement sur les données et recommandations du marché selon des experts indépendants en matière de rémunérations.

      Fondements de la résolution 2013.02.28.02

      Attirer et conserver le personnel de haut niveau en fournissant une rémunération globale concurrentielle est un aspect crucial pour l'organisation. En adoptant la rémunération du directeur de l'ICANN, David Olive comme étant raisonnable, le Comité des rémunérations et le Conseil ont examiné et accepté l'analyse de marché et les recommandations des experts indépendants en matière de rémunérations, et en prenant cette mesure, ils ont confirmé l'absence de conflit concernant la rémunération globale de David Olive.

      Cette décision n'aura d'impact fiscal ni sur l'organisation ou la communauté, ni sur la sécurité, la stabilité et la résilience du système de noms de domaine. Il s'agit d'une fonction administrative et organisationnelle qui n'exige pas de commentaires publics.

    Quatorze membres du Conseil d'administration ont voté en faveur des résolutions 2013.02.28.01 et 2013.02.28.02. Erika Mann et Judith Vazquez n'étaient pas disponibles pour voter ces résolutions. Les résolutions ont été adoptées.

    Une fois le vote sur l'ordre du jour convenu terminé, Bertrand de La Chapelle a fait une enquête concernant l'état d'un point que l'on avait proposé d'inclure préalablement à l'ordre du jour du Conseil. Le point concernait la demande de création d'un regroupement de Cyber café dans l'établissement des parties non-contractées de la GNSO.

    Ray Plzak a fourni une brève mise à jour sur cette question et a informé le Conseil que la question était en train d'être revue par le Comité des améliorations structurelles. Des informations mises à jour seront soumises à l'étude du Conseil lors de sa prochaine réunion ordinaire programmée.

  2. Ordre du jour principal:

    1. Proposition de l'Institut arabe de résolution des litiges pour collaborer en tant que fournisseur UDRP

      Le président a passé ce point 2.a. de l'ordre du jour convenu à l'ordre du jour principal. Le président a présenté le sujet et commencé la discussion en se centrant sur une méthode permettant d'atteindre une résolution finale sur cette question.

      Samantha Eisner a constaté que puisque les modifications apportées dans la demande de l'ACDR n'étaient pas de nature suffisamment substantielle pour amener à une recommandation qu'un autre commentaire public avait exigée avant d'être étudiée par le Conseil, si le Conseil est d'avis que cet autre commentaire public est recommandé, il n'y a donc aucune objection à l'élimination de ce point pour des commentaires ultérieurs. Le personnel rapporterait ensuite un récapitulatif de ces commentaires au Conseil.

      Le président a souligné certaines inquiétudes ayant attiré son attention et liées à la question de savoir comment l'ICANN allait garantir l'uniformité parmi les fournisseurs. Le président aimerait clôturer cette question.

      Samantha a confirmé que la clôture de la question de l'uniformité des fournisseurs pouvait se faire séparément de la demande spécifique à partir de la demande de l'ACDR, et que l'ICANN pouvait élaborer un avant-projet de déclaration séparée ou un document public portant sur l'uniformité.  Cela permettrait de clôturer les travaux sur les questions communautaires concernant l'uniformité des fournisseurs, tout en procédant à l'étude de la candidature de l'ACDR.

      Bruce Tonkin a demandé une explication du cadre actuel pour répondre à des situations où un fournisseur UDRP ne remplirait pas ses obligations ou lorsqu'il y aurait des problèmes de contrôle qualité. Bruce a également demandé des informations sur le pire des scénarios possibles ou sur les problèmes de gestion liée au risque dans ces situations.

      Samantha a signalé qu'il y avait eu très peu d'allégations réelles concernant le mauvais comportement du fournisseur UDRP ayant été portées à l'attention de l'ICANN, et il a été déterminé que celles qui avaient été présentées, étaient plutôt une réclamation du plaignant n'étant pas satisfait de la décision prise. Mais lorsque des réclamations ou des fautes ont lieu, l'ICANN les examine et mène une enquête si besoin est. Dans le pire des scénarios de fautes commises par le fournisseur, l'ICANN a la possibilité de révoquer l'approbation du fournisseur UDRP. En raison de l'absence de plaintes au fil des ans, l'ICANN n'a pas de procédure solide pour ce type d'examen et de révocation de plainte, mais on pourrait en élaborer une. Il est également important de remarquer que la procédure d'approbation du fournisseur UDRP a été partiellement identifiée comme appartenant au cadre du processus de développement de politiques de la GNSO. Il y a quelques années, la GNSO a eu l'opportunité de prendre en charge un problème particulier traitant avec les fournisseurs UDRP mais la GNSO n'a pas donné suite à la question. Récemment, dans le PDP potentiel de l'UDRP, voici l'un des points qui pourrait être inclus ici. Ce PDP est a été remis à plus tard, après l'entrée des nouveaux gTLD dans la racine. Il se peut que certains de ces travaux soient abordés à travers ce processus politique.

      Bruce est d'accord sur l'utilité d'avoir une certaine forme de contrat ou de processus publiquement disponible pour la révision ou la révocation ou les fournisseurs.

      Le conseiller juridique et secrétaire a constaté que le marché concurrentiel des facteurs des services de résolution des litiges des fournisseurs UDRP fonctionnait tel que prévu. La proposition de formaliser un processus de traitement des plaintes contre les fournisseurs de l'UDRP serait un net progès important.

      Bertrand de La Chapelle a approuvé la proposition visant à mieux documenter le processus de remise des fournisseurs UDRP non performants mais il croit qu'il n'est pas nécessaire de convoquer à une autre série de commentaires publics sur la candidature de l'ACDR étant donné que les commentaires reçus seraient probablament similaires à ceux déjà collectés.

      Le président a signalé que, bien qu'il soit d'accord avec Bertrand sur le résultat probable d'autres commentaires concernant la candidature de l'ACDR, la réponse à la demande de commentaires sur la nouvelle version a été significative. Les commentaires publics soient-ils reçus ou pas, le Conseil estime qu'il est correct de remettre à plus tard, au moins une réunion, la décision sur la demande de l'ACDR, lorsque les travaux pour clôturer la question de l'uniformité des fournisseurs seront terminés.

      Bruce a confirmé cela car le public n'avait pas vu les nouveaux documents. Dans l'avenir, le besoin de commentaires supplémentaires pourrait s'atténuer s'il y avait au moins la possibilité de publier ce type de document avant que des mesures ne soient prises par le Conseil.

      Bertrand a donné son soutien au début d'une période de commentaires concernant la demande de l'ACDR en ce moment.

      Après avoir tenu compte de l'avis du Conseil, le président a ordonné au personnel d'ouvrir une période supplémentaire de commentaires sur la candidature de l'ACDR et a également demandé au bureau du conseiller juridique de fournir des informations à la communauté sur le cadre utilisé pour répondre aux fournisseurs UDRP non performants ou contre-performants. Aucune résolution n'a été adoptée.

    2. Redélégation du domaine .ML qui représente le Mali

      Une fois que le président a soumis la résolution à l'étude, Elise Gerich a fourni un bref historique de la demande de redélégation des ccTLD représentant le Mali et de la procédure suivie par le département Fonction de l'IANA dans le traitement de la demande de redélégation en cours.

      Kuo-Wei Wu a par la suite présenté et Bill Graham a soutenu la résolution suivante:

      Le conseiller juridique et secrétaire a effectué un petit peaufinage à la résolution proposée pour améliorer la rédaction.

      Bertrand de La Chapelle a réitéré une demande qu'il avait faite auparavant pour que l'ICANN revisite le vocabulaire utilisé dans les résolutions concernant la délégation et la redélégation car l'étude réalisée par l'ICANN ne peut pas toujours lui permettre d'émettre un jugement sur le fond comme quoi la demande est dans l'intérêt de la communauté Internet. Au lieu de cela, la démonstration que cette procédure a été suivie fait partie de l'évaluation des critères soutenant un jugement. Cette discussion peut avoir lieu plus tard.

      Ray Plzak a appuyé l'opinion de Bertrand.

      Le président a demandé de reprendre ce point dans une discussion ultérieure avec le personnel.

      Le Conseil a ensuite pris les décisions suivantes:

      Résolu (2013.02.28.03), l'ICANN a examiné et a évalué la demande et la documentation montre que le processus de redélégation a été suivi et qu'il répond aux intérêts des communautés Internet locales et mondiales.

      Quatorze membres du Conseil ont voté en faveur de la résolution 2013.02.28.03. Erika Mann et Judith Vazquez n'étaient pas disponibles pour voter cette résolution. La résolution a été adoptée.

      Fondements de la résolution 2013.02.28.03

      Dans le cadre des fonctions de l'IANA, l'ICANN reçoit des demandes pour déléguer et redéléguer des domaines de premier niveau géographique. Le personnel de l'ICANN a examiné et évalué une demande de redélégation pour ce domaine et a fourni un rapport au Conseil de l'ICANN indiquant que les procédures correctes ont été suivies pour cette évaluation. La supervision du processus par le Conseil permet de s'assurer que l'ICANN exerce correctement ses responsabilités quant au fonctionnement stable et sécurisé des systèmes d'identifiant unique d'Internet et conformément au Contrat définissant les fonctions de l'IANA. L'assurance que le processus est bien suivi contribue à la responsabilité de l'ICANN. Cette action n'aura pas d'impact fiscal sur l'ICANN ou la communauté, et aura un impact positif sur la sécurité, la stabilité et la résilience du système de noms de domaine.

      Il s'agit d'une fonction administrative et organisationnelle qui n'exige pas de commentaires publics.

    3. Délégation du domaine .укр qui représente l'Ukraine

      Une fois que le président a présenté la résolution pour sa considération, Elise Gerich a fait une brève présentation de la délégation du ccTLD proposée à l'Ukraine. Elise a confirmé que la demande répondait aux exigences de la procédure accélérée et la procédure a été suivie.

      Kuo-Wei Wu a par la suite présenté et Bill Graham a soutenu la résolution suivante:

      Le Conseil a ensuite pris les décisions suivantes:

      Résolu (2013.02.28.04), l'ICANN a examiné et a évalué la demande et la documentation montre que le processus de délégation a été suivi et qu'il répond aux intérêts des communautés Internet locales et mondiales.

      Quatorze membres du Conseil ont voté en faveur de la résolution 2013.02.28.04. Erika Mann et Judith Vazquez n'étaient pas disponibles pour voter cette résolution. La résolution a été adoptée.

      Fondements de la résolution 2013.02.28.04

      Dans le cadre des fonctions de l'IANA, l'ICANN reçoit des demandes pour déléguer et redéléguer des domaines de premier niveau géographique. Le personnel de l'ICANN a examiné et évalué une demande de délégation pour ce domaine et a présenté un rapport au Conseil de l'ICANN indiquant que les procédures correctes ont été suivies pour cette évaluation. La supervision du processus par le Conseil permet de s'assurer que l'ICANN exerce correctement ses responsabilités quant au fonctionnement stable et sécurisé des systèmes d'identifiant unique d'Internet et conformément au Contrat définissant les fonctions de l'IANA. L'assurance que le processus est bien suivi contribue à la responsabilité de l'ICANN. Cette action n'aura pas d'impact fiscal sur l'ICANN ou la communauté, et aura un impact positif sur la sécurité, la stabilité et la résilience du système de noms de domaine.

      Il s'agit d'une fonction administrative et organisationnelle qui n'exige pas de commentaires publics.

    4. Nouvelle approche pour le processus des délégations et redélégations des ccTLD

      Le Conseil et le personnel se sont engagés dans une discussion à propos de la nouvelle approche du processus d'examen du Conseil pour les demandes de délégation et redélégation des ccTLD en vertu du nouveau contrat des fonctions IANA.

      Bertrand de La Chapelle a réitéré sa demande de modifier la rédaction lorsque le Conseil approuvera une délégation ou redélégation de ccTLD et de préciser que le Conseil joue un rôle de surveillance en vertu du contrat des fonctions IANA, plutôt que celui d'émettre des jugements de fond sur ces questions.

      Chris Disspain a constaté que les travaux de la ccNSO sur le cadre d'interprétation tiendront compte des modifications conformément au contrat des fonctions IANA. Les travaux du cadre d'interprétation (Framework of interpretation – FoI) pourraient finalement avoir un effet sur la façon dont l'ICANN tient compte des critères concernant les délégations et redélégations des ccTLD, mais aucune modification dans la formulation n'est actuellement exigée selon les travaux du FoI.

      Ray Plzak a signalé que les modifications proposées dans la formulation de futures résolutions représentent une démarche importante du Conseil vers un rôle de surveillance. Ceci met le Conseil en dehors de sa position d'émetteur de jugements qualitatifs sur certaines questions et diminue l'importance qu'il avait acquise dans l'organe législatif. Il ne s'agit pas de se dégager de la responsabilité pour s'assurer que tout est bien fait mais plutôt de renforcer la position du Conseil en assurant que les procédures soient respectées.

      Chris est d'accord avec Ray tout en remarquant le fait que si le Conseil ne mène pas des discussions liées aux politiques, cela ne veut absolument pas dire que sa responsabilité soit diminuée. Le Conseil peut se centrer sur la gouvernance.

      Le président a constaté que des discussions ultérieures pouvaient avoir lieu sur cette question, le cas échéant.

    5. Mise à jour des informations de la réunion de Beijing

      Geoff Bickers and Jeff Moss ont fait une brève présentation au Conseil des préparations logistiques en matière de sécurité du personnel et du Conseil pour la réunion de Beijing.

      Le président a ordonné au personnel de programmer un appel informatif complet sur les questions portant sur la sécurité avant la réunion de Beijing.

    6. Questions diverses

      Bertrand de la Chapelle a donné un bref aperçu de la récente réunion du Sommet mondial sur la société de l'information (World Summit on the Information Society – WSIS) à l'UNESCO à Paris.

      Le Président-directeur général a fourni une brève mise à jour de ses réunions et de ses voyages au cours des dernières semaines et a remercié les membres du Conseil de l'aide fournie pour organiser les réunions clés dans leurs juridictions locales.

minutes-28feb13-fr.pdf  [258 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."