Résolutions adoptées par le Conseil d'administration | 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/resolutions-25jan11-en.htm

This document has been translated into multiple languages for information only. The original and authoritative text (in English) may be found at: http://www.icann.org/en/minutes/resolutions-25jan11-en.htm

*Note: si disponible, une justification préliminaire des actions du CA est présentée suite à la résolution y liée. La justification préliminaire n'est finale que lorsqu'elle est approuvée avec le compte-rendu de la réunion du CA.

  1. Ordre du jour convenu
    1. Approbation du compte-rendu de la réunion extraordinaire du CA de l'ICANN 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
    3. Approbation du 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
    5. De la part du SSAC - nomination du président du SSAC
    6. De la part du SSAC - remerciements au membre sortant du SSAC - Christophe Reverd
    7. De la part du SSAC - remerciements au membre et vice-président sortant du SSAC - Ray Plzak
    8. De la part du SSAC - remerciements au président sortant du SSAC - Steve Crocker
    9. Approbation du processus de politique mondiale relative au suivi après l'épuisement d'IPv4
    10. Approbation du plan de mise en oeuvre de la révision du RSSAC
    11. Approbation de la proposition d'amendement des réglements pour la création d'un poste de président élu non votant auprès du comité de nomination
    12. Remerciements au comité de nomination 2010
    13. Approbation de la redélégation du nom de domaine .BF représentant Burkina
    14. Approbation de la redélégation du nom de domaine .CD représentant la République démocratique du Congo
    15. Approbation de la redélégation du nom de domaine .SY représentant la République arabe Syrienne
    16. Approbation de la délégation du nom de domaine .한국 (« Hanguk ») représentant la République de Corée en coréen
    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
    18. Approbation de la délégation du nom de domaine .سورية (« Souriya ») représentant la République arabe Syrienne en arabe
    19. Approbation de la délégation des sept noms de domaine de premier niveau représentant l'Inde en diverses langues

Ordre du jour principal

  1. 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
  2. Approbation de la demande de Telnic suite à 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
  3. Documents de justification
    1. Études économiques – justification d'adoption
    2. Participation croisée - justification d'adoption
  4. Consultations du CA/GAC
    1. Nouveaux gTLD
    2. ICM
  5. Rapport sur les révisions de l'affirmation d'engagements comprenant les recommandations de l'équipe de révision de la responsabilité et transparence – prochaines étapes

 

  1. Ordre du jour convenu

    Il est résolu, d'approuver par la présente les résolutions suivantes de 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.

Ordre du jour principal

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

    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, 147 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.

    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. Aprè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/en/reviews/board/board-review-final-26jan10-en.pdf [PDF, 116 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.

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

    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 l'avocat-conseil soient autorisés à prendre les mesures appropriées pour mettre en œuvre la modification.

    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.
    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 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.
    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é noté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 notait 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].

  3. Documents de justification

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

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

      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 en cours de révision et sera publiée en ligne une fois approuvée avec le compte-rendu de la réunion.

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

      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 (2010.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.

      Justification de la résolution 2010.01.25.23

      La justification débattue au cours de la réunion du CA est en cours de révision et sera publiée en ligne sous forme préliminaire avec le rapport préliminaire de cette réunion, et tel qu'approuvée par le CA avec le compte-rendu de cette réunion.

  4. Consultations du CA/GAC

    1. Nouveaux gTLD

      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 - bureau d'enregistrement ;
      • 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.

      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 en revue (y compris les documents justificatifs et les références) et qui ont été préparés pour la réunion, 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 de candidature 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.

      Il y aura un impact fiscal important sur le budget de l'ICANN compte tenu de la réunion, 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 règlements.

    2. ICM

      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.

      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.

      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.

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

    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.

    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. Des ressources humaines importantes 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.