Compte-rendu | Réunion extraordinaire du Conseil d'administration de l'ICANN 25 janvier 2011

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/minutes/minutes-25jan11-en.htm

Une réunion extraordinaire du Conseil d'administration de l'ICANN a eu lieu par téléconférence le 25 Janvier 2011 à 20:00 UTC.

Peter Dengate Trush a rapidement rappelé la séance à l'ordre.

Outre le président Peter Dengate Thrush les administrateurs suivants ont participé à toute ou partie de la réunion: Rod Beckstrom (président et PDG), Steve Crocker (vice-président), Sébastien Bachollet, Cherine Chalaby, Bertrand de La Chapelle, Rita Rodin Johnston, Erika Mann, Gonzalo Navarro, Raymond A. Plzak, Rajasekhar Ramaraj, George Sadowsky, Mike Silber, Bruce Tonkin, Katim Touray et Kuo-Wu Wei.

Les Liaisons du Conseil suivants ont participé à toute ou partie de la réunion:  Heather Dryden, GAC Liaison; Ram Mohan, SSAC Liaison; Thomas Narten, IETF Liaison; et Suzanne Woolf, RSSAC Liaison.

Reinhard Scholl, TLG Liaison, s'est excusé.

En outre, la suivante direction et le personnel de l'ICANN a participé à toute ou partie de la réunion: John Jeffrey, conseiller général et secrétaire; Akram Atallah, chef de l'exploitation; Kurt Pritz, vice-président; Diane Schroeder, Directeur du Soutien du Conseil; et Amy Stathos, conseiller général adjoint.

 

1. Session exécutive

   Le Conseil a procédé à une séance à huis clos, en toute confiance. Aucune mesure n'a été prise au cours de la séance à huis clos.

2. Ordre du jour convenu

   Le président du Conseil a présenté la conception de l'ordre du jour pour les nouveaux membres du Conseil et a remarqué que tout membre du Conseil peut demander le retrait des articles de l'ordre du jour convenu.  Le Conseil a demandé trois éléments qui doivent être transportés à l'ordre du jour principal, l'approbation des propositions d'amendement des règlements concernant la modification des dates de fin de mandat des membres du CA choisis par les organisations de soutien et At-Large; la demande VeriSign RSEP (pour .NAME) pour la libération des chaînes numériques uniquement et les chaînes numériques avec des traits d'union, et la demande de Telnic conformément à la politique d'évaluation de services de registre (RSEP) pour l'autorisation de chaînes uniquement numériques sauf pour les labels à un seul caractère, qui ont été déplacés vers les premiers éléments sur l'ordre du jour principal.

   Les résolutions suivantes ont été approuvées à l'unanimité 16-0. Les résolutions ont été déplacées ensemble par le président, et George Sadowsky a appuyé la motion.

   IL EST RÉSOLU, d'approuver les résolutions suivantes à cet ordre du jour convenu:

   1. Approbation du compte-rendu de la réunion extraordinaire du CA de l'ICANN du 8 décembre 2010

      Il est résolu (2011.01.25.01), que le CA approuve par la présente le compte-rendu de la réunion extraordinaire du CA du 8 décembre 2010.

   2. Approbation du compte-rendu de la réunion ordinaire du CA de l'ICANN du 10 décembre 2010

      Il est résolu (2011.01.25.02) que le CA approuve par la présente le compte-rendu de la réunion ordinaire du CA de l'ICANN du 10 décembre 2010.

   3. Approbation du compte-rendu de la réunion organisationnelle du CA de l'ICANN du 10 décembre 2010

      Il est résolu (2011.01.25.03) que le CA approuve par la présente le compte-rendu de la réunion organisationnelle du CA de l'ICANN du 10 décembre 2010.

   4. Approbation de la charte révisée du comité des finances

      Attendu que le comité des finances du CA (BFC) fonctionne actuellement conformément à une charte approuvée en l'an 2000 consultable à l'adresse http://www.icann.org/en/committees/finance/.

      Attendu qu'au titre de l'obligation de la part du BFC de réviser ses activités et de formuler des recommandations appropriées en vue de mises à jour ou d'améliorations, le BFC a approuvé le 5 décembre 2010 une charte révisée qui reflète mieux les activités actuelles du BFC.  La charte révisée incorpore aussi, sans changements, le langage standard des chartes de comités du CA tel que précédemment approuvé par le comité de gouvernance du CA. Voir http://www.icann.org/en/minutes/resolutions-06mar09.htm#10.

      Il est résolu (2011.01.25.04), que la charte révisée du comité des finances du CA soit approuvée.

      Justification de la résolution 2011.01.25.04

      L'approbation en ce moment de la charte révisée du comité des finances du CA (BFC) est logique, cette version révisée reflétant mieux les activités actuelles du BFC que la version précédente. Elle est aussi conforme, maintenant, aux révisions récentes de toutes les autres chartes, telles qu'approuvées par le comité de gouvernance du CA. De plus, la charte révisée reflète les activités du BFC dans la mesure où elles se rapportent à la taille et au champ d'activités de l'ICANN en 2011 et que le BFC fonctionne conformément aux meilleures pratiques. Dans l'élaboration de la charte révisée, autant les meilleures pratiques que les activités réelles du BCF de l'ICANN ont été passées en revue et considérées importantes pour approuver la charte révisée.

      L'approbation de la charte révisée du BFC devrait avoir un impact public positif dans la mesure où elle renforce la responsabilité et la transparence de l'organisation et s'aligne sur les activités actuelles du BFC et les meilleures pratiques. La révision de la charte du BFC n'a pas d'impact financier sur l'ICANN ou sur la communauté. La confirmation du mandat du BFC de par la révision de sa charte ne présente aucun impact sur la sécurité, la stabilité et la résilience systémiques du DNS.

   5. De la part du SSAC - nomination du président du SSAC

      Attendu que l'article XI, section 2, sous-section 2 des règlements régit le comité consultatif sur la sécurité et la stabilité (SSAC).

      Attendu que l'article XI, section 2, sous-section 2 des règlements stipule que le CA nomme le président et les membres du SSAC.

      Attendu que le 10 décembre 2010, Steve Crocker a annoncé son intention de démissionner de son poste de président du SSAC à compter de la sélection par le SSAC d'un nouveau président et de sa nomination par le CA.

      Attendu que le 22 décembre 2010, Ray Plzak a démissionné de son poste de vice-président du SSAC.

      Attendu que le SSAC a entamé un processus d'élection de président et de vice-président par les membres du comité, démarrant le 10 décembre 2010 et prenant fin le 7 janvier 2011.

      Attendu que le comité a élu Patrik Fältström pour le poste de président et James Galvin pour le poste de vice-président.

      Il est résolu (2011.01.25.05), que le CA accepte la recommandation du SSAC et nomme Patrik Fältström au poste de président du SSAC et présente ses meilleurs vœux à Patrik Fältström et à James Galvin appelés à remplir ces nouveaux rôles importants.

   6. De la part du SSAC - remerciements au membre sortant du SSAC - Christophe Reverd

      Attendu que Christophe Revers a été nommé au comité consultatif sur la sécurité et la stabilité de l'ICANN le 26 juin 2009.

      Attendu que l'ICANN souhaite remercier Christophe Reverd pour ses services à la communauté de par sa participation au comité consultatif sur la sécurité et la stabilité.

      Il est résolu (2011.01.25.06), que les services de Christophe Reverd à l'ICANN de par sa participation au comité consultatif sur la sécurité et la stabilité lui ont valu l'appréciation profonde du CA et que le CA souhaite à Christophe Reverd beaucoup de succès dans tous ses projets à venir.

   7. De la part du SSAC - remerciements au membre et vice-président sortant du SSAC - Ray Plzak

      Attendu que Ray Plzak a été nommé au comité consultatif sur la sécurité et la stabilité de l'ICANN le 17 mai 2002.

      Attendu que l'ICANN souhaite remercier Ray Plazak pour ses services à la communauté de par sa participation en tant que vice-président et membre au comité consultatif sur la sécurité et la stabilité.

      Il est résolu (2011.01.25.07) que les services de Ray Plzak à l'ICANN de par sa participation en tant que vice-président et membre au comité consultatif sur la sécurité et la stabilité lui ont valu l'appréciation profonde du CA et que le CA souhaite à Ray Plzak beaucoup de succès dans tous ses projets à venir.

   8. De la part du SSAC - remerciements au président sortant du SSAC - Steve Crocker

      Attendu que Dr. Stephen Crocket a été nommé président du comité consultatif sur la sécurité et la stabilité de l'ICANN le 14 mars 2002.

      Attendu que Dr. Croker a rempli ses fonctions de président du SSAC avec la plus grande compétence et le plus grand dévouement.

      Attendu que Dr. Crocker a contribué au fonctionnement du SSAC en matière de structure et de fond, et a guidé le comité à travers des étapes importantes telles que le SiteFinder et l'extensibilité de la racine. 

      Attendu que Dr. Crocker a élargi la composition des membres du SSAC pour inclure des experts en une vaste gamme de sujets, tout en renforçant la diversité géographique du comité et l'étendue du soutien du personnel.

      Attendu que Dr. Crocker a guidé le SSAC à travers sa première révision externe détaillée et a veillé sur la mise en œuvre de toutes les recommandations de manière opportune.

      Attendu que Steve Crocker a transformé le concept du comité consultatif sur la sécurité et la stabilité en excellence dans l'exécution ce qui a résulté en une crédibilité renforcée du comité en particulier et de l'ICANN en général.

      Attendu que le 10 décembre 2010, Dr. Crocker a annoncé son intention de démissionner de son poste de président du SSAC à compter de la sélection par le SSAC d'un nouveau président et de sa nomination par le CA.

      Attendu que le SSAC a entamé un processus d'élection de président et de vice-président par les membres du comité, démarrant le 10 décembre 2010 et prenant fin le 7 janvier 2011.

      Attendu que le comité a élu Patrik Fältström pour le poste de président et James Galvin pour le poste de vice-président.

      Attendu que le 25 janvier 2011, le CA a nommé Patrik Fältström au poste de nouveau président du SSAC.

      Il est résolu (2011.01.25.08), que les services et le dévouement constants de Dr. Crocker en sa qualité de président du comité consultatif sur la sécurité et la stabilité lui ont valu la reconnaissance immense et l'appréciation profonde de l'ICANN et que le CA souhaite beaucoup de succès à Dr. Crocker dans tous ses projets à venir.

   9. Approbation du processus de politique mondiale relative au suivi après l'épuisement d'IPv4

      Attendu que les procédures de révision du CA pour des politiques mondiales relatives aux ressources de numéros Internet transmises pour ratification par le conseil de l'organisation de soutien aux politiques d'adressage (ASO) conformément au protocole d'entente de l'ASO, indiquent que « lorsque, conformément à l'étape 1 du processus mondial d'élaboration de politiques du protocole d'entente de l'ASO (pièce jointe A, article 1), le personnel de l'ICANN chargé de liaison avec la communauté d'adressage prend conscience d'une élaboration de politique mondiale dans le cadre du champ d'application du protocole d'entente de l'ASO, le personnel de l'ICANN informe le Conseil d'administration de l'ICANN de ce fait. Le CA décide, en tant que de besoin, que cette élaboration devrait être suivie par le personnel de l'ICANN et enjoint au PDG de l'ICANN d'affecter du personnel à cette tâche. Le personnel de l'ICANN ainsi affecté informe toutes les organisations de soutien et tous les comités consultatifs de l'ICANN, établit une page Web de l'ICANN devant être constamment mise à jour et rédige un rapport préalable constamment mis à jour se rapportant à cette élaboration de politique mondiale. Ce rapport préalable est fourni au CA à sa demande ».

      Attendu que le personnel de l'ICANN a informé le CA qu'une proposition de politique intitulée « proposition de politique globale pour l'allocation d'IPv4 par l'IANA après l'épuisement » est en cours d'élaboration et que cette proposition est en première phase d'adoption au sein des RIR individuels ainsi que de reconnaissance de la part du conseil d'adressage de l'ASO en tant que proposition de politique mondiale valable.

      Attendu que la proposition est identifiée comme étant une élaboration de politique mondiale dans le cadre du champ d'application du protocole d'entente existant entre l'ICANN et l'ASO.

      Il est résolu (2011.01.25.09), que le CA demande que l'élaboration de la proposition de politique intitulée « proposition de politique mondiale pour l'allocation d'IPv4 par l'IANA après l'épuisement » soit suivie par le personnel de l'ICANN en accord avec les procédures de révision du CA concernant de telles propositions de politiques et enjoigne au PDG de l'ICANN d'affecter du personnel à cette tâche.

      Justification de la résolution 2011.01.25.09

      La proposition de politique mondiale a atteint l'étape de discussion au sein de tous les registres Internet régionaux et il est temps de commencer à rédiger et à publier en ligne des rapports préalables concernant l'état de la proposition. Enjoindre au personnel de réaliser le travail de suivi nécessaire a pour but de servir les obligations de l'ICANN selon le protocole d'entente avec l'ASO et les procédures de révision du CA pour les politiques mondiales relatives aux ressources de numéros Internet.

      Le fait d'enjoindre au personnel de suivre la proposition aura un impact budgétaire minimal, étant donné que du personnel de l'ICANN est déjà affecté à l'ASO et que le suivi de propositions à ce stade nécessite un effort limité de la part du personnel.   Si approuvée, la mise en œuvre future pourrait résulter en des impacts supplémentaires sur le budget, le public et les questions liées à la sécurité/stabilité, mais le moment n'est pas encore le bon pour évaluer ce qui précède. Demander un suivi de la part du personnel à ce stade permettra aussi de progresser dans la préparation préalable d'une demande de l'ASO pour la ratification.

   10. Approbation du plan de mise en œuvre de la révision du RSSAC

       Attendu que le 5 août 2010, le CA a résolu de recevoir le rapport final du groupe de travail sur la révision du RSSAC, et a enjoint au comité sur les améliorations structurelles (SIC) de « présenter une série de mesures proposées à l'approbation du CA lors de sa réunion d'octobre 2010, afin d'aborder les conclusions et les recommandations formulées dans le rapport final de ce groupe de travail », sur http://www.icann.org/en/minutes/resolutions-05aug10-en.htm#2.f.

       Attendu que les membres du personnel de l'ICANN soutenant les révisions organisationnelles ont identifié dans un document intitulé « rapport final du groupe de travail sur la révision du RSSAC : étapes de mise en oeuvre », daté de décembre 2010, une série de mesures visant à aborder les recommandations résultant du groupe de travail et les ont présentées au SIC.

       Attendu que le SIC trouve les mesures proposées adéquates et propose que le personnel, en coordination avec le SIC, finalise un plan de mise en œuvre fondé sur les étapes de mise en œuvre identifiées, et soumette au CA un plan de mise en œuvre final.

       Il est résolu (2011.01.25.10), que le CA approuve le « rapport final du groupe de travail sur la révision du RSSAC : étapes de mise en œuvre » présenté par le SIC et enjoigne au SIC, en coordination avec le personnel, de fournir au CA un plan de mise en œuvre final afin d'aborder les conclusions et recommandations formulées dans le rapport final du groupe de travail sur la révision du RSSAC.

       Justification de la résolution 2011.01.25.10

       Les étapes de mise en œuvre proposées ont été présentées au CA en réponse à la résolution adoptée par le CA le 5 août 2010 et demandant la soumission de cette proposition. Les étapes de mise en œuvre abordent les recommandations découlant du rapport final du groupe de travail sur la révision. Une version préliminaire du rapport final a été publiée en ligne pour solliciter les commentaires du public et nul commentaire n'a été reçu et en particulier, nul commentaire indiquant que l'adoption des recommandations pourrait avoir un impact négatif. De plus, l'adoption du plan de mise en œuvre pour la révision du RSSAC préparera l'effort d'un personnel dédié visant à améliorer la coopération et la communication entre l'ICANN et les opérateurs de serveurs racine dans le cadre de la structure du RSSAC.

       Ordonner la création d'un plan de mise en œuvre final aura un impact budgétaire minimal, du fait que ceci nécessitera plus de ressources de la part du personnel  soutenant les revues organisationnelles de l'ICANN. L'identification d'étapes de mise en œuvre finales devrait survenir dans le cadre des ressources déjà affectées. L'impact supplémentaire du travail de mise en œuvre sera identifié autant que faire se peut.

   11. Approbation de la proposition d'amendement des règlements pour créer un poste de président élu sans droit de vote au comité de nomination.

       Attendu que l'article VII, sections 2 et 3 des règlements régit la composition du comité de nomination (NomCom) et les durées des mandats des membres du NomCom.

       Attendu que dans son rapport final publié le 29 janvier 2010 http://www.icann.org/fr/reviews/nomcom/nomcom-review-finalization-wg-final-report-29jan10-fr.pdf [PDF, 291 KB], le groupe de travail sur la finalisation de la révision du NomCom recommandait que le président du NomCom soit élu un an au préalable, ce qui nécessitait des changements des règlements de l'ICANN, à savoir de l'article VII, sections 2 et 3 consultable à l'adresse http://www.icann.org/en/general/bylaws.htm#VII.

       Attendu que le 12 mars 2010, le CA a reçu le rapport final de révision du NomCom et a enjoint au comité sur les améliorations structurelles (SIC) d'identifier les actions nécessaires pour traiter les recommandations dans le rapport, sur http://www.icann.org/en/minutes/resolutions-12mar10-en.htm#1.6.

       Attendu que le SIC, lors de sa réunion du 14 octobre 2010, a recommandé que les règlements soient amendés afin de mettre en pratique la recommandation du groupe de travail sur la finalisation de la révision du NomCom, en élisant le président du NomCom un an au préalable, tout en soulignant que les amendements des règlements en question devaient incorporer la flexibilité appropriée pour le CA.

       Attendu que le CA, lors de sa réunion du 28 octobre 2010, a résolu que les amendements des règlements proposés devaient être publiés pour consultation publique.

       Attendu que les amendements des règlements proposés, voir http://www.icann.org/en/general/proposed-bylaws-revision-vii-10nov10-en.pdf [PDF, 64 KB], ont été proposés à la consultation publique du 10 novembre au 10 décembre et que cette période a pris fin sans réception de commentaires.

       Il est résolu (2011.01.25.11), que le CA approuve les amendements des règlements proposés et ordonne au personnel de collaborer avec le comité sur les améliorations structurelles afin de préparer les nouvelles dispositions de mise en œuvre pour une entrée en vigueur pour le comité de nomination de 2013.

       Justification de la résolution 2011.01.25.11

       Les amendements des règlements proposés auront pour but de réaliser la recommandation du groupe de travail sur la finalisation de la révision du NomCom en désignant un président du NomCom un an au préalable, tout en privilégiant une flexibilité appropriée pour le CA en termes d'examen de la candidature au poste de président.

       Nul commentaire n'ayant été reçu indiquant que ceci pourrait ne pas être un changement positif concernant le comité de nomination et ses procédures. L'impact budgétaire de ce qui précède est neutre, la transition d'une fonction de conseiller du président sans droit de vote à la fonction de président élu ne représente pas de changement du nombre des membres du comité de nomination soutenus par le biais du budget du comité de nomination.

   12. Remerciements au comité de nomination 2010

       Attendu que le 27 août 2009, l'ICANN a nommé Wolfgang Kleinwächter, président du comité de nomination.

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

       Il est résolu (2011.01.25.12), que le Conseil d'administration de l'ICANN exprime son appréciation profonde à l'égard de Wolfgang Kleinwächter et de tous les membres du comité de nomination de 2010 pour leur dévouement, leur travail ardu et leurs efforts couronnés de succès.

   13. Approbation de la redélégation du nom de domaine .BF représentant Burkina

       Attendu que BF est le code de pays de deux lettres correspondant à Burkina dans la liste ISO 3166-1.

       Attendu que l'ICANN a reçu une demande de redélégation du .BF à l'autorité de régulation des communications électroniques ;

       Attendu que l'ICANN a révisé la demande, et a décidé que la proposition était dans l'intérêt des communautés Internet locales et mondiales.

       Il est résolu (2011.01.25.13), que la proposition de redélégation du nom de domaine .BF à l'autorité de régulation des communications électroniques soit approuvée.

       Justification de la résolution 2011.01.25.13

       Pourquoi le CA aborde-t-il la question maintenant ?

       Le personnel présente les demandes de délégation et de redélégation des noms de domaine de codes de pays au CA pour une prise de décision, lorsque le personnel est satisfait que le candidat a fourni un dossier de candidature suffisamment complet ayant de fortes chances de faire l'objet d'une décision positive de la part du CA. En accord avec les engagements de l'ICANN quant au traitement opportun des demandes ayant rapport avec la fonction IANA, et la zone racine du DNS en particulier, le Conseil d'administration de l'ICANN cherche à évaluer de telles demandes lors de sa réunion extraordinaire programmée suivante.

       Quelle est la proposition en cours d'examen ?

       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. En accord avec la pratique établie, le Conseil d'administration de l'ICANN est impliqué dans la prise de décision pour traiter de telles demandes, cette implication étant l'une des phases de ce processus multiphasique.

       Quelles parties prenantes ou autres sont-elles consultées ?

       Au cours de l'évaluation d'une demande de délégation, le personnel de l'ICANN consulte le candidat, l'opérateur actuel (s'il y a lieu), et d'autres parties directement concernées. En accord avec la pratique de l'ICANN consistant à garder confidentielles des demandes de changements de zone racine avant l'achèvement du processus, l'ICANN n'a pas procédé à une consultation publique sur ce sujet.

       Quelles préoccupations ou problématiques ont-elles été soulevées par la communauté ?

       Toutes préoccupations ou problématiques sont soulevées dans le cadre du rapport public qui sera publié en rapport avec cette action. Ce rapport sera publié sur le site Web de l'IANA à l'adresse http://www.iana.org/ une fois que la demande de changement de zone racine aura complété avec succès le traitement final, normalement 1 à 2 mois après la décision du CA.

       Quels documents importants le CA a-t-il examiné ?

       Le CA s'occupe d'évaluer les demandes par rapport à une variété de critères touchant à l'intérêt général. Ces critères consistent entre autres à établir le fait que le code de pays est éligible (à savoir qu'il apparaît dans la liste de la norme ISO 3166-1) ; à établir que le gestionnaire proposé est soutenu par la communauté Internet locale ; à établir que l'opérateur proposé est compétent du point de vue opérationnel et technique ; à établir que le gestionnaire proposé est établi au niveau local et assujetti aux lois locales ; à établir que le gestionnaire proposé opère de manière juste et équitable ; à établir qu'au cas où il y aurait transfert d'opérations, un plan approprié existe pour préserver la stabilité permanent du domaine ; et à établir que l'action est compatible avec toutes les lois et réglementations locales en vigueur. Au cours du processus de compilation de la part du personnel, il est demandé au candidat de fournir une variété de documents soutenant ces divers aspects.

       Les informations pertinentes ressortant des documents fournis et de la recherche effectuée par le personnel sont fournies au CA et publiées dans un rapport public à la fin de la mise en œuvre d'une demande approuvée.

       Quels facteurs le CA a-t-il trouvé importants ?

       Le CA a considéré les facteurs décrits dans le rapport public, en rapport avec les principes de base de la délégation d'un nom de domaine de code de pays décrits plus haut.

       Y-a-t-il des impacts positifs ou négatifs sur la communauté ?

       L'approbation opportune de gestionnaires de noms de domaine de code de pays qui satisfont les divers critères d'intérêt public est positive en matière de mission globale de l'ICANN, et de communautés locales que les noms de domaine de code de pays de premier niveau sont appelés à desservir.

       Y-a-t-il des ramifications ou des impacts fiscaux sur l'ICANN (plan stratégique, plan d'exploitation, budget) ; la communauté ; et/ou le public ?

       L'administration des délégations de codes de pays dans la zone racine du DNS fait partie des fonctions de l'IANA, et la délégation ne devrait provoquer aucune variance significative sur les dépenses pré-planifiées. Le rôle de l'ICANN ne consiste pas à évaluer l'impact fiscal des opérations internes des noms de domaine de code de pays de premier niveau dans un pays, mais à s'assurer que l'opérateur est basé dans le pays et détient les mécanismes appropriés pour permettre à la communauté Internet locale de surveiller correctement le fonctionnement permanent du domaine.

       Y-a-t-il des questions de sécurité, de stabilité ou de résilience liées au DNS ?

       Pour les délégations de noms de domaine de code de pays de premier niveau, l'ICANN cherche à approuver les demandes dans le cadre desquelles les préoccupations raisonnables ont été abordées de manière satisfaisante et pour lesquelles le nouveau gestionnaire proposé a démontré un niveau suffisant de compétence opérationnelle et technique de sorte que ces préoccupations soient minimes.

   14. Approbation de la redélégation du nom de domaine .CD représentant la République démocratique du Congo

       Attendu que CD est le code de pays de deux lettres correspondant à la République démocratique du Congo dans la liste ISO 3166-1 ;

       Attendu que l'ICANN a reçu une demande de redélégation du .CD à l'office congolais des postes et télécommunications ;

       Attendu que l'ICANN a révisé la demande, et a décidé que la redélégation proposée était dans l'intérêt des communautés Internet locales et mondiales.

       Il est résolu (2011.01.25.14), que la redélégation proposée du nom de domaine .CD à l'office congolais des postes et télécommunications soit approuvée.

       Justification de la résolution 2011.01.25.14

       Pourquoi le CA aborde-t-il la question maintenant ?

       Le personnel présente les demandes de délégation et de redélégation des noms de domaine de codes de pays au CA pour une prise de décision, lorsque le personnel est satisfait que le candidat a fourni un dossier de candidature suffisamment complet ayant de fortes chances de faire l'objet d'une décision positive de la part du CA. En accord avec les engagements de l'ICANN quant au traitement opportun des demandes ayant rapport avec la fonction IANA, et la zone racine du DNS en particulier, le Conseil d'administration de l'ICANN cherche à évaluer de telles demandes lors de sa réunion extraordinaire programmée suivante.

       Quelle est la proposition en cours d'examen ?

       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.

       En accord avec la pratique établie, le Conseil d'administration de l'ICANN est impliqué dans la prise de décision pour traiter de telles demandes, cette implication étant l'une des phases de ce processus multiphasique.

       Quelles parties prenantes ou autres sont-elles consultées ?

       Au cours de l'évaluation d'une demande de délégation, le personnel de l'ICANN consulte le candidat, l'opérateur actuel (s'il y a lieu), et d'autres parties directement concernées. En accord avec la pratique de l'ICANN consistant à garder confidentielles des demandes de changements de zone racine avant l'achèvement du processus, l'ICANN n'a pas procédé à une consultation publique sur ce sujet.

       Quelles préoccupations ou problématiques ont-elles été soulevées par la communauté ?

       Toutes préoccupations ou problématiques sont soulevées dans le cadre du rapport public qui sera publié en rapport avec cette action. Ce rapport sera publié sur le site Web de l'IANA à l'adresse http://www.iana.org/ une fois que la demande de changement de zone racine aura complété avec succès le traitement final, normalement 1 à 2 mois après la décision du CA.

       Quels documents importants le CA a-t-il examiné ?

       Le CA s'occupe d'évaluer les demandes par rapport à une variété de critères touchant à l'intérêt général.

       Ces critères consistent entre autres à établir le fait que le code de pays est éligible (à savoir qu'il apparaît dans la liste de la norme ISO 3166-1) ; à établir que le gestionnaire proposé est soutenu par la communauté Internet locale ; à établir que l'opérateur proposé est compétent du point de vue opérationnel et technique ; à établir que le gestionnaire proposé est établi au niveau local et assujetti aux lois locales ; à établir que le gestionnaire proposé opère de manière juste et équitable ; à établir qu'au cas où il y aurait transfert d'opérations, un plan approprié existe pour préserver la stabilité permanent du domaine ; et à établir que l'action est compatible avec toutes les lois et réglementations locales en vigueur. Au cours du processus de compilation de la part du personnel, il est demandé au candidat de fournir une variété de documents soutenant ces divers aspects.

       Les informations pertinentes ressortant des documents fournis et de la recherche effectuée par le personnel sont fournies au CA et publiées dans un rapport public à la fin de la mise en œuvre d'une demande approuvée.

       Quels facteurs le CA a-t-il trouvé importants ?

       Le CA a considéré les facteurs décrits dans le rapport public, en rapport avec les principes de base de la délégation d'un nom de domaine de code de pays décrits plus haut.

       Y-a-t-il des impacts positifs ou négatifs sur la communauté ?

       L'approbation opportune de gestionnaires de noms de domaine de code de pays qui satisfont les divers critères d'intérêt public est positive en matière de mission globale de l'ICANN, et de communautés locales que les noms de domaine de code de pays de premier niveau sont appelés à desservir.

       Y-a-t-il des ramifications ou des impacts fiscaux sur l'ICANN (plan stratégique, plan d'exploitation, budget) ; la communauté ; et/ou le public ?

       L'administration des délégations de codes de pays dans la zone racine du DNS fait partie des fonctions de l'IANA et la délégation ne devrait provoquer aucune variance significative sur les dépenses pré-planifiées. Le rôle de l'ICANN ne consiste pas à évaluer l'impact fiscal des opérations internes des noms de domaine de code de pays de premier niveau dans un pays, mais à s'assurer que l'opérateur est basé dans le pays et détient les mécanismes appropriés pour permettre à la communauté Internet locale de surveiller correctement le fonctionnement permanent du domaine.

       Y-a-t-il des questions de sécurité, de stabilité ou de résilience liées au DNS ?

       Pour les délégations de noms de domaine de code de pays de premier niveau, l'ICANN cherche à approuver les demandes dans le cadre desquelles les préoccupations raisonnables ont été abordées de manière satisfaisante et pour lesquelles le nouveau gestionnaire proposé a démontré un niveau suffisant de compétence opérationnelle et technique de sorte que ces préoccupations soient minimes.

   15. Approbation de la redélégation du nom de domaine .SY représentant la République arabe Syrienne

       Attendu que SY est le code de pays de deux lettres correspondant à la République arabe Syrienne dans la liste ISO 3166-1 ;

       Attendu que l'ICANN a reçu une demande de redélégation du .SY à l'agence nationale pour les services de réseau ;

       Attendu que l'ICANN a révisé la demande, et a décidé que la redélégation proposée serait dans l'intérêt des communautés Internet locales et mondiales.

       Il est résolu (2011.01.25.15), que la redélégation proposée du nom de domaine .SY à l'agence nationale pour les services de réseau soit approuvée.

       Justification de la résolution 2011.01.25.15

       Pourquoi le CA aborde-t-il la question maintenant ?

       Le personnel présente les demandes de délégation et de redélégation des noms de domaine de codes de pays au CA pour une prise de décision, lorsque le personnel est satisfait que le candidat a fourni un dossier de candidature suffisamment complet ayant de fortes chances de faire l'objet d'une décision positive de la part du CA. En accord avec les engagements de l'ICANN quant au traitement opportun des demandes ayant rapport avec la fonction IANA, et la zone racine du DNS en particulier, le Conseil d'administration de l'ICANN cherche à évaluer de telles demandes lors de sa réunion extraordinaire programmée suivante.

       Quelle est la proposition en cours d'examen ?

       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.

       En accord avec la pratique établie, le Conseil d'administration de l'ICANN est impliqué dans la prise de décision pour traiter de telles demandes, cette implication étant l'une des phases de ce processus multiphasique.

       Quelles parties prenantes ou autres sont-elles consultées ?

       Au cours de l'évaluation d'une demande de délégation, le personnel de l'ICANN consulte le candidat, l'opérateur actuel (s'il y a lieu), et d'autres parties directement concernées. En accord avec la pratique de l'ICANN consistant à garder confidentielles des demandes de changements de zone racine avant l'achèvement du processus, l'ICANN n'a pas procédé à une consultation publique sur ce sujet.

       Quelles préoccupations ou problématiques ont-elles été soulevées par la communauté ?

       Toutes préoccupations ou problématiques sont soulevées dans le cadre du rapport public qui sera publié en rapport avec cette action. Ce rapport sera publié sur le site Web de l'IANA à l'adresse http://www.iana.org/ une fois que la demande de changement de zone racine aura complété avec succès le traitement final, normalement 1 à 2 mois après la décision du CA.

       Quels documents importants le CA a-t-il examiné ?

       Le CA s'occupe d'évaluer les demandes par rapport à une variété de critères touchant à l'intérêt général. Ces critères consistent entre autres à établir le fait que le code de pays est éligible (à savoir qu'il apparaît dans la liste de la norme ISO 3166-1) ; à établir que le gestionnaire proposé est soutenu par la communauté Internet locale ; à établir que l'opérateur proposé est compétent du point de vue opérationnel et technique ; à établir que le gestionnaire proposé est établi au niveau local et assujetti aux lois locales ; à établir que le gestionnaire proposé opère de manière juste et équitable ; à établir qu'au cas où il y aurait transfert d'opérations, un plan approprié existe pour préserver la stabilité permanent du domaine ; et à établir que l'action est compatible avec toutes les lois et réglementations locales en vigueur. Au cours du processus de compilation de la part du personnel, il est demandé au candidat de fournir une variété de documents soutenant ces divers aspects.

       Les informations pertinentes ressortant des documents fournis et de la recherche effectuée par le personnel sont fournies au CA et publiées dans un rapport public à la fin de la mise en œuvre d'une demande approuvée.

       Quels facteurs le CA a-t-il trouvé importants ?

       Le CA a considéré les facteurs décrits dans le rapport public, en rapport avec les principes de base de la délégation d'un nom de domaine de code de pays décrits plus haut.

       Y-a-t-il des impacts positifs ou négatifs sur la communauté ?

       L'approbation opportune de gestionnaires de noms de domaine de code de pays qui satisfont les divers critères d'intérêt public est positive en matière de mission globale de l'ICANN, et de communautés locales que les noms de domaine de code de pays de premier niveau sont appelés à desservir.

       Y-a-t-il des ramifications ou des impacts fiscaux sur l'ICANN (plan stratégique, plan d'exploitation, budget) ; la communauté ; et/ou le public ?

       L'administration des délégations de codes de pays dans la zone racine du DNS fait partie des fonctions de l'IANA, et la délégation ne devrait provoquer aucune variance significative sur les dépenses pré-planifiées. Le rôle de l'ICANN ne consiste pas à évaluer l'impact fiscal des opérations internes des noms de domaine de code de pays de premier niveau dans un pays, mais à s'assurer que l'opérateur est basé dans le pays et détient les mécanismes appropriés pour permettre à la communauté Internet locale de surveiller correctement le fonctionnement permanent du domaine.

       Y-a-t-il des questions de sécurité, de stabilité ou de résilience liées au DNS ?

       Pour les délégations de noms de domaine de code de pays de premier niveau, l'ICANN cherche à approuver les demandes dans le cadre desquelles les préoccupations raisonnables ont été abordées de manière satisfaisante et pour lesquelles le nouveau gestionnaire proposé a démontré un niveau suffisant de compétence opérationnelle et technique de sorte que ces préoccupations soient minimes.

   16. Approbation de la délégation du nom de domaine .한국 (« Hanguk ») représentant la République de Corée en coréen

       Attendu que, 한국 (« Hanguk »), encodé comme « xn--3e0b707e », est une chaîne qui a été considérée représenter de manière appropriée la République de Corée à travers la procédure accélérée IDN.

       Attendu que l'ICANN a reçu une demande pour la délégation du .한국 à l'agence Internet et sécurité de Corée.

       Attendu que l'ICANN a révisé la demande, et a décidé que la délégation proposée serait dans l'intérêt des communautés Internet locales et mondiales.

       Il est résolu (2011.01.25.16), que la délégation proposée du nom de domaine .한국 à l'agence Internet et sécurité de Corée soit approuvée.

       Justification de la résolution 2011.01.25.16

       Pourquoi le CA aborde-t-il la question maintenant ?

       Le personnel présente les demandes de délégation et de redélégation des noms de domaine de codes de pays au CA pour une prise de décision, lorsque le personnel est satisfait que le candidat a fourni un dossier de candidature suffisamment complet ayant de fortes chances de faire l'objet d'une décision positive de la part du CA. En accord avec les engagements de l'ICANN quant au traitement opportun des demandes ayant rapport avec la fonction IANA, et la zone racine du DNS en particulier, le Conseil d'administration de l'ICANN cherche à évaluer de telles demandes lors de sa réunion extraordinaire programmée suivante.

       Quelle est la proposition en cours d'examen ?

       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.

       En accord avec la pratique établie, le Conseil d'administration de l'ICANN est impliqué dans la prise de décision pour traiter de telles demandes, cette implication étant l'une des phases de ce processus multiphasique.

       Quelles parties prenantes ou autres sont-elles consultées ?

       Au cours de l'évaluation d'une demande de délégation, le personnel de l'ICANN consulte le candidat, l'opérateur actuel (s'il y a lieu), et d'autres parties directement concernées. En accord avec la pratique de l'ICANN consistant à garder confidentielles des demandes de changements de zone racine avant l'achèvement du processus, l'ICANN n'a pas procédé à une consultation publique sur ce sujet.

       Quelles préoccupations ou problématiques ont-elles été soulevées par la communauté ?

       Toutes préoccupations ou problématiques sont soulevées dans le cadre du rapport public qui sera publié en rapport avec cette action. Ce rapport sera publié sur le site Web de l'IANA à l'adresse http://www.iana.org/ une fois que la demande de changement de zone racine aura complété avec succès le traitement final, normalement 1 à 2 mois après la décision du CA.

       Quels documents importants le CA a-t-il examiné ?

       Le CA s'occupe d'évaluer les demandes par rapport à une variété de critères touchant à l'intérêt général.

       Ces critères consistent entre autres à établir le fait que le code de pays est éligible (à savoir qu'il apparaît dans la liste de la norme ISO 3166-1) ; à établir que le gestionnaire proposé est soutenu par la communauté Internet locale ; à établir que l'opérateur proposé est compétent du point de vue opérationnel et technique ; à établir que le gestionnaire proposé est établi au niveau local et assujetti aux lois locales ; à établir que le gestionnaire proposé opère de manière juste et équitable ; à établir qu'au cas où il y aurait transfert d'opérations, un plan approprié existe pour préserver la stabilité permanent du domaine ; et à établir que l'action est compatible avec toutes les lois et réglementations locales en vigueur. Au cours du processus de compilation de la part du personnel, il est demandé au candidat de fournir une variété de documents soutenant ces divers aspects.

       Les informations pertinentes ressortant des documents fournis et de la recherche effectuée par le personnel sont fournies au CA et publiées dans un rapport public à la fin de la mise en œuvre d'une demande approuvée.

       Quels facteurs le CA a-t-il trouvé importants ?

       Le CA a considéré les facteurs décrits dans le rapport public, en rapport avec les principes de base de la délégation d'un nom de domaine de code de pays décrits plus haut.

       Y-a-t-il des impacts positifs ou négatifs sur la communauté ?

       L'approbation opportune de gestionnaires de noms de domaine de code de pays qui satisfont les divers critères d'intérêt public est positive en matière de mission globale de l'ICANN, et de communautés locales que les noms de domaine de code de pays de premier niveau sont appelés à desservir.

       Y-a-t-il des ramifications ou des impacts fiscaux sur l'ICANN (plan stratégique, plan d'exploitation, budget) ; la communauté ; et/ou le public ?

       L'administration des délégations de codes de pays dans la zone racine du DNS fait partie des fonctions de l'IANA et la délégation ne devrait provoquer aucune variance significative sur les dépenses pré-planifiées. Le rôle de l'ICANN ne consiste pas à évaluer l'impact fiscal des opérations internes des noms de domaine de code de pays de premier niveau dans un pays, mais à s'assurer que l'opérateur est basé dans le pays et détient les mécanismes appropriés pour permettre à la communauté Internet locale de surveiller correctement le fonctionnement permanent du domaine.

       Y-a-t-il des questions de sécurité, de stabilité ou de résilience liées au DNS ?

       Pour les délégations de noms de domaine de code de pays de premier niveau, l'ICANN cherche à approuver les demandes dans le cadre desquelles les préoccupations raisonnables ont été abordées de manière satisfaisante et pour lesquelles le nouveau gestionnaire proposé a démontré un niveau suffisant de compétence opérationnelle et technique de sorte que ces préoccupations soient minimes.

   17. Approbation de la délégation du nom de domaine .新加坡 (« Singapour ») et du nom de domaine .சிங்கப்பூர் (« Singapour »), représentant Singapour en chinois et en tamil

       Attendu que Singapour apparaît actuellement dans la liste de la norme ISO 3166-1 ;

       Attendu que 新加坡 (« Singapour »), encodé comme « xn--yfro4i67o »; et சிங்கப்பூர் (« Singapour »), encodé comme « xn--clchc0ea0b2g2a9gcd »; sont deux chaînes qui sont considérées représenter Singapour de manière appropriée à travers la procédure accélérée IDN ;

       Attendu que l'ICANN a reçu une demande de délégation des .新加坡 et .சிங்கப்பூர் à Singapore Network Information Centre Pte Ltd ;

       Attendu que l'ICANN a révisé la demande, et a décidé que la délégation proposée serait dans l'intérêt des communautés Internet locales et mondiales.

       Il est résolu (2011.01.25.17), que la délégation proposée des noms de domaine de premier niveau à Singapore Network Information Centre Pte Ltd soit approuvée.

       Justification de la résolution 2011.01.25.17

       Pourquoi le CA aborde-t-il la question maintenant ?

       Le personnel présente les demandes de délégation et de redélégation des noms de domaine de codes de pays au CA pour une prise de décision, lorsque le personnel est satisfait que le candidat a fourni un dossier de candidature suffisamment complet ayant de fortes chances de faire l'objet d'une décision positive de la part du CA. En accord avec les engagements de l'ICANN quant au traitement opportun des demandes ayant rapport avec la fonction IANA, et la zone racine du DNS en particulier, le Conseil d'administration de l'ICANN cherche à évaluer de telles demandes lors de sa réunion extraordinaire programmée suivante.

       Quelle est la proposition en cours d'examen ?

       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.

       En accord avec la pratique établie, le Conseil d'administration de l'ICANN est impliqué dans la prise de décision pour traiter de telles demandes, cette implication étant l'une des phases de ce processus multiphasique.

       Quelles parties prenantes ou autres sont-elles consultées ?

       Au cours de l'évaluation d'une demande de délégation, le personnel de l'ICANN consulte le candidat, l'opérateur actuel (s'il y a lieu), et d'autres parties directement concernées. En accord avec la pratique de l'ICANN consistant à garder confidentielles des demandes de changements de zone racine avant l'achèvement du processus, l'ICANN n'a pas procédé à une consultation publique sur ce sujet.

       Quelles préoccupations ou problématiques ont-elles été soulevées par la communauté ?

       Toutes préoccupations ou problématiques sont soulevées dans le cadre du rapport public qui sera publié en rapport avec cette action. Ce rapport sera publié sur le site Web de l'IANA à l'adresse http://www.iana.org/ une fois que la demande de changement de zone racine aura complété avec succès le traitement final, normalement 1 à 2 mois après la décision du CA.

       Quels documents importants le CA a-t-il examiné ?

       Le CA s'occupe d'évaluer les demandes par rapport à une variété de critères touchant à l'intérêt général.

       Ces critères consistent entre autres à établir le fait que le code de pays est éligible (à savoir qu'il apparaît dans la liste de la norme ISO 3166-1) ; à établir que le gestionnaire proposé est soutenu par la communauté Internet locale ; à établir que l'opérateur proposé est compétent du point de vue opérationnel et technique ; à établir que le gestionnaire proposé est établi au niveau local et assujetti aux lois locales ; à établir que le gestionnaire proposé opère de manière juste et équitable ; à établir qu'au cas où il y aurait transfert d'opérations, un plan approprié existe pour préserver la stabilité permanent du domaine ; et à établir que l'action est compatible avec toutes les lois et réglementations locales en vigueur. Au cours du processus de compilation de la part du personnel, il est demandé au candidat de fournir une variété de documents soutenant ces divers aspects.

       Les informations pertinentes ressortant des documents fournis et de la recherche effectuée par le personnel sont fournies au CA et publiées dans un rapport public à la fin de la mise en œuvre d'une demande approuvée.

       Quels facteurs le CA a-t-il trouvé importants ?

       Le CA a considéré les facteurs décrits dans le rapport public, en rapport avec les principes de base de la délégation d'un nom de domaine de code de pays décrits plus haut.

       Y-a-t-il des impacts positifs ou négatifs sur la communauté ?

       L'approbation opportune de gestionnaires de noms de domaine de code de pays qui satisfont les divers critères d'intérêt public est positive en matière de mission globale de l'ICANN, et de communautés locales que les noms de domaine de code de pays de premier niveau sont appelés à desservir.

       Y-a-t-il des ramifications ou des impacts fiscaux sur l'ICANN (plan stratégique, plan d'exploitation, budget) ; la communauté ; et/ou le public ?

       L'administration des délégations de codes de pays dans la zone racine du DNS fait partie des fonctions de l'IANA, et la délégation ne devrait provoquer aucune variance significative sur les dépenses pré-planifiées. Le rôle de l'ICANN ne consiste pas à évaluer l'impact fiscal des opérations internes des noms de domaine de code de pays de premier niveau dans un pays, mais à s'assurer que l'opérateur est basé dans le pays et détient les mécanismes appropriés pour permettre à la communauté Internet locale de surveiller correctement le fonctionnement permanent du domaine.

       Y-a-t-il des questions de sécurité, de stabilité ou de résilience liées au DNS ?

       Pour les délégations de noms de domaine de code de pays de premier niveau, l'ICANN cherche à approuver les demandes dans le cadre desquelles les préoccupations raisonnables ont été abordées de manière satisfaisante et pour lesquelles le nouveau gestionnaire proposé a démontré un niveau suffisant de compétence opérationnelle et technique de sorte que ces préoccupations soient minimes.

   18. Approbation de la délégation du nom de domaine .سورية (« Souriya ») représentant la République arabe Syrienne en arabe

       Attendu que la République arabe Syrienne apparaît actuellement dans la liste de la norme ISO 3166-1 ;

       Attendu que .سورية (« Sourya »), encodé comme « xn--ogbpf8fl », est une chaîne qui a été considérée représenter la République arabe Syrienne de manière appropriée à travers la procédure accélérée IDN.

       Attendu que l'ICANN a reçu une demande de délégation du  .سورية à l'agence nationale pour les services de réseau.

       Attendu que l'ICANN a révisé la demande, et a décidé que la délégation proposée serait dans l'intérêt des communautés Internet locales et mondiales.

       Il est résolu (2011.01.25.18), que la délégation proposée du nom de domaine .سورية (« Sourya ») à l'agence nationale pour les services de réseau soit approuvée.

       Justification de la résolution 2011.01.25.18

       Pourquoi le CA aborde-t-il la question maintenant ?

       Le personnel présente les demandes de délégation et de redélégation des noms de domaine de codes de pays au CA pour une prise de décision, lorsque le personnel est satisfait que le candidat a fourni un dossier de candidature suffisamment complet ayant de fortes chances de faire l'objet d'une décision positive de la part du CA. En accord avec les engagements de l'ICANN quant au traitement opportun des demandes ayant rapport avec la fonction IANA, et la zone racine du DNS en particulier, le Conseil d'administration de l'ICANN cherche à évaluer de telles demandes lors de sa réunion extraordinaire programmée suivante.

       Quelle est la proposition en cours d'examen ?

       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.

       En accord avec la pratique établie, le Conseil d'administration de l'ICANN est impliqué dans la prise de décision pour traiter de telles demandes, cette implication étant l'une des phases de ce processus multiphasique.

       Quelles parties prenantes ou autres sont-elles consultées ?

       Au cours de l'évaluation d'une demande de délégation, le personnel de l'ICANN consulte le candidat, l'opérateur actuel (s'il y a lieu), et d'autres parties directement concernées. En accord avec la pratique de l'ICANN consistant à garder confidentielles des demandes de changements de zone racine avant l'achèvement du processus, l'ICANN n'a pas procédé à une consultation publique sur ce sujet.

       Quelles préoccupations ou problématiques ont-elles été soulevées par la communauté ?

       Toutes préoccupations ou problématiques sont soulevées dans le cadre du rapport public qui sera publié en rapport avec cette action. Ce rapport sera publié sur le site Web de l'IANA à l'adresse http://www.iana.org/ une fois que la demande de changement de zone racine aura complété avec succès le traitement final, normalement 1 à 2 mois après la décision du CA.

       Quels documents importants le CA a-t-il examiné ?

       Le CA s'occupe d'évaluer les demandes par rapport à une variété de critères touchant à l'intérêt général.

       Ces critères consistent entre autres à établir le fait que le code de pays est éligible (à savoir qu'il apparaît dans la liste de la norme ISO 3166-1) ; à établir que le gestionnaire proposé est soutenu par la communauté Internet locale ; à établir que l'opérateur proposé est compétent du point de vue opérationnel et technique ; à établir que le gestionnaire proposé est établi au niveau local et assujetti aux lois locales ; à établir que le gestionnaire proposé opère de manière juste et équitable ; à établir qu'au cas où il y aurait transfert d'opérations, un plan approprié existe pour préserver la stabilité permanent du domaine ; et à établir que l'action est compatible avec toutes les lois et réglementations locales en vigueur. Au cours du processus de compilation de la part du personnel, il est demandé au candidat de fournir une variété de documents soutenant ces divers aspects.

       Les informations pertinentes ressortant des documents fournis et de la recherche effectuée par le personnel sont fournies au CA et publiées dans un rapport public à la fin de la mise en œuvre d'une demande approuvée.

       Quels facteurs le CA a-t-il trouvé importants ?

       Le CA a considéré les facteurs décrits dans le rapport public, en rapport avec les principes de base de la délégation d'un nom de domaine de code de pays décrits plus haut.

       Y-a-t-il des impacts positifs ou négatifs sur la communauté ?

       L'approbation opportune de gestionnaires de noms de domaine de code de pays qui satisfont les divers critères d'intérêt public est positive en matière de mission globale de l'ICANN, et de communautés locales que les noms de domaine de code de pays de premier niveau sont appelés à desservir.

       Y-a-t-il des ramifications ou des impacts fiscaux sur l'ICANN (plan stratégique, plan d'exploitation, budget) ; la communauté ; et/ou le public ?

       L'administration des délégations de codes de pays dans la zone racine du DNS fait partie des fonctions de l'IANA, et la délégation ne devrait provoquer aucune variance significative sur les dépenses pré-planifiées. Le rôle de l'ICANN ne consiste pas à évaluer l'impact fiscal des opérations internes des noms de domaine de code de pays de premier niveau dans un pays, mais à s'assurer que l'opérateur est basé dans le pays et détient les mécanismes appropriés pour permettre à la communauté Internet locale de surveiller correctement le fonctionnement permanent du domaine.

       Y-a-t-il des questions de sécurité, de stabilité ou de résilience liées au DNS ?

       Pour les délégations de noms de domaine de code de pays de premier niveau, l'ICANN cherche à approuver les demandes dans le cadre desquelles les préoccupations raisonnables ont été abordées de manière satisfaisante et pour lesquelles le nouveau gestionnaire proposé a démontré un niveau suffisant de compétence opérationnelle et technique de sorte que ces préoccupations soient minimes.

   19. Approbation de la délégation des sept noms de domaine de premier niveau représentant l'Inde en diverses langues

       Attendu que l'Inde apparaît actuellement dans la liste de la norme ISO 3166-1;

       Attendu que भारत   («Bharat»), encodé comme «xn--h2brj9c»; ; بھار «Bharat»), encodé comme «xn--mgbbh1a71e»; భారత్ («Bharat»), encodé comme "xn--fpcrj9c3d"; ભારત («Bharat»), encodé comme «xn--gecrj9c»; ਭਾਰਤ («Bharat»), encodé comme «xn--s9brj9c»; இந்தியா («Bharat»), encodé comme «xn--xkc2dl3a5ee0h»; et ভারত («Bharat»), encodé comme «xn--45brj9c»; sont sept chaînes qui ont été considérées représenter l'Inde de manière appropriée à travers la procédure accélérée IDN;

       Attendu que l'ICANN a reçu une demande de délégation des sept chaînes en tant que noms de domaine de premier niveau à la National Internet Exchange de l'Inde;

       Attendu que l'ICANN a révisé la demande, et a décidé que les délégations proposées seraient dans l'intérêt des communautés Internet locales et mondiales.

       IL EST RÉSOLU (2011.01.25.19), que la délégation proposée des sept noms de domaine de premier niveau à la National Internet Exchange de l'Inde soit approuvée.

       Justification de la résolution 2011.01.25.19

       Pourquoi le CA aborde-t-il la question maintenant?

       Le personnel présente les demandes de délégation et de redélégation des noms de domaine de codes de pays au CA pour une prise de décision, lorsque le personnel est satisfait que le candidat a fourni un dossier de candidature suffisamment complet ayant de fortes chances de faire l'objet d'une décision positive de la part du CA. En accord avec les engagements de l'ICANN quant au traitement opportun des demandes ayant rapport avec la fonction IANA, et la zone racine du DNS en particulier, le Conseil d'administration de l'ICANN cherche à évaluer de telles demandes lors de sa réunion extraordinaire programmée suivante.

       Quelle est la proposition en cours d'examen?

       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.

       En accord avec la pratique établie, le Conseil d'administration de l'ICANN est impliqué dans la prise de décision pour traiter de telles demandes, cette implication étant l'une des phases de ce processus multiphasique.

       Quelles parties prenantes ou autres sont-elles consultées?

       Au cours de l'évaluation d'une demande de délégation, le personnel de l'ICANN consulte le candidat, l'opérateur actuel (s'il y a lieu), et d'autres parties directement concernées. En accord avec la pratique de l'ICANN consistant à garder confidentielles des demandes de changements de zone racine avant l'achèvement du processus, l'ICANN n'a pas procédé à une consultation publique sur ce sujet.

       Quelles préoccupations ou problématiques ont-elles été soulevées par la communauté?

       Toutes préoccupations ou problématiques sont soulevées dans le cadre du rapport public qui sera publié en rapport avec cette action. Ce rapport sera publié sur le site Web de l'IANA à l'adresse http://www.iana.org/ une fois que la demande de changement de zone racine aura complété avec succès le traitement final, normalement 1 à 2 mois après la décision du CA.

       Quels documents importants le CA a-t-il examiné?

       Le CA s'occupe d'évaluer les demandes par rapport à une variété de critères touchant à l'intérêt général.

       Ces critères consistent entre autres à établir le fait que le code de pays est éligible (à savoir qu'il apparaît dans la liste de la norme ISO 3166-1); à établir que le gestionnaire proposé est soutenu par la communauté Internet locale; à établir que l'opérateur proposé est compétent du point de vue opérationnel et technique; à établir que le gestionnaire proposé est établi au niveau local et assujetti aux lois locales; à établir que le gestionnaire proposé opère de manière juste et équitable; à établir qu'au cas où il y aurait transfert d'opérations, un plan approprié existe pour préserver la stabilité permanent du domaine; et à établir que l'action est compatible avec toutes les lois et réglementations locales en vigueur. Au cours du processus de compilation de la part du personnel, il est demandé au candidat de fournir une variété de documents soutenant ces divers aspects.

       Les informations pertinentes ressortant des documents fournis et de la recherche effectuée par le personnel sont fournies au CA et publiées dans un rapport public à la fin de la mise en œuvre d'une demande approuvée.

       Quels facteurs le CA a-t-il trouvé importants?

       Le CA a considéré les facteurs décrits dans le rapport public, en rapport avec les principes de base de la délégation d'un nom de domaine de code de pays décrits plus haut.

       Y-a-t-il des impacts positifs ou négatifs sur la communauté?

       L'approbation opportune de gestionnaires de noms de domaine de code de pays qui satisfont les divers critères d'intérêt public est positive en matière de mission globale de l'ICANN, et de communautés locales que les noms de domaine de code de pays de premier niveau sont appelés à desservir.

       Y-a-t-il des ramifications ou des impacts fiscaux sur l'ICANN (plan stratégique, plan d'exploitation, budget); la communauté; et/ou le public?

       L'administration des délégations de codes de pays dans la zone racine du DNS fait partie des fonctions de l'IANA, et la délégation ne devrait provoquer aucune variance significative sur les dépenses pré-planifiées. Le rôle de l'ICANN ne consiste pas à évaluer l'impact fiscal des opérations internes des noms de domaine de code de pays de premier niveau dans un pays, mais à s'assurer que l'opérateur est basé dans le pays et détient les mécanismes appropriés pour permettre à la communauté Internet locale de surveiller correctement le fonctionnement permanent du domaine.

       Y-a-t-il des questions de sécurité, de stabilité ou de résilience liées au DNS?

       Pour les délégations de noms de domaine de code de pays de premier niveau, l'ICANN cherche à approuver les demandes dans le cadre desquelles les préoccupations raisonnables ont été abordées de manière satisfaisante et pour lesquelles le nouveau gestionnaire proposé a démontré un niveau suffisant de compétence opérationnelle et technique de sorte que ces préoccupations soient minimes.

       Les résolutions 2011.01.25.01, 2011.01.25.02, 2011.01.25.03, 2011.01.25.04, 2011.01.25.05, 2011.01.25.06, 2011.01.25.07, 2011.01.25.08, 2011.01.25.09, 2011.01.25.10, 2011.01.25.11, 2011.01.25.12, 2011.01.25.13, 2011.01.25.14, 2011.01.25.15, 2011.01.25.16, 2011.01.25.17, 2011.01.25.18, and 2011.01.25.19 ont été approuvés en un seul vote, approuvant les articles de l'ordre du jour convenu. Tous les membres du conseil présents ont unanimement approuvé ces résolutions.

       Ram Mohan a remercié Steve Crocker et Ray Plzak pour leur service sur le SSAC et exprimé sa profonde gratitude et reconnaissance pour leur travail dans l'orientation de la SNCC jusqu'à l'endroit où il se trouve maintenant.

       Le président était d'accord avec Ram et a remarqué au Conseil que c'était sur la demande du président que Steve est resté en tant que président de la SSAC à travers le cycle de révision de l'organisation. Le président a remarqué que les résolutions ont été adoptées par acclamation grâce à Steve et Ray et leur service au SSAC.

Ordre du jour principal

3. Approbation des propositions d'amendement des règlements concernant la modification des dates de fin de mandat des membres du CA choisis par les organisations de soutien et At-Large

   Le président a présenté les modifications proposées aux règlements pour aligner la fin du mandat des administrateurs nommés par l'Organisation de soutien et de la communauté At-Large (Sièges 9-15) à une réunion de l'ICANN, à des fins de transition. Cette recommandation découle des recommandations du Groupe de travail d'examen du Conseil. Le cycle de transition actuelle est entre les réunions, et la recommandation permettra une meilleure remise. Les révisions proposées des statuts ont été publiées pour les commentaires du public et la période de commentaires a été prolongée, avant de sa présentation au CA pour approbation. Le président a constaté que, bien qu'il ne fût pas nécessaire pour les administrateurs nommé à SO de s'abstenir de voter, il a compris que certains membres peuvent choisir de s'abstenir sur ce point. Le président a ensuite demandé que les membres du CA nommés par le comité de nomination proposent et appuyent la présente résolution.

   Steve Crocker a proposé et George Sadowsky a appuyé la résolution.

   Le président a ouvert le débat.

   Sébastien Bachollet a demandé pourquoi la recommandation ne permettait pas la possibilité d'une transition lors d'une réunion dans les neuf mois de l'assemblée générale annuelle, par opposition à la limitation de huit mois indiqués dans la proposition. Sébastien a remarqué qu'il y aura des cas où il y aura une réunion dans le délai de neuf mois, mais pas dans le délai de huit mois, et il n'y a pas une grande différence dans l'ajout d'un mois supplémentaire. Sébastien a également noté qu'il s'abstiendra de voter sur ce point parce que, s'il est approuvé, il aura une incidence sur la durée de son mandat.

   Amy Stathos a expliqué que le Comité des améliorations structurelles a transmis cette question au Comité du Conseil de gouvernance (BGC) pour la mise en œuvre, et le BGC a discuté la possibilité d'avoir la fenêtre de la transition définie comme six à neuf mois au lieu de six à huit mois.  Le BGC a conclu que huit mois après l'AGA était le montant maximum de temps qui devrait s'écouler avant la transition. Si la réunion de mi-année s'est produite au-delà de la fenêtre de huit mois, les termes passeront au cours des six mois après l'intervalle AGM actuellement en place.

   Le président a noté que le processus pour mettre en œuvre cette recommandation est en cours, et nous devrions procéder à l'examen.

   Le CA a ensuite pris les décisions suivantes:

   Attendu que les règlements exigent actuellement que tous les membres entrants du Conseil d'administration de l'ICANN non sélectionnés par le comité de nomination (NomCom) entrent en fonction six mois après l'assemblée générale annuelle (AGM) de l'année précédente.

   Attendu que la fin de cette période de six mois après l'AGM de l'année précédente survient d'habitude dans l'intervalle entre les conférences internationales de l'ICANN («conférence»).

   Attendu que le groupe de travail sur la révision du CA (BRWG) a recommandé  [PDF, 146 KB] que la prise de fonctions des membres du CA non désignés par le NomCom survienne lors de la conférence du milieu d'année pour faciliter une transition fluide des membres du CA.

   Attendu que le comité de gouvernance du Conseil d'administration («BGC») a examiné la question, a été d'accord avec la logique du BRWG mais a reconnu qu'une conférence de milieu d'année peut ne pas toujours avoir lieu, et que le BGC a donc recommandé des modifications de la recommandation du BRWG pour permettre une entrée en fonctions des administrateurs entrants sans retard.

   Attendu que les propositions d'amendements des règlements pour refléter les recommandations du BRWG ont fait l'objet d'une consultation publique de deux mois (du 8 novembre 2010 au 8 janvier 2011) à l'adresse http://www.icann.org/en/public-comment/public-comment-201012-en.htm#bylaws-amend-article-vi8.

   Attendu que seul un commentaire public en faveur des amendements proposés a été reçu au cours de la période de consultation publique.

   IL EST RÉSOLU (2011.01.25.20), que le CA approuve les propositions d'amendements des règlements nécessaires afin de faciliter un changement dans la transition des membres du CA sélectionnés par les organisations de soutien ou la communauté At-Large.

   Neuf membres du CA ont voté en faveur de la résolution 2011.01.25.20  Le président, Sébastien Bachollet, Rita Rodin Johnston, Gonzalo Navarro, Ray Plzak, Mike Silber et Bruce Tonkin se sont abstenus de voter sur la résolution. La résolution a été adoptée.

   Justification de la résolution 2011.01.25.20

   Suite à une revue indépendante du Conseil d'administration de l'ICANN effectuée par la Boston Consulting Group (BCG) (http://www.icann-ombudsman.com/en/reviews/board/report-02nov08-en.pdf [PDF, 921 KB], un groupe de travail sur la révision du Conseil d'administration (BRWG) a été établi pour aider à définir la faisabilité de mise en œuvre des recommandations de la BCG. TAprès de nombreuses réunions, des communications par courriel de grande envergure et des analyses de documents, le BRWG a émis son rapport final (http://www.icann.org/fr/reviews/board/board-review-final-26jan10-fr.pdf [PDF, 146 KB]) en janvier 2010. Une des recommandations du BRWG, que le CA a examiné, était que tous les membres non sélectionnés par le comité de nomination, entrent en fonction lors d'une conférence de milieu d'année de l'ICANN. Avec quelques petites modifications pour aborder le cas où il n'y aurait pas de conférence de milieu d'année, le CA estime que le raisonnement et l'orientation des recommandations du BRWG visent à assurer une transition fluide des membres du Conseil d'administration. Le seul commentaire reçu de la part de la communauté provenait de l'ALAC et soutenait les propositions d'amendements des règlements. (Voir http://forum.icann.org/lists/bylaws-amend-article-vi8/msg00000.html «Les propositions d'amendements des règlements concernant les transitions de mandat des membres du Conseil d'administration s'alignent sur les philosophies de l'ALAC en matière de transitions. L'ALAC accueille favorablement et soutient ces amendements».)

   Le CA s'attend à ce que ceci ait un impact public positif, du fait que les nouveaux membres du CA entreront en fonction à la fin de la conférence, ce qui permettrait aux membres sortants du CA de mettre un terme à leurs mandats à la fin de ladite conférence. Une période de transition offre une transition beaucoup plus fluide que le fait de changer de mandat dans l'intervalle séparant les réunions du CA. Les membres sortants du CA pourront compléter le cycle de mise au courant et de traitement des sujets en suspens devant être discutés et décidés lors de la réunion suivante. De même, les nouveaux membres du CA pourront recommencer avec les questions suivantes au début de la procédure.

   La décision du CA pourrait avoir un impact financier minime sur l'ICANN du fait que le déplacement et l'hébergement autant des membres sortants que des nouveaux membres seront financés pendant la réunion de transition. Toutefois, tel qu'organisé actuellement, il n'y aura besoin de financement supplémentaire que pour quatre membres du CA au maximum, si ce n'est moins. Il est peu probable que le montant éventuel requis pour le soutien au déplacement ait un impact sur le budget ou la communauté. Le CA ne voit pas d'impact sur la sécurité, la stabilité et la résilience systémiques du DNS.

4. Approbation de la demande VeriSign RSEP (pour. NAME) pour la libération des chaînes numériques uniquement et les chaînes numériques avec traits d'union

   Le président a demandé à George Sadowsky de traiter ce point, comme George avait demandé son retrait de l'ordre du jour convenu.

   George a déclaré qu'il avait lu les matériaux pour les demandes .NAME et .TEL, est il a remarqué qu'il était en faveur de la demande .TEL, mais contre la demande de .NAME. George a noté que ce sont des TLD sponsorisés qui ont été établis avec les règles en place, y compris une règle disant qu’il ne pouvait pas y avoir des noms totalement numériques. Pour la demande .TEL, George a remarqué sa compréhension de la demande d'étendre au-delà des noms numériques d'un chiffre, mais il ne comprend pas comment il ne peut pas y avoir confusion de l'utilisateur au sein de .NAME, lorsqu'une chaîne arbitraire de chiffres peut y être enregistrée. Cela causerait confusion pour les utilisateurs directs entre .NAME et .TEL, et il est seulement approprié pour .TEL.

   Le président a demandé des éclaircissements de George au sujet d'une confusion potentielle, comme beaucoup d'autres TLD présentent déjà la possibilité d'avoir des chaînes numériques, donc pourquoi y avait-il un problème spécifique de confusion dans les chaînes numériques uniquement lorsqu’utilisé en .NAME.

   George a répondu qu'il ne serait pas sémantiquement clair pour un utilisateur sur ce qu'un chiffre suivi de l'extension .NAME signifie; cela pouvait être un numéro de téléphone, ou pas.

   Le président a rappelé que la possibilité existe déjà dans d'autres TLD, et il n'y a aucun risque de confusion.

   George a confirmé qu'il identifie toujours un risque de confusion quant à la demande .NAME.

   Mike Silber a fait remarquer que sa préoccupation n'est pas dans le détail de l'application par un registre, mais plutôt le processus de traitement de ces demandes par le biais du processus de modification RSEP, comme l'a souligné Tim Ruiz. Mike a remarqué que le processus RSEP peut ne pas convenir à ce type de changement, et qu'il préférerait le conseil du personnel sur un mécanisme approprié pour les modifications de ce type.

   Suzanne Woolf a offert des éclaircissements sur les préoccupations soulevées par George. L'idée derrière les TLD sponsorisés est qu'il y avait un sens à déduire des noms, pas tous les TLD sont créés de la même façon. Il y a des constructions qui pourraient être acceptées dans un TLD, mais causer confusion d'utilisation dans un autre TLD, selon le signifié que les gens donnent aux extensions. La suggestion de Mike d’une problématique de processus est juste, mais il se pourrait que l'idée des TLD sponsorisés ne fonctionne pas à long terme dans la pratique.

   Bruce Tonkin a précisé que .NAME est un TLD limité, pas un TLD sponsorisé.

   Le président a noté que cela peut être une distinction sans différence lorsque le registre est à la recherche de changer ce qui peut être des conditions fondamentales de fonctionnement. Le président a noté qu'il n'a pas de problème avec la demande .TEL, seulement avec la demande .NAME. Si l'élément clé était la définition d'un nom, aujourd'hui ceci est en cours de changement. Le président remarque qu'il approuve des processus qui permettent le développement des entreprises et la croissance commerciale, mais ceci doit être en conformité avec les politiques. Le président a remarqué qu'il était possible que le CA retire ce point pour un examen plus approfondi, et demande travail demande vers un cadre d'évaluation de ce type de changement. Le président a remarqué que le Conseil ne cherche pas à bloquer le développement, mais à s'assurer qu'il y ait une voie claire qui mène à des résultats prévisibles.

   Bruce a clarifié la construction de .TEL et .NAME. .TEL, comme d'autres sTLD, a été mis en place avec la délégation de la responsabilité de l'élaboration des politiques du CA de l'ICANN à un organisme de sponsorisation. Sur cette base, il est raisonnable d'approuver le changement de .TEL parce qu'il a été présenté par l'organisme parrain et il n'y a pas de bonnes raisons techniques pour ne pas le faire. .NAME est différent, puisque la gestion politique appartient essentiellement à l'ICANN. Ils ont demandé un changement pour lequel il y avait un avis et des commentaires publics. A moins qu'il y a des préoccupations quant aux changements soulevées par ce processus, Bruce a fait remarquer qu'il est enclin à approuver la demande parce que c'est compatible avec le processus dans d'autres TLD plus ouverts. D'autres TLD sont en mesure d'allouer des chaînes numériques, donc il ne peut pas y avoir une raison d'imposer une restriction ici.

   Kurt Ritz a fourni un résumé de la période de commentaires du public, où quatre commentaires ont été reçus, dont un commentaire négatif Le commentaire négatif a soulevé une question quant à la façon dont le nombre pourrait poser des problèmes aux propriétaires de marques pour protéger des droits. Les commentaires - et la question de savoir si le changement allait changer la nature de la charte .NAME - ont été transmis à VeriSign, qui a répondu à ces préoccupations. Cette lettre a été fournie au CA. La demande a été considérée pendant un certain temps.

   Le président a déclaré qu'à son avis la réponse ne tient pas compte de la différence d'un changement fondamental dans le registre.

   Sébastien Bachollet a remarqué que ce serait un grand changement et il a constaté la problématique de représenter nos noms en chiffres, comme les numéros de passeport. Il a fait remarquer qu'il ne serait pas d'accord avec ce changement.

   Lors de l'interrogation par le Conseil, la majorité des administrateurs a indiqué qu'ils souhaitaient reporter l'examen de la demande .NAME pour permettre un délai de réflexion.

   Le Conseil a examiné la demande de VeriSign pour .NAME ainsi que la demande RSEP pour .TEL relatives à la libération des chaînes numériques uniquement, et les différences potentielles dans l'examen du Conseil de chaque demande.

   Le président a demandé au Conseil et il a été déterminé que la majorité des administrateurs souhaite reporter la discussion sur la demande .NAME pour permettre un délai de réflexion. Le président a remarqué que le Conseil pourrait faire le suivi avec le personnel sur toute question sur ce point, et a demandé au secrétaire d'ajourner ce point à l'ordre du jour de la prochaine réunion du Conseil.

5. Approbation de la demande de Telnic conformément à la politique d'évaluation de services de registre (RSEP) pour l'autorisation de chaînes uniquement numériques sauf pour les labels à un seul caractère

   Le président a ensuite demandé au Conseil sur l'opportunité de reporter l'examen de la demande .TEL. Une majorité du Conseil a indiqué qu'il était prêt à passer au vote.

   Le président a ensuite proposé et Bruce Tonkin a appuyé la résolution, et le Conseil a ensuite pris les mesures suivantes:

   Attendu que TELNIC a déposé une demande conformément à la politique d'évaluation de services de registre de l'ICANN pour modifier l'accord de registre .TEL et permettre l'attribution de noms de domaine uniquement numériques (à l'exception des noms à un seul chiffre) dans .TEL.

   Attendu que .TEL est l'un des deux seuls gTLD non autorisés pour le moment à attribuer des noms de domaine uniquement numériques.

   Attendu que l'ICANN a évalué la proposition de modification de l'accord de registre .TEL en tant que nouveau service de registre conformément à la politique d'évaluation de services de registre, qu'elle n'a pas identifié de problématiques relatives à la sécurité, la stabilité ou la concurrence et a publié en ligne une modification sollicitant les commentaires du public et l'examen de la part du CA (voir http://www.icann.org/en/announcements/announcement-14oct10-en.htm).

   Attendu que les problématiques potentielles citées lors de la période de consultation publique et par l'ICANN ont été abordées de manière adéquate dans les réponses de Telnic.

   Attendu que l'approbation de la proposition augmenterait les options disponibles pour les titulaires de noms de domaine souhaitant enregistrer leurs noms de domaine dans .TEL.

   IL EST RÉSOLU (2011.01.25.21), que la modification visant à permettre l'attribution de noms de domaine uniquement numériques (à l'exception des noms à un seul chiffre) dans .TEL soit approuvée et que le président et le conseiller soient autorisés à prendre les mesures appropriées pour mettre en œuvre la modification.

   Douze membres du CA ont voté en faveur de la résolution 2011.01.25.21.  Sébastien Bachollet, Bertrand de La Chapelle, Rita Rodin Johnston et Mike Silber se sont abstenus de voter sur la résolution. La résolution a été adoptée.

   Thomas Narten a demandé que la justification proposée soit modifiée pour inclure des renseignements historiques sur l'introduction des noms de caractère unique dans les TLD, et le président et Bruce Tonkin ont confirmé cette demande. Le personnel a accepté de présenter les informations complémentaires dans la justification fournie à la Commission avec le compte-rendu de la réunion proposée.

   Justification de la résolution 2011.01.25.21

   Pourquoi le CA aborde-t-il la question maintenant?

   Le 8 octobre 2010, Telnic a déposé une demande conformément à la politique d'évaluation de services de registre de l'ICANN pour modifier l'accord de registre .TEL et permettre l'attribution de noms de domaine uniquement numériques (à l'exception des noms à un seul chiffre) dans .TEL. L'ICANN a averti Telnic qu'une modification des annexes 6, liste des noms réservés et S, la charte, serait nécessaire pour mettre le nouveau service en œuvre. L'ICANN a décidé que la modification constituait un changement important de l'accord de registre; ainsi, un examen de la part du CA était nécessaire. Telnic avait présenté une demande RSEP le 11 août 2010 pour accorder des noms à un ou deux caractères ASCII et cette demande a été approuvée le 18 Novembre 2010.

   Quelles sont les propositions en cours d'examen?

   Le CA a examiné s'il devait approuver ou pas la modification proposée pour permettre l'attribution de noms de domaine uniquement numériques (à l'exception des noms à un seul chiffre) dans .TEL.

   Quelles parties prenantes ou autres ont-elles été consultées?

   La modification proposée a fait l'objet d'une consultation publique du 14 octobre 2010 au 13 novembre 2010; quatre commentaires ont été reçus, l'un était en faveur, l'un n'abordait pas les mérites de la proposition mais faisait une suggestion pour l'améliorer, l'un soulevait une problématique potentielle et le dernier était la réponse de Telnic. L'ICANN a demandé à Telnic de traiter les questions soulevées dans le cadre de la consultation publique et par l'ICANN, ce que Telnic et l'autorité déléguée de .TEL pour la mise en place de politiques, à savoir «IPAG» ont fait en soumettant deux lettres séparées à l'ICANN.

   Quelles sont les antécédents des noms de domaine d'une seule lettre?

   Comme indiqué dans le rapport final du groupe de travail pour les noms réservés du GNSO, daté du 23 mai 2007 («RN-WG Rapport»), «[il] semble que l'objectif initial pour réserver les caractères uniques a été motivé par des préoccupations techniques», que le rapport concluait ne sont plus applicables. Les problèmes techniques ont été largement considérés comme centré en réservant des chaînes d'une seule lettre au deuxième niveau pour permettre l'expansion future de l'espace du nom. À la lumière de cette conclusion, le rapport RN-WG a recommandé «que des lettres simples et chiffres seront publiés au deuxième niveau dans les TLD génériques futurs, et que ceux qui sont actuellement réservés dans les TLD génériques existants devraient être libérés.» Le rapport du RN-WG Report se trouve sur http://gnso.icann.org/issues/new-gtlds/final-report-rn-wg-23may07.htm.

   Comme le RN-WG a publié son rapport en 2007, huit (c'est-à-dire .BIZ, .COOP, .INFO, .JOBS, .MOBI, .PRO, .TEL, et .TRAVEL) des dix-sept registres gTLD sous contrat avec l'ICANN ont demandé (via des demandes RSEP) et ont reçu l'approbation pour la libération de noms à caractère unique du second degré. Les registres qui ont été approuvés pour attribuer ces noms précédemment réservés le font par une demande de propositions, des ventes aux enchères, et des mécanismes du premier arrivé, premier servi.

   Quelles préoccupations ou problématiques ont-elles été soulevées par la communauté?

   Un des commentaires posait la question suivante: 1) si la proposition pouvait constituer un changement fondamental du TLD ; et, accessoirement, 2) si l'autorité déléguée de mise en place de politiques était suivie.

   Quels documents importants le CA a-t-il examiné?

   Lors de l'examen de la modification proposée, le CA a passé les documents suivants en revue: la demande de Telnic pour un nouveau service de registre <http://www.icann.org/en/registries/rsep/telnic-request-08oct10-en.pdf> [PDF, 33 KB]; la modification proposée sujette à une résolution du CA <http://www.icann.org/en/tlds/agreements/tel/proposed-tel-amendment-2-14oct10-en.pdf> [PDF, 65 KB]; les commentaires publics ayant rapport à la modification <http://forum.icann.org/lists/tel-numeric-only-domains/>; une lettre de la part de l'IPAG de .TEL abordant les questions soulevées <http://www.icann.org/en/registries/rsep/conroy-to-pritz-25nov10-en.pdf> [PDF, 644 KB]; et une lettre de la part de Telnic abordant les questions soulevées <http://www.icann.org/en/registries/rsep/mahdavi-to-schwartz-07jan11-en.pdf> [PDF, 80 KB].

   Quels facteurs le CA a-t-il trouvé importants?

   1. L'ICANN a examiné les seuils de sécurité, stabilité et concurrence liés au service proposé conformément à la RSEP et n'a identifié aucune problématique d'importance. Les noms de domaine uniquement numériques ont été autorisés dans 14 gTLD et plusieurs ccTLD depuis des années sans préjudice pour la sécurité ou la stabilité de l'Internet. D'un point de vue purement technique, il n'y a pas de différence sur ce pour lequel un TLD permet des noms uniquement numériques. Il n'y a donc pas de problème créé par cette proposition. L'ICANN a averti Telnic qu'une modification des annexes 6, liste des noms réservés et S, la charte, serait nécessaire pour mettre le nouveau service en œuvre.

   En outre, les recommandations RN-WG (notées ci-dessus dans l'histoire) pour les nouveaux gTLD incluaient que des chaînes simples et de deux caractères exclusivement numériques devaient être réservés au niveau supérieur en raison de préoccupations techniques. La RN-WG a remarqué en outre que «si une recherche suffisante à une date ultérieure montre que les problèmes techniques et les préoccupations sont abordées, la question du statut de réserve de libération peut être revue."  La recommandation RN-WG également incluait que ces noms soient libérés au deuxième niveau dans les TLD génériques futurs, et que ceux qui sont actuellement réservés dans les TLD génériques existants devraient être libérés. La RN-WG n'a pas abordé les chaînes numériques uniques au-delà de deux caractères car ils sont déjà autorisés dans la majorité des registres gTLD et ne soulèvent pas de problèmes techniques. Les registres qui ont des restrictions contre les chaînes numériques uniques le font à leur discrétion comme un élément contractuel de leur accord d'enregistrement avec l'ICANN.

   2. La modification proposée a fait l'objet d'une consultation publique du 14 octobre 2010 au 13 novembre 2010; quatre commentaires ont été reçus, l'un était en faveur, l'un n'abordait pas les mérites de la proposition mais faisait une suggestion pour l'améliorer, l'un soulevait une problématique potentielle et le dernier était la réponse de Telnic. La période de consultation publique n'a pas produit d'opinion consensuelle claire sur le fait que la modification devrait être approuvée ou pas ; la contribution de chacun des commentateurs suggérait une voie différente, et certaines problématiques, décrites ci-dessus, ont été remarquées.

   3. Le commentaire exprimé par Tim Ruiz (bureau d'enregistrement GoDaddy.com, Inc.) suggérait que la proposition pouvait constituer un changement essentiel du but du TLD. Ruiz ajoutait aussi que la promesse de Telnic de ne pas permettre des enregistrements de deuxième niveau uniquement numériques était un aspect fondamental de sa candidature et la raison principale pour laquelle .TEL avait été accordé à Telnic et non pas à Pulver (un autre candidat pour le sTLD .TEL à l'époque). Il concluait en disant que cette demande ne devrait pas être accordée sans un nouvel appel d'offres pour le sTLD .TEL même, qui donnerait ainsi la possibilité à d'autres offrants de participer à la compétition.

   4. Khashayar Mahdavi, PDG de Telnic Limited (registre .TEL) a soumis une réponse au commentaire de Tim Ruiz. Il déclarait que la proposition ne constituait pas un changement fondamental de la nature de .TEL, puisque la restriction sur toutes chaînes entièrement numériques n'avait rien à voir avec la nature de .TEL et était une mesure mise en place pour répondre à des préoccupations initiales concernant des conflits potentiels avec le protocole ENUM. Il déclarait que le but de .TEL, tel que décrit dans sa charte, était de servir la communauté d'utilisateurs qui souhaitaient utiliser un TLD pour mémoriser et publier leurs coordonnées de contact dans le DNS.

   5. En réponse à la demande de l'ICANN, l'organe chargé de la mise en place de politiques de .TEL, à savoir l'IPAG, a fourni des informations supplémentaires dans une lettre datée du 25 novembre 2010, expliquant le processus d'élaboration de politique et d'approbation qui avait été suivi, afin d'élaborer la demande RSEP.

   6.  Dans la même lettre, Lawrence Conroy, président de l'IPAG et expert réputé en protocole ENUM, expliquait pourquoi la proposition ne créait pas de problème technique avec le protocole ENUM. Conroy déclarait «dans cette proposition, les labels à un chiffre (tels que 1.tel ou 4.tel) sont réservés, au lieu de continuer à appliquer une interdiction globale de tous les labels numériques (tels que 3663.tel); ceci n'est ni nécessaire ni utile. En bloquant tous les labels à un seul chiffre, la racine d'un arbre du protocole ENUM ne peut pas être directement placée dans .tel. Le protocole ENUM ne fonctionne simplement pas avec des labels à plusieurs chiffres. Telnic n'avait pas et n'a pas l'intention de lancer une alternative au protocole ENUM et a un accord de longue date avec l'ICANN que ce sera le cas pour .tel.» (la lettre est comprise dans l'annexe).

   7. Dans une lettre rédigée par Telnic, datée du 7 janvier 2011, en réponse à la demande de l'ICANN, Telnic expliquait pourquoi elle estimait que la proposition ne provoquerait pas de confusion entre un nom uniquement numérique sous .TEL et ce qui pouvait être considéré comme étant un numéro de téléphone correspondant. Telnic remarquait que la question ne s'était pas posée auparavant, que des outils adéquats existent pour résoudre les cas de confusion réelle de l'utilisateur et/ou de représentation erronée et que d'autres TLD offraient déjà de tels noms sans restrictions ni problèmes. Enfin, Telnic notait que si une confusion des utilisateurs venait à être identifiée en tant que problème réel, l'IPAG était bien qualifiée pour s'occuper de toutes questions éventuellement soulevées.

   8. .TEL est l'un des deux gTLD auxquels il est interdit d'attribuer des noms de domaine uniquement numériques. En approuvant la proposition, .TEL serait en meilleure position de concurrencer les autres gTLD sur le marché, lesquels à leur tour, offriraient plus d'options aux titulaires de noms de domaine.

   Y-a-t-il des impacts positifs ou négatifs sur la communauté?

   En approuvant la modification proposée, le marché des gTLD deviendra plus compétitif en permettant à .TEL d'avoir une offre similaire aux autres gTLD, et, surtout, les titulaires de noms de domaine disposeront de plus d'options desquelles choisir pour enregistrer leurs noms de domaine.

   Y-a-t-il des ramifications ou des impacts fiscaux sur l'ICANN (plan stratégique, plan d'exploitation, budget); la communauté; et/ou le public?

   Il n'y pas de ramifications ou d'impacts fiscaux prévisibles sur l'ICANN (plan stratégique, plan d'exploitation, budget); la communauté ; et/ou le public.

   Y-a-t-il des questions de sécurité, de stabilité ou de résilience liées au DNS?

   Le service proposé ayant rapport avec la modification a fait l'objet d'une révision préliminaire relative à la sécurité et la stabilité conformément à la politique d'évaluation des services de registre. L'ICANN n'a pas identifié de questions de sécurité, de stabilité ou de concurrence: http://www.icann.org/en/registries/rsep/arias-to-shadrunov-14oct10-en.pdf [PDF, 53 KB].

6. RAPPORT DU PDG

   Le Conseil a reçu un rapport du PDG sur les progrès accomplis depuis la réunion de Cartagena. Le PDG a remercié le Conseil pour sa reconnaissance du travail préparatoire accompli par le personnel avant la consultation du Conseil/GAC. Le PDG a également fourni une mise à jour sur la planification de la réunion de Silicon Valley/San Francisco, y compris l'augmentation des possibilités de parrainage disponible lors de cette réunion comme un moyen pour améliorer l'événement tout en gardant le montant de budget de l'ICANN bas.

   Le président a remercié le PDG pour le travail pour inclure une justification dans les documents du CA, et les travaux de conseil du GAC.

   Bruce Tonkin a remarqué qu'il y avait des préoccupations de la communauté en ce qui concerne le saut dans les niveaux de parrainage, et il a demandé si les niveaux mis en place pour la réunion de Silicon Valley/San Francisco devraient demeurer stable pour les réunions futures de l'ICANN.

   Le PDG a remarqué que les possibilités de parrainage fournissent aux entreprises un moyen de se promouvoir et de développer les marques, et que c'est un moyen de couvrir les coûts et/ou mettre à jour les réunions de l'ICANN. Le PDG a cité le modèle des réunions de l'IGF entièrement auto-financées, tout en reconnaissant que l'histoire des réunions de l'ICANN exige qu'il y ait un certain niveau de financement et de soutien technique disponible pour la cohérence. Pour mettre à jour la réunion de Silicon Valley sans augmenter le budget, une catégorie supérieure de parrainage a été créée. Le président a remarqué qu'avant de déterminer les niveaux de parrainage pour les réunions futures, il devrait y avoir un examen du programme, en mettant l'accent sur la collection de fonds pour atténuer les préoccupations budgétaires, et de le faire d'une manière qui soit équitable et transparente pour tous.

   Bertrand de La Chapelle a mis en doute la comparaison avec l'IGF, compte tenu notamment du cycle de trois réunions/an de l'ICANN, par opposition aux réunions une fois par an de l'IGF. Bertrand a soulevé la question du lien entre le niveau de parrainage et la capacité de présenter les matériels et les activités à la communauté de l'ICANN, et si l'acte de parrainer une réunion est une activité commerciale.

   Le PDG a précisé qu'il ne voyait pas les réunions de l'ICANN comme des activités commerciales - ils ne le sont pas. Plutôt le parrainage de la réunion est une activité commerciale pour ceux qui cherchent la visibilité à travers leur parrainage.

   Le président a remarqué qu'il est important de rappeler que ceux qui ne sponsorisent pas les réunions de l'ICANN y participent quand-même.

   Ram Mohan s'est renseigné sur la dotation de ressources pour soutenir le projet de gestion des variantes des IDN.

   Le PDG a remarqué que Naela Sarras avait été nommée pour remplacer Tina Dam en tant que directeur des IDN. Naela avait déjà travaillé dans le département de fonctions de l'IANA. Le PDG a également remarqué que des consultants externes seraient utilisés pour une grande partie du travail sur le projet de gestion des variantes des IDN.

   Sébastien Bachollet a fait remarquer l'activité politique ainsi que celle commerciale que le parrainage peut représenter, et la nécessité de tenir compte de ceux qui n'ont pas d'argent, qui ont également la possibilité de partager des éléments avec la communauté.

   Le PDG a précisé que les privilèges accordés aux promoteurs devraient être que des privilèges commerciaux, il n'y a pas de lien au travail politique de l'ICANN et d'autres activités de l'ICANN et de la communauté. Le PDG a demandé au Conseil de partager avec lui les préoccupations que quelque chose est livré en privilèges de parrainage qui ne devrait pas être là.

   George Sadowsky s'est renseigné de l'inclusion d'une session de 90 minutes sur le calendrier des réunions de l'ICANN pour les sponsors de haut niveau, et comment cela peut interférer avec d'autres questions prévues pour la semaine de la réunion.

   Le PDG a confirmé que la question soulevée par George était une question importante qui devrait être examinée avant de définir les possibilités de parrainage pour la réunion en Asie.

   Mike Silber a remarqué que quelques années auparavant, il avait été décidé que les réunions ne devraient pas être exécuté uniquement par le financement de sponsors locaux et ne devraient pas être perçus comme des activités à coût zéro. S'il ya un changement à cette décision, un comité du conseil devrait être impliqué dans ce travail.

   Le PDG a précisé qu'il n'y avait pas d’intention de diriger les réunions comme une activité à coût nul; l'augmentation de la possibilité de parrainage apporterait des améliorations aux réunions, et pour la réunion de Silicon Valley on couvrirait le coût de la Gala, comme cette responsabilité est de l'ICANN. Les réunions se font selon le budget approuvé par le Conseil.

   Le président a constaté l'importance de cette conversation, et il a remarqué que la participation du public pourrait examiner un bon nombre de ces questions.

   Rita Johnston Rodin a fait remarquer qu'il y avait une certaine confusion dans la communauté en ce qui concerne le changement des niveaux de parrainage, et elle demandé que le personnel soit plus explicatif et transparent dans la présentation des changements aux réunions.

   Le PDG a remarqué que l'organisation était de plus en plus professionnelle, que des inquiétudes avaient été soulevées que l'ICANN travaille pour réaliser des bénéfices, ce qui était une perception erronée. La direction travaille pour un travail à but non lucratif de classe mondiale, et s'il y avait des perceptions contraires, le PDG a proposé d'en parler au CA.

7. Plan Stratégique

   Kurt Pritz a fourni un bref exposé sur l'état du plan de travail stratégique, prévue pour approbation à la réunion de Silicon Valley/San Francisco. Kurt a remarqué qu'il y avait eu des consultations téléphoniques avec le ccNSO, le GNSO et l'ALAC, et un projet de commentaire rouge dirigé au public avait été produit. En outre, le groupe de travail du Conseil avait rencontré le personnel pour discuter les modifications au plan, y compris une meilleure identification des zones où l'ICANN contrôle les résultats et les domaines et d’autres dans lesquels l'ICANN a tout simplement l'influence - comme le nombre de TLD qui signent la racine. Un autre changement avait été celui de fournir des objectifs plus mesurables dans chaque rubrique. Il y avait des objectifs spécifiques qui avaient été ajoutés, ainsi qu'une meilleure définition des termes. Pour compléter le travail du plan stratégique, il y aurait un examen des commentaires publics récemment terminés et qu’une nouvelle version serait présentée avant la réunion de Silicon Valley/San Francisco.

8. Documents de justification

   Le conseiller et secrétaire a présenté un exposé sur le travail pour créer trois niveaux de documents de justification, fondés sur la complexité de la question à l'examen du CA, tel que représenté dans les documents de cette réunion. La première est une explication longue, qui identifie tous les points traités et considérés comme faisant partie de la décision, comme la justification de la participation croisée. La déclaration de la justification .TEL est un exemple de déclaration de deuxième niveau, qui est plus bref. Le troisième niveau de déclaration est pour les questions administratives ou des questions plus facilement considérées, pour montrer les fondements de la décision d'une manière plus brève. Le conseiller et secrétaire a appelé à une rétroaction continue du CA sur la façon dont ces documents peuvent être améliorées.

   George Sadowsky a demandé des éclaircissements sur le but de ces documents justificatifs. Montrent-ils la ligne droite de la décision, ou qu’il a été remarqué que ce travail continuera à évoluer et que des commentaires sont les bienvenus? Le Conseil a examiné la différence entre les justifications et les comptes-rendus des réunions, et la portée des documents justificatifs à présenter selon les questions examinées, les matériaux considérés, et les raisons pour lesquelles des points ont été rejetés ou acceptés.

   Rita Johnston Rodin a fait valoir sa compréhension que les justifications ne sont pas des comptes-rendus, qui indiquent des discussions et des votes. Les déclarations de justification fournissent la justification qui sous-tend les décisions du Conseil - quelles documents le CA a-t-il examiné; les arguments que le CA a entendu, les avantages et les inconvénients de la décision entreprise et d'autres éléments pertinents. Les déclarations de justification n'enregistrent pas les pensées spécifiques des membres du conseil ou la dissension.

   Le président a remarqué que le Conseil semblait être d'accord sur le but de la justification, bien qu'il y ait des décisions spécifiques prises par le CA qui pourraient exiger plus de détails, tels que les travaux sur des études économiques. George et Rita ont raison, pas tous les problèmes n’ont besoin d'un récapitulatif complet, mais il peut y avoir des moments où un niveau de détail est approprié dans une déclaration de justification. Le président a fait savoir que l'organisation continuera à améliorer cette pratique.

   Le conseiller et secrétaire a remarqué que, au sein de la discussion sur les déclarations de justification proposées, si le Conseil a constaté un détail manquant, celui devrait être soulevé. Les documents énoncent l'opinion de la majorité du Conseil.

   Le président a confirmé que le sentiment général était que la communauté veut voir un aperçu des questions examinées, les documents examinés, et pourquoi des éléments ont été rejetés ou acceptés. La position des directeurs sera consignée dans le compte-rendu.

   1. Études économiques - justification de l'adoption

      Le conseiller et secrétaire a présenté le travail accompli pour construire une justification détaillée des mesures prises par le Conseil en ce qui concerne les études économiques au sein du programme des nouveaux gTLD. Comme les membres du Conseil avaient déjà fourni quelques commentaires avant la réunion du Conseil, une note a été faite que certaines améliorations pourraient être apportées au document.

      Le président a ouvert le débat.

      Katim Touray a demandé que la résolution du Conseil précise que cette déclaration est la justification du CA, et non pas une déclaration du personnel.

      Sébastien Bachollet et Thomas Narten ont indiqué qu'ils avaient proposé des modifications rédactionnelles.

      Rita Johnston Rodin a remarqué que la déclaration proposée montre en générale la position du CA.

      Le président a invité le CA à travailler ensemble avec le conseiller sur les suggestions d'ordre rédactionnel et s'est enquis des problèmes de haut niveau que le Conseil pourrait souhaiter examiner. Le président a invité le Conseil à formuler des commentaires éditoriaux au conseiller le plus tôt possible après la réunion.

      Le conseiller a confirmé que tout commentaire serait transformé en une nouvelle version et transmis au Conseil pour examen, ensemble avec la déclaration de justification, pour être finalisé pour la publication dans le compte-rendu du Conseil. Le rapport préliminaire du compte-rendu indique que la déclaration de justification est encore en cours d'édition.

      Le président a ensuite proposé le projet de résolution, remarquant qu'il y aurait une période de fignolage du texte de la justification, et Rita Johnston Rodin l'a appuyé.

      Bertrand de La Chapelle a indiqué qu'il avait proposé des modifications au texte de la résolution et il a discuté le contenu de ses insertions proposées.

      Heather Dryden a demandé que toute résolution prise n'indique pas que le Guide du candidat sera finalisé ou approuvé à la réunion de Silicon Valley, comme ce n'est pas l'attente du GAC.

      Le président et Rita ont averti que toute résolution doit se concentrer sur l'approbation de la justification concernant la décision du Conseil sur les études économiques, et ne devrait pas aller au-delà de la portée de cette question.

      Rita a ensuite soulevé la question de la façon dont les commentaires du public de la phase 2 de l'étude économique des nouveaux gTLD seraient pris en compte, ainsi que de l'avis du GAC, si cette résolution est approuvée à la réunion.

      Le président a confirmé que, bien que l'ICANN ne fasse plus d'autres études, il écoutera attentivement tous les conseils qui seront fournis en ce qui concerne les études qui ont été achevés.

      Le PDG a remarqué qu'il est important d'écouter la communauté pour voir s'il y a d’autres idées sur la base des études entreprises à ce jour.

      Le président a corroboré avec le conseiller que la résolution avait constaté qu'il y avait un examen de la justification, qu'elle était en cours de finalisation, et qu'elle serait une partie du compte-rendu.

      Le CA a ensuite pris les décisions suivantes:

      Attendu que le 10 décembre 2010, le CA a reconnu que la question primordiale de l'appel pour l'analyse économique avait été abordée par une consultation d'experts et des analyses approfondies, y compris les rapports rédigés par CRA International, Dennis Carlton, Michael Katz et Greg Rosston. http://www.icann.org/fr/minutes/resolutions-10dec10-fr.htm#2.

      Attendu que le 10 décembre 2010, le CA a reconnu que concernant l’appel pour l'analyse économique, l'ICANN se trouvait en cours de procédure de réception et d'examen des commentaires publics et que le CA prendrait en compte ces commentaires publics, y compris les conseils du GAC et avait enjoint au personnel de procéder au changement http://www.icann.org/fr/minutes/resolutions-10dec10-fr.htm#2.

      Attendu que toutes les études économiques ont confirmé les avantages globaux de la poursuite de l'ouverture de l'espace de nommage, qui permettait l'innovation, augmentait le choix et privilégiait un environnement compétitif plus sain.

      Attendu que l'introduction de règles et de mécanismes de protection détaillés via les commentaires de la communauté dans les versions préliminaires successives du guide de candidature est le moyen le plus approprié pour minimiser les coûts potentiels liés à la mise en œuvre de cette politique et pour optimiser l'utilisation de l'espace de nommage en tant que ressource mondiale commune.

      Attendu qu'afin d'éviter le manque à gagner d'autres retards, les efforts devraient se concentrer maintenant sur la finalisation de ces mécanismes, durant la réunion du CA-GAC en février et de par l'interaction communautaire à la conférence de Silicon Valley en mars.

      Attendu que le PDG continuera à veiller à ce que le personnel prenne en compte les commentaires publics sur l'étude économique relative aux nouveaux gTLD, phase II, ainsi que les conseils du GAC en matière d'appel pour des études économiques et procède aux révisions appropriées de la version finale du guide de candidature.

      Attendu que le PDG surveillera attentivement la synchronisation de la mise en œuvre et le respect des obligations de l'ICANN selon l'affirmation d'engagements selon lesquelles si et quand les nouveaux gTLD auront été en fonctionnement pendant une année, l'ICANN organisera une révision qui examinera la mesure dans laquelle l'introduction ou l'expansion des gTLD a favorisé la concurrence, la confiance et le choix des consommateurs, ainsi que l'efficacité (a) du processus d'application et d'évaluation, et (b) des dispositifs de protection mis en place pour atténuer les problèmes liés à l'introduction ou à l'expansion.

      Attendu que le CA a pris la justification en considération dans sa prise de décision et est en cours de procédure de révision de la justification, qui fera partie du compte-rendu de cette réunion à compter de l'approbation.

      IL EST RÉSOLU (2011.01.25.22), que le CA ne commandera pas d'autres études économiques sur les nouveaux gTLD avant de prendre sa décision sur le lancement du programme de nouveaux gTLD, le CA ayant établi que la commande d'autres études économiques ne guiderait pas mieux la décision du CA.

      Quinze membres du CA ont voté en faveur de la résolution 2011.01.25.22. Rita Rodin Johnston s’est opposée à la résolution. La résolution a été adoptée.

      Rita a fait valoir sa conviction que la justification est appropriée, ainsi que la résolution, mais qu'elle est préoccupé d'une perspective de gouvernance sur le processus de discuter le cadre des résolutions à la volée. En outre, Rita a soulevé une préoccupation - comme indiqué précédemment - que le commentaire public sur cette question vient de fermer et le Conseil adopte déjà une résolution sur la base de ces commentaires.

      Justification de la résolution 2011.01.25.22

      Conformément à la résolution du CA, la justification, tel que débattu au cours de la réunion, est publiée http://www.icann.org/fr/minutes/rationale-economic-studies-21mar11-fr.pdf [PDF, 131 KB].

   2. Participation croisée - justification de l'adoption

      Le Conseil a remarqué que tous les conflits d'intérêt déclarés précédemment sur ce sujet restaient, et qu'il n'était pas nécessaire pour les membres et les liaisons en conflit de quitter la réunion pour la discussion du moment qu'ils se sont abstenus de participer à la discussion.

      Le président ouvre la discussion sur les questions de haut niveau au sein de la justification, et que la déclaration proposée englobe le débat sur la participation croisée.

      George Sadowsky a remarqué qu'il n'était pas au courant de la possibilité de présenter des commentaires préalablement, il n'avait donc pas eu la chance de fournir un libellé suggéré capable de retirer son objection. George a indiqué qu'il votera contre la résolution.

      Sébastien Bachollet a demandé que certains des problèmes de l'histoire de la participation croisée, tels que l'inclusion des termes dans les accords de registre .COM et .NET soient inclus dans la déclaration de justification.

      Le conseiller a confirmé que les informations historiques pouvaient être insérées.

      Le président a remarqué qu'il y aurait une brève période après la réunion pour fournir des suggestions de fignolage sur la déclaration de justification, qui seraient postés avec le rapport préliminaire de la réunion.

      Katim Touray a présenté des amendements proposés à la résolution à l'examen du Conseil.

      Ray Plzak a soulevé la question de savoir pourquoi le Conseil devait voter sur la justification, et pourquoi la publication d'une justification n'était pas suffisante. Ray a indiqué qu’il ne voterait pas sur la résolution en raison de ce problème.

      Le président a constaté que la position de Ray semblait être qu'il n'y avait pas besoin d'avoir un vote sur la justification, mais que Ray n'avait pas indiqué son opposition au texte même de la justification.

      Le président a ensuite proposé et Steve Crocker a appuyé la résolution suivante:

      Attendu que le 5 novembre 2010, le CA a adopté une résolution sur la question de participation croisée entre registres et bureaux d'enregistrement pour le programme des nouveaux gTLD. http://www.icann.org/en/minutes/resolutions-05nov10-en.htm.

      Attendu que le CA a révisé et examiné une justification proposée expliquant la décision du CA.

      IL EST RÉSOLU (2011.01.25.23), que le CA adopte la justification proposée comme justification de la décision du CA concernant la participation croisée entre registres et bureaux d'enregistrement dans le programme des nouveaux gTLD.

      Neuf membres du CA ont voté en faveur de la résolution 2011.01.25.23  Ray Plzak, George Sadowsky, Katim Touray et Kuo-Wei Wu se sont opposés à la résolution. Sébastien Bachollet, Bertrand de La Chapelle, Rita Rodin Johnston et Mike Silber se sont abstenus de voter sur la résolution. La résolution a été adoptée.

      Justification de la résolution 2011.01.25.23

      La justification approuvée par le Conseil est fournie ici: http://www.icann.org/fr/minutes/rationale-cross-ownership-21mar11-fr.pdf [PDF, 178 KB].

9. Consultations du CA/GAC

   1. Processus de consultations

      Le conseiller et secrétaire a décrit le travail accompli à ce jour pour former un processus proposé pour des consultations avec le GAC, en commençant par une proposition rédigée après la réunion de Cartagena, et intégrant les révisions des membres du Conseil pour créer un document de processus unique, et il a remarqué qu'il y a une discussion en cours sur la formation d'un processus.

      Le président a raconté qu'un groupe de travail du Conseil avait été créé pour répondre aux consultations, avec l'identification d'animateurs, et une série d'appels prévus pour clarifier les positions sur les questions. Le président a remarqué que l'objectif était de parvenir à une consultation avec les statuts du GAC à la réunion de Silicon Valley. Le président a expliqué que, comme la consultation de Bruxelles était si peu de temps avant la réunion de Silicon Valley, l'ICANN ne serait pas en mesure de finaliser le guide jusqu'à la réunion de San Francisco.

      Heather Dryden a fait remarquer son inquiétude que le CA semblait être prêt à adopter un processus final, tandis que le GAC s'attendait à être en mesure d'examiner, commenter et parvenir à un accord sur comment serait le processus. Dans le processus tel que prévu dans les matériaux, Heather croyait que le GAC avait des commentaires, pourtant ce serait un projet utile que le GAC y réponde. Heather a demandé que toute action sur ce point du Conseil permette une soit une occasion au GAC à influencer et à apporter des modifications au processus.

      Le président a confirmé que le Conseil ne mettrait pas en place un processus générique pour ensuite essayer à l'utiliser lors de la réunion de Silicon Valley, mais plutôt, il qu'il y aurait une consultation avec le GAC et que ceci permettrait de développer un processus générique pour l'avenir. Le président a remarqué que le Conseil n'allait pas permettre un retard pour identifier le processus idéal de consultation pour organiser les prochaines consultations des statuts qui seront nécessaires sur les.XXX et les nouveaux gTLD. Le président est convenu d'appeler le document tel que présenté au Conseil un projet, pour permettre une entrée du GAC, en remarquant que des améliorations seront probablement identifiés par le processus de consultation réelle.

      Heather a répondu qu'il y aura probablement un commentaire sur le processus proposé, et que des ajustements ultérieurs après la première consultation pourraient être utiles. Cependant, Heather s'est demandée si l'action du Conseil sur le processus proposé enverrait le message erroné que le processus avait été décidé.

      Ray Plzak a demandé si le CA pouvait identifier le processus générique comme celui qui serait utilisée que pour la première consultation, par opposition à que ce serait le processus pour toutes les futures consultations.

      Heather a déconseillé de rendre une décision que le processus proposé serait utilisé dans sa forme actuelle pour les premières consultations des statuts, en absence d'une entrée du GAC sur le processus.

      Le président a recommandé que ce point pourrait être pour discussion seulement, et Ray et Heather ont convenu qu'aucune résolution a été nécessaire à ce moment, du moment que la communication sur la formation d'un processus continuait. Le président a accepté d'envoyer le processus proposé au GAC comme une version idéalisée.

      Ray a confirmé que la suggestion du président correspondait au sens du CA, de même a fait Steve Crocker.

      Le PDG a donné son soutien pour les commentaires de Ray, et a clarifié la position du personnel sur ce point. Bien que le personnel ait préféré une définition plus précise du processus, il avait été assoupli en réponse aux commentaires de Heather concernant les préoccupations du GAC. Il est nécessaire d'avoir un processus qui montre que les statuts sont respectés, et ceci peut être atteint par un processus concis et défini. Les itérations du processus proposées ont été fournies au CA à plusieurs reprises. Le PDG a remarqué son accent sur l'importance d'avoir des processus clairs pour atteindre une réunion fructueuse à Bruxelles, comme l'ICANN dépense près d'un demi-million de dollars pour réaliser cet événement.

      Le conseiller, à l'appui de la déclaration du PDG, a remarqué que le personnel a préparé une version alternative plus serrée du processus qui pourrait être partagée avec le Conseil pour examiner et déterminer quelle version envoyer au GAC pour discussion.

      Rita Johnston Rodin a appuyé l'offre du conseiller de partager la version supplémentaire, et a demandé que les membres du Conseil aient l'occasion d'envoyer des commentaires sur les deux versions au personnel avant de prendre une décision quant à la version à envoyer au GAC.

      Le président a accepté la proposition de Rita, de sorte que le sens du CA a pu être identifié en ce qui concerne la sélection d'un processus. Le président a demandé que la variante soit fournie par le personnel, puis le Conseil travaillerait sous l’ajout ou commentaire.

   2. Nouveaux gTLD

      Le président a ensuite abordé la question spécifique de la consultation de Bruxelles sur les nouveaux gTLD, pour déclencher la consultation des statuts à San Francisco.

      Heather Dryden a remarqué que les documents présentés au Conseil au sujet d'un processus proposé pour la consultation de Bruxelles sur les nouveaux gTLD n’avaient pas encore été approuvés par le GAC, et qu'elle n'avait pas encore vu la documentation. Bien que la documentation reflète un bon nombre des conversations entre elle et le président du conseil, il y avait des éléments qui nécessitent une réflexion plus approfondie du GAC et un raffinement. Heather a déclaré que l'information aurait dû être présentée plus tôt et ne pas faire partie d'un paquet de documents du CA, et comme le GAC n'avait pas eu l'occasion d'examiner ces documents et commentaires, Heather a demandé que les documents ne soient pas publiés. Il y a certains points dans les documents sur lesquels le CA et le GAC ne concordent pas. Heather a également proposé un libellé de rechange pour la résolution du Conseil sur ce sujet pour préciser que le Guide du candidat ne sera pas finalisé et approuvé lors de la réunion de Silicon Valley, contre les attentes du GAC. Le GAC considère qu'il y a toujours des problèmes significatifs et substantiels avec le guide du candidat, bien qu'il ne cherche pas à rouvrir la conversation sur toutes les questions.

      Le président a confirmé que les modifications à la résolution de Heather pourraient être considérées, pourvu que la consultation des statuts soit serrée par cet amendement.

      Gonzalo Navarro a demandé que cette consultation d’amendement déclenchant des statuts soit très claire.

      Le conseiller a donné la langue pour répondre aux demandes du CA.

      Le président a proposé et Mike Silber a appuyé la résolution suivante:

      Attendu que le Conseil d'administration de l'ICANN et le comité consultatif gouvernemental de l'ICANN (GAC) ont programmé une réunion du 28 février au 1er mars 2011 à Bruxelles, en Belgique («réunion») pour discuter autour d'une liste de questions soulevées par le GAC et ayant rapport avec le programme de nouveaux gTLD comme suit («sujets»):

      • Les procédures d'objection y compris les exigences pour le paiement de frais de la part des gouvernements;
      • Procédures pour la révision des chaînes sensibles;
      • Extensibilité de la zone racine;
      • Marché et impacts économiques;
      • Séparation registre - registrar;
      • Protection des ayants droit et questions relatives à la protection des consommateurs;
      • Différends avec les gouvernements après la délégation;
      • Usage et protection des noms géographiques;
      • Recours légal pour les candidats;
      • Fourniture de possibilités à toutes les parties prenantes y compris celles provenant des pays en développement;
      • Recommandations de diligence dans l'application de la loi pour amender l'accord d'accréditation de bureau d'enregistrement tel que noté dans le communiqué de Bruxelles; et
      • Le besoin de mise en garde précoce des candidats lorsqu'une chaîne proposée pourrait être considérée comme controversée ou donnant lieu à des sensibilités (y compris les noms géographiques).

      Attendu que la réunion n'est pas voulue être la consultation stipulée dans l'article XI, section 2, paragraphe 1(j) des règlements de l'ICANN.

      Attendu que le CA souhaite faire en sorte que la consultation stipulée par les règlements ait lieu dans le cadre de la conférence de l'ICANN à Silicon Valley/San Francisco («SV/SF») prévue du 13 au 18 mars 2011.

      Attendu que le CA a pour intention que la consultation stipulée par les règlements dans le cadre de la conférence SV/SF soit limitée aux sujets discutés au cours de la réunion.

      Il est résolu (2011.01.25.24), que le Conseil d'administration décide par la présente qu'il a l'intention de progresser vers un lancement du programme des nouveaux gTLD, aussi proche que pratiquement possible de la forme établie dans la version finale proposée du guide de candidature.

      Il est résolu (2011.01.25.25), que le CA décide par la présente de prendre des mesures concernant les sujets mentionnés ci-dessus qui, pour le moment, ne sont pas en accord avec les conseils du GAC.

      Il est résolu (2011.01.25.26), que le Conseil d'administration de l'ICANN déclenche par la présente la consultation stipulée dans les règlements de l'ICANN, article XI, section 2, paragraphe 1(j), qui aura lieu le jeudi 17 mars 2011, dans le cadre de la conférence SV/SF de l'ICANN.

      Il est résolu (2011.01.25.27), que la consultation stipulée par les règlements déclenchée ci-dessus, soit limitée aux sujets débattus lors de la réunion concernant lesquels le CA n'a pas changé de position au cours ou après la réunion, et qui continuent à ne pas être en accord avec les conseils du GAC.

      Tous les membres du Conseil présents ont approuvé les résolutions 2011.01.25.24, 2011.01.25.25, 2011.25.26 et 2011.25.27.

      Heather Dryden a réitéré sa préoccupation que le processus inclus dans le livre du Conseil ne soit pas publié, comme la déclaration que les documents représentant l'accord actuel des parties n'est pas tout à fait exacte. Les documents ne devaient pas être publiés sans l'apport du GAC et l'incorporation des observations du GAC.

      Le président a confirmé que lui et Heather poursuivraient un dialogue sur ce sujet.

      Sébastien Bachollet a ensuite demandé si le soutien de voyage pourrait être ajouté pour les présidents des organisations de parrainage de l'ICANN et des comités consultatifs pour assister à la consultation de Bruxelles.

      Le président a déclaré qu'à son avis, tout en ayant les présidents SO et AC en ligne pourrait être utile, les présidents ne sont souvent pas les autorités sur tous les sujets spécifiques identifiés pour la discussion et qu’on devrait se centrer sur la consultation avec la participation d'experts. Le président du Conseil a de manière informelle interrogé sur le sujet, et beaucoup étaient opposés à l'idée.

      Le président a remarqué que, même si, à première vue, cela semblait être une bonne idée, il n'y a aucune garantie qu'ils seraient en mesure de contribuer au débat, et que de les avoir à une réunion où ils ne peuvent rien dire semblait un niveau élevé de coûts sans en gagner beaucoup.

      Steve Crocker a demandé si tous les présidents effectivement voulaient venir, de sorte que l'ICANN ne donnerait pas l'impression qu'ils sont tenus d'y assister. La réunion est déjà très nombreuse. Cependant, Steve a indiqué que s'il y avait une situation où un président devrait vraiment participer, mais ne se le pouvait pas permettre, il pouvait être approprié à convenir quelque aide.

      Sébastien a déclaré qu'il était au courant d'au moins trois personnes qui tentaient de participer, même s'il n'y avait aucun soutien de voyage de l'ICANN. Sébastien a soulevé le problème de montrer à la communauté que l'ICANN soutien qu'une partie de la communauté.

      Bruce Tonkin a remarqué qu'inviter que les présidents pouvait créer plus de problèmes que ceux qui sont résolus, du moment que d'autres voudront y assister. La réunion sera entièrement transcrite. Aucune décision ne sera prise à Bruxelles. La Consultation du GAC n'est pas destinée à être un dialogue avec la communauté en général, mais un dialogue entre le Conseil et le GAC, qui est ouvert à écouter tous.

      Le président a convenu avec Bruce, en soulignant l'idée que la réunion de Bruxelles n'est pas une consultation de la collectivité. Le président a remarqué que, comme il ne semble ne pas y avoir un soutien pour ajouter le support du voyage sous la forme proposée, la conversation sur ce point pourrait se poursuivre encore en ligne.

      Justification des résolutions 2011.01.25.24 – 2011.01.25.27

      Le CA et le GAC ont tous les deux identifié un besoin d'avoir une consultation concernant les questions en suspens ayant rapport avec le lancement proposé du programme de nouveaux gTLD. Les deux parties ont convenu qu'il s'agissait du bon moment pour avoir cette consultation. Le CA passera tous les documents (y compris les documents justificatifs et les références) qui ont été préparés pour la réunion en revue, prenant en considération les conseils du GAC. De plus, le CA a consulté toutes les parties prenantes par le biais du processus de publication en ligne et de révision de chaque version du guide du candidat en fonction des problématiques identifiées par le GAC. Les problématiques particulières soulevées par le GAC qui seront abordées à la réunion se trouvent dans le communiqué du GAC de Carthagène. http://gac.icann.org/press-release/gac-2010-communique-39.

      La tenue de la réunion et de la consultation stipulée par les règlements entre le CA et le GAC devrait avoir un impact positif sur la communauté. Elle assure l'ensemble de la communauté que le CA prend très au sérieux le processus des commentaires et les exigences des règlements et espère obtenir le plus grand consensus possible.

      Comme résultat de la réunion y aura un impact fiscal important sur le budget de l'ICANN, qui nécessitera des ressources supplémentaires pour le déplacement, l'hébergement, l'espace de réunion et les dépenses y liées. Ceci comprend les dépenses pour certains des membres du GAC, les membres du CA, les membres du personnel et, éventuellement, d'autres représentants. Les membres du GAC qui ne sont pas subventionnés pour cette réunion pourraient aussi ressentir un certain impact fiscal s'ils choisissent d'assister personnellement à la réunion. Il n'y a pas de questions de sécurité, de stabilité ou de résilience liées au DNS qui résulteront du fait de l'organisation de la réunion ou de la consultation stipulée par les statuts.

   3. ICM

      Le conseiller et secrétaire a présenté une résolution qui adopte clairement la position du Conseil que les questions sur ICM sont pour une consultation des statuts avec le GAC.

      Le président a confirmé que la résolution autorisait l'envoi d'une lettre, contenant tous les documents concernant l'identification du CA des conseils du GAC sur ce sujet.

      Le PDG a proposé et Katim Touray a appuyé la résolution suivante:

      Attendu qu'à sa réunion à Carthagène, en Colombie, le CA a noté son accord avec l'évaluation préparée par le personnel concernant les conflits potentiels avec les conseils du GAC si le CA procédait avec sa décision de conclure un accord de registre avec le registre ICM pour le sTLD .XXX, et a invoqué le processus de consultation du GAC. Voir http://www.icann.org/fr/minutes/resolutions-10dec10-fr.htm#4.

      Attendu qu'au cours de la réunion à Carthagène, le GAC a recherché des déclarations affirmatives de la part du CA sur ses positions concernant les points liées à ICM.

      Attendu que dans une tentative visant à rendre aussi productive que possible une consultation future avec le GAC, la position du CA sur tous les points des conseils du GAC est clairement présentée dans un document joint.

      IL EST RÉSOLU (2011.01.25.28), que le CA enjoigne au personnel de fournir au GAC le document présentant la position complète du CA concernant les points des conseils du GAC.  Les positions du CA présentées correspondent aux points identifiées pour la consultation lors de la réunion du CA du 28 octobre 2010.

      Dix membres du CA ont approuvé la résolution 2011.01.25.28. Cherine Chalaby, Rita Rodin Johnston, Erika Mann, Rajasekhar Ramaraj et Kuo-Wei Wu n'étaient pas disponibles au vote sur la résolution. Sébastien Bachollet s'est abstenu de voter sur la résolution.

      Bruce Tonkin a ensuite demandé si la date réelle pour la consultation des statuts en la matière ICM a été définie, car elle n'était pas énoncée dans la résolution.

      Le président a remarqué qu'il n'y avait pas encore une date précise, bien qu'il semble que le GAC et le Conseil voulaient tenter de le faire à Bruxelles, s'il y avait du temps.

      Bruce a remarqué que par courtoisie pour ICM il devrait y avoir une certaine indication de la date.

      Le PDG a proposé que le 17 mars soit spécifié pour la consultation des statuts ICM, en constatant que le personnel est prêt à l'avoir plus tôt. Toutefois, s'il n'y avait pas de temps pour la consultation ICM à Bruxelles, avoir une réunion supplémentaire avant la réunion de Silicon Valley serait extrêmement coûteux, à moins que la réunion puisse se produire par téléphone.

      Bruce a déclaré que les deux seules solutions sont à Bruxelles ou à San Francisco, et le président du GAC a indiqué que l'ordre du jour pour Bruxelles est complet sur les questions des nouveaux gTLD. Bruce a recommandé qu'elle doive être officiellement prévue pour San Francisco.

      Le président a évoqué la possibilité que la consultation avec le GAC sur la question de l'ICM pouvait être très courte, si les points de désaccord sont faibles.  Le président a ensuite accepté une proposition exigeant que la consultation soit terminée au plus tard le 17 mars.

      Heather Dryden a confirmé que l'idée d'une consultation sur ICM le 17 mars avait été présentée au GAC, mais elle n'a pas eu les informations sur l'idée. Bien qu'il y ait la possibilité de programmer la consultation ICM à Bruxelles, Heather a remarqué que du moment que l’agenda était complète cela était peu probable.

      Bruce Tonkin a ensuite proposé et le PDG a appuyé la résolution suivante:

      IL EST RÉSOLU (2011.01.25.29), que le Conseil d'administration de l'ICANN établisse par la présente que la consultation sur ICM telle que déclenchée à Carthagène et tel que stipulé dans les règlements de l'ICANN à l'article XI, section 2, paragraphe 1(j), aura lieu au plus tard le jeudi 17 mars 2011.

      Dix membres du CA ont approuvé la résolution 2011.01.25.29. Cherine Chalaby, Rita Rodin Johnston, Erika Mann, Rajasekhar Ramaraj et Kuo-Wei Wu n'étaient pas disponibles au vote sur la résolution. Sébastien Bachollet s'est abstenu de voter sur la résolution.

      Justification des résolutions 2011.01.25.28 – 2011.01.25.29

      Alors que le CA a poursuivi la considération de la candidature d'ICM pour le sTLD .XXX, le 28 octobre 2010, le CA a identifié des domaines qui nécessitaient une consultation avec le GAC avant que le CA ne passe un accord de registre avec ICM, étant donné que certaines parties des conseils du GAC pouvaient ne pas être en accord avec l'action prévue par le CA. L'obligation de la part du CA de consulter le GAC ressort de l'article XI, section 2.1(j)-(k) des règlements de l'ICANN, et le CA a officiellement invoqué le processus de consultation lors de sa réunion à Carthagène. Afin de rendre la consultation aussi productive que possible, et d'aborder la préoccupation du GAC, à savoir d'être informé de la position du CA quant au fait de la mesure dans laquelle la passation d'un accord de registre avec ICM serait en désaccord avec les conseils du GAC, le document ci-joint fournit plus de détails et des citations spécifiques qui appuient la position du CA concernant chaque partie des conseils du GAC.

      La fourniture d'un document détaillé présentant la position du CA est susceptible de résulter en un impact positif sur le public. Le document présentant la position du CA fournit des détails et des explications utiles pour l'ensemble de la communauté de l'ICANN alors que les discussions autour de l'approbation anticipée d'un accord de registre pour le sTLD .XXX se poursuivent. La transmission de ce document ne donne lieu à aucun impact fiscal sur l'ICANN, la communauté ou le public. Toutefois, il pourrait y avoir des dépenses et des coûts supplémentaires encourus dans le cadre de la facilitation de la consultation entre le CA et le GAC, y compris les dépenses de déplacement et d'hébergement.  La fourniture du document présentant la position du CA n'aura aucun impact sur la sécurité, la stabilité ou la résilience du DNS.

10. Rapport sur les révisions de l'AOC y compris les recommandations de l'ATRT - prochaines étapes

    Le Conseil a tenu un appel de quorum et a estimé que onze membres votants sont demeurés présents.

    Mike Silber a demandé une réunion d’information plus complète avec le personnel, concernant les recommandations ATRT en dehors de la réunion du Conseil. Le PDG a confirmé qu'une réunion serait organisée.

    Steve Crocker a ensuite proposé et Mike Silber a appuyé la résolution suivante:

    Attendu que l'affirmation d'engagements exige que l’ICANN organise une révision - devant être achevée au plus tard le 31 décembre 2010 - de son exécution de ses engagements à maintenir et à améliorer des dispositifs solides pour la contribution du public, la responsabilité et la transparence de sorte à assurer que les résultats de ses prises de décisions reflètent l'intérêt public et soient responsables devant toutes les parties prenantes;

    Attendu que tel que requis par l'affirmation, l'équipe de révision de la responsabilité et transparence (ATRT) a soumis son rapport final au CA le 31 décembre 2010 et l'a publié sollicitant les commentaires publics jusqu'au 14 février 2011;

    Attendu que l'affirmation indique que le CA prendra des mesures relatives aux recommandations dans les six mois à compter de la réception du rapport;

    IL EST RÉSOLU (2011.01.25.30), que le CA reconnait le travail ardu et le dévouement des membres de l'ATRT de l'ICANN et remercie ces bénévoles pour leur participation à ce processus intensif et public soumis à des délais difficiles afin de produire une série détaillée de recommandations pour améliorer l'ICANN;

    IL EST RÉSOLU (2011.01.25.31), que le CA encourage le public à commenter les recommandations de l'ATRT et demande à toutes les organisations de soutien et à tous les comités consultatifs et au comité de nomination de fournir au CA des commentaires initiaux relatifs au rapport, d'ici le 14 février 2011, et que le comité consultatif gouvernemental et le comité de nomination travaillent avec le CA pour envisager les mesures à prendre concernant les recommandations ayant rapport à leurs organisations;

    IL EST RÉSOLU (2011.01.25.32), que le CA demande au personnel de l'ICANN de fournir au CA une proposition d'action du CA concernant chaque recommandation et, si possible, de proposer des plans de travail initiaux et des budgets relatifs aux recommandations, ainsi qu'un rapport d'état des efforts liés à toutes les recommandations, d'ici le 21 février 2011, prenant en compte tous les commentaires reçus.

    Dix membres du CA ont approuvé la résolution 2011.01.25.30, 2011.01.25.31 et 2011.01.25.32. Cherine Chalaby, Rita Rodin Johnston, Erika Mann, Rajasekhar Ramaraj et Kuo-Wei Wu n'étaient pas disponibles au vote sur la résolution. Peter Dengate Thrush s'est abstenu de voter sur les résolutions.

    Le président a remarqué que la raison de son abstention est due à son service sur la responsabilisation et la transparence de l'équipe d'évaluation, mais il soutient l'idée maîtresse de la résolution.

    Justification des résolutions 2011.01.25.30 – 2011.01.25.32

    Le respect de l'affirmation d'engagements nécessite que l'ICANN entreprenne la création de propositions pour la prise de mesures par le CA concernant chaque recommandation ressortant du rapport final de l'équipe de révision de la responsabilité et transparence (ATRT). Alors que ce travail est déjà en cours, l'engagement de l'ICANN à l'égard de la responsabilité et de la transparence est servi par l'intermédiaire d'un suivi transparent du processus.

    Les commentaires de la communauté concernant les recommandations finales de l'ATRT sont encore en train d'être exprimés dans le cadre du processus de consultation publique. La création d'une proposition d'action de la part du CA aura un impact budgétaire sur l'organisation. D’importantes ressources humaines seront consacrées à la création de la proposition, et la proposition elle-même identifiera d'autres considérations budgétaires dans la mise en œuvre des recommandations. Il est possible que les ressources financières de l'organisation aient besoin d'être réaffectées pour permettre un soutien suffisant en personnel afin de créer une proposition significative.

11. Nouveaux gTLD

    1. Recommandations du groupe de travail Rec6

       Kurt Pritz a remarqué que le personnel souhaitait que le CA fournisse une orientation sur cette question avant de la réunion avec le GAC à Bruxelles.

       Le président a suggéré que, en raison du manque de temps, un appel d'information pourrait être mis en place pour la discussion.

       Le PDG a confirmé qu'un appel serait mis en place sur ce point.

       Aucune mesure n'a été prise.

       En raison de contraintes de temps, d'autres éléments n'ont pas été considérés.

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