Résolutions adoptées par le Conseil d'administration | Réunion extraordinaire du Conseil d'administration de l'ICANN 28 juillet 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-28jul11-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
  2. Réception du cadre de sécurité, stabilité et résilience pour l'exercice budgétaire FY12
  3. Nomination d'un nouveau médiateur

 

  1. Ordre du jour convenu

    Il est résolu, d'approuver les résolutions suivantes de cet ordre du jour convenu :

    1.1. Approbation du compte-rendu de la réunion du Conseil d'administration de l'ICANN du 20 juin 2011

    Il est résolu (2011.07.28.01), que le CA approuve le compte-rendu de la réunion du Conseil d'Administration de l'ICANN du 20 juin 2011.

    1.2. Approbation du compte-rendu de la réunion du Conseil d'administration de l'ICANN du 24 juin 2011

    Il est résolu (2011.07.28.02), que le CA approuve le compte-rendu de la réunion du Conseil d'Administration de l'ICANN du 24 juin 2011.

    1.3. Approbation du compte-rendu de la réunion organisationnelle du Conseil d'administration de l'ICANN du 24 juin 2011

    Il est résolu (2011.07.28.03), que le CA approuve le compte-rendu de la réunion organisationnelle du Conseil d'Administration de l'ICANN du 24 juin 2011.

    1.4. Approbation du compte-rendu de la réunion du Conseil d'administration de l'ICANN du 25 juin 2011

    Il est résolu (2011.07.28.04), que le CA approuve le compte-rendu de la réunion du Conseil d'Administration de l'ICANN du 25 juin 2011.

    1.5. Approbation de la redélégation du nom de domaine .om représentant Oman

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

    Attendu que l'ICANN a reçu une demande de redélégation de .OM à l'autorité de contrôle des télécommunications (Telecommunications Regulatory Authority).

    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 par la présente (2011.07.28.05), que la redélégation proposée du nom de domaine de premier niveau .OM à l'autorité de contrôle des télécommunications soit approuvée.

    Justification de la résolution 2011.07.28.05

    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 à déterminer que le code de pays remplit les conditions requises (par ex. qu'il fait partie de 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 basé sur place et sujet à la législation locale ; à établir que le gestionnaire proposé fonctionne de manière juste et équitable ; à établir que dans les cas où il y aurait transfert d'opérations, un plan adéquat est en place pour préserver la stabilité continue du nom de domaine ; et à établir que l'action est conforme à toutes 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 oeuvre 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 continu 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.

  2. Réception du cadre de sécurité, stabilité et résilience pour l'exercice budgétaire FY12

    Attendu que le cadre de sécurité, stabilité et résilience (SSR) pour l'exercice budgétaire FY12 a été publié en ligne pour la consultation publique du 2 mai au 7 juin 2011.

    Attendu que le résumé et l'analyse des commentaires publics ont été réalisés et publiés le 8 juin 2011.

    Attendu que le personnel a réalisé une séance d'information de la communauté lors de la conférence de Singapour et a incorporé les remarques et retours d'information reçus dans les priorités opérationnelles décrites dans le cadre SSR, y compris les références, objectifs, étapes importantes et un mécanisme permettant d'évaluer le succès des activités SSR.

    Il est résolu (2011.07.28.06), que le CA accuse la réception du cadre SSR pour l'exercice budgétaire FY12.

    Justification des résolutions 2011.07.28.06

    Selon l'affirmation d'engagements signée par l'ICANN et le ministère du Commerce des États-Unis le 30 septembre 2009, préserver la sécurité, la stabilité et la résilience du DNS constitue un engagement clé. L'affirmation reconnait dans sa section 9.2 que l'ICANN a adopté un plan de sécurité, stabilité et résilience (SSR), qui sera régulièrement actualisé afin de refléter les menaces naissantes pour le DNS, y compris les identifiants uniques. Les plans SSR précédents ont été publiés en 2009 et 2010, et le Conseil d'administration de l'ICANN en a accusé la réception aux conférences internationales de Sydney en Australie (juin 2009) et de Carthagène en Colombie (décembre 2010).

    Cette dernière version du cadre SSR a été actualisée en un format plus simplifié et accessible, et a été publiée en may 2011 pour présenter la documentation de base de l'ICANN sur les SSR à temps avec la publication du plan opérationnel et budget de l'ICANN pour l'exercice budgétaire FY12. Ce document informe la communauté sur le rôle de l'ICANN en matière de SSR, décrit les domaines dans lesquels l'ICANN a la responsabilité opérationnelle, les domaines dans lesquels l'ICANN a un rôle de collaboration, facilitation et contribution, et les domaines dans lesquels l'ICANN est un observateur d'activités menées par d'autres au sein de l'écosystème.  Les remarques de la communauté reçues au cours de la période de consultation publique étaient en général en faveur du format révisé, et demandaient plus de spécificité et de précision concernant les définitions.

    Un document du CA comprenant les détails du cadre SSR et une annexe fournissant des informations relatives aux commentaires reçus entre le 2 mai et le 7 juin 2011 ont été remis au CA. 

    Le document est distinct du plan opérationnel et budget de l'ICANN et nul impact fiscal découlant de cette décision n'est prévu. Le cadre sert d'information sur les activités de l'ICANN en matière de SSR durant l'exercice budgétaire prochain.

  3. Nomination d'un nouveau médiateur

    Attendu que le 31 janvier 2011, le médiateur de l'ICANN s'est engagé dans d'autres projets.

    Attendu que depuis le 1er février 2011, un médiateur intérimaire accomplissait toutes les fonctions et remplissait les responsabilités du médiateur.

    Attendu que l'ICANN a procédé à une recherche approfondie et mondiale d'un nouveau médiateur.

    Attendu que le CA a identifié un nouveau médiateur qui a accepté le poste.

    Il est résolu (2011.07.28.07), conformément à l'article V, section 1.2 des règlements de l'ICANN, que le CA nomme par la présente Chris LaHatte médiateur de l'ICANN pour un mandat initial de deux ans, entrant en vigueur le 28 juillet 2011 et ce jusqu'au 27 juillet 2013, et autorise l'avocat-conseil et le secrétaire à signer un accord avec M. LaHatte.

    Justification proposée de la résolution 2011.07.28.07

    Les règlements de l'ICANN exigent que l'ICANN maintienne un bureau de médiateur. Voir article V des règlements à l'adresse http://www.icann.org/en/general/bylaws.htm#V. Pour l'ICANN, la fonction de médiateur a un impact positif sur la transparence et la responsabilité de l'ICANN, cette fonction étant l'un des trois mécanismes de responsabilité principaux au sein de l'ICANN. Étant donné qu'il existe un budget pour un médiateur de l'ICANN depuis 2004 lorsque le premier médiateur a été nommé, remplacer le médiateur intérimaire actuel aura un impact financier minime sur l'ICANN.  La nomination d'un nouveau médiateur n'aura pas d'impact négatif sur la sécurité, la stabilité et la résilience systémiques du système de noms de domaine.