Skip to main content
Resources

Résolutions approuvées par le Conseil d'administration | Réunion ordinaire 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/resolutions-16mar12-en.htm

  1. Ordre du jour approuvé

 

  1. Ordre du jour approuvé

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

    1.1. Approbation du procès verbal de la réunion du Conseil de l'ICANN du 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 de développement stratégique (PDP) sur la politique de transfert des 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 dans les statuts, qui ont donné lieu au rapport final délivré le 30 mai 2011.

    Attendu que le groupe de travail 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 de 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 été soumise aux commentaires du public (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 révisé et discuté la proposition faite par le personnel de l'ICANN concernant la Partie B de la Recommandation nº 9, 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 nombre de voix nécessaires pour imposer de nouvelles obligations aux parties contractantes de l'ICANN.

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

    Il est résolu (2012.03.16.02) que le Conseil d'administration adopte les recommandations du conseil de la GNSO qui modifient la politique de transfert de noms de domaine entre bureaux d'enregistrement stipulées dans http://www.icann.org/fr/transfers/policy-fr.htm.

    Il est résolu (2012.03.16.03) que le PDG développera et complètera un plan de mise en œuvre pour ces recommandations et la communication continue 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) s'agit d' une politique de consensus 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 secteurs d'adressage PDP pour améliorer la politique existante. Le groupe de travail de l'IRTP Partie B a traité 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 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 de l'IRTP Partie B PDP a reçu le consensus unanime du groupe de travail 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 signale que le motif de refus nº7 de l'IRTP devrait être remplacé par l'ajout d'une nouvelle disposition 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, compte tenu de la suppression du motif de refus nº 7 approuvé précédemment par le Conseil d'administration de l'ICANN, propose 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 ». Les modifications proposées pour l'IRTP se trouvent soulignées en rouge dans la proposition du personnel de l'ICANN sur la recommandation nº 9 , partie B de l'IRTP, partie 2 , qui figure dans l'annexe. Les éléments principaux des 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 si

    Le bureau d'enregistrement doit retirer le statut « verrouillé par le bureau d'enregistrement » dans les 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 recueillir 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 figurent dans initiation of the PDP, the Initial Report, proposed Final Report et the Staff Proposal on Recommendation 9, Part 2, additionnellement aux mises à jour du conseil de la GNSO ainsi que comme ateliers pour informer et demander l'opinion de la communauté de l'ICANN lors des réunions de l'ICANN (voir par exemple, Brussels Meeting et San Francisco Meeting). Les déclarations des regroupements et du groupe des parties prenantes ont été soumises (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 IRTP Partie B PDP (voir section 6 du IRTP Part B Final Report [PDF, 1.04 MB]). De plus, tel que stipulé dans les statuts de l'ICANN, un public comment forum a été inclus dans les recommandations pour la considération du Conseil d'administration de l'ICANN.

    Quelles sont les préoccupations ou les questions ayant été soulevées par la communauté ?

    Après la clôture 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 the Intellectual Property Constituency submitted a number of comments, 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 ayant été révisés par le Conseil ?

    Le Conseil a révisé le GNSO Council Recommendations Report to the Board [PDF, 576 KB], ainsi que la synthèse des commentaires publics et la réponse de l'équipe à ces commentaires.

    Quels sont les facteurs que le Conseil a trouvés significatifs ?

    La recommandation a été élaborée par le groupe de travail 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 de 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, les questions liées au transfert sont le premier domaine de plainte selon les données de conformité contractuelle de l'ICANN. Des améliorations faites à la politique de transferts interopérateur de registre (IRTP) ont le potentiel de réduire le nombre de plainte 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é ?

    Des améliorations faites à la politique de transferts interopérateur de registre (IRTP) ont le potentiel de réduire le nombre de plainte 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 pour les bureaux d'enregistrement mais ils sont considérés comme ayant un impact minimal et comme nécessaire pour aborder les questions qui font partie de ce processus de développement des politiques. Les recommandations, si elles sont appliquées, pourraient être utiles pour préciser et consolider l'IRTP, pour le bénéfice de toutes les parties concernées.

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

    En dehors de ces changements nécessaires dans le processus pour les bureaux d'enregistrement comme indiqué ci-dessus, 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 questions de sécurité, de stabilité ou de résilience concernant le DNS ?

    Il n'y a aucun problème de sécurité, de stabilité ou de résilience lié au DNS si le Conseil approuve les recommandations proposées.

    1.3. Changement des statuts pour le nouveau processus de développement 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 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.

    Attendu qu'un forum de commentaires publics 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 révisé les changements proposés ainsi que les commentaires présentés.

    Il est résolu (2012.03.16.04), que 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é posté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 action 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/about/governance/bylaws>, 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 audits relève de la responsabilité du Conseil d'administration.

    Attendu que le Comité d'audit du Conseil a discuté de l'engagement d'un audit 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 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.

    Il est résolu (2012.03.16.05), que 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 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 pour préciser 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.

    Il est résolu (2012.03.16.06), que 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 posté aussitôt 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. Une façon 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 enjoint 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, ceci appartenant au rôle de l'ICANN tel que défini dans les statuts de l'ICANN.

    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.

    Il est résolu (2012.03.16.07), que 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, à savoir 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é de personnes expertes dans chaque secteur 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 reflété par l'établissement de ce groupe de travail aidera l'ICANN à poursuivre son œuvre de maintien de la sécurité, stabilité et 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 la responsabilité. L'établissement du groupe de travail ne devrait pas avoir d'impact fiscal sur l'organisation ou la communauté.

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

    Attendu que .BH est le code de pays de deux lettres correspondant à Bahrein 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 Internet locales et mondiales ;

    Il est résolu (2012.03.16.08), que 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 redélégation des domaines de code de pays dès que le candidat aura 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 DNS, le Conseil de l'ICANN cherche à évaluer ces demandes lors de sa prochaine assemblée prévue.

    Quelles sont les propositions à l'étude ?

    La proposition est d'approuver une demande adressée à l'IANA pour changer ou désigner une 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, 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, 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, en temps opportun 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 que : les codes de pays soient admissibles (p. ex. énumérés dans la norme ISO 3166-1) ; l'administrateur proposé reçoive le soutien de la communauté Internet locale ; l'opérateur proposé possède les compétences opérationnelles et techniques ; l'administrateur proposé opère depuis une base locale et en vertu de la loi locale ; l'administrateur proposé opère de manière juste et équitable ; 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 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 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 redélégations 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é et/ou 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 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.

    1.8. Approbation des modifications à l'adhésion au 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.

    Il est résolu (2012.03.16.09), que 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 à sa charte et d'exécuter sa mission. Depuis sa création, le SSAC a invité les 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 l'accumulation 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é de par sa participation au comité consultatif sur la sécurité et la stabilité.

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

    Fondements de la résolution 2012.03.16.10

    Le SSAC a l'habitude de recevoir la reconnaissance du Conseil pour les services rendus par les membres du comité lors de leur départ.

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

    Attendu que, l'ICANN tient à remercier l'énergie considérable et les compétences que les membres de la communauté des parties prenantes apportent au processus de l'ICANN.

    Attendu qu'en reconnaissance de ces contributions l'ICANN souhaite remercier les membres de la communauté à la fin de leurs mandats au service des organisations de soutien et des comités consultatifs.

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

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

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

    1.11. Nous remercions les 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 et ICANNWiki, et nos sponsors locaux, 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. Nous remercions les scribes, les interprètes, le personnel, les équipes engagées pour l'évènement et le personnel de l'hôtel

    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 permis la réalisation de cet événement dans ses merveilleuses installations. 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, National Academy of Sciences pour leur soutien. Nous remercions tout spécialement Dr. Gabriel Macaya Trejos, Dr. Guy de Teramond, Jéssica Calvo, Karen Gamboa, Luis Diego Espinoza, et Allan Campos, Université du Costa Rica.

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

    (Remarque : La version préliminaire des fondements des actions du Conseil d'administration, le cas échéant, est présentée sous la résolution associée. La version préliminaire n'est pas définitive tant qu'elle n'a pas été approuvée dans les procès verbaux de la réunion du Conseil.)

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