Skip to main content
Resources

Procès-verbaux | Réunion ordinaire du Conseil d'administration de l'ICANN | Costa Rica

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-16mar12-en.htm

 

Une réunion ordinaire du Conseil d'administration de l'ICANN a eu lieu le 16 mars 2012 à San Jose, Costa Rica, à 11h10 heure locale.

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, Erika Mann, Gonzalo Navarro, 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.

  1. Ordre du jour approuvé

 

  1. Ordre du jour approuvé

    Le Président a signalé qu'il y avait des changements par rapport à l'ordre du jour publié avant la réunion. Il a également expliqué que le Conseil avait œuvré pour faciliter le processus afin de s'assurer que tous les points soient dûment renseignés et documentés et que toutes les parties concernées aient pu exprimer leur avis. Suite aux discussions détaillées de la réunion du Conseil qui s'est tenue au cours de la semaine, le Conseil a supprimé certains points qui figuraient avant dans l'ordre du jour. Le Conseil a également décidé de reporter la votation sur le plan stratégique. Par conséquent, tous les points de l'ordre du jour font partie de l'ordre du jour approuvé par le Conseil. Le président a ensuite présenté les points de l'ordre du jour approuvé.

    Avant l'examen par le Conseil des points de l'ordre du jour approuvé, Cherine Chalaby a lu à haute voix une note de remerciement aux sponsors, figurant au point 1.11 de l'ordre du jour. Le président et PDG a lu à haute voix les remerciements aux scribes, aux interprètes, au personnel, aux équipes de travail des organisateurs et de l'hôtel, figurant au point 1.12.

    Gonzalo Navarro a déclaré qu'il est difficile de remercier tous ceux qui ont participé à cet extraordinaire événement. Il a signalé la chaleureuse hospitalité des costariciens et a remercié les organisateurs pour leur hospitalité et pour tout ce qu'ils avaient réussi à mettre à disposition de l'ICANN. Gonzalo a également exprimé sa reconnaissance à la présidente Chinchilla pour son discours d'ouverture de la réunion. Ensuite, Gonzalo a lu à haute voix des remerciements aux hôtes locaux, figurant au point 1.13 de l'ordre du jour.

    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.1. Approbation du procès-verbal de la réunion du Conseil de l'ICANN du 7 février 2012

    Résolu (2012.03.16.01), le Conseil approuve les procès-verbaux de la Réunion du Conseil de l'ICANN du 7 février 2012.

    1.2. Approbation de la Recommandation nº 9, partie B sur les IRTP, 2e partie

    Attendu que, le 24 juin 2009, le Conseil de la GNSO a lancé un processus d'élaboration de politiques (PDP) sur la procédure de transfert de noms de domaine entre bureaux d'enregistrement Partie B (IRTP Partie B) abordant cinq questions relatives à la charte. <https://community.icann.org/display/gnsoirtpb/3.+WG+Charter>

    Attendu que le PDP a suivi les étapes prévues pour les PDP dans les statuts, qui ont donné lieu au rapport final présenté le 30 mai 2011.

    Attendu que le groupe de travail sur l'IRTP Partie B (GT) a atteint un consensus total sur les recommandations concernant chacune des cinq questions énoncées dans la Charte.

    Attendu que, concernant la partie nº 2 de la Recommandation nº 9, le Conseil de la GNSO a décidé lors de sa réunion en date du 22 juin 2011 de demander au personnel de l'ICANN de proposer des nouvelles dispositions sur le verrouillage/déverrouillage de noms de domaine, compte tenu des délibérations du Groupe de travail sur l'IRTP, Partie B, sur cette question ( Voir Rapport final sur l'IRTP Partie B - (Recommandation nº 9, 2e partie), Après l'analyse de la proposition, le Conseil de la GNSO examinera la possibilité d'approuver la recommandation.

    Attendu que le personnel de l'ICANN a élaboré la proposition en consultation avec le groupe de travail sur l'IRTP Partie B et que celle-ci a fait l'objet d'une consultation publique (Voir http://www.icann.org/en/public-comment/irtp-b-staff-proposals-22nov11-en.htm).

    Attendu que des commentaires faits par le regroupement de la propriété Intellectuelle en dehors de la date limite fixée pour la réception de commentaires ont été toutefois pris en compte par le Conseil de la GNSO, et que la proposition a été soumise au Conseil de la GNSO.

    Attendu que le Conseil de la GNSO a examiné et discuté la proposition faite par le personnel de l'ICANN concernant la Partie B de la Recommandation nº 9 sur l'IRTP, 2e partie.

    Attendu que le Conseil de la GNSO a adopté par unanimité la recommandation ainsi que la proposition faite par le personnel de l'ICANN dans sa réunion du 19 janvier 2012 (Voir http://gnso.icann.org/resolutions/#201201).

    Attendu que le vote du conseil de la GNSO a atteint et dépassé le seuil de vote nécessaire pour imposer de nouvelles obligations aux parties contractantes de l'ICANN.

    Considérant qu'après le vote du Conseil de la GNSO, une période de commentaires publics de 21 jours portant sur les recommandations approuvées a été établie, et que les commentaires ont été résumés et examinés (http://www.icann.org/en/public-comment/irtp-b-rec9-part2-23jan12-en.htm).

    Résolu (2012.03.16.02), le Conseil d'administration adopte les recommandations du conseil de la GNSO visant à modifier la politique de transfert de noms de domaine entre bureaux d'enregistrement, présentées dans http://www.icann.org/fr/transfers/policy-fr.htm.

    Résolu (2012.03.16.03), le PDG élaborera et complètera un plan de mise en œuvre pour ces recommandations et poursuivra la communication avec la communauté concernant ces travaux.

    Fondements des résolutions 2012.03.16.02 – 2012.03.16.03

    Pourquoi cette question est-elle abordée maintenant ?
    La politique de transfert de noms de domaine entre bureaux d'enregistrement (IRTP) est une politique consensuelle adoptée en 2004 qui met à disposition des titulaires de noms de domaine un processus simple afin qu'ils puissent transférer les noms de domaine entre bureaux d'enregistrement. Le Conseil de la GNSO a établi une série de cinq groupes de travail (Parties A à E) pour examiner et considérer plusieurs révisions à cette politique.

    L'IRTP PDP Partie B est le deuxième d'une série de cinq PDP programmés, destinés à améliorer certains aspects de la politique existante. Le groupe de travail sur l'IRTP Partie B s'est focalisé sur cinq problématiques portant plus particulièrement sur le piratage de noms de domaine, l'annulation urgente d'un transfert non approprié et l'utilisation du statut de verrouillage. La plupart de ces recommandations ont été déjà adoptées par le Conseil de la GNSO et le Conseil d'administration de l'ICANN. En ce qui concerne la partie 2 de la Recommandation nº 9 , une proposition avait été demandée au personnel de l'ICANN. Suite à des consultations auprès du groupe de travail sur l'IRTP, Partie B et à un forum de consultation publique portant sur la proposition du personnel, le Conseil de la GNSO a approuvé par unanimité la Partie B de la Recommandation nº 9 , partie 2 , ainsi que la proposition du personnel lors de sa réunion du 19 janvier 2012 (Voir http://gnso.icann.org/resolutions/#201201). Le rapport final sur le PDP de l'IRTP Partie B a reçu le consensus unanime du groupe de travail sur l'IRTP Partie B ainsi que du Conseil de la GNSO.

    Pourquoi la proposition est-elle présentée à la considération du Conseil d'administration ?

    La recommandation nº 9 , partie 2 suggère que le motif de refus nº7 de l'IRTP devrait être remplacé par une nouvelle disposition, incorporée dans une section différente de l'IRTP, où soit indiqué quand et comment les domaines peuvent être verrouillés ou déverrouillés. La proposition du personnel de l'ICANN, tenant compte de la suppression du motif de refus nº 7 approuvée précédemment par le Conseil d'administration de l'ICANN, suggère d'élargir la section 5 existante (exigences d'enregistrement pour les opérateurs de registre fondées sur l'EPP) de l'IRTP afin d'y inclure le point « Statut verrouillé par le bureau d'enregistrement ». Dans la proposition du personnel de l'ICANN sur la recommandation nº 9 , partie B de l'IRTP, partie 2 [PDF, 490 KB] , qui figure dans l'annexe, les modifications proposées pour l'IRTP se trouvent soulignées en rouge. Les principales modifications proposées sont les suivants :

    Les bureaux d'enregistrement ne peuvent imposer un verrouillage interdisant le transfert d'un nom de domaine que si l'accord de registre prévoit les termes et les conditions régissant un tel verrouillage, avec le consentement exprès du titulaire du nom de domaine : et

    Le bureau d'enregistrement doit retirer le statut « verrouillé par le bureau d'enregistrement » dans les cinq (5) jours calendaires suivant la demande initiale du titulaire du nom de domaine, si le bureau d'enregistrement ne fournit pas au titulaire de nom de domaine des mécanismes pour modifier le statut « verrouillé par le bureau d'enregistrement. »

    Actions de communication menées par le groupe de travail pour connaître le point de vue des groupes les plus susceptibles d'être affectés :
    Les forums de commentaires du public, organisés par le groupe de travail, ont eu lieu à l'occasion du lancement du PDP, de la présentation du rapport initial, du rapport final proposé et de la proposition du personnel sur la recommandation 9, partie 2, et s'ajoutent aux mises à jour du conseil de la GNSO et aux ateliers destinés à informer et à demander l'opinion de la communauté de l'ICANN lors des réunions de l'ICANN (voir par exemple, la réunion de Bruxelles et la réunion de San Francisco). Les déclarations des regroupements et des groupes des parties prenantes ont été présentées (voir https://community.icann.org/display/gnsoirtpb/IRTP+Part+B). Tous les commentaires reçus ont été révisés et étudiés par le groupe de travail sur le PDP de l'IRTP Partie B (voir section 6 du Rapport final sur l'IRTP Partie B [PDF, 1.04 MB]). De plus, tel que stipulé dans les statuts de l'ICANN, un forum de consultation publique a été organisé sur les recommandations qui seront soumises à la considération du Conseil d'administration de l'ICANN.

    Quelles sont les préoccupations ou les questions soulevées par la communauté ?
    Après la finalisation du forum de commentaires publics sur la proposition du personnel (aucun commentaire reçu) et la soumission de la proposition au Conseil de la GNSO, le regroupement de la propriété intellectuelle a présenté un ensemble de commentaires qui ont été examinés lors des délibérations du Conseil de la GNSO sur la proposition. Or, aucune modification de la recommandation ne s'est avérée nécessaire suite à l'examen de ces commentaires. La proposition du personnel ainsi que la motion visant à adopter la recommandation ont été adoptées à l'unanimité.

    Quels sont les documents importants examinés par le Conseil ?
    Le Conseil a examiné le rapport sur les recommandations du Conseil de la GNSO au Conseil [PDF, 576 KB], ainsi que la synthèse des commentaires publics et la réponse du personnel à ces commentaires.

    Quels sont les facteurs que le Conseil a trouvés significatifs ?
    La recommandation a été élaborée par le groupe de travail sur l'IRTP Partie B selon le processus d'élaboration des politiques de la GNSO, tel que décrit dans l'annexe A des statuts de l'ICANN et a reçu le soutien unanime du conseil de la GNSO. Comme indiqué dans les statuts de l'ICANN, le soutien unanime à cette motion par le Conseil (majorité qualifiée) oblige le Conseil à adopter la recommandation, sauf si, par un vote de plus de 66 %, le Conseil détermine que la politique concernée n'est pas dans le meilleur intérêt de la communauté de l'ICANN ou de l'ICANN. En outre, d'après les données provenant du département de conformité contractuelle de l'ICANN, les questions liées au transfert se trouvent parmi les principales plaintes. Les améliorations introduites à l'IRTP ont le potentiel de réduire le nombre de plaintes et d'offrir davantage de clarté et de prévisibilité aux registrants et aux bureaux d'enregistrement.

    Cela a-t-il des effets positifs ou négatifs pour la communauté ?
    Les améliorations introduites à l'IRTP ont le potentiel de réduire le nombre de plaintes et d'offrir davantage de clarté et de prévisibilité aux registrants et aux bureaux d'enregistrement. L'adoption des recommandations exigera des changements dans les processus des bureaux d'enregistrement. Ces changements, dont l'impact est jugé minimal, sont nécessaires pour résoudre les difficultés posées par ce processus d'élaboration de politiques. Les recommandations, si elles sont appliquées, pourraient servir à préciser et à consolider l'IRTP, au bénéfice de toutes les parties concernées.

    Y a-t-il un impact au niveau fiscal ou des répercussions sur l'ICANN (plan stratégique, plan opérationnel, budget), sur la communauté et/ou sur le public ?
    En dehors des changements indiqués ci-dessus, nécessaires dans le processus des bureaux d'enregistrement , aucune autre répercussion fiscale ou d'autres conséquences ne sont attendues pour l'ICANN, pour la communauté et/ ou pour le public.

    Y a-t-il des implications sur la sécurité, la stabilité ou la résilience du DNS ?
    Aucun problème de sécurité, de stabilité ou de résilience lié au DNS n'est à prévoir suite à l'approbation par le Conseil des recommandations proposées.

    1.3. Changement des statuts pour le nouveau processus d'élaboration de politiques de la GNSO

    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 sur le processus d'élaboration des politiques, proposant une nouvelle annexe A pour les statuts de l'ICANN et un manuel pour le processus d'élaboration des politiques (PDP), conformément à une directive visant à développer un nouveau PDP plus efficace, capable de mieux répondre 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 de nouveaux seuils de vote établis dans le rapport final mis à jour du groupe de travail sur les PDP.

    Attendu qu'un forum de consultation publique a été mis en place le 10 février 2012 concernant les changements proposés et qu'aucun commentaire n'y a été reçu.

    Attendu que le Conseil d'administration de l'ICANN a examiné les changements proposés ainsi que les commentaires présentés.

    Résolu (2012.03.16.04), le Conseil d'administration de l'ICANN approuve les révisions supplémentaires des statuts de l'ICANN <http://www.icann.org/en/general/proposed-bylaws-changes-gnso-pdp-redline-10feb12-en.pdf> [PDF, 134 KB] dans la mesure où cela s'avère nécessaire pour la mise en place du nouveau PDP.

    Fondements de la résolution 2012.03.16.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. Dans un souci de responsabilité à l'égard de la communauté de l'ICANN, les changements proposés ont été publiés et soumis aux commentaires du public afin d'assurer la participation de la communauté et la transparence dans toutes les étapes de la mise en place (voir http://www.icann.org/en/public-comment/bylaws-amend-gnso-pdp-10feb12-en.htm). Cette décision n'aura d'impact ni sur les ressources de l'ICANN ni sur la sécurité et la stabilité du DNS.

    1.4. Nomination d'un auditeur indépendant

    Considérant que l'article XVI des statuts de l'ICANN, < http://www.icann.org/fr/general/bylaws-fr.htm >, exige qu'à la fin de l'exercice financier les livres de l'ICANN soient vérifiés par des comptables agréés. Les statuts stipulent également que la nomination des auditeurs financiers relève de la responsabilité du Conseil d'administration.

    Attendu que le comité d'audit du Conseil a examiné l'engagement d'un auditeur indépendant pour l'exercice qui arrive à terme le 30 juin 2012, et a recommandé que le Conseil d'administration engage Moss Adams LLP.

    Attendu que le Comité d'audit du Conseil a recommandé que le Conseil demande au personnel de signer un contrat de services professionnels avec Moss Adams, décision qui sera soumise à la considération du président du Comité d'audit.

    Résolu (2012.03.16.05), le Conseil autorise le Président directeur général à engager Moss Adams LLP comme auditeur financier pour l'exercice finissant le 30 juin 2012.

    Fondements de la résolution 2012.03.16.05

    Le recours à un auditeur indépendant s'encadre dans l'obligation de l'ICANN de mettre en place un audit de ses livres comptables. L'ICANN pousse ainsi un peu plus loin sa responsabilité à l'égard de ses statuts et de ses processus. Les résultats de l'audit indépendant seront disponibles pour le public. Cet engagement comporte un impact financier qui a été déjà budgété dans le plan opérationnel de l'ICANN. Il n'en résulte aucun impact sur la sécurité ou la stabilité du DNS.

    1.5. Approbation de la politique en matière de contrats et de dépenses

    Attendu que le comité des finances du Conseil d'administration a examiné la politique actuelle de dépenses et a recommandé qu'elle soit révisée afin qu'il soit clair qu'elle concerne autant l'autorité en matière contractuelle qu'en matière de dépenses.

    Attendu que le Conseil d'administration est d'accord avec le comité des finances du Conseil d'administration.

    Résolu (2012.03.16.06), le Conseil d'administration adopte la politique en matière de contrats et de dépenses, comme indiqué dans <http://www.icann.org/en/about/financials/signing-authority> (remarque : le document révisé sera publié dès qu'il sera disponible), qui remplace la politique de dépenses de l'ICANN révisée pour la dernière fois le 10 décembre 2010.

    Fondements de la résolution 2012.03.16.06

    Le Conseil d'administration s'engage à assurer que les opérations de l'ICANN soient gérées de la façon la plus efficace possible. Un moyen d' y parvenir consiste à donner à la direction l'autorité pour passer les contrats nécessaires au fonctionnement quotidien de l'organisation, et pour procéder en temps voulu aux déboursements liés à ces contrats. L'objectif de la politique en matière de contrats et de dépenses est de donner à la direction l'autorité pour faire fonctionner l'organisation, tout en veillant à ce qu'il existe des mécanismes de supervision suffisants dès lors que les dépenses liées à un projet ou à un contrat dépassent les 500 000,00 USD.

    L'impact, s'il y en a un, sur la communauté de l'ICANN sera faible dans la mesure où le but de la révision de cette politique est de préciser son applicabilité. Aucun impact financier n'est à prévoir ni pour l'ICANN, ni pour la communauté, ni sur la sécurité, la stabilité ou la résilience du système des noms de domaine.

    1.6. Approbation de la charte du groupe de travail sur le cadre de gestion de risques pour le DNS

    Attendu que le 18 mars 2011, le Conseil d'administration a demandé au comité de gouvernance du Conseil d'administration (BGC) de recommander au Conseil d'administration un groupe de travail pour superviser l'élaboration d'un cadre et d'un système de gestion des risques pour le DNS, ces aspects se rapportant au rôle de l'ICANN tel que défini dans ses statuts.

    Attendu que dans sa réunion du 28 octobre 2011, le Conseil d'administration de l'ICANN a approuvé la participation de ses membres au groupe de travail, suivant la recommandation du comité de gouvernance du Conseil d'administration.

    Attendu que le 12 mars 2012, le comité de gouvernance du Conseil d'administration a approuvé la version préliminaire de la charte du groupe de travail sur le cadre de gestion des risques pour le DNS et a recommandé son approbation par le Conseil d'administration.

    Résolu (2012.03.16.07), le Conseil d'administration approuve la charte du groupe de travail sur le cadre de gestion des risques pour le DNS.

    Fondements de la résolution 2012.03.16.07

    L'élaboration d'un cadre de gestion des risques a pour objectif de répondre au souhait exprimé par le Conseil d'administration d'élaborer un cadre de sécurité pour les services d'attribution de noms et d'adresses d'Internet qui définisse les secteurs de concentration clés et identifie à qui revient la responsabilité de chaque secteur. Le Conseil d'administration a établi ce groupe de travail composé d'experts issus de chaque domaine pertinent pour superviser l'élaboration d'un tel cadre et système de gestion des risques pour le DNS, tel qu'il appartient au rôle de l'ICANN défini dans les règlements de l'ICANN. Le progrès dont témoigne l'établissement de ce groupe de travail aidera l'ICANN à poursuivre son travail de maintien de la sécurité, la stabilité et la résilience du DNS.

    Les résultats du travail supervisé par ce groupe devraient avoir un impact positif sur la communauté, dans la mesure où ils aideront à définir les secteurs de concentration et à identifier les responsabilités. L'établissement du groupe de travail ne devrait pas avoir d'impact fiscal sur l'organisation ou sur la communauté.

    1.7. Approbation de la redélégation de .BH

    Attendu que .BH est le code de pays à deux lettres correspondant à Bahreïn dans la liste ISO 3166-1.

    Considérant que l'ICANN a reçu une demande de redélégation de .BH 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 d' Internet locales et mondiales ;

    Résolu (2012.03.16.08), la redélégation proposée du domaine .BH en faveur de l'autorité de régulation des télécommunications est approuvée.

    Fondements de la résolution 2012.03.16.08

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

    L'ICANN soumet à la considération du Conseil les requêtes de délégation et de redélégation des domaines de code de pays lorsque le candidat a présenté une candidature suffisamment complète ayant 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 du DNS, le Conseil de l'ICANN cherche à évaluer ces demandes lors de sa prochaine assemblée prévue.

    Quelle est la proposition à l'étude ?

    La proposition consiste à approuver une demande adressée à l'IANA pour changer ou désigner l'organisation commanditaire (également connue sous le nom de gestionnaire ou administrateur) d'un nom de domaine de code de pays de premier niveau. 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, 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é dans le 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, en temps opportun 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. Ces critères visent à établir : que le code de pays soit éligible (par exemple, qu'il figure dans la norme ISO 3166-1) ; que l'administrateur proposé soit soutenu par la communauté Internet locale ; que l'opérateur proposé possède des compétences opérationnelles et techniques ; que l'administrateur proposé opère depuis une base locale et en vertu de la loi locale ; que l'administrateur proposé opère de manière juste et équitable ; au cas où il y aurait un transfert des opérations, qu'un plan approprié soit mis en place pour préserver la continuité de la stabilité du domaine ; et que la décision 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. Les informations pertinentes provenant de ces documents ainsi que de tout autre travail de recherche sont adressées au Conseil et publiées dans un rapport public à l'issue 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, à la lumière des principes fondamentaux de délégation de domaine de code de pays décrits ci-dessus.

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

    L'approbation en temps opportun des redélégations de noms de domaine de code de pays répondant à l'ensemble de critères d'intérêt public est positive au regard de la mission globale de l'ICANN ainsi que pour les communautés locales auxquelles les domaines de premier niveau de code de pays sont censés servir.

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

    La gestion de délégations des codes de pays dans la zone racine du DNS fait partie de la fonction de l'IANA, et la 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é.

    1.8. Approbation des modifications des membres du SSAC

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

    Attendu que le Comité des membres du SSAC, au nom du SSAC, demande que le Conseil nomme Robert Guerra et Julie Hammer au SSAC.

    Résolu (2012.03.16.09), le Conseil d'administration nomme Robert Guerra et Julie Hammer au SSAC.

    Fondements de la résolution 2012.03.16.09

    Le SSAC est un groupe diversifié de personnes dont l'expertise dans des sujets spécifiques lui permet de satisfaire aux objectifs de sa charte et d'exécuter sa mission. Depuis sa création, le SSAC a invité des personnes ayant une connaissance et une expérience approfondies dans les domaines techniques et de sécurité qui sont cruciaux pour la sécurité et la stabilité du système de noms de domaine de l'Internet.
    Le fonctionnement continu du SSAC en tant qu'entité compétente dépend de la participation continue d'experts talentueux qui ont consenti à offrir bénévolement leur temps et leur énergie afin que le SSAC remplisse sa mission
    . Robert Guerra est conseiller spécial du Citizen Lab à la Munk School of Global Affairs de l'Université de Toronto, et co-fondateur de Privaterra. Robert a été membre du SSAC de 2009 à 2010. Outre sa vaste expérience technique, il apporterait au SSAC la perspective de la société civile. Julie Hammer est directrice indépendante du Conseil d'administration de auDA, le ccTLD australien. Julie apporterait au SSAC sa vaste expérience en matière de sécurité.

    1.9. Remerciements aux membres du SSAC sortants

    Attendu que, Xiaodong Lee a été nommé au comité consultatif sur la sécurité et la stabilité de l'ICANN le 25 juin 2010.

    Attendu que l'ICANN souhaite remercier Xiaodong Lee pour ses services à la communauté prêtés dans le cadre de sa participation au comité consultatif sur la sécurité et la stabilité.

    Résolu (2012.03.16.10), les services prêtés par Xiaodong Lee à l'ICANN dans le cadre de sa participation au comité consultatif sur la sécurité et la stabilité lui ont valu l'appréciation profonde du Conseil d'administration, qui souhaite à Xiaodong Lee beaucoup de succès dans son nouveau rôle au sein de l'ICANN.

    Fondements de la résolution 2012.03.16.10

    La reconnaissance exprimée par le Conseil au SSAC pour les services rendus par les membres du comité lors de leur départ s'inscrit dans les pratiques habituelles.

    1.10. Remerciements au bénévole de la ccNSO sortant

    Attendu que l'ICANN tient à remercier la communauté des parties prenantes pour l'énergie et les compétences qu'ils mettent au service du processus de l'ICANN.

    Attendu qu'en reconnaissance de leurs contributions l'ICANN souhaite remercier les membres de la communauté lorsque leur mandat au sein des organisations de soutien et des comités consultatifs s'achève.

    Attendu qu'un (1) membre de la ccNSO a quitté son poste depuis la réunion de Dakar :

    Patricio Poblete, membre du conseil de la GNSO depuis sa formation en 2004 jusqu'en mars 2012.

    Résolu (2012.03.16.11), les services de Patricio Poblete pendant son mandat lui ont valu la profonde appréciation du Conseil d'administration, qui souhaite à Patricio Poblete beaucoup de succès dans ses projets à venir.

    1.11. Remerciement aux sponsors

    Le Conseil tient à remercier les sponsors suivants :

    Verisign, Inc., Afilias Limited, .ORG, The Public Interest Registry, Neustar, China Organizational Name Administration Center, Iron Mountain, Knet Co., Ltd., CORE Internet Council of Registrars, SX Registry S.A., China Network Information Center, UniForum SA dba the .ZA Central Registry, Sedari, InterNetX, Community.Asia, Freedom Registry, Inc., GMO Registry, Inc., TANGO REGISTRY SYSTEMS, Foundation for Assistance for Internet Technologies and Infrastructure Development, CloudNames, Dejan SEO Pty Ltd and ICANNWiki, and our local sponsors, ICE (Instituto Costarricense de Electricidad), Instituto Costarricense de Turismo (ICT), LACNIC – Registro de Direcciones de Internet para America Latina y el Caribe, Ministerio de Ciencia y Tecnologia (MICIT), et SOMOS UCR.

    1.12. Remerciement aux scribes, aux interprètes, au personnel et aux équipes de l'hôtel et celles chargées de l'organisation de l'événement

    Le Conseil exprime sa gratitude aux scribes, aux interprètes, aux équipes techniques et à l'ensemble du personnel de l'ICANN pour les efforts réalisés afin de faciliter le bon déroulement de la réunion.

    Le Conseil souhaite également remercier la direction et le personnel de l'hôtel Ramada Plaza Herradura pour avoir mis à disposition ces merveilleuses installations pour la réalisation de l'événement. Stephanie Roncallo, Lucia Bolaños, Luis Bustos Valerin, et Andrea Muñoz ont reçu des remerciements spéciaux.

    1.13. Remerciements aux hôtes

    Le Conseil d'administration souhaite exprimer ses remerciements à l'organisateur et hôte local, NIC Costa Rica et l'Académie nationale des Sciences pour leur soutien. Nous remercions tout spécialement Me. Gabriel Macaya Trejos, Me. Guy de Teramond, Jéssica Calvo, Karen Gamboa, Luis Diego Espinoza, et Allan Campos, Université du Costa Rica.

    Le Conseil remercie la présidente du Costa Rica, Mme. Laura Chinchilla Miranda, et le Alejandro Cruz, ministre de la science et la technologie pour leur soutien et leur participation à la réunion.

    Les résolutions 2012.03.16.01, 2012.03.16.02, 2012.03.16.03, 2012.03.16.04, 2012.03.16.05, 2012.03.16.06, 2012.03.16.07, 2012.03.16.08, 2012.03.16.09, 2012.03.16.10, et 2012.03.16.11 ont été approuvées à l'unanimité. Seize membres du Conseil ont voté en faveur des résolutions. Les résolutions ont été adoptées.

    Le président a ensuite levé la séance.

minutes-16mar12-fr.pdf  [205 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."