Résolutions adoptées par le Conseil | Silicon Valley / San Francisco 18 mars 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-18mar11-en.htm

*Remarque : la version préliminaire des Fondements des actions du Conseil, le cas échéant, est présentée au dessous de la Résolution associée. La version préliminaire des Fondements n'est pas définitive tant qu'elle n'a pas été approuvée avec les procès verbaux de la réunion du Conseil.

  1. Ordre du jour approuvé
  2. Approbation du Plan stratégique 2011-2014
  3. Processus pour la conclusion du Guide de candidature pour les nouveaux gTLD
  4. Révisions AOC comprenant les recommandations de l'ATRT
  5. Approbation de la candidature au registre ICM de .XXX
  6. Approbation des dépenses liées à des activités ordonnées par le Conseil
  7. Révision TLG – Mesures fondées sur le Rapport final des examinateurs indépendants
  8. Révision de la Procédure accélérée ccTLD IDN
  9. Approbation de la demande de RSEP VeriSign pour l'introduction de Chaînes composée de numérique uniquement pour le TLD .NAME
  10. Nomination d'un Médiateur intérimaire
  11. Nomination d'un audit indépendant
  12. Amendement des Statuts liés à l'ALAC : publication pour commentaires publics
  13. Chartre de regroupement d'utilisateurs non commerciaux : publication pour les commentaires publics
  14. Processus proposé pour la reconnaissance des nouveaux regroupements dans la GNSO : extension des commentaires publics

 

  1. Ordre du jour approuvé

    RÉSOLU, les résolutions suivantes de cet ordre du jour sont approuvées :

    1.1. Approbation du procès verbal de la réunion du Conseil spécial de l'Icann du 25 janvier 2011

    Résolu (2011.03.18.01), le Conseil approuve les procès-verbaux de la Réunion spéciale du Conseil de l'ICANN du 25 janvier 2011.

    1.2. Approbation des modifications à l'adhésion au SSAC

    Attendu que, le Comité consultatif pour la sécurité et la stabilité (SSAC) revoit son adhésion et procède de temps en temps à des ajustements.

    Attendu que, le Comité des membres SSAC, au nom du SSAC, demande que le Conseil nomme David Conrad au SSAC.

    Résolu (2011.03.18.02), que le Conseil d'administration nomme David Conrad au SSAC.

    Fondements de la résolution 2011.03.18.02

    Le SSAC est un groupe diversifié de personnes dont l'expertise dans des sujets spécifiques lui permet de satisfaire à sa charte et d'exécuter sa mission. Depuis sa création, le SSAC a invité les personnes ayant une connaissance et une expérience approfondies dans les domaines techniques et de sécurité qui sont cruciaux pour la sécurité et la stabilité du système de nom de domaine de l'Internet.

     Le fonctionnement continu du SSAC en tant qu'organe compétent dépend de la participation d'experts en la matière qui ont consenti à donner de leur temps et énergie pour mener à bien la mission du SSAC. David Conrad a fourni son expertise au SSAC, autant lorsqu'il était membre du personnel de l'ICANN, que plus récemment à titre d'invité. Le SSAC bénéficiera de l'engagement de David en tant que membre à part entière, ce qui permettra au SSAC d'accéder à des compétences qui sont essentielles pour qu'il assume ses responsabilités.

    1.3. Révision du ccNSO – Réception du Rapport final du Groupe de travail du conseil (GT) et dissolution du GT

    Attendu que, le Groupe de travail chargé de la révision du ccNSO a remis au Comité pour les améliorations structurelles ( - SIC) son rapport final d'activités, qui contient des conclusions et des recommandations pour renforcer l'efficacité de cette structure.

    Attendu que, le Groupe de travail chargé de la révision du ccNSO a rempli les tâches qui lui ont été confiées au moment de sa création, il peut maintenant être dissous.

    Attendu que, le Conseil est d'accord avec le SIC sur sa proposition de remercier le président et les membres du Groupe de travail pour leur engagement et leur capacité à remplir les tâches qui leur sont assignées, et

    Considérant que, le SIC fournira au Conseil une série de propositions d'actions pour répondre aux conclusions et aux recommandations du rapport final du Groupe de travail.

    Résolu (2011.03.18.03), le Conseil reçoit le rapport final du Groupe de travail chargé de la révision du ccNSO.

    Résolu (2011.03.18.04), le Conseil dissout le Groupe de travail chargé de la révision du ccNSO et remercie le président et les membres du Groupe de travail chargé de la révision du ccNSO : Jean-Jacques Subrenat (président), Ram Mohan, Demi Getschko, Alejandro Pisanty et Vittorio Bertola, pour leur engagement et leur capacité à s'acquitter de leurs tâches.

    Résolu (2011.03.18.05), le Conseil ordonne au Comité pour les améliorations structurelles de présenter un ensemble de mesures pour leur approbation lors de la Réunion du Conseil du 24 juin 2011, de manière à répondre aux conclusions et aux recommandations formulées dans le rapport final du Groupe de travail.

    Fondements de la résolution 2011.03.18.03-2011.03.18.05

    Les actions proposées concluent une étape importante dans le processus de révision et ouvrent la voie à la planification et à la mise en œuvre des mesures recommandées pour la réalisation de l'objectif de la révision, notamment l'amélioration du ccNSO. Ces actions peuvent être réalisées grâce aux efforts du personnel de l'ICANN existant et ne devraient pas entraîner de conséquences budgétaires. Aucun effet négatif potentiel n'a été identifié et il n'y a aucun avantage à retarder lesdites actions.

    1.4. Approbation de la révision des Statuts : Mise en œuvre du Rapport du Groupe de travail de révision du SSAC

    A. Changements dans les Statuts

    Considérant que, l'article XI, section 2, paragraphe 2 des Statuts régissant le Comité consultatif pour la sécurité et la stabilité (SSAC).

    Considérant que, dans son rapport final publié le 29 janvier 2010 <http://www.icann.org/fr/reviews/ssac/ssac-review-wg-final-report-29jan10-fr.pdf> [PDF, 210 Ko], le Comité consultatif pour la sécurité et la stabilité (SSAC) a recommandé que la zone de travail un (1) de la Charte du SSAC (section 2 (2) (a) (1) <http://www.icann.org/en/general/bylaws.htm#XI>)  devrait être supprimée car elle est hors de portée des activités du SSAC.

    Attendu que, le 12 mars 2010, le Conseil a reçu le rapport final du SSAC et a sollicité au Comité pour les améliorations structurelles (SIC) d'identifier les actions nécessaires pour répondre aux recommandations du rapport, à < http://www.icann.org/en/minutes/resolutions-12mar10-en.htm#1.6>.

    Considérant que, le SIC, lors de sa Réunion du 14 octobre 2010, a recommandé que le Statut soit modifié pour respecter la recommandation du Groupe de travail chargé de l'amélioration du SSAC en supprimant une zone de travail et en renumérotant les autres zones de travail.

    Attendu que, le SIC a également étudié la recommandation de l'examinateur du SSAC selon laquelle le Conseil devrait avoir le pouvoir de révoquer les membres du SSAC, et a recommandé que le Statut soit modifié pour tenir compte de ce pouvoir de révocation. Toute décision de révocation doit être prise en consultation avec le SSAC.

    Considérant que, dans sa résolution 2010.28.10.11 le Conseil a ordonné au personnel de publier les amendements proposés des Statuts pour une période de non moins de 30 jours.

    Considérant que, les amendements proposés ont été publiés pour être soumis aux commentaires publics pendant une période de 30 jours à compter du 3 novembre 2010 et terminant le 2 décembre 2010.

    Considérant que, le personnel a fourni au Conseil un résumé et une analyse des commentaires du public et a recommandé que le Conseil approuve les amendements du Statuts tels que publiés à < http://www.icann.org/en/general/proposed-bylaw-changes-xi-2-03nov10-en.pdf > [PDF, 60 Ko].

    Résolu (2011.03.18.06), le Conseil approuve les révisions des Statuts telle que publiée pour les commentaires du public conformément aux recommandations découlant de la révision du Groupe de travail du SSAC.

    B. Procédure pour élaborer un cadre de sécurité

    Considérant que, dans son rapport final publié le 29 janvier 2010 <http://www.icann.org/fr/reviews/ssac/ssac-review-wg-final-report-29jan10-fr.pdf> [PDF, 210 Ko], le Comité consultatif pour la sécurité et la stabilité (SSAC) a recommandé que la zone de travail un (1) de la Charte du SSAC (section 2 (2) (a) (1) < http://www.icann.org/en/general/bylaws.htm#XI >) devrait être supprimée car elle est hors de portée des activités du SSAC.

    Attendu que, le 18 mars 2011, le Conseil a approuvé l'amendement des statuts qui reflète la suppression d'une zone de travail de la Charte SSAC, qui stipule : «Pour développer un cadre de sécurité pour le services d'attribution d'adresse et de nommage d'Internet qui définisse les principaux domaines d'intervention et identifie les responsabilités pour chaque région. Le comité doit se concentrer sur les aspects opérationnels de l'infrastructure de nommage critique ».

    Attendu que, le Conseil de l'ICANN souhaite que les travaux prévus dans la zone de travail soient effectués par l'ICANN.

    Résolu (2011.03.18.07), le Conseil ordonne au Comité de gouvernance du conseil de recommander au Conseil un groupe de travail pour superviser l'élaboration d'un cadre de gestion des risques et d'un système de DNS conformément au rôle de l'ICANN tel que défini dans les statuts de l'ICANN. Le Conseil recommande que le BGC prenne en compte dans sa recommandation l'inclusion d'un membre du groupe de travail provenant du SSAC. Le Conseil demande que le BGC présente sa recommandation au Conseil lors de la réunion qui se tiendra à Singapour en juin 2011.

    Fondements des résolutions 2011.03.18.06 et 2011.03.18.07

    Les actions proposées sont en ligne avec le plan de mise en œuvre adopté à la suite de la révision du SSAC et servent à remplir les engagements pris par le Conseil à cette fin. Les changements des Statuts ont été publiés pour les commentaires publics. ucun commentaire n'a été reçu indiquant de possibles effets négatifs et il n'y a aucune raison de retarder l'adoption de l'amendement. La tâche d'élaborer un cadre de sécurité est destinée à satisfaire le désir exprimé par le Conseil que les travaux dans la zone de travail un de la Charte SSAC doivent être effectués par l'ICANN. Il n'y a aucune raison de retarder la tâche exploratoire car elle n'aura aucun impact sur le budget. Le rapport résultant de cette tâche exploratoire devra traiter explicitement les estimations de ressources, qui seront ensuite examinées et décidées par le Conseil une fois la tâche accomplie et les propositions présentées. L'approbation de l'ouverture de ladite tâche aidera l'ICANN à continuer à travailler pour maintenir la sécurité, la stabilité et la résilience du DNS.

    1.5. Approbation de l'adhésion des membres du Groupe de travail des variantes IDN

    Attendu que, le Conseil a demandé que le BGC recommande l'adhésion d'un Groupe de travail de Variante IDN du Conseil (BV-WG) pour surveiller et suivre le Projet des questions de Variante IDN. Voir Résolution (2010.12.10.31), disponible sur <http://www.icann.org/fr/minutes/resolutions-10dec10-fr.htm#7>

    Considérant que, le BGC a recommandé au Conseil d'approuver les membres suivants du Conseil pour siéger au BV-WG : Ram Mohan (président), Thomas Narten, Kuo-Wei Wu et Suzanne Woolf.

    Résolu (2011.03.18.08), le Conseil de l'ICANN approuve Ram Mohan, Thomas Narten, Suzanne Woolf et Kuo-Wei Wu en tant que membres du Groupe de travail de Variante IDN du Conseil, avec Ram Mohan comme président.

    1.6. Approbation du site de la réunion publique de l'ICANN en Amérique du Nord – octobre 2012

    Considérant que, l'ICANN a l'intention de tenir sa troisième réunion en 2012 dans la région de l'Amérique du Nord en conformité avec sa politique.

    Attendu que l'Autorité canadienne pour les enregistrements Internet (ACEI) s'est proposée pour accueillir la Réunion de l'ICANN en Amérique du Nord planifiée pour 2012.

    Considérant que, le personnel a effectué une révision approfondie de la proposition faite par l'Autorité canadienne pour les enregistrements Internet (ACEI) et l'a estimée acceptable.

    Attendu que, le Comité de finances du Conseil d'administration a examiné et approuvé le budget de la Réunion de l'ICANN en Amérique du Nord planifiée pour 2012, dont le budget ne doit pas dépasser 2,01 millions d'USD.

    Résolu (2011.03.18.09), le Conseil détermine que les réunions de l'ICANN auront lieu à Toronto, Canada du 14 au 19 octobre 2012 en tant que Réunion annuelle de 2012, et approuve un budget qui ne doit pas dépasser 2,01 millions d'USD.

    Fondements de la résolution 2011.03.18.09

    Dans le cadre du calendrier de réunions publiques de l'ICANN, l'ICANN organise trois fois par an une réunion dans une région géographique différente (tel que défini dans les Statuts de l'ICANN). La 41ème réunion, prévue du 14 au 24 juin 2011, doit avoir lieu dans la région géographique Asie-Pacifique. Un appel de recommandations pour l'emplacement de la réunion en Amérique du Nord a été publié le 1er novembre 2010. Une proposition a été reçue de la part de l'Autorité canadienne pour les enregistrements Internet (ACEI).

    Le Conseil a examiné la recommandation du personnel pour organiser la réunion à Toronto, Canada, et il a été déterminé que la proposition satisfait aux principales conditions établies dans les critères de sélection du lieu de réunion utilisés pour guider le travail de sélection du site. En dehors de l'appel des recommandations, le processus de sélection des sites ne fait pas l'objet d'une consultation publique, étant donné que la considération primordiale est l'évaluation par le personnel de la faisabilité d'un site quelconque.

    Le fait d'organiser la réunion et de fournir une aide pour le voyage le cas échéant aura un impact financier sur l'ICANN, ainsi que sur la communauté, car cela implique des frais de voyage pour certains participants à la réunion. Le fait d'accueillir la réunion n'aura aucun impact sur la sécurité ou la stabilité du DNS.

    1.7. Réunion de l'ICANN à Singapour – juin 2011

    Considérant que, l'ICANN a l'intention d'organiser sa deuxième réunion de 2011 dans la région Asie-Pacifique conformément à sa politique.

    Considérant que, le Conseil avait préalablement désigné Amman, Jordanie, comme site de la réunion de la région Asie-Pacifique de juin 2011.

    Considérant que, en raison de circonstances imprévues, le Comité exécutif du Conseil de l'ICANN a déterminé de changer le lieu de la réunion et que celle-ci ait lieu à Singapour.

    Résolu (2011.03.18.10), le Conseil ratifie l'approbation de Singapour de la part du Comité exécutif comme site de la réunion publique de l'ICANN de juin 2011.

    Fondements de la résolution 2011.03.18.10

    Dans le cadre du calendrier de réunions publiques de l'ICANN, l'ICANN organise trois fois par an une réunion dans une région géographique différente (tel que défini dans les Statuts de l'ICANN). La 41ème réunion, prévue du 18 au 24 juin 2011, doit avoir lieu dans la région géographique Asie-Pacifique. Bien que le Conseil avait déjà désigné Amman, Jordanie, comme site pour la réunion de l'Asie-Pacifique de juin 2011, des circonstances imprévues ont obligé le Comité exécutif à modifier l'emplacement de la réunion et que celle-ci ait lieu à Singapour.

    Le Conseil a examiné la recommandation pour organiser la réunion à Singapour, et il a déterminé que la proposition satisfait aux principales conditions établies dans les critères de sélection du lieu de réunion utilisés pour guider le travail de sélection du site. En dehors de l'appel des recommandations, le processus de sélection des sites ne fait pas l'objet d'une consultation publique, étant donné que la considération primordiale est l'évaluation par le personnel de la faisabilité d'un site quelconque.

    Toutes les réunions publiques promeuvent les objectifs de transparence et de responsabilité de l'ICANN. Le fait d'organiser la réunion et de fournir une aide pour le voyage le cas échéant aura un impact financier sur l'ICANN, ainsi que sur la communauté, car cela implique des frais de voyage pour certains participants à la réunion. Le fait d'accueillir la réunion n'aura aucun impact sur la sécurité ou la stabilité du DNS.

    1.8. Approbation des dates des réunions publiques de l'ICANN pour la période 2014-2016

    Attendu que, l'ICANN a l'intention de tenir des réunions en 2014, 2015 et 2016, en conformité avec sa politique.

    Attendu que, les dates proposées dans le présent document ont été publiées pour les commentaires publics pendant une période de 15 jours s'achevant le 8 mars 2011.

    Attendu que, le personnel a effectué un examen approfondi des commentaires publics reçus et les a utilisés pour élaborer le calendrier suivant concernant les dates recommandées pour les réunions de l'ICANN :

    2014

    23 - 28 mars 2014, 49ème | Europe (proposée)

    22 - 27 juin 2014, 50 ème | Amérique du Nord (proposée)

    12 - 17 octobre 2014, 51 ème | l'Asie-Pacifique (proposée)

    2015

    8 - 13 février 2015, 52 ème | l'Afrique (proposée)

    21 - 26 juin 2015, 53 ème | Amérique latine (proposée)

    18 - 23 octobre 2015, 54 ème | Europe (proposée)

    2016

    28 février-4 mars 2016, 55 ème | Amérique du Nord (proposée)

    19 - 24 juin 2016, 56 ème | l'Asie-Pacifique (proposée)

    Résolu (2011.03.18.11), le Conseil accepte les dates des réunions qui se tiendront en 2014, 2015 et 2016.

    Fondements de la résolution 2011.03.18.11

    Alors que l'ICANN continue d'examiner la structure générale des réunions et des conférences qu'il planifie, y compris le nombre, le type et la rotation géographique, il est important d'identifier et de publier les dates proposées pour les réunions de l'ICANN d'ici 2016. La publication des dates de réunion est importante pour prévenir les conflits avec d'autres événements communautaires, ainsi que pour permettre aux participants des réunions de l'ICANN de planifier leur participation.

    Les dates proposées ont été choisies en prenant soin d'éviter la superposition avec des jours fériés, des jours de fêtes importants et des célébrations dans les différents pays du monde. De même, tous les efforts ont été déployés pour identifier et prévenir de possibles superpositions avec d'autres événements communautaires. Par la suite, des recommandations du personnel ont été présentées pour être révisées par les membres du Comité de participation publique de l'ICANN, et ces recommandations ont été publiées pendant une période de 15 jours de commentaires publics. Bien que certains commentaires aient signalé des conflits de calendrier concernant deux dates de réunion en juin, il n'y a aucune autre date alternative pour ces réunions.

    Le fait d'annoncer les prochaines dates des réunions de l'ICANN n'aura aucun impact financier sur l'ICANN. Le fait d'annoncer ces dates n'aura aucun impact sur la sécurité ou la stabilité du DNS.

    1.9. Nous remercions les bénévoles du Conseil ccNSO sortant

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

    Considérant que, en reconnaissance de ces contributions, l'ICANN souhaite remercier les membres de la communauté qui arrivent à la fin de leur période de service respective dans les Organisations de parrainage et dans les Comités consultatifs.

    Considérant que, le mandat de quatre conseillers du ccNSO est arrivé à terme à la fin de la réunion de

    Ondrej Filip (mars 2005 - mars 2011)

    Mohamed El Bashir (mars 2005 - mars 2011)

    Patrick Hosein (mars 2008 - mars 2011)

    Chris Disspain (juin 2004 - mars 2011)

    Résolu (2011.03.18.12), Ondrej Filip, Mohamed El Bashir, Patrick Hosein et Chris Disspain ont gagné la profonde gratitude du Conseil pour les services prêtés pendant leurs mandats, et le Conseil leur souhaite bonne chance dans leurs futures entreprises.

    Considérant que, Chris Disspain a été choisi comme premier président du ccNSO en décembre 2004.

    Considérant que, Chris a été élu à un siège du Conseil d'administration de l'ICANN pour un mandat prenant effet en juin 2011.

    Considérant que, à la fin de la réunion de Chris quittera sa fonction de président du Conseil du ccNSO pour occuper son siège au Conseil de l'ICANN.

    Résolu (2011.03.18.12), Chris Disspain a gagné la profonde gratitude du Conseil pour ses services en tant que premier président du ccNSO.

    1.10. Nous remercions les sponsors

    Le Conseil tient à remercier les suivants :

    VeriSign, Neustar, .ORG, The Public Interest Registry, Iron Mountain, Afilias Limited, GMO Registry, Inc., AusRegistry International, China Internet Network Information Center (CNNIC), Community.Asia, united-domains AG, Internet Systems Consortium, InterNetX, NTT Communications – Global IP Network, RegistryPro, ironDNS, NameMedia et JSU RU-CENTER.

    1.11. Nous remercions les scribes, les interprètes, le personnel, les équipes engagées pour l'évènement et le personnel de l'hôtel

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

    Le Conseil souhaite également remercier la direction et le personnel de l'hôtel The Westin St. Francis, à San Francisco, pour avoir permis la réalisation de cet événement dans ses merveilleuses installations.

    1.12. Nous remercions les orateurs

    Le Conseil tient à exprimer ses remerciements aux orateurs chargés de la Cérémonie de bienvenue, Ira Magaziner, Vint Cerf, Andrew McLaughlin et Larry Strickling, pour leur soutien et leur participation à la réunion. Le Conseil souhaite aussi remercier tout spécialement l'ancien président Bill Clinton pour ses lucides contributions à la communauté de l'ICANN.

    1.13. Nous remercions les participants aux réunions

    Considérant que, le succès de l'ICANN dépend des contributions des participants aux réunions.

    Considérant que, les participants se sont engagés dans un dialogue fructueux et productif lors de cette réunion.

    Résolu, le Conseil remercie les participants pour leurs contributions.

  2. Approbation du Plan stratégique 2011-2014

    Considérant que, le Plan stratégique de l'ICANN prévu pour la période juillet 2011-juin 2014 vise à établir quatre domaines stratégiques de haut niveau pour l'ICANN.

    Considérant que, le Plan stratégique de l'ICANN prévu pour la période juillet 2011-juin 2014 identifie, outre ces quatre domaines d'intervention, des facilitateurs dans tous les domaines afin de refléter l'engagement de l'ICANN dans la création d'un modèle multipartite coopératif, international, transparent et responsable.

    Considérant que, le Plan stratégique de l'ICANN prévu pour la période juillet 2011-juin 2014 inclut des objectifs et des projets stratégiques, les détails des travaux communautaires et du personnel seront reflétés dans le plan opérationnel et les indicateurs de performance stratégique seront identifiés.

    Considérant que, le Plan stratégique de l'ICANN est basé sur des contributions de la part du personnel de l'ICANN, des organisations communautaires, du Conseil d'administration de l'ICANN, des consultations publiques sur le site Web de l'ICANN et des présentations lors de la réunion de l'ICANN à Cartagena et aux regroupements.

    Considérant que, le Plan stratégique constituera le cadre dans lequel le plan opérationnel pour la période juillet 2011-juin 2012 et le budget associé seront construits.

    Considérant que, les membres de la communauté ont été d'une grande disponibilité et que le Conseil apprécie le travail qu'ils ont accompli.

    Résolu (2011.03.18.13), le Conseil approuve le Plan stratégique prévu pour la période juillet 2011-juin 2014 et demande au président et au personnel d'avancer dans la mise en œuvre du processus de planification opérationnelle basé sur la communauté dont les objectifs stratégiques ont été énoncés dans le plan. Quelques modifications mineures seront présentées au personnel par le Conseil avant la clôture des activités lundi 21 mars 2011, et ces changements seront soumis au président pour leur approbation finale.

    Fondements de la résolution 2011.03.18.13

    Quelles sont les parties prenantes ou autres personnes ayant été consultées ?

    Dans le cadre de cette révision approfondie, l'ICANN a mené de nombreuses consultations communautaires faites pour recevoir des contributions. Ces consultations ont compris des réunions avec le Groupe de planification de stratégie et d'opérations ccNSO, le leadership de la GNSO, l'ALAC, et la RALO (séparément). Au cours de l'Atelier du Conseil d'administration de Silicon Valley qui a eu lieu récemment, le Conseil d'administration a formé un groupe de travail pour discuter de la planification stratégique et tracer une orientation générale. Ce groupe est composé de Steve Crocker, Bruce Tonkin, Katim Touray, Mike Silber, Ramaraj, Ray Plzak, Dennis Jennings (retraité), et Jonne Soininen (retraité).

    Quelles préoccupations ou questions ont été soulevées par la communauté?

    Après la période de commentaires publics (27 novembre 2010 - prolongée jusqu'au 25 janvier 2011) et les consultations réitérées, les trois domaines mentionnés ci-dessous ont été identifiés comme étant des domaines de préoccupation qui devaient être améliorés.

    1. Réorganisation des objectifs pour : (a) distinguer les zones d'influence versus zone de contrôle et (b) préciser les niveaux d'engagement.

    Sur la base consultations avec les Groupes de travail du Conseil, la formulation des premières sections de chaque domaine d'intervention a été révisée pour amplifier et clarifier le rôle  de l'influence versus le contrôle de l'ICANN dans chaque domaine d'intervention stratégique.

    2. Mettre en œuvre des objectifs plus mesurables avec : (a) une définition précise des résultats souhaités et (b) un modèle d'évaluation systématique.

    Des paramètres de performance ont été ajoutés à chaque domaine d'intervention fournissant des données mesurables pour évaluer les progrès de l'ICANN vers les objectifs stratégiques. Des commentaires pertinents contribuant à clarifier les divers objectifs du Plan stratégique ont été incorporés. Par exemple, quelques titres ont été modifié comme suit : « Le choix des consommateurs, concurrence et innovation » a été remplacé par « Concurrence, confiance et choix des consommateurs » afin que la rédaction soit cohérente avec l'Affirmation d'engagements ; et « Un écosystème d'Internet sain » a été remplacé par : « Un écosystème de gouvernance d'Internet sain ».

    3. Réviser et reformuler le texte pour plus de clarté.

    La rédaction des sections qui décrivent les objectifs de façon plus détaillée a été standardisée et un ensemble d'objectifs stratégiques plus mesurables a été répertorié à la fin de chaque section.

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

    L'impact est positif, car la communauté verra dans le Plan stratégique actualisé que ses commentaires ont été pris en compte et que le modèle multipartite ascendant de prise de décisions est appliqué. En deuxième lieu, le Plan stratégique a été amélioré afin d'incorporer des paramètres de performance stratégiques en ligne avec les commentaires et les attentes de la Communauté.

    Ce plan comprend également 36 nouveaux paramètres de performance que l'ICANN va maintenant appliquer dans le processus de Planification opérationnel afin d'établir un lien entre le processus de Planification stratégique et les processus opérationnel et budgétaire. L'ICANN a également besoin de développer les mécanismes de suivi et de compte rendu de ces nouveaux indicateurs de performance pour assurer une plus grande transparence et responsabilité.

    Le processus de planification de cette année a été conçu pour être une version « peaufinée » du plan précédent, mais finalement il a entraîné des ajustements plus substantiels suite à la large participation et contribution de la communauté. Le processus de consultation a été modifié en conséquence, pour pouvoir incorporer l'information disponible, ce qui a retardé la date de l'approbation du plan qui était prévue à Cartagena (décembre 2010) et qui a finalement eu lieu lors de la réunion de

    Etant donné que les processus de planification futurs se traduiront par des engagements de même intensité, le cycle de Planification stratégique sera lancé plus tôt l'année prochaine. Ce cycle de planification sera publié prochainement.

    Le reste du cycle de planification annuelle comprend : l'approbation du plan stratégique, l'incorporation du plan stratégique dans le cadre du Plan opérationnel (actuellement en cours), et enfin l'élaboration du prochain budget de l'exercice financier (qui sera présenté au mois de juin pour son approbation). Un cadre du Plan opérationnel proposé a été publié ; il contient de nombreux aspects du Plan stratégique proposé.

    Dans le cadre du processus de planification de l'ICANN, le Plan stratégique adopté guide le développement du Plan opérationnel et budgétaire de l'exercice financier 2012. Historiquement, le Plan stratégique est important car il est centré sur les priorités opérationnelles du Conseil, du personnel et de la communauté pour les trois prochaines années.

  3. Processus pour la conclusion du Guide de candidature pour les nouveaux gTLD

    Attendu que le Conseil et le Comité consultatif gouvernemental ont tenu une réunion intersessionnelle à Bruxelles dans l'intention d'identifier les différences entre la mise en œuvre proposée et les conseils du GAC et, le cas échéant, parvenir à un accord sur ces questions.

    Attendu que le Conseil et le GAC ont mené des débats approfondis lors de la réunion de San Francisco afin de poursuivre leurs efforts pour parvenir à des solutions mutuellement acceptables sur les questions identifiées par le GAC dans sa fiche de suivi.

    Attendu que le Conseil a révisé et examiné les commentaires effectués par les regroupements, les parties prenantes, et les individus appartenant à la communauté en général lors de la réunion de San Francisco.

    Considérant que, l'Article XI, Section 2.1j des Statuts de l'ICANN prévoit que « Les conseils du Comité consultatif gouvernemental sur les questions de politique publique doivent être dûment pris en compte, tant dans leur formulation que dans l'adoption de politiques. Si le Conseil de l'ICANN décide d'agir contrairement à l'avis du GAC, il doit en avertir ce dernier, en précisant les raisons pour lesquelles il n'a pas respecté cet avis. Le Comité consultatif gouvernemental et le Conseil de l'ICANN essayerons alors, de bonne foi et de façon efficace et opportune, de trouver une solution mutuellement acceptable ».

    Considérant que, dans ses efforts pour implémenter le processus stipulé dans ses Statuts, l'ICANN (i) a élaboré des documents d'information préliminaires sur chacun des thèmes du GAC identifiés dans le Communiqué du GAC de Carthagène, (ii) a effectué des appels informels entre l'ICANN et des experts du GAC, ( iii) a participé à une réunion d'environ trois jours avec le GAC à Bruxelles et (iv) a révisé la fiche de suivi du GAC et l'a complétée par des commentaires exhaustifs.

    Considérant que, ces contributions ont été dûment examinées par le Conseil.

    Résolu (2011.03.18.14), le Conseil remercie le GAC pour les heures de travail consacrées à la préparation et à la tenue des récents échanges entre le Conseil et le GAC, et remercie la communauté pour son soutien et sa coopération permanente.

    Résolu (2011.03.18.15), le Conseil adopte un calendrier de travail pour compléter le guide de candidature et lancer le processus des nouveaux gTLD tel que publiée au http://www.icann.org/en/minutes/draft-timeline-new-gtlds-18mar11-en.pdf [PDF, 117 Ko].

    Résolu (2011.03.18.16), comme indiqué dans le calendrier, l'ICANN a établi que le 15 avril 2011 serait la date de la publication d'une réponse finale à la fiche de suivi du GAC, ainsi que celle des parties du Guide de candidature qui ont était modifiées.

    Résolu (2011.03.18.17), le Conseil a l'intention de terminer le processus prévu en respectant la date fixée, en laissant le temps nécessaire au Conseil de l'ICANN pour l'approbation finale du programme de mise en œuvre des nouveaux gTLD lors d'une réunion extraordinaire qui se tiendra le lundi 20 juin 2011, pendant la réunion de l'ICANN à Singapour. (Remarque : le Conseil a également l'intention de tenir sa réunion habituelle le matin du vendredi 24 juin 2011 afin de conclure sa réunion du milieu de l'année).

    Fondement des résolutions 2011.03.18.14 et 2011.03.18.17

    Les fondements discutés lors de la réunion du Conseil seront publiés sous forme d'ébauche avec le rapport préliminaire de cette réunion, et ensuite la version finale approuvée par le Conseil sera publiée avec le procès-verbal de ladite réunion.

  4. Révisions AOC comprenant les recommandations de l'ATRT

    Considérant que, le rapport de offre 27 recommandations visant à améliorer l'ICANN, et que l'Affirmation d'engagements exige que l'ICANN mette en œuvre les recommandations contenues dans ce rapport avant le 30 juin 2011.

    Considérant que, le Conseil a encouragé les commentaires du public et la contribution de la part des organisations de l'ICANN concernant le rapport.

    Considérant que, le personnel a fourni 27 suggestions de mise en œuvre initiales, ainsi que les budgets et les calendriers proposés pour la révision du Conseil.

    Attendu que le Conseil considère que les 27 recommandations ont le potentiel de promouvoir les objectifs de transparence et de responsabilité de l'ICANN et peuvent être mis en œuvre par l'ICANN après un examen scrupuleux et transparent et avec le soutien et les ressources nécessaires.

    Considérant que, certaines des recommandations ATRT ont un lien avec des opérations que le personnel a déjà modifiées ou est en train de modifier (grâce aux contributions de l'ATRT) et que l'application de certaines recommandations demandera davantage de temps, de ressources, et de consultations.

    Résolu (2011.03.18.18), le Conseil a reçu les plans de mise en œuvre initiale, et ordonne au personnel de les publier dès que possible.

    Résolu (2011.03.18.19), le Conseil demande que le personnel de l'ICANN lui soumette les plan finaux proposés pour la mise en œuvre des recommandations ATRT afin qu'il puisse les évaluer le plus tôt possible.

    Résolu (2011.03.18.20), le Conseil demande des informations sur le coût de la mise en œuvre de toutes les recommandations ATRT et suggère d'en tenir compte lors de la réunion du Conseil concernant l'impact estimé sur le budget de l'année financière 2012 qui se tiendra en avril 2011.

    Résolu (2011.03.18.21), le Conseil demande que le Comité consultatif gouvernemental et le Comité de nomination travaillent en collaboration avec le Conseil sur la mise en œuvre des recommandations concernant leurs respectives organisations.

    Résolu (2011.03.18.22), pour répondre pleinement aux obligations énoncées dans l'Affirmation d'engagements, le Conseil demande au personnel de l'ICANN de proposer des paramètres pour quantifier et contrôler les activités prévues dans l'Affirmation d'engagements et dans le rapport de l'ATRT, et les points de référence qui permettent à l'ICANN de comparer ses efforts pour garantir la responsabilité et la transparence avec les meilleures pratiques des organismes internationaux.

    Fondements des résolutions 2011.03.18.18 et 2011.03.18.22

    Comme le requiert l'Affirmation d'engagements, les recommandations de (ATRT) ont été transmises au Conseil le 31 décembre 2010 et publiées pour être soumises aux commentaires publics. L'ATRT fournit un rapport constructif qui est fondé sur les engagements et les améliorations de l'ICANN et qui les valide. Le Conseil a encouragé les contributions de la communauté, y compris des Organisations de soutien, des Comités consultatifs et du Comité de nomination, et il a révisé les contributions du personnel et proposé des plans de mise en œuvre. Les commentaires publics étaient en faveur du rapport de l'ATRT, la diligence due du personnel a donné lieu à la recommandation pour que l'ICANN continue à faire les efforts nécessaires pour mettre en œuvre les 27 recommandations de l'ATRT.

    Le Conseil considère que ces recommandations : ont le potentiel de promouvoir les objectifs de transparence et de responsabilité de l'ICANN qui sont énoncés dans l'Affirmation d'engagements et dans les Statuts de l'ICANN; peuvent être mises en œuvre par l'ICANN (en attendant l'assignation de ressources) et ne semblent pas affecter négativement la sécurité, la stabilité et la résilience systémiques du DNS. Le Conseil a demandé au personnel de travailler avec les organisations concernées et d'élaborer des plans de mise en œuvre pour les soumettre à l'approbation du Conseil. Il observe que l'ICANN a déjà fait des progrès concernant la mise en œuvre de plusieurs changements opérationnels demandés par l'ATRT.

    Enfin, le Conseil a demandé au personnel de développer des paramètres et des points de référence pour l'évaluation. Sans un accord basé sur des actions claires et mesurables, les efforts futurs pour améliorer la transparence et la responsabilisation pourraient s'avérer insuffisants.

  5. Approbation de la candidature au registre ICM de .XXX

    Considérant que, le 25 juin 2010, après avoir reçu de nombreux commentaires du public concernant les options disponibles pour l'ICANN pour considérer la Déclaration du panel de révision indépendant du 19 février 2010, le Conseil de l'ICANN a accepté (en partie) les conclusions du Panel. Le Conseil a ensuite demandé au personnel « de conduire des opérations de diligence due pour assurer que : (1) la candidature du registre ICM est toujours valable et (2) il n'y a aucun changement dans les qualifications ICM ».

    Considérant que, le personnel de l'ICANN a agi avec la diligence due démontrant que la candidature au registre ICM est valable et qu'il n'y a eu aucun changement négatif dans les qualifications d'ICM.

    Considérant que, le registre ICM a proposé à l'ICANN un nouvel accord de registre comprenant des dispositions, des exigences et des garanties supplémentaires pour répondre aux questions que le GAC et d'autres membres de la communauté avaient soulevées concernant l'accord proposé au préalable.

    Considérant que, l'accord de registre proposé et le matériel de due diligence ont été publiés pour être soumis aux commentaires du public. Plus de 700 commentaires ont été reçus, bien que peu d'entre eux portaient sur la formulation de l'accord de registre. Aucune modification de l'accord de registre n'a été recommandée en réponse aux commentaires.

    Considérant que, le 10 décembre 2010, le Conseil a manifesté son accord envers une évaluation qui suggérait que la validation de l'accord de registre proposé n'était en contradiction qu'avec trois points des recommandations du GAC et a ordonné au personnel de communiquer cette information au GAC.

    Considérant que, le 10 décembre 2010, le Conseil a déterminé qu'il envisageait de conclure un accord de registre avec le Registre ICM pour les sTLD .XXX, soumis à la considération du GAC, et a ainsi invoqué la consultation prévue dans l'article XI, section 2, paragraphe 1 (j) des Statuts de l'ICANN. Voir <http://www.icann.org/fr/minutes/resolutions-10dec10-fr.htm#4>.

    Considérant que, pour faciliter la consultation des Statuts avec le GAC le 25 janvier 2011, le Conseil a demandé au personnel de transmettre au GAC une lettre énonçant clairement la position du Conseil sur la façon dont l'accord de registre proposé par ICM satisfait à certains aspects des recommandations du GAC, et énumérant les questions liées aux conseils du GAC qui restent en suspens. La lettre a été transmise le 11 février 2011 et elle est disponible sur le site Internet < http://www.icann.org/en/correspondence/jeffrey-to-to-dryden-10feb11-en.pdf > [PDF, 236 Ko].

    Attendu que, le 16 mars 2011 le GAC a transmis une lettre du Conseil clarifiant les recommandations du GAC concernant la question ICM.

    Attendu que le Conseil a évalué attentivement les commentaires provenant de la communauté et du CAG avant de prendre cette décision, en concordance avec la mission de l'ICANN.

    Considérant que, le 17 mars 2011, le Conseil et le GAC ont consulté formellement les Statuts de l'ICANN concernant les aspects de l'accord de registre qui pourraient être incompatibles avec les conseils du GAC.

    Résolu (2011.03.18.23), le Conseil autorise le CEO ou le Conseiller général à signer l'accord de registre proposé pour les sTLD .XXX dans essentiellement la même formulation qui a été publiée et soumise aux commentaires publics en août 2010.

    Résolu (2011.03.18.24), le Conseil adopte et intègre pleinement les Fondements pour l'Approbation de l'accord de registre avec ICM pour les sTLD .XXX <http://www.icann.org/fr/minutes/draft-icm-rationale-18mar11-fr.pdf> [PDF, 1.07 Mo] afin de soutenir la conclusion de l'accord de registre proposé.

    Résolu (2011.03.18.25), le Conseil et le GAC ont complété une consultation de bonne foi en vertu de l'Article XI, Section 2.j des Statuts de l'ICANN. Étant donné que le Conseil et le GAC ne sont pas parvenus à une solution mutuellement acceptable, conformément à l'Article XI, Section 2.k des Statuts de l'ICANN, le Conseil incorpore et adopte, comme indiqué dans les Fondements, les raisons pour lesquelles les conseils du GAC n'ont pas été suivis. La déclaration du Conseil ne porte pas atteinte aux droits ou aux obligations des membres du GAC à l'égard de questions de politique publique relevant de leur responsabilité.

    Fondements des résolutions 2011.03.18.23 et 2011.03.18.25

    Version préliminaire du 18 mars 2011 de l'argumentaire relatif a l'approbation du contrat de registre avec l'ICM pour le STLD .XXX [PDF, 1.07 Mo]

  6. Approbation des dépenses liées à des activités ordonnées par le Conseil

    Considérant que le 29 juin 2010, le Conseil de l'ICANN a approuvé le Plan opérationnel et le budget pour l'exercice financier 2011.

    Considérant que, pendant l'exercice financier 2011 le Conseil a entrepris plusieurs activités qui n'ont pas été considérées dans le budget.

    Considérant que, le budget pour ces activités a été présenté le 13 mars 2011 au Comité de finances du Conseil (Board Finance Committee, BFC).

    Attendu que le Comité de finances du Conseil recommande au Conseil de confirmer les budgets proposés pour ces activités, tout en sollicitant au CEO de rester dans le budget global approuvé pour l'exercice financier 2011, dans la mesure du possible en utilisant pour le financement de ces activités la réserve d'urgence de 1,5 millions de dollars.

    Résolu (2011.03.18.26), le Conseil confirme que le CEO a été chargé de mener les activités pour lesquelles un budget additionnel a été recommandé par le Comité des finances du Conseil.

    Résolu (2011.03.18.27), le Conseil approuve les budgets proposés pour les activités supplémentaires suivantes de l'exercice financier 2011 pour un montant ne dépassant pas les 1.640.000 de dollars : (i) Révisions AOC; (ii) troisième retraite du Conseil; (iii) réunion du GAC; (iv) Panel Variante IDN et (v) recommandations ATRT. Le Conseil ordonne également au CEO d'utiliser la réserve d'urgence de1,5 millions de dollars pour éviter de dépasser, dans la mesure du possible, le montant total du budget approuvé pour l'exercice financier 2011 lors de la mise en œuvre des activités susmentionnées.

    Fondements des résolutions 2011.03.18.26 et 2011.03.18.27

    Le Conseil avait déjà approuvé les principales activités traitées dans la présente résolution. Au moment où le Conseil a approuvé ces activités, les budgets pour les postes supplémentaires n'étaient pas disponibles. Par conséquent, le BFC a approuvé le budget desdites activités supplémentaires et le Conseil a confirmé son approbation des activités à la lumière du budget lié à celles-ci.

    L'approbation de ces postes supplémentaires devrait avoir un effet positif au niveau du public en ce sens qu'elle accroît la transparence du montant consacré à ces activités entreprises par l'ICANN dans le présent exercice financier. Leur impact sur les finances de l'ICANN apparaît clairement dans le budget et dans le fait que son CEO a demandé que, dans la mesure du possible, le budget initial de l'exercice financier 2011 soit respecté. Cela n'aura pas d'incidence financière sur la Communauté de l'ICANN. L'approbation des postes de ces lignes budgétaires ne présente aucun impact sur la sécurité, la stabilité et la résilience systémiques du DNS.

  7. Révision TLG – Mesures fondées sur le Rapport final des examinateurs indépendants

    Considérant que, les examinateurs indépendants pour la Révision du Groupe de liaison technique (TLG) ont livré un rapport final qui contient des conclusions et des recommandations visant à renforcer l'efficacité de cette structure, notamment en abandonnant la structure actuelle et, éventuellement, en la remplaçant par des arrangements bilatéraux ou autres.

    Considérant que, le rapport a été publié et soumis aux commentaires publics, tant au stade de projet que dans sa version définitive, et que certains commentaires reçus ont soulevé des préoccupations quant à l'avenir des relations entre l'ICANN et d'autres membres de la communauté technique d'Internet.

    Attendu que, le Conseil est d'accord avec le Comité pour les améliorations structurelles (SIC) sur sa proposition visant à remercier les examinateurs indépendants et les autres personnes impliquées dans les observations et la promotion des activités de la révision pour leur engagement et leur contributions; et

    Attendu que, le Conseil est d'accord avec le SIC sur sa proposition de créer un Groupe de travail du Conseil pour analyser les mesures visant à améliorer la coordination et la coopération entre l'ICANN et d'autres membres de la communauté technique d'Internet avant de décider de démanteler le TLG.

    Résolu (2011.03.18.28), le Conseil accepte le rapport final sur la révision du TLG élaboré par le JAS Communications LLC et il remercie les examinateurs, le personnel et les membres du SIC pour leur travail de révision.

    Résolu (2011.03.18.29), le Conseil établit le Groupe de travail des relations techniques du Conseil chargé d'étudier les mesures visant à renforcer la coordination et la coopération entre l'ICANN et d'autres membres de la communauté technique d'Internet dans l'intention de, entre autres, dissoudre le TLG lors de la Réunion annuelle de 2011 ; il prie le Groupe de travail d'engager la communauté de l'ICANN dans un processus de consultation exhaustif sur la coordination et la coopération entre l'ICANN et d'autres membres de la communauté technique d'Internet.

    Résolu (2011.03.18.30), le Conseil prie le BGC de désigner cinq membres de ce groupe de travail, dont l'un au poste de Président, pour que cela soit considéré lors de la réunion du Conseil du 21 avril 2011.

    Résolu (2011.03.18.31), le Conseil demande que le SIC élabore une charte pour ce groupe de travail fondée sur le rapport de la révision du TLG, les commentaires de cette révision et les autres informations disponibles, pour qu'elle soit considérée lors de la réunion du Conseil du 21 avril 2011.

    Fondements des résolutions 2011.03.18.28 et 2011.03.18.31

    Les actions proposées représentent la conclusion d'une étape importante dans le processus de révision et ouvrent la voie à un examen attentif des mesures proposées par les examinateurs indépendants, en s'assurant que toutes les restructurations seront effectuées dans un ordre convenu par la communauté. Les actions à décider ne doivent pas entraîner de conséquences budgétaires dues à leur propre impact, ni d'effets négatifs potentiels. Il est important d'appliquer ces mesures maintenant pour préparer en temps opportun les actions de restructuration à venir qui seront soumises à l'examen et à la décision du Conseil.

  8. Révision de la Procédure accélérée ccTLD IDN

    Considérant que, le Plan de mise en œuvre final du mécanisme de Procédure accélérée ccTLD IDN a été approuvé par le Conseil de l'ICANN lors de sa réunion annuelle à Séoul, République de Corée, le 30 octobre 2009 et lancé le 16 novembre 2009.

    Considérant que, le Plan de mise en œuvre final exige une révision annuelle du processus, et que le Conseil de l'ICANN a demandé au personnel de «surveiller le fonctionnement de la Procédure accélérée ccTLD IDN à intervalles réguliers pour assurer son bon fonctionnement, et, sous réserve d'examen du Conseil, d'actualiser la procédure lorsque de nouvelles technologies ou politiques deviennent disponibles, dans le but de répondre efficacement aux besoins des demandeurs de Procédure accélérée et pour mieux répondre aux besoins de la communauté Internet mondiale ».

    Considérant que, l'ICANN a conclu la première révision de la Procédure accélérée ccTLD IDN, réalisée en deux parties : une séance publique tenue au cours de la réunion de l'ICANN à Cartagena, le 6 décembre 2010 et un forum de commentaires publics en ligne tenu du 22 octobre au 17 décembre 2010 et prolongé par la suite jusqu'au 31 janvier 2011 à la demande de la communauté.

    Considérant que l'ICANN a publié le 21 février 2011, un examen des commentaires reçus accompagné des recommandations de l'ICANN et des commentaires généraux.

    Considérant que, le Conseil constate que la Procédure accélérée est limitée dans son approche et dans les critères d'éligibilité ; tandis que la communauté travaille à résoudre les questions de politique nécessaires pour construire un processus continu de large portée, et tandis que les principales questions liées à la gestion des variantes TLD sont en cours d'étude conformément à la proposition préliminaire pour l'étude des questions liées à la délégation des variantes TLD IDN qui a été soumise aux commentaires publics.

    Résolu (2011.03.18.32), le Conseil de l'ICANN approuve les recommandations énoncées dans «Les recommandations de l'ICANN des commentaires du public reçus sur la Révision de la Procédure accélérée ccTLD IDN » et demande au CEO de mener à bien les travaux stipulés.

    Résolu (2011.03.18.33), le Conseil tient à remercier la communauté pour sa participation à la première révision annuelle de la Procédure accélérée, et à signaler que la première révision de la Procédure accélérée est terminée.

    Fondements des Résolutions 2011.03.18.32 et 2011.03.18.33

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

    Comme cela a été approuvé par le Conseil, la Procédure accélérée ccTLD IDN requiert que le personnel effectue une révision annuelle de la procédure. Le Programme de Procédure accélérée ccTLD IDN a été lancé en novembre 2009 et sa première révision a commencé en octobre 2010.

    Quelles sont les propositions à l'étude ?

    De nombreuses propositions ont été reçues par la communauté dans le cadre du processus de révision, y compris des propositions visant à modifier la nature limitée du mécanisme de Procédure accélérée. En se centrant sur les changements qui pourraient être faits pour améliorer la Procédure accélérée, tout en restant fidèle à sa nature limitée, des propositions raisonnables ont été examinées. Les principales propositions prises en considération sont celles qui sont liées aux clarifications dans la communication avec les demandeurs et à une meilleure éducation concernant le processus.

    Quelles sont les parties prenantes ou autres personnes ayant été consultées ?

    Une période de consultation publique s'est tenue du 22 octobre 2010 au 31 janvier 2011 et une session de consultation ouverte a été organisée lors de la réunion de l'ICANN de Cartagena, avec la participation interactive du public présent à Carthagène et de ceux qui participaient à distance dans le monde entier. Ces deux forums ont permis une participation communautaire importante des membres de la communauté technique du DNS et de la communauté ccTLD, ainsi que des utilisateurs individuels d'Internet.

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

    Comme détaillé dans l'annexe, il y avait des préoccupations générales quant à la nature limitée du mécanisme de Procédure accélérée ccTLD IDN. Les questions spécifiques portaient notamment sur l'absence d'un processus d'appel, sur les tables IDN et sur la transparence du processus lorsqu'une requête est en suspens. D'autres préoccupations opérationnelles portaient sur des questions telles que la confusion entre les exigences de documentation pour l'évaluation des chaînes et le processus de délégation IANA. Les travaux en cours sont actuellement effectués pour répondre aux préoccupations opérationnelles.

    Quels sont les documents importants ayant été révisés par le Conseil ?

    La mise en œuvre finale du Plan de Procédure accélérée ccTLD IDN, les commentaires publics reçus de la communauté technique du DNS, la communauté des ccTLD, les utilisateurs individuels d'Internet, et les recommandations de l'ICANN portant sur les commentaires publics reçus sur la révision du mécanisme de Procédure accélérée ccTLD IDN (http://www.icann.org/en/public-comment/fast-track-review-summary-comments-18feb11-en.pdf) [PDF, 268 Ko].

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

    Malgré sa portée limitée, le mécanisme de Procédure accélérée ccTLD IDN fonctionne bien. Depuis son lancement, le programme de Procédure accélérée ccTLD IDN a reçu des demandes de 34 pays/territoires différents ; 25 pays/territoires ont terminé la phase d'évaluation de chaîne de la Procédure, et 17 pays/territoires (représentés par 27 ccTLD IDN) ont été délégués dans la zone racine du DNS. Une série d'actions continues sont prises pour résoudre les problèmes opérationnels exprimés lors de la révision afin d'améliorer la communication avec les demandeurs. Les améliorations en cours dans le travail d'éducation et de communication, ainsi que le travail de consultation identifié par le personnel, sont importants pour assurer qu'aucun changement majeur ne doit être effectué dans le mécanisme de Procédure accélérée. En outre, le travail lié à la politique actuelle au sein du ccNSO concernant une plus grande introduction de ccTLD IDN représente un autre domaine de préoccupations qui doit soulevé et abordé.

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

    Plusieurs commentaires reçus ont été envoyés par la communauté Internet bulgare qui exprimait sa déception concernant le refus de leur candidature à une chaîne, indiquant que cela pouvait avoir un impact négatif sur cette communauté si aucun mécanisme d'appel n'est engagé dans le processus. Toutefois, en maintenant la portée limitée de la Procédure accélérée et en permettant au travail lié à la politique d'IDN de continuer sans ingérence, l'impact sur la communauté pour le maintien de la transparence de l'ICANN et de ses processus sera positif.

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

    Cela peut donner lieu à des coûts supplémentaires dans la conduite de la campagne de sensibilisation, même minimes. Une plus grande implication avec le navigateur et avec la communauté des développeurs d'applications peut exiger un plus large soutien de la communauté et des organisations de soutien. Du personnel et / ou des consultants supplémentaires seront nécessaires pour fournir une expertise afin de soutenir les travaux sur les tables ou les variantes IDN. Si des modifications substantielles au mécanisme actuel de Procédure accélérée ccTLD IDN avaient été considérées, elles auraient probablement impliqué des fonds supplémentaires.

    Y a-t-il des questions de sécurité, de stabilité ou de résilience concernant le DNS ?

    La gestion prudente du mécanisme actuel de Procédure  accélérée ccTLD IDN vise à garantir que les chaînes ne causent pas de problèmes de stabilité et de sécurité du DNS ou ne provoquent pas de confusion pour la communauté Internet. Les 25 pays et territoires qui ont mis en place la Procédure accélérée à ce jour satisfaisaient aux critères énoncés dans le Plan final de mise en œuvre pour une introduction en toute sécurité des IDN au premier niveau du DNS.

  9. Approbation de la demande de RSEP VeriSign pour l'introduction de Chaînes composée de numérique uniquement pour le TLD .NAME

    Considérant que, VeriSign a soumis une demande sollicitant aux responsables de la Politique d'évaluation des services de registre de l'ICANN de modifier l'accord de registre .NAME pour permettre l'assignation des noms de domaine uniquement composés de numériques et ceux contenant des chiffres et des traits d'union dans .NAME.

    Considérant que, .NAME est le seul gTLD qui actuellement n'est pas autorisé à assigner des noms de domaine uniquement composés de numériques et des noms contenant des chiffres et des traits d'union.

    Considérant que, après avoir évalué la proposition d'amendement de l'accord de registre .NAME en tant que nouveau service de registre conformément à la Politique d'évaluation des services de registre, l'ICANN n'a identifié aucun problème de sécurité, stabilité ou concurrence et a publié un amendement pour qu'il soit soumis aux commentaires publics et à la considération du Conseil (voir < http://www.icann.org/en/announcements/announcement-3-16sep10-en.htm >).

    Considérant que les problèmes potentiels cités au cours de la période de commentaires publics ont été correctement abordés dans la réponse de VeriSign à l'ICANN, qui a également décrit les mécanismes existants pour faire face aux problèmes mentionnés.

    Considérant que, la proposition permettrait d'accroître les options disponibles pour que les registrants puissent enregistrer des noms de domaine dans .NAME.

    Résolu (2011.03.18.34), que l'amendement qui permet l'assignation de noms de domaine uniquement numériques et contenant des chiffres et des traits d'union dans. NAME est approuvé, et que le président et le Conseiller général sont autorisés à prendre les mesures nécessaires pour mettre en œuvre ledit amendement.

    Fondements de la résolution 2011.03.18.34

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

    Le 25 août 2010 VeriSign a soumis une demande sollicitant aux responsables de la Politique d'évaluation des services de registre (Registry Services Evaluation Policy, RSEP) de l'ICANN de modifier l'accord de registre .NAME pour permettre l'assignation des noms de domaine uniquement numériques et contenant des chiffres et des traits d'union sous .NAME. L'ICANN a informé VeriSign que pour mettre en œuvre le nouveau service il serait nécessaire un amendement des Annexes 6 (Plan de noms réservés), et 11 (Restrictions d'enregistrement). L'ICANN a déterminé que l'amendement représentait une modification substantielle de l'Accord de registre et que, par conséquent, cette mesure devait être évaluée par le Conseil.

    • Quelles sont les propositions à l'étude ?

    Le Conseil a évalué l'approbation ou le rejet de l'amendement proposé afin de permettre l'assignation des noms de domaine uniquement numériques et contenant des chiffres et des traits d'union dans .NAME.

    • Quelles sont les parties prenantes ou autres personnes ayant été consultées ?

    L'amendement proposé a été soumis aux commentaires publics du 16 septembre au 16 octobre 2010; quatre commentaires ont été reçus ; l'un n'était pas lié à la proposition, l'autre n'abordait pas le fondement de la proposition, le troisième signalait deux problèmes potentiels, et le dernier était favorable à la proposition. L'ICANN a demandé à VeriSign de répondre aux questions soulevées dans le forum de commentaires publics, ce que VeriSign a fait en soumettant une lettre de réponse à l'ICANN.

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

    Les questions suivantes ont été soulevées par un intervenant au forum de commentaires publics: 1) la proposition peut-elle constituer un changement fondamental du TLD et 2) l'élargissement proposé de la définition de « Nom personnel » pourrait-il avoir un impact sur les enregistrements défensifs qui seraient requis par un titulaire de marque.

    • Quels sont les documents importants ayant été révisés par le Conseil ?

    En ce qui concerne l'amendement proposé, le Conseil a examiné les documents suivants : la demande de VeriSign pour un nouveau service de registre < http://www.icann.org/en/registries/rsep/verisign-name-request-25aug10-en.pdf > [PDF, 342 Ko]; l'amendement proposé soumis à l'approbation du Conseil < http://www.icann.org/en/tlds/agreements/name/proposed-name-amendment-15sep10-en.pdf > [57 Ko]; les commentaires publics concernant l'amendement< http://www.icann.org/en/registries/rsep/steele-to-pritz-07jan11-en.pdf >; une lettre de VeriSign abordant les questions soulevées dans les commentaires publics < http://www.icann.org/en/registries/ rsep/steele-to-pritz-07jan11-en.pdf > [PDF, 83 Ko] et une lettre de VeriSign abordant une question du Conseil <http://www.icann.org/en/registries/rsep/waldron-to-arias-28feb11-en.pdf > [PDF, 224 Ko].

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

    1. L'ICANN a mené la révision du seuil pour la sécurité, la stabilité et la concurrence du service proposé en vertu de la RSEP, et n'a pas identifié de problèmes importants. Des noms uniquement numériques ont été autorisés dans 14 gTLD et dans plusieurs ccTLD pendant des années sans que cela n'affecte la sécurité ou la stabilité de l'Internet. D'un point de vue purement technique, le TLD qui assigne des noms uniquement numériques ne fait aucune différence ; donc, cette proposition ne pose aucun nouveau problème. L'ICANN a informé VeriSign que pour mettre en œuvre le nouveau service il serait nécessaire un amendement des Annexes 6 (Plan de noms réservés), et 11 (Restrictions d'enregistrement).

    2. L'amendement proposé a été soumis aux commentaires publics du 16 septembre 2010 au 16 octobre 2010; quatre commentaires ont été reçus ; l'un n'était pas liée à la proposition, l'autre n'abordait pas les fondements de la proposition, le troisième signalait deux problèmes potentiels, et le dernier était favorable à la proposition. La période de commentaires n'a pas abouti à un consensus clair indiquant si l'amendement devait être approuvé ou pas ; chaque intervenant a suggéré une voie différente, et certains problèmes, décrits ci-dessus, ont été signalés.

    3. Un commentaire, effectué par Steven Metalitz, suggère que la proposition pourrait impliquer un changement fondamental du TLD. L'ICANN a posé cette même question à VeriSign après réception de la requête. S. Metalitz a signalé en outre que l'élargissement proposé de la définition de « Nom personnel » pourrait avoir un impact sur les enregistrements défensifs qui seraient requis par un propriétaire de marque.

    4. Pour répondre aux remarques de S. Metalitz, VeriSign a fourni des données additionnelles à l'ICANN dans une lettre du 7 janvier 2011 stipulant que « Le changement proposé pour permettre d'assigner des noms de domaines uniquement numériques et des noms contenant des chiffres et des traits d'union n'implique pas un changement fondamental du TLD .name, puisque le TLD .name continuera à être utilisé pour l'usage personnel. VeriSign a ajouté : « En outre, les chiffres dans le contexte .name sont actuellement pertinents à cause de la façon dont le Web et l'Internet sont mondialement utilisés. Dans de nombreux endroits dans le monde, notamment dans les pays en voie de développement, le téléphone portable est devenu la forme prédominante de communication et d'interface sur l'Internet. On est connu par un numéro de téléphone. Taper des chiffres sur une interface téléphonique est souvent plus facile que taper des lettres ».

    5. En outre, VeriSign a déclaré que : « les défis relatifs à l'enregistrement de noms de domaines .name uniquement numériques et de noms contenant des chiffres et des traits d'union seraient traités par le biais de la Politique de résolution de litiges pour les exigences d'éligibilité ». Finalement, VeriSign a également mentionné deux services offerts par la compagnie à la communauté de protection de marques et d'IP qui pourraient contribuer à atténuer le problème perçu. En ce qui concerne la protection des marques, il est également intéressant de noter que .NAME est destiné à l'utilisation personnelle et non pas aux entreprises.

    6. Pour répondre à une question soulevée par un membre du Conseil, VeriSign a fourni des informations supplémentaires à l'ICANN dans une lettre datée du 28 février 2011 signalant que « Le domaine de premier niveau (TLD) .name a été initialement conçu pour représenter l'identité individuelle d'une personne sur l'Internet. Plus important encore, le but du TLD .name était de disposer de domaines pour un usage personnel », ajoutant que « Depuis que le TLD [.NAME] a été introduit, la façon dont les gens s'identifient en ligne est passée de n'inclure que le nom ou le surnom d'une personne à inclure aussi les surnoms pour les avatars et les blogs ou pour différents réseaux sociaux. Dans les régions du monde en voie de développement, ou la téléphonie mobile montre une croissance rapide à cause du retard de développement de l'infrastructure de la connexion à haut débit et de la pénétration des PC, l'utilisation du numéro de téléphone mobile est devenue plus important pour accéder à Internet. Dans ces régions du monde, les données d'identité personnelle incluent le numéro de téléphone portable.

    7. Dans la lettre du 28 février 2011, VeriSign a signalé que « l'élimination de la restriction concernant les noms exclusivement numériques déterminerait la parité entre le TLD .name et tous les autres gTLD maintenant que l'ICANN a approuvé une RSEP similaire à celle de Telnic en janvier 2011. « En approuvant la proposition, le TLD .NAME serait dans une meilleure position pour rivaliser avec le reste des gTLD sur le marché, qui, à leur tour, offriraient davantage d'options aux registrants ».

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

    En approuvant la modification proposée, le marché des gTLD sera plus compétitif en permettant au TLD .NAME d'avoir une offre similaire au reste des gTLD et, plus important encore, en offrant aux registrants davantage d'options pour l'enregistrement.

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

    L'approbation de cet amendement n'a pas d'impact fiscal prévisible sur le Plan stratégique, le Plan opérationnel, le Budget, la communauté ou le public.

    •  Y a-t-il des questions de sécurité, de stabilité ou de résilience concernant le DNS ?

    Le service proposé concernant l'amendement a été soumis à la révision de la sécurité et de la stabilité préliminaire en vertu de la Politique d'évaluation des services de registres. L'ICANN n'a identifié aucun problème concernant la sécurité, la stabilité ou la concurrence : <http://www.icann.org/en/registries/rsep/arias-to-kane-09sep10-en.pdf> [PDF, 78 Ko]

  10. Nomination d'un Médiateur intérimaire

    Considérant que, Frank Fowlie, l'ancien médiateur de l'ICANN, a quitté l'ICANN le 31 janvier 2011, voir < http://www.icann.org/en/announcements/announcement-28oct10-en.htm >, et qu'une recherche a été lancée pour trouver un successeur qui remplisse la fonction définie dans l'article V des Statuts de l'ICANN.

    Considérant que Herb Waye a servi de médiateur adjoint pour l'Icann.

    Attendu que le Comité de compensation recommande que Herb Waye soit désigné comme médiateur provisoire en attendant de lui trouver un remplaçant.

    Résolu (2011.03.18.35), Herb Waye est nommé médiateur intérimaire de l'ICANN, conformément à l'article V, section 1.2 des Statuts, à compter du 1er février 2010 jusqu'à la date où le Conseil nommera un nouveau médiateur pour le remplacer.

    Fondements de la résolution 2011.03.18.35

    Étant donné que la fonction de médiateur représente un aspect important des mécanismes de responsabilité de l'ICANN, le fait de laisser le poste vacant et de ne pas avoir de médiateur risque d'avoir une répercussion publique négative. Étant donné que Herb Waye a déjà rempli cette fonction, sa nomination au poste de médiateur intérimaire aura un moindre impact sur le public pendant que la recherche de son successeur suit son cours.

    Cette nomination intérimaire implique un impact fiscal sur l'ICANN à cause du salaire et des bénéfices perçus par le médiateur intérimaire. Cet impact est minime, car ces dépenses ont déjà été incluses dans le budget opérationnel de l'ICANN.

  11. Nomination d'un audit indépendant

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

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

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

    Résolu (2011.03.18.36), le Conseil autorise le Président directeur général à engager Moss Adams LLP comme audit financier pour l'exercice terminant le 30 juin 2011.

  12. Amendement des Statuts liés à l'ALAC : publication pour les commentaires publics

    Considérant que, le 9 juin 2009 a été publié le Final Report of the ALAC Review Working Group on ALAC Improvements [PDF, 292 Ko] (Rapport final du groupe de travail de révision d'ALAC relatif aux améliorations de l'ALAC), 9 juin 2009), comprenant une recommandation visant à modifier les Statuts de l'ICANN afin de refléter l'objectif continu du Comité consultatif At-large (At-Large Advisory Committe, ALAC) au sein de l'ICANN.

    Considérant que, le 26 juin 2009, le Board resolved (le Conseil a décidé) que toutes les recommandations (à l'exception celle qui concerne l'assignation de deux Directeurs doté du droit de vote à At-Large), présentées dans le Final Report  [PDF, 292 Ko] pourraient être mises en œuvre, comme cela a été recommandé par le Comité pour les améliorations structurelles (Structural Improvements Committee, SIC).

    Attendu que, le 5 août 2010, le Board approved (le Conseil a approuvé) ALAC/At-Large Improvements Implementation Project Plan [PDF, 399 Ko] – (7 juin 2010), identifiant les paragraphes spécifiques des Statuts de l'ICANN concernant l'ALAC qui devraient être révisés, compte tenu de http://www.icann.org/fr/reviews/alac/final-report-alac-review-09jun09-fr.pdf [PDF, 292 Ko].

    Considérant que, le personnel de l'ICANN, en collaboration avec l'ALAC, a identifié et recommandé des modifications spécifiques de la section des Statuts de l'ICANN concernant l'ALAC afin de refléter l'objectif continu de l'ALAC, comme décrit dans le http://www.icann.org/fr/reviews/alac/final-report-alac-review-09jun09-fr.pdf ) [PDF, 292 Ko].

    Considérant que, le SIC a examiné les amendements des statuts proposés et il recommande au Conseil de solliciter au CEO de l'ICANN de publier les amendements proposés pour les soumettre aux commentaires publics.

    RÉSOLU (2011.03.18.37), le Conseil ordonne au CEO de l'ICANN de publier les amendements proposés pour les soumettre aux commentaires publics afin de refléter l'objectif continu de l'ALAC au sein de l'ICANN, comme décrit sur http://www.icann.org/fr/reviews/alac/final-report-alac-review-09jun09-fr.pdf [PDF, 292 Ko].

    Fondements de la résolution 2011.03.18.37

    Ces amendements des Statuts de l'ICANN clarifieront l'objectif continu du Comité consultatif At-Large (ALAC). Ils ont été recommandés par le Final Report of the ALAC Review WG on ALAC Improvements [PDF, 292 Ko](9 juin 2009), approuvé par le Conseil le 26 juin 2009. Les paragraphes des Statuts modifiés ont été identifiés dans l'"https://st.icann.org/data/workspaces/at-large-improvements/attachments/at_large_improvements_workspace:20100615224612-0-15340/original/ALAC-At-Large Improvements Implementation Project Plan (7 June 2010).pdf"  (7 juin 2010), approuvé par le Conseil le 5 août 2010. Étant donné que le Project Plan [PDF, 399 Ko] devrait être achevé vers la fin mars 2011, le moment est adéquat pour cette clarification concernant l'objectif continu de l'ALAC.

    Le personnel a consulté l'ALAC sur les amendements proposés. La publication des amendements proposés pour permettre les commentaires publics n'aura aucun d'impact fiscal, ni sur la sécurité, la stabilité ou la résilience du Système de nom de domaine (DNS).

  13. Chartre de regroupement d'utilisateurs non commerciaux : publication pour les commentaires publics

    Considérant que, on July 30, 2009 le Conseil a approuvé une Charte de transition pour le Groupe des parties prenantes non commerciales (Non Commercial Stakeholder Group, NCSG) de la GNSO.

    Considérant que, la section 8.1 de la Charte de transition du NCSG indique qu'une charte du NCSG finale sera établie au plus tard lors de la réunion du Conseil au cours de la Réunion générale annuelle de l'ICANN en 2011.

    Considérant que, les membres du NCSG ont élaboré une charte permanente pour le NCSG et consulté la direction du Comité pour les améliorations structurelles et le personnel de l'ICANN sur la Charte permanente proposée, et que le SIC recommande que, après la révision finale, la Charte proposée soit publiée pour être soumise aux commentaires publics.

    RÉSOLU (2011.03.18.38), le Conseil ordonne au CEO de publier la Charte NCSG proposée pour ouvrir un forum de commentaires publics de 30 jours. Lors de la clôture du forum, un résumé et une analyse des commentaires reçus doivent être fournis au Conseil pour être soumis à une nouvelle révision avant de passer à l'action.

    Fondements de la résolution 2011.03.18.38

    La publication de la charte proposée pour les commentaires du public contribuera à satisfaire à la directive du Conseil de 2009 exigeant une charte permanente opérationnelle pour le NCSG. Le lancement de cette consultation publique donnera à la communauté l'occasion d'examiner et de commenter une structure organisationnelle fondamentale dans la GNSO. Il n'y a pas d'impact budgétaire concernant le lancement d'une consultation publique, et le temps de travail que cela impliquera pour le personnel consacré à cette activité ne dépassera pas les paramètres normaux. La publication n'aura aucune incidence sur la sécurité, la stabilité ou la résilience du DNS.

  14. Processus proposé pour la reconnaissance des nouveaux regroupements dans la GNSO : extension des commentaires publics

    Considérant que, en juin 2008, le Conseil d'administration de l'ICANN a approuvé une série de recommandations concernant la façon d'améliorer les structures et les opérations de la GNSO, et que ces améliorations comprenaient des recommandations approuvées par le Conseil visant à clarifier et à promouvoir la possibilité pour les nouveaux regroupements GNSO de s'auto constituer.

    Considérant que, le Conseil a ordonné au personnel de l'ICANN de développer et administrer les procédures à respecter de la part d'un organisateur potentiel pour soumettre une pétition visant à l'approbation d'un nouveau regroupement de la GNSO et que les procédures initiales ont déjà été mises en œuvre.

    Considérant que, grâce à l'expérience obtenue avec ces procédures, le Comité pour les améliorations structurelles a identifié la possibilité d'améliorer ces procédures et, à cette fin, a développé un « processus de reconnaissance des nouveaux regroupements de la GNSO ».

    Considérant que le nouveau processus proposé par le SIC modifie significativement les procédures originales et a été conçu pour atteindre les objectifs suivants :

    1. Optimiser le temps et les efforts nécessaires pour former, organiser et proposer un nouveau regroupement de la GNSO par le biais d'une séquence simplifiée de démarches à suivre, d'une évaluation objective, des critères équitables et transparents et en laissant la possibilité de participer à la communauté.
    2. Déléguer davantage d'autorité à chaque groupe de parties prenantes de la GNSO pour l'évaluation de propositions de nouveaux regroupements tout en préservant le rôle de supervision du Conseil.
    3. Gérer l'ensemble du processus dans un calendrier flexible, mais spécifique, et
    4. fournir un ensemble partiel de critères à utiliser lors de la révision périodique de la GNSO.

    Considérant que, le SIC a autorisé le personnel à ouvrir un Forum de consultation publique (Public Consultation Forum, PCF) sur le processus de reconnaissance de nouveaux regroupements de la GNSO pour permettre les contributions de la communauté. Le PCF a été ouvert le 2 février 2011 pour une période initiale de 30 jours, pendant laquelle deux commentaires ont été reçus.

    Attendu que, le SIC considère que le prolongement du délai pour examiner, discuter et commenter la nouvelle procédure proposée pourrait bénéficier la communauté et que la durée du PCF devrait être prolongée.

    RÉSOLU (2011.03.18.39), le Conseil ordonne au CEO de prolonger la durée du PCF concernant le processus proposé pour la reconnaissance de nouveaux regroupements de la GNSO (http://www.icann.org/en/public-comment/public-comment-201103-en.htm#newco-process-recognition) de deux semaines supplémentaires après la clôture de la Réunion publique de l'ICANN de Silicon Valley ; c'est-à-dire, jusqu'au 3 avril 2011.

    Fondements de la résolution 2011.03.18.39

    La promotion de nouveaux regroupements de la GNSO a été une des principales recommandations après la révision de la GNSO et une stratégie importante pour élargir la participation aux efforts de développement de la politique de la GNSO. Le prolongement de la durée de ce forum de consultation publique donnera aux membres de la communauté davantage d'occasions de soumettre des commentaires sur une proposition visant à améliorer les processus existants. Ce prolongement de la période de consultation n'aura aucun impact négatif sur le budget, et la gestion ultérieure du PCF ne dépassera pas les paramètres normaux de fonctionnement. Le prolongement de la durée du PCF n'aura aucune incidence sur la sécurité, la stabilité ou la résilience du DNS.