Skip to main content
Resources

Résolutions approuvées | Réunion ordinaire du Conseil d’administration de l’ICANN

Cette page est disponible en:

  1. Ordre du jour approuvé :
    1. Approbation du procès-verbal du Conseil d'administration
    2. Redélégation du domaine .MK et délégation du domaine .мкд représentant l'ancienne République yougoslave de Macédoine au Macedonian Academic Research Network Skopje
    3. Délégation du domaine გე (« ge ») représentant la Géorgie en alphabet géorgien (Mkhedruli) au Information Technologies Development Center
    4. Report de la date de suppression du ccTLD .AN (Antilles néerlandaises)
    5. Modifications de la charte du groupe des représentants des bureaux d'enregistrement
    6. Remerciements aux membres de la communauté
    7. Remerciements aux sponsors de la 51e réunion de l'ICANN
    8. Remerciements aux interprètes, au personnel, aux équipes de l'hôtel et aux personnes chargées de l'organisation de la 51e réunion de l'ICANN 18
  2. Ordre du jour principal :
    1. Remerciements au comité de nomination 2014
    2. Introduction de noms de domaine à deux caractères dans l'espace des noms des nouveaux gTLD
    3. Plan stratégique de l'ICANN pour les exercices 2016-2020
    4. Examen par le Conseil d'administration des recommandations issues du groupe de travail intercommunautaire chargé de renforcer la responsabilité de l'ICANN
    5. Un grand merci à Olga Madruga-Forti pour ses services prêtés dans le cadre du Conseil d'administration de l'ICANN
    6. Un grand merci à Sébastien Bachollet pour ses services prêtés dans le cadre du Conseil d'administration de l'ICANN
    7. Un grand merci à Bill Graham pour ses services prêtés dans le cadre du Conseil d'administration de l'ICANN
    8. Un grand merci à Heather Dryden pour ses services prêtés dans le cadre du Conseil d'administration de l'ICANN

 

  1. Ordre du jour approuvé :

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

      Résolu (2014.10.16.01), le Conseil d'administration approuve le procès-verbal de la réunion ordinaire du Conseil d'administration de l'ICANN du 9 septembre 2014.

    2. Redélégation du domaine .MK et délégation du domaine .мкд représentant l'ancienne République yougoslave de Macédoine au Macedonian Academic Research Network Skopje

      Résolu (2014.10.16.02), dans le cadre de ses responsabilités en vertu du contrat des fonctions IANA, l'ICANN a examiné et évalué la demande de redélégation du domaine de premier niveau géographique .MK et de délégation du domaine de premier niveau géographique IDN .мкд au Macedonian Academic Research Network Skopje. La documentation montre que cette demande a suivi les procédures appropriées pour son évaluation.

      Résolu (2014.10.16.03), le Conseil d'administration ordonne, en vertu de l'article 5.2 du chapitre III des statuts de l'ICANN, que certaines parties des fondements des résolutions, du rapport préliminaire ou des procès-verbaux non appropriées à la diffusion publique en ce moment à cause des obligations contractuelles, en soient exemptées jusqu'à ce que la publication soit autorisée conformément auxdites obligations contractuelles.

      Fondements des résolutions 2014.10.16.02 et 2014.10.16.03

      Pourquoi le Conseil d'administration aborde-t-il cette question maintenant ?

      Conformément au contrat des fonctions IANA, le personnel de l'ICANN a évalué deux demandes de redélégation et délégation des ccTLD et présente son rapport au Conseil d'administration à des fins d'examen. Cet examen du Conseil d'administration vise à assurer que le personnel de l'ICANN a suivi les procédures appropriées.

      Quelle est la proposition à l'étude ?

      Il est proposé d'approuver deux demandes soumises au département IANA visant à confier l'organisation de parrainage (connue également sous le nom de gestionnaire ou administrateur) des domaines de premier niveau géographiques .мкд et .MK au Macedonian Academic Research Network Skopje.

      Quelles parties intéressées ou autres ont été consultées ?

      Au cours de l'évaluation des demandes de redélégation et délégation, le personnel de l'ICANN consulte le candidat et d'autres parties concernées. Dans le cadre du processus de candidature, le candidat doit décrire les consultations effectuées dans le pays concernant le ccTLD et la possibilité d'application dans sa communauté Internet locale.

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

      Le personnel n'est pas informé des questions ou des inquiétudes soulevées par la communauté concernant ces demandes.

      Quels sont les documents importants examinés par le Conseil d'administration ?

      Le Conseil d'administration a examiné les évaluations suivantes du personnel du département IANA :

      • Les domaines sont éligibles à une délégation permanente, étant donné que MK est un code alpha-2 attribué figurant dans la norme ISO 3166-1 pour l'ancienne République yougoslave de Macédoine, et que мкд est la chaîne de noms de domaine internationalisés approuvée pour l'ancienne République yougoslave de Macédoine ;
      • Les demandes sont acceptées par l'organisation de parrainage existante, le ministère des Affaires étrangères ;
      • Le gouvernement concerné a été consulté et n'émet aucune réserve ;
      • L'organisation de parrainage proposée ainsi que ses contacts acceptent leurs responsabilités en matière de gestion de ces domaines ;
      • Il ressort des propositions que la communauté Internet locale a été dûment consultée et apporte son soutien ;
      • Les propositions n'enfreignent aucune loi ou règlementation connue ;
      • Les propositions garantissent que les domaines seront gérés localement au sein du pays et respecteront le droit local ;
      • L'organisation de parrainage proposée a confirmé qu'elle assurera la gestion des domaines de façon juste et équitable ;
      • L'organisation de parrainage proposée a prouvé qu'elle disposait de compétences opérationnelles et techniques adéquates et a l'intention d'exploiter les domaines ;
      • La configuration technique proposée respecte les différentes exigences de conformité technique du département IANA ;
      • Aucun risque ou aucune inquiétude spécifique lié à la stabilité d'Internet n'a été identifié ; et
      • Le personnel a recommandé que ces demandes soient mises en œuvre sur la base des facteurs considérés.

      Ces évaluations sont adaptées aux critères et cadres politiques appropriés tels que « Structure et délégation du système des noms de domaine » (RFC 1591) et « Principes et directives pour la délégation et l'administration des domaines de premier niveau géographiques ».

      Dans le cadre du processus établi par le contrat des fonctions IANA, le « Rapport sur la délégation et redélégation » sera publié sur http://www.iana.org/reports.

      Quels sont les facteurs que le Conseil d'administration a jugés significatifs ?

      Le Conseil d'administration n'a identifié aucun facteur d'inquiétude concernant ces demandes.

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

      L'approbation en temps opportun des administrateurs de noms de domaine géographiques répondant aux critères d'intérêt public a un impact positif vis-à-vis de la mission globale de l'ICANN et des communautés locales qui se voient assigner des domaines de premier niveau géographiques, et permet de satisfaire aux obligations de l'ICANN établies en vertu du contrat des fonctions IANA.

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

      La gestion des délégations géographiques dans la zone racine du DNS fait partie des fonctions IANA, et le processus de délégation ne devrait pas produire de variation significative des dépenses prévues. Ce n'est pas le rôle de l'ICANN d'évaluer l'impact financier des opérations internes des domaines de premier niveau géographiques au sein d'un pays.

      Y a-t-il des implications sur la sécurité, la stabilité ou la résilience du DNS ?

      L'ICANN estime que ces demandes ne présentent pas de risques significatifs à la sécurité, la stabilité ou la résilience.

      Il s'agit d'une fonction administrative et organisationnelle qui ne nécessite pas de consultation publique.

    3. Délégation du domaine გე (« ge ») représentant Georgia dans l'alphabet géorgien (Mkhedruli) au Information Technologies Development Center

      Résolu (2014.10.16.04), dans le cadre de ses responsabilités en vertu du contrat des fonctions IANA, l'ICANN a examiné et évalué la demande de délégation du domaine de premier niveau géographique გე au Information Technologies Development Center (ITDC). La documentation montre que cette demande a suivi les procédures appropriées pour son évaluation.

      Résolu (2014.10.16.05), le Conseil d'administration ordonne, en vertu de l'article 5.2 du chapitre III des statuts de l'ICANN, que certaines parties des fondements des résolutions, du rapport préliminaire ou des procès-verbaux non appropriées à la diffusion publique en ce moment à cause des obligations contractuelles, en soient exemptées jusqu'à ce que la publication soit autorisée conformément auxdites obligations contractuelles.

      Fondements des résolutions 2014.10.16.04 et 2014.10.16.05

      Pourquoi le Conseil d'administration aborde-t-il cette question maintenant ?

      Conformément au contrat des fonctions IANA, le personnel de l'ICANN a évalué une demande de délégation des ccTLD et présente son rapport au Conseil d'administration à des fins d'examen. Cet examen du Conseil d'administration vise à assurer que le personnel de l'ICANN a suivi les procédures appropriées.

      Quelle est la proposition à l'étude ?

      Il est proposé d'approuver une demande soumise à l'IANA visant à créer un domaine de premier niveau géographique et à confier le rôle de l'organisation de parrainage (connue également sous le nom de gestionnaire ou administrateur) au Information Technologies Development Center (ITDC).

      Quelles parties intéressées ou autres ont été consultées ?

      Au cours de l'évaluation d'une demande de délégation, le personnel de l'ICANN consulte le candidat et d'autres parties concernées. Dans le cadre du processus de candidature, le candidat doit décrire les consultations effectuées dans le pays concernant le ccTLD et la possibilité d'application dans sa communauté Internet locale.

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

      Le personnel n'est pas informé des questions ou des inquiétudes soulevées par la communauté concernant cette demande.

      Quels sont les documents importants examinés par le Conseil d'administration ?

      Le Conseil d'administration a examiné les évaluations suivantes du personnel du département IANA :

      • Le domaine est éligible à la délégation, étant donné qu'il s'agit d'une chaîne ayant été approuvée par la procédure accélérée ccTLD IDN et représentant un pays figurant dans la norme ISO 3166-1 ;
      • Le gouvernement concerné a été consulté et n'émet aucune réserve ;
      • L'organisation de parrainage proposée ainsi que ses contacts acceptent leurs responsabilités en matière de gestion de ces domaines ;
      • Il ressort de la proposition que la communauté Internet locale a été dûment consultée et apporte son soutien ;
      • La proposition n'enfreint aucune loi ou règlementation connue ;
      • La proposition garantit que le domaine sera géré localement au sein du pays et respectera le droit local ;
      • L'organisation de parrainage proposée a confirmé qu'elle assurera la gestion du domaine de façon juste et équitable ;
      • L'organisation de parrainage proposée a prouvé qu'elle disposait de compétences opérationnelles et techniques adéquates et a l'intention d'exploiter le domaine ;
      • La configuration technique proposée respecte les différentes exigences de conformité technique du département IANA ;
      • Aucun risque ou aucune inquiétude spécifique lié à la stabilité d'Internet n'a été identifié ; et
      • Le personnel a recommandé que cette demande soit mise en œuvre sur la base des facteurs considérés.

      Ces évaluations sont adaptées aux critères et cadres politiques appropriés tels que « Structure et délégation du système des noms de domaine » (RFC 1591) et « Principes et directives pour la délégation et l'administration des domaines de premier niveau géographiques ».

      Dans le cadre du processus établi par le contrat des fonctions IANA, le « Rapport sur la délégation et la redélégation » sera publié sur http://www.iana.org/reports.

      Quels sont les facteurs que le Conseil d'administration a jugés significatifs ?

      Le Conseil d'administration n'a identifié aucun facteur d'inquiétude concernant cette demande.

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

      L'approbation en temps opportun des administrateurs de noms de domaine géographiques répondant aux critères d'intérêt public a un impact positif vis-à-vis de la mission globale de l'ICANN et des communautés locales qui se voient assigner des domaines de premier niveau géographiques, et permet de satisfaire aux obligations de l'ICANN établies en vertu du contrat des fonctions IANA.

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

      La gestion des délégations des extensions géographiques dans la zone racine du DNS fait partie des fonctions IANA, et le processus de délégation ne devrait pas produire de variation significative des dépenses prévues. Ce n'est pas le rôle de l'ICANN d'évaluer l'impact financier des opérations internes des domaines de premier niveau géographiques au sein d'un pays.

      Y a-t-il des implications sur la sécurité, la stabilité ou la résilience du DNS ?

      L'ICANN estime que cette demande ne pose pas de risques significatifs à la sécurité, la stabilité ou la résilience.

      Il s'agit d'une fonction administrative et organisationnelle qui ne nécessite pas de consultation publique.

    4. Report de la date de suppression du ccTLD .AN (Antilles néerlandaises)

      Attendu que le domaine de premier niveau .AN est en cours de démantèlement suite au remplacement de son extension géographique ISO 3166-1 par les nouveaux codes.

      Attendu que le 11 octobre 2011, le Conseil d'administration a décidé que le domaine .AN devrait être retiré au plus tard le 31 octobre 2014.

      Attendu que l'opérateur du domaine .AN et le ministère des Affaires étrangères néerlandais ont sollicité un report de neuf mois de la date limite afin de fournir aux derniers titulaires de nom de domaine une occasion supplémentaire d'achever leur transition visant à abandonner le domaine .AN.

      Résolu (2014.10.16.06), la date limite pour la suppression de la zone racine du DNS du domaine .AN est prolongée jusqu'au 31 juillet 2015.

      Fondements de la résolution 2014.10.16.06

      Pourquoi le Conseil d'administration aborde-t-il cette question maintenant ?

      Le domaine de premier niveau .AN doit être retiré de la zone racine du DNS au plus tard le 31 octobre 2014. L'opérateur du domaine .AN et le ministère des Affaires étrangères néerlandais ont sollicité un report de la date de suppression.

      Quelle est la proposition à l'étude ?

      La demande consiste à reporter la date de suppression du domaine de premier niveau .AN au 31 juillet 2015.

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

      L'opérateur du domaine .AN a fait savoir que bien que la majorité des titulaires de nom de domaine aient migré vers les nouveaux domaines, il reste une minorité d'environ 30 titulaires de nom de domaine qui ont besoin de davantage de temps afin d'achever leur transition. L'opérateur craint que la date limite actuelle ne puisse être respectée par les derniers titulaires de nom de domaine.

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

      L'approbation de la demande de report permet au personnel de l'ICANN de collaborer avec l'opérateur actuel afin d'achever la suppression du domaine .AN. Cela montre la rapidité avec laquelle le département des fonctions IANA remplit ses obligations tout en travaillant avec la communauté afin de prendre en compte ses besoins le cas échéant.

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

      La gestion des délégations des extensions géographiques dans la zone racine du DNS fait partie des fonctions IANA, et le report de la date de suppression ne devrait pas produire de variation significative des dépenses prévues. Ce n'est pas le rôle de l'ICANN d'évaluer l'impact financier des opérations internes des domaines de premier niveau géographiques au sein d'un pays.

      Y a-t-il des implications sur la sécurité, la stabilité ou la résilience du DNS ?

      L'acceptation de la demande de report de la date de suppression contribue au maintien de la sécurité et la stabilité du nom de domaine .AN, l'ICANN travaillant parallèlement avec l'opérateur afin de supprimer le nom de domaine de la zone racine du DNS.

      Il s'agit d'une fonction administrative et organisationnelle qui ne nécessite pas de consultation publique.

    5. Modifications de la charte du groupe des représentants des bureaux d'enregistrement

      Attendu que le groupe des représentants des bureaux d'enregistrement (RrSG) de la GNSO a proposé une série de modifications de sa charte constitutive.

      Attendu que le RrSG, le personnel de l'ICANN et le comité des améliorations structurelles (SIC) ont satisfait à l'ensemble des exigences liées au processus de modification des chartes du groupe des représentants et des unités constitutives de la GNSO du Conseil d'administration.

      Résolu (2014.10.16.07), le Conseil d'administration de l'ICANN approuve les modifications de la charte du groupe des représentants des bureaux d'enregistrement, et enjoint au personnel de consulter le nouveau document constitutif sur les pages Web du groupe y afférentes.

      Fondements de la résolution 2014.10.16.07

      Les statuts de l'ICANN (article 5.3 du chapitre X) prévoient que « chaque groupe de représentants sera reconnu par le Conseil d'administration de l'ICANN ». L'interprétation faite par le Conseil d'administration de cette disposition est la suivante : le Conseil d'administration de l'ICANN est tenu d'approuver formellement toutes modifications des documents constitutifs des groupes de représentants (GS) et/ou des unités constitutives de l'organisation de soutien aux extensions génériques (GNSO).

      En septembre 2013, le Conseil d'administration a mis au point un processus de modification des chartes du groupe des représentants et des unités constitutives de la GNSO (le « processus ») afin de fournir une méthodologie simplifiée à des fins de respect des exigences des statuts.

      Le groupe des représentants des bureaux d'enregistrement (RrSG), le personnel de l'ICANN et le comité des améliorations structurelles (SIC) ont suivi toutes les étapes identifiées dans le processus, et ont notamment précisé que les propositions de modifications de la charte n'auront aucun impact financier ou en termes de responsabilité sur l'ICANN et publié les modifications à des fins d'examen et de consultation de la communauté (aucune objection n'a été émise).

      Cette décision n'est censée avoir aucun impact sur la sécurité, la stabilité et la résilience du système des noms de domaine.

    6. Remerciements aux membres de la communauté

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

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

      Attendu que le mandat des membres suivants de la communauté At-Large arrive à son terme :

      • Rinalia Abdul Rahim – Président du groupe de travail At-Large sur les IDN
      • Fouad Bajwa – Vice-président de l'APRALO
      • Olivier Crépin-Leblond – Président de l'ALAC
      • Alan Greenberg –
      • Philip Johnson – Secrétariat de l'AFRALO
      • Evan Leibovitch – Vice-président de l'ALAC (NARALO)
      • Glenn McKnight – Secrétariat de la NARALO
      • Jean-Jacques Subrenat – Membre de l'ALAC (EURALO, membre du comité de nomination)
      • Dev Anand Teelucksingh – Membre de l'ALAC (LACRALO)

      Résolu (2014.10.16.08), Rinalia Abdul Rahim, Fouad Bajwa, Olivier Crépin-Leblond, Alan Greenberg, Philip Johnson, Evan Leibovitch, Glenn McKnight, Jean-Jacques Subrenat et Dev Anand Teelucksingh ont gagné la profonde appréciation du Conseil d'administration pendant la durée de leur service et le Conseil d'administration leur souhaite beaucoup de succès dans leurs projets à venir au sein de la communauté de l'ICANN ou autres.

      Attendu que le mandat du membre suivant du comité consultatif (AC) de l'organisation de soutien à l'adressage (ASO) arrive à son terme :

      • Naresh Ajawani – Membre de l'AC de l'ASO

      Résolu (2014.10.16.09), Naresh Ajawani a gagné la profonde appréciation du Conseil d'administration pendant la durée de son service et le Conseil d'administration lui souhaite beaucoup de succès dans ses projets à venir au sein de la communauté de l'ICANN ou autres.

      Attendu que le mandat des membres suivants du conseil de l'organisation de soutien aux extensions géographiques (ccNSO) arrive à son terme :

      • Keith Davidson – Président du groupe de travail sur le cadre d'interprétation
      • Hong Xue – Conseiller de la ccNSO

      Résolu (2014.10.16.10), Keith Davidson et Hong Xue ont gagné la profonde appréciation du Conseil d'administration pendant la durée de leur service et le Conseil d'administration leur souhaite beaucoup de succès dans leurs projets à venir au sein de la communauté de l'ICANN ou autres.

      Attendu que le mandat des membres suivants de l'organisation de soutien aux extensions génériques (GNSO) arrive à son terme :

      • John Berard – Conseiller de la GNSO (unité constitutive des représentants des entités commerciales)
      • Ching Chiao – Conseiller de la GNSO (groupe des représentants des opérateurs de registres)
      • Jeffrey Eckhaus – Vice-président du groupe des représentants des bureaux d'enregistrement
      • Maria Farrell – Conseiller de la GNSO (unité constitutive des représentants des entités non commerciales)
      • Magaly Pazello – Conseiller de la GNSO (unité constitutive des représentants des entités non commerciales)
      • Petter Rindforth – Conseiller de la GNSO (unité constitutive des représentants de la propriété intellectuelle)
      • Klaus Stoll – Conseiller de la GNSO (unité constitutive à but non lucratif responsable des questions opérationnelles)
      • Jennifer Wolfe – Conseiller de la GNSO (membre du comité de nomination)

      Résolu (2014.10.16.11), John Berard, Ching Chiao, Jeffrey Eckhaus, Maria Farrell, Magaly Pazello, Petter Rindforth, Klaus Stoll et Jennifer Wolfe ont gagné la profonde appréciation du Conseil d'administration pendant la durée de leur service et le Conseil d'administration leur souhaite beaucoup de succès dans leurs projets à venir au sein de la communauté de l'ICANN ou autres.

      Attendu que le mandat des membres suivants du comité de nomination (NomCom) arrive à son terme :

      • Ron Andruff – Délégué de l'unité constitutive des représentants des entités commerciales
      • Veronica Cretu – Délégué du comité consultatif At-Large
      • William Manning – Délégué du RSSAC
      • John McElwaine – Délégué de l'unité constitutive des représentants de la propriété intellectuelle
      • Russ Mundy – Délégué de l'IAB auprès de l'IETF
      • Vanda Scartezini – Délégué du comité consultatif At-Large

      Résolu (2014.10.16.12), Ron Andruff, Veronica Cretu, William Manning, John McElwaine, Russ Mundy et Vanda Scartezini ont gagné la profonde appréciation du Conseil d'administration pendant la durée de leur service et le Conseil d'administration leur souhaite beaucoup de succès dans leurs projets à venir au sein de la communauté de l'ICANN ou autres.

    7. Remerciements aux sponsors de la 51e réunion de l'ICANN

      Le Conseil d'administration tient à remercier les sponsors suivants :  Verisign, Inc., Public Interest Registry, Afilias Limited, PDR Solutions FZC, Community.Asia, Neustar, Freenom, China Internet Network Information Center, .GLOBAL, .CLUB Domains, CentralNic, Brandma.Co, NCC Group, Trademark Clearinghouse, Hu Yi Global Information Resources (Holding) Company, HongKong Limited, Uniregistry Corp., ZA Central Registry, Minds + Machines Group, Iron Mountain, Inc., INOC, Radix FZC et ICANNWIKI.

    8. Remerciements aux interprètes, au personnel, aux équipes de l'hôtel et aux personnes chargées de l'organisation de la 51e réunion de l'ICANN

      Le Conseil d'administration exprime sa gratitude aux scribes, aux interprètes, à l'équipe audiovisuelle, 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 d'administration souhaite également remercier la direction et le personnel du Grand Hyatt Century Plaza Hotel pour avoir mis à disposition ces merveilleuses installations pour la tenue de l'événement. Un grand merci également à Kim Aragon, directeur adjoint de la planification des événements et Susie Schultz, responsable des ventes à l'international.

  2. Ordre du jour principal :

    1. Remerciements au comité de nomination 2014

      Attendu que l'ICANN a nommé Cheryl Langdon-Orr directrice du comité de nomination 2014, Stéphane Van Gelder président-élu du comité de nomination 2014, et Yrjö Länsipuro président adjoint.

      Attendu que le comité de nomination 2014 était composé de délégués de chacun des organes consultatifs et unités constitutives de l'ICANN.

      Résolu (2014.10.16.13), le Conseil d'administration de l'ICANN exprime sa plus profonde reconnaissance à Cheryl Langdon-Orr, Stéphane Van Gelder, Yrjö Lansipuro et à l'ensemble des membres du comité de nomination 2014 (dont Ron Andruff, Satish Babu, John Berryhill, Alain Bidron, Don Blumenthal, Veronica Cretu, Sarah B. Deutsch, Robert Guerra, Hans Petter Holen, Louis Houle, Juhani Juselius, Brenden Kuerbis, Bill Manning, John McElwaine, Russ Mundy, Vanda Scartezini et Fatimata Seye Sylla) pour leur dévouement, leur travail ardu et leurs efforts couronnés de succès.

    2. Introduction de noms de domaine à deux caractères dans l'espace des noms des nouveaux gTLD

      Attendu que le 4 décembre 2006, le panel d'évaluation technique des services de registre (RSTEP) a indiqué que la proposition visant à autoriser l'inclusion des noms de domaine de second niveau à deux caractères (SLD) dans le gTLD .name ne risquait pas de nuire considérablement à la sécurité ou à la stabilité.

      Attendu que l'article 2 de la spécification 5 du contrat de registre des nouveaux gTLD prévoit que les étiquettes à deux caractères « seront exclues de l'enregistrement ou attribuées à l'opérateur de registre de deuxième niveau. Ces étiquettes ne peuvent pas être activées dans le DNS, et ne peuvent pas être mises à disposition à des fins d'enregistrement à toute personne ou entité autre que l'opérateur de registre, à condition que ces chaînes d'étiquettes à deux caractères puissent être mises à disposition dans la mesure où l'opérateur de registre parvient à un accord avec le gouvernement concerné et avec le gestionnaire d'extensions géographiques de la chaîne comme indiqué dans la norme ISO 3166-1 alpha-2. L'opérateur de registre peut également proposer la mise à disposition de ces réservations en fonction de la mise en œuvre de mesures visant à éviter la confusion avec les extensions géographiques correspondantes, sous réserve de leur approbation par l'ICANN. »

      Attendu que le 18 janvier 2014, les opérateurs de registre représentant 207 nouveaux gTLD ont présenté des demandes au titre de la politique d'évaluation des services de registre (RSEP) pour la mise en œuvre d'un nouveau service de registre consistant en la mise à disposition de différents ensembles d'étiquettes à deux caractères.

      Attendu que pour chaque demande au titre de la RSEP, l'ICANN a dans un premier temps indiqué que la concurrence, la stabilité ou la sécurité (selon la définition de ces termes prévue par la RSEP) ne risquaient pas d'être affectées par ces services de registre proposés.

      Attendu que le comité consultatif gouvernemental (GAC) a souligné que certains de ses membres ont fait part de leurs inquiétudes quant à la mise à disposition de noms de domaine à deux caractères qui consistent en des combinaisons lettre/lettre, et que le GAC souhaite par conséquent examiner cette question lors de la 51e réunion de l'ICANN à Los Angeles.

      Attendu que, dans son communiqué de Los Angeles [PDF, 127 KB] (15 octobre 2014), le GAC a noté qu'il n'était « pas en position de dégager un avis consensuel eu égard à l'utilisation de noms de domaine de second niveau à deux caractères dans les opérations des nouveaux gTLD, y compris ces combinaisons de lettres qui figurent également dans la liste ISO 3166-1 alpha 2. » Le GAC a également noté que, « suite à l'examen de ces demandes au titre de la RSEP, et conformément au guide de candidature, le GAC estime que la période de consultation publique constitue un important mécanisme de transparence, et demande en outre à l'ICANN d'alerter les gouvernements concernés en cas de présentation de ces demandes. »

      Résolu (2014.10.16.14), la stabilité ou la sécurité ne risquent pas d'être affectées par le service de registre proposé pour la mise à disposition de domaines à deux caractères dans l'espace des noms des nouveaux gTLD, et le Conseil d'administration autorise le président-directeur général, ou son ou ses représentants, à développer et mettre en œuvre une procédure efficace pour la mise à disposition de domaines à deux caractères qui, à l'heure actuelle, sont réservés en vertu du contrat de registre des nouveaux gTLD, en prenant en compte l'avis du GAC indiqué dans le communiqué de Los Angeles.

      Fondements de la résolution 2014.10.16.14

      Pourquoi le Conseil d'administration aborde-t-il cette question ?

      L'article 2 de la spécification 5 (Programme des noms réservés) du contrat de registre des nouveaux gTLD aborde la question des réservations d'étiquettes à deux caractères de la façon suivante :

      Toutes les étiquettes ASCII à deux caractères seront exclues de l'enregistrement ou attribuées à l'opérateur de registre de deuxième niveau dans le TLD. Ces étiquettes ne peuvent pas être activées dans le DNS, et ne peuvent pas être mises à disposition à des fins d'enregistrement à toute personne ou entité autre que l'opérateur de registre, à condition que ces chaînes d'étiquettes à deux caractères puissent être mises à disposition dans la mesure où l'opérateur de registre parvient à un accord avec le gouvernement concerné et avec le gestionnaire d'extensions géographiques de la chaîne comme indiqué dans la norme ISO 3166-1 alpha-2. L'opérateur de registre peut également proposer la mise à disposition de ces réservations en fonction de la mise en œuvre de mesures visant à éviter la confusion avec les extensions géographiques correspondantes, sous réserve de leur approbation par l'ICANN.

      En janvier 2014, les opérateurs de registre de nouveaux gTLD ont commencé à présenté des demandes à l'ICANN au titre du processus de politique d'évaluation des services de registre (RSEP) proposant de mettre en œuvre un nouveau service de registre afin de mettre à disposition certains noms de domaine à deux caractères qui sont réservés en vertu du contrat de registre des nouveaux gTLD. La mise en œuvre des propositions impliquera de modifier l'annexe A des contrats de registre respectifs. Les modifications proposées afin de mettre en œuvre le nouveau service de registre ont été soumises à consultation publique au cours des derniers mois. En tout, l'ICANN a publié 28 propositions et modifications de RSEP concernant un total de 203 nouveaux gTLD. L'ICANN continue de recevoir chaque semaine de nouvelles demandes au titre de la RSEP pour le même service de registre.

      Conformément à l'article 2.4.D de la RSEP et aux notes de mise en œuvre de la RSEP, si la mise en œuvre d'un service proposé implique une modification substantielle du contrat de registre, le Conseil d'administration de l'ICANN devra mener une évaluation préliminaire.

      Quelle est la proposition à l'étude ?

      Le Conseil d'administration prend actuellement des mesures afin d'enjoindre au président-directeur général de développer et mettre en œuvre un processus efficace pour la mise à disposition de noms à deux caractères dans les nouveaux gTLD, en prenant en compte l'avis du GAC indiqué dans le communiqué de Los Angeles.

      Quelles parties intéressées ou autres ont été consultées ?

      Au 24 septembre 2014, le personnel de l'ICANN avait mis en place cinq (5) forums de commentaires publics afin d'obtenir l'avis de la communauté sur les modifications visant à mettre en œuvre le nouveau service de registre proposé : le 12 juin 2014 <https://www.icann.org/public-comments/two-char-new-gtld-2014-06-12-en> ; le 8 juillet 2014 <https://www.icann.org/public-comments/two-char-new-gtld-2014-07-08-en> ; le 23 juillet 2014 <https://www.icann.org/public-comments/two-char-new-gtld-2014-07-23-en> ; le 19 août 2014 <https://www.icann.org/public-comments/two-char-new-gtld-2014-08-19-en> ; et le 12 septembre 2014 <https://www.icann.org/public-comments/two-char-new-gtld-2014-09-12-en>. Différents membres de la communauté ont soumis des commentaires, dont le comité consultatif At-Large (ALAC) et des opérateurs de registre.

      De plus, l'ICANN a alerté le GAC chaque fois qu'une demande d'un opérateur de registre était publiée à des fins de consultation publique.

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

      Plusieurs commentaires reçus lors de la période de consultation publique mettaient en avant une série d'arguments en faveur de, ou contre, la mise à disposition générale de certains noms à deux caractères dans l'espace des noms des nouveaux gTLD. La majorité des commentaires reçus étaient en faveur de la mise à disposition des noms de domaine à deux caractères.

      Les arguments contre la mise à disposition des noms de domaine à deux caractères exprimaient deux principales inquiétudes. La première inquiétude est associée à l'utilisation des noms de domaine à deux caractères et au fait qu'il est généralement admis que cette utilisation crée une confusion dans l'esprit des utilisateurs ou peut conduire à des abus. La seconde inquiétude concerne la façon d'assurer une protection spécifique des ccTLD lorsque de nouveaux noms de pays ou de territoire sont créés.

      Les commentaires publics reçus jusqu'à présent sont largement en faveur de l'introduction de noms de domaine à deux caractères dans l'espace des noms des nouveaux gTLD. Les arguments en faveur de la mise à disposition des noms de domaine à deux caractères étaient les suivants :

      • L'introduction des noms de domaine à deux caractères renforcerait la concurrence étant donné que les restrictions actuelles entravent la concurrence, notamment pour les nouveaux gTLD qui sont en concurrence avec les anciens TLD (délégués avant la série de demandes de nouveaux gTLD de 2012) qui sont eux en mesure de proposer de tels enregistrements. Les restrictions actuelles imposées aux opérateurs de registre des nouveaux gTLD créent une situation de discrimination contraire à l'article 3 du chapitre II des statuts de l'ICANN qui prévoit un traitement non discriminatoire des parties prenantes de l'ICANN.
      • L'introduction des noms de domaine à deux caractères entraîne un risque de confusion limité, voire nul, comme l'a montré l'utilisation antérieure de noms de domaine à deux caractères dans les TLD existants.
      • La mise à disposition de certains types de noms de domaine à deux caractères dans le but d'inclure au moins un chiffre ou nombre ne poserait pas de problème et pourrait être envisagée.
      • La mise à disposition de noms de domaine à deux caractères permettrait à des sociétés et à des marques de disposer de noms de domaine segmentés et personnalisés afin de connecter avec le public, et de fournir des contenus localisés, élargissant ainsi le choix des consommateurs et stimulant la croissance économique, notamment dans les pays en développement.
      • Le service de registre proposé ne va pas à l'encontre des exigences des mécanismes de protection des droits (RPM).
      • Il existe une véritable tradition en matière de mise à disposition de noms de domaine à deux caractères dans l'histoire des demandes au titre de la RSEP.
      • La mise à disposition d'extensions géographiques et de noms est autorisée par le guide de candidature.

      Le GAC a également soulevé certaines inquiétudes concernant la mise à disposition de certains noms de domaine à deux caractères (à savoir les combinaisons lettre/lettre). Dans son communiqué de Singapour du 27 mars 2014, le GAC a examiné la proposition du groupe des registres de marque de processus simplifié sous forme d'addenda au contrat de registre pour l'approbation de noms de pays et de codes de second niveau à deux lettres et caractères. Le GAC a déclaré ce qui suit : « Bien que le GAC n'ait pas de craintes majeures quant au fait que les propriétaires de marques demandent l'approbation de tels noms, cette approbation devrait toutefois être effectuée directement avec les pays concernés plutôt que via un processus opérationnel au niveau du GAC. » Le GAC a indiqué que les membres individuels du GAC pourraient apporter leur soutien aux propositions associées à leur pays respectif, si demande en est faite. Le GAC a suggéré d'envisager de mettre en place un registre de pays pour lesquels il ne serait pas nécessaire de présenter des demandes individuels.

      Par la suite, dans son communiqué de Los Angeles, le GAC a noté qu'il n'était « pas en position de dégager un avis consensuel eu égard à l'utilisation de noms de domaine de second niveau à deux caractères dans les opérations des nouveaux gTLD, y compris ces combinaisons de lettres qui figurent également dans la liste ISO 3166-1 alpha 2. » Le GAC a également noté que, « suite à l'examen de ces demandes au titre de la RSEP, et conformément au guide de candidature, le GAC estime que la période de consultation publique constitue un important mécanisme de transparence, et demande en outre à l'ICANN d'alerter les gouvernements concernés en cas de présentation de ces demandes. » La décision prise aujourd'hui par le Conseil d'administration prend en considération les conclusions du GAC concernant la mise à disposition de domaines à deux caractères.

      Quels sont les documents importants examinés par le Conseil d'administration ? Quels sont les facteurs que le Conseil d'administration a jugés significatifs ?

      Le Conseil d'administration a examiné différents supports et a également considéré plusieurs facteurs significatifs lors de ses délibérations relatives à l'approbation ou non de la demande. Les supports et facteurs significatifs que le Conseil d'administration a examinés dans le cadre de ses délibérations comprenaient, sans s'y limiter, ce qui suit :

      Cela a-t-il des effets positifs ou négatifs pour la communauté ? Y a-t-il un impact fiscal ou des répercussions à prévoir sur l'ICANN (plan stratégique, plan opérationnel, budget), sur la communauté et/ou sur le public ? Y a-t-il des implications sur la sécurité, la stabilité ou la résilience du DNS ?

      L'impact global sur la communauté devrait être positif dans la mesure où de nouvelles possibilités de diversification et de concurrence au sein de l'espace des noms des gTLD sont proposées, et alors qu'aucun risque de confusion dans l'esprit des utilisateurs n'a été identifié.

      La mise en œuvre définitive de ce service de registre pourrait avoir un impact financier sur l'ICANN, la communauté ou le public, étant donné que des coûts supplémentaires liés aux implications générales de ce service de registre sont à prévoir.

      Tel qu'indiqué par le panel d'évaluation technique des services de registre de l'ICANN dans un rapport du 4 décembre 2006 sur la proposition de mise à disposition de domaines à deux caractères dans le gTLD .name, la stabilité ou la sécurité ne risquent pas d'être affectées par un tel service.

      S'agit-il d'un processus de développement de politiques défini au sein des organisations de soutien de l'ICANN ou bien d'une fonction organisationnelle et administrative de l'ICANN nécessitant une consultation publique ou ne nécessitant pas de consultation publique ?

      La politique d'évaluation des services de registre constitue une politique de consensus de l'ICANN en vigueur depuis le 15 août 2006. Conformément à la politique, l'ICANN a publié les modifications du contrat de registre à des fins de consultation publique étant donné que la mise en œuvre du service proposé imposait ce qui était alors perçu comme une modification substantielle du contrat de registre. Suite à la résolution adoptée aujourd'hui, les propositions futures de RSEP exigeant la mise à disposition de noms à deux caractères composés de combinaisons lettre/nombre ou nombre/nombre ne seront plus considérées comme exigeant une modification substantielle du contrat de registre.

    3. Plan stratégique de l'ICANN pour les exercices 2016-2020

      Attendu que le plan stratégique de l'ICANN pour les exercices 2016–2020 est le résultat d'un long processus collaboratif, ascendant, multipartite et multilingue qui a débuté en ligne en avril 2013 et lors de la réunion de l'ICANN à Pékin (et est détaillé en ligne).

      Attendu que le Plan stratégique fournit une nouvelle vision de l'ICANN, réitère la mission actuelle de l'ICANN, et décrit cinq objectifs stratégiques, chacun étant accompagné de buts stratégiques, de facteurs clés de succès et de risques stratégiques.

      Attendu qu'afin de compléter le plan stratégique, un plan opérationnel sur cinq ans fournit, pour chaque objectif et but stratégique, des portefeuilles d'activités de l'ICANN, des facteurs opérationnels clés de succès, des risques opérationnels, des indicateurs clés de performance, des dépendances clés, et des échéances sur cinq ans (au niveau des buts), et que ces plans serviront conjointement de fondation aux plans et budgets opérationnels annuels.

      Résolu (2014.10.16.15), le plan stratégique de l'ICANN pour les exercices 2016-2020 est adopté, et le président-directeur général de l'ICANN enjoint de prendre les mesures nécessaires à la publication et à l'exécution du plan.

      Fondements de la résolution 2014.10.16.15

      TLe plan stratégique précise la vision de l'ICANN, réaffirme la mission de l'ICANN et énonce cinq objectifs stratégiques, chacun étant accompagné de buts stratégiques, de facteurs clés de succès (résultats) et de risques stratégiques. Il servira de guide aux activités de l'ICANN pour les exercices 2016-2020 et orientera les plans et budgets opérationnels de l'ICANN.

      Afin d'informer davantage le public et de renforcer la responsabilité et la transparence de l'ICANN, des mesures (indicateurs clés de performance) et des échéances ambitieuses sur cinq ans ont été développées dans un plan opérationnel sur cinq ans qui vient compléter le plan stratégique. Véritable nouveauté du processus de planification de l'ICANN, le plan opérationnel sur cinq ans détaille, pour chaque objectif et but stratégique, les portefeuilles des activités de l'ICANN, les facteurs opérationnels clés de succès (résultats), les risques, les indicateurs clés de performance (mesures), les dépendances clés, et les échéances sur cinq ans (au niveau des buts).

      En commençant par l'exercice 2016, le plan stratégique ainsi que le plan opérationnel sur cinq ans, orienteront les plans et budgets opérationnels annuels. Les plans et budgets opérationnels annuels indiqueront les exigences des stratégies en termes de ressources, l'impact sur la sécurité, la stabilité et la résilience du DNS, et toutes mesures nécessaires d'atténuation des risques.

      L'évolution des travaux, la réalisation des objectifs et l'efficacité des stratégies seront gérées et rapportées à travers les systèmes de gestion de l'ICANN, notamment grâce à un ensemble de facteurs clés de succès et d'indicateurs clés de performance. Ceux-ci serviront de fondement à un contrôle de planification annuel afin de confirmer que l'organisation est sur la bonne voie, ou de souligner que des ajustements sont nécessaires.

      Le plan stratégique de l'ICANN est le résultat d'un long processus collaboratif, ascendant, multipartite et multilingue qui a débuté en ligne en avril 2013 et lors de la réunion de l'ICANN à Pékin. L'ICANN a dans une large mesure sollicité l'avis du public sur ses principaux défis et opportunités et sur les domaines stratégiques soulevés par le Conseil d'administration de l'ICANN. Les commentaires publics et les discussions engagées au sein de la communauté (détaillés ici) impliquant les organisations de soutien, les groupes de représentants, les unités constitutives et les comités consultatifs ont eu une influence sur l'ensemble des aspects du plan stratégique. Les réponses à tous les commentaires publics reçus eu égard aux projets de plan stratégique sont disponibles ici [PDF, 808 KB] et ici [PDF, 414 KB]. Le plan stratégique reflète également les travaux et commentaires relatifs aux initiatives associées telles que le cadre de la sécurité, la stabilité et la résilience, les stratégies de participation régionale et les thèmes stratégiques du panel de stratégie.

    4. Examen par le Conseil d'administration des recommandations issues du groupe de travail intercommunautaire chargé de renforcer la responsabilité de l'ICANN

      Attendu que le Conseil d'administration reconnaît que la communauté veille activement à ce que soit réuni un groupe de travail intercommunautaire chargé de renforcer la responsabilité de l'ICANN.

      Attendu que les commentaires de la communauté eu égard à l'évolution du processus de renforcement de la responsabilité de l'ICANN ont été d'une valeur inestimable et que le Conseil d'administration attend avec impatience de recevoir les recommandations qui bénéficient d'un large soutien et consensus au niveau de la communauté.

      Attendu que le Conseil d'administration a conscience que des questions restent en suspens concernant la façon dont il prendra en compte les recommandations issues du groupe de travail intercommunautaire chargé de renforcer la responsabilité de l'ICANN.

      Résolu (2014.10.16.17), le Conseil d'administration s'engage à respecter les principes suivants lors de l'examen des recommandations du groupe de travail intercommunautaire chargé de renforcer la responsabilité et la gouvernance de l'ICANN :

      1. Ces principes s'appliquent aux recommandations consensuelles issues du groupe de travail intercommunautaire chargé de renforcer la responsabilité et la gouvernance de l'ICANN.
      2. Si le Conseil d'administration estime qu'il n'est pas dans l'intérêt général de mettre en œuvre une recommandation issue du groupe de travail intercommunautaire chargé de renforcer la responsabilité et la gouvernance de l'ICANN (recommandation du CCWG), il doit engager un dialogue avec le CCWG. La décision en vertu de laquelle il n'est pas dans l'intérêt général de mettre en œuvre une recommandation du CCWG doit être prise suite à un vote à la majorité des deux tiers du Conseil d'administration.
      3. Le Conseil d'administration doit fournir un exposé détaillé des fondements justifiant l'engagement d'un dialogue. Le Conseil d'administration devra convenir avec le CCWG du mode de dialogue (par exemple téléconférence, e-mail ou autre). Les discussions seront tenues de bonne foi, dans les plus brefs délais et de manière efficace afin de trouver une solution mutuellement acceptable.
      4. Le CCWG sera en mesure de répondre aux inquiétudes du Conseil d'administration et de lui rapporter les autres délibérations relatives à ces inquiétudes. Le CCWG débattra des inquiétudes du Conseil d'administration dans un délai de 30 jours à compter de l'engagement d'un dialogue par le Conseil d'administration.
      5. Si le CCWG modifie une recommandation, elle sera renvoyée au Conseil d'administration à des fins de nouvel examen. Le CCWG doit fournir un exposé détaillé sur la façon dont la modification prend en compte les inquiétudes émises par le Conseil d'administration.
      6. Si, après modification, le Conseil d'administration estime qu'il n'est toujours pas dans l'intérêt général de mettre en œuvre la recommandation du CCWG, le Conseil d'administration peut renvoyer son avis au CCWG à des fins de nouvel examen ; là encore, un vote à la majorité des deux tiers est nécessaire afin de prendre une décision. Un exposé détaillé des fondements justifiant la décision du Conseil d'administration est de nouveau requis. Dans l'hypothèse où le Conseil d'administration déciderait de ne pas accepter une modification, le Conseil d'administration ne sera alors pas en droit de proposer une solution à la question sur laquelle porte la recommandation avant que le CCWG et le Conseil d'administration n'arrivent à un accord.

      Fondements de la résolution 2014.10.16.16

      En réponse à l'appel de la communauté à un examen de la responsabilité de l'ICANN à la lumière de la modification de la relation historique avec le gouvernement américain, l'ICANN a accepté d'aller de l'avant via l'élaboration d'un processus de renforcement de la responsabilité de l'ICANN. Maintenant qu'il a été convenu que le processus prendra la forme d'un groupe de travail intercommunautaire, la communauté a exigé une réponse définitive quant à la façon dont le Conseil d'administration assurera le traitement des recommandations issues du groupe de travail intercommunautaire, notamment concernant la capacité du Conseil d'administration à modifier ou rejeter les recommandations avec lesquelles il n'est pas d'accord. Suite à l'adoption par la communauté d'un modèle de groupe de travail intercommunautaire comprenant un agent de liaison, le Conseil d'administration souhaite poursuivre le dialogue tout au long du processus avec l'ensemble des participants afin de dégager des recommandations et d'arriver à un consensus global sur lequel reposera chacune de ces recommandations.

      Le Conseil d'administration a entendu les inquiétudes de la communauté et énonce ces principes visant à guider la façon dont le Conseil d'administration examinera les recommandations consensuelles issues du groupe de travail intercommunautaire chargé de renforcer la responsabilité de l'ICANN. Ils s'inspirent des exigences des processus de développement de politiques de la GNSO et la ccNSO, afin de reconnaître l'ensemble des contributions à la mission de responsabilité.

      L'adoption de ces principes n'a ni d'impact financier ni d'impact au niveau des ressources sur l'ICANN qui puissent être présentement identifiés. Cette décision n'est censée avoir aucun impact sur la sécurité, la stabilité et la résilience du système des noms de domaine.

      Il s'agit d'une fonction administrative et organisationnelle pour laquelle des commentaires publics ont déjà été reçus.

    5. Un grand merci à Olga Madruga-Forti pour ses services prêtés dans le cadre du Conseil d'administration de l'ICANN

      Attendu qu'Olga Madruga-Forti a été nommée membre du Conseil d'administration de l'ICANN par le comité de nomination le 18 octobre 2012.

      Attendu que le mandat d'Olga au sein du Conseil d'administration de l'ICANN est arrivé à son terme le 16 octobre 2014.

      Attendu qu'Olga a été membre des comités suivants :

      • Comité d'audit
      • Comité des relations mondiales
      • Comité de gouvernance
      • Comité du programme des nouveaux gTLD

      Résolu (2014.10.16.17), Olga Madruga-Forti a gagné la profonde appréciation du Conseil d'administration pendant la durée de son service et le Conseil d'administration lui souhaite beaucoup de succès dans ses projets à venir au sein de la communauté de l'ICANN ou autres.

    6. Un grand merci à Sébastien Bachollet pour ses services prêtés dans le cadre du Conseil d'administration de l'ICANN

      Attendu que Sébastien Bachollet a été nommé membre du Conseil d'administration de l'ICANN par la communauté At-Large le 9 décembre 2010.

      Attendu que le mandat de Sébastien au sein du Conseil d'administration de l'ICANN est arrivé à son terme le 16 octobre 2014.

      Attendu que Sébastien a été membre des comités et groupes de travail suivants :

      • Comité des finances
      • Comité des améliorations structurelles
      • Comité de la participation du public et des parties prenantes
      • Groupe de travail sur la stratégie des réunions

      Résolu (2014.10.16.18), Sébastien Bachollet a gagné la profonde appréciation du Conseil d'administration pendant la durée de son service et le Conseil d'administration lui souhaite beaucoup de succès dans ses projets à venir au sein de la communauté de l'ICANN ou autres.

    7. Un grand merci à Bill Graham pour ses services prêtés dans le cadre du Conseil d'administration de l'ICANN

      Attendu que Bill Graham a été nommé membre du Conseil d'administration de l'ICANN par l'organisation de soutien aux extensions génériques le 23 juin 2011.

      Attendu que le mandat de Bill au sein du Conseil d'administration de l'ICANN est arrivé à son terme le 16 octobre 2014.

      Attendu que Bill a été membre des comités et groupes de travail suivants :

      • Comité d'audit
      • Comité des relations mondiales
      • Comité de gouvernance
      • Comité IANA
      • Comité du programme des nouveaux gTLD
      • Comité des risques
      • Comité des améliorations structurelles
      • Groupe de travail mixte Conseil d'administration-GAC pour la mise en œuvre des recommandations

      Résolu (2014.10.16.19), Bill Graham a gagné la profonde appréciation du Conseil d'administration pendant la durée de son service et le Conseil d'administration lui souhaite beaucoup de succès dans ses projets à venir au sein de la communauté de l'ICANN ou autres.

    8. Un grand merci à Heather Dryden pour ses services prêtés dans le cadre du Conseil d'administration de l'ICANN

      Attendu que Heather Dryden a été nommée agent de liaison du GAC auprès du Conseil d'administration de l'ICANN le 25 juin 2010.

      Attendu que le mandat de Heather au sein du Conseil d'administration de l'ICANN est arrivé à son terme le 16 octobre 2014.

      Attendu que Heather a été agent de liaison des comités suivants :

      • Comité du programme des nouveaux gTLD

      Résolu (2014.10.16.20), Heather Dryden a gagné la profonde appréciation du Conseil d'administration pendant la durée de son service et le Conseil d'administration lui souhaite beaucoup de succès dans ses projets à venir au sein de la communauté de l'ICANN ou autres.

resolutions-16oct14-fr.pdf  [457 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."