Skip to main content
Resources

Résolutions adoptées par le Conseil d'administration | Réunion spéciale du Conseil d'administration

Cette page est disponible en:

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-21apr11-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 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. Confidential Personnel Matter – Session exécutive
  2. Consent Agenda
  3. From the BFC – Approval of Increase Of The Registrar Accreditation Application Fee
  4. From the SIC – Approval of Charter for Board Technical Relations Working Group
  5. Review of Vertical Integration for Existing gTLD Registry Operators
  6. ATRT
  7. IDN ccTLD DELEGATIONS

 

  1. Points confidentiels du personnel – Session exécutive

    En session exécutive, le Conseil d'administration a voté deux résolutions connexes (2011.04.21.C01, 2011.04.21.C02) qui resteront confidentielles comme une « action concernant la problématique du personnel ou de l'emploi », conformément l'article III, section 5.2 des statuts de l'ICANN.

  2. Ordre du jour approuvé

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

    2.1 Approbation du procès verbal de la réunion du Conseil spécial de l'Icann du 18 mars 2011

    RESOLU (2011.04.21.01), le Conseil approuve les procès-verbaux de la Réunion spéciale du Conseil de l'ICANN du 18 mars 2011.

    2.2 Du Comité de gouvernance de la Commission (Board Governance Committee (BGC)- Réunion pour remplir les postes vacants de direction

    Attendu que, en accord avec la conclusion de la réunion du mois de juin à Singapour, il y aura un siège vacant pour la présidence du Conseil d'administration dû au changement du siège 11 du conseil de l'ICANN.

    Attendu que, le Comité de gouvernance du Conseil d'administration a déterminé qu'il est préférable de remplir de manière immédiate le siège vacant au sein du Conseil, d'aborder immédiatement les changements nécessaires à la composition des membres des Comités et du Conseil à cause de la transition de ses membres, et qu'il est prévu de présenter des recommandations au Conseil à ce sujet.

    Attendu qu'il est nécessaire de convoquer à une réunion du Conseil, dès que possible après la conclusion de la réunion du mois de juin 2011, pour que le Conseil prenne les mesures nécessaires afin d'élire un président (et un vice-président, si nécessaire), et qu'il désigne les membres du comité du Conseil, si besoin est.

    RÉSOLU (2011.04.21.02), le secrétaire devra convoquer à une réunion du Conseil d'administration, immédiatement après la fin de la réunion du mois de juin 2011.

    FONDEMENTS DE LA RÉSOLUTION 2011.04.21.02:

    Cette résolution administrative assure que le Conseil continuera à exercer ses fonctions de leadership lors du changement du/des membre/s du Conseil d'administration. Il n'y a pas d'impact fiscal anticipé découlant de cette décision puisque la réunion aura lieu dans le même emplacement de la réunion du mois de juin 2011. Il n'y aura pas d'impact sur la sécurité, la stabilité et la résilience du système des noms de domaine suite à cette action.

    2.3 Du Comité de gouvernance de la commission (Board Governance Commitee – BGC) – Code de conduite révisé

    Considérant que, le Comité de gouvernance de la commission (BGC) est chargé de surveiller la conformité du Conseil vis-à-vis des dispositions du Code de conduite de l'organisation, approuvé en 2008.

    Considérant que le BGC a identifié que les Directives du code de conduite sont en mesure de fournir le guide et l'assistance pour garantir la conformité avec le Code de conduite.

    Considérant qu'il est nécessaire de réaliser des révisions non-substantielles au code de conduite pour introduire des références aux directives du code de conduite, et que le BGC a approuvé les révisions proposées.

    RÉSOLU (2011.04.21.03), le Conseil d'administration approuve le Code de conduite révisé et donne des instructions au personnel pour la publication du Code de conduite révisé sur le site Web de l'ICANN.

    FONDEMENTS DE LA RÉSOLUTION 2011.04.21.03:

    Il est essentiel que le Conseil respecte les dispositions du Code de conduite pour maintenir la transparence et la responsabilité du processus de prise de décisions de l'ICANN. Le Code de conduite approuvé en 2008 a été le résultat des commentaires du public, et les changements approuvés ce jour ne modifient pas substantiellement les dispositions souscrites par la communauté. Le Code de conduite révisé aidera le Conseil à maintenir la cohérence avec le Code de conduite, par le biais de l'incorporation de Directives identifiant plus clairement les processus afin de gérer les manquements potentiels du Code. Il n'y aura pas d'impact fiscal anticipé sur la sécurité, et il n'y aura pas d'impact sur la stabilité et la résilience du système des noms de domaine suite à cette action.

    2.4 À propos du BGC – Contribution du milieu universitaire au NomCom

    Attendu que, Article VII, Section 2.8.c des statuts de l'ICANN exige au NomCom d'inclure un membre avec droit de vote sélectionné par une « entité désignée par le Conseil afin de représenter le milieu universitaire et des organisations similaires » (Entité de sélection).

    Attendu que, malgré les tentatives d'identifier une Entité de sélection, le Conseil n'a pas eu de succès, et que, au lieu de cela, il a recommandé directement des délégués pour qu'ils représentent le milieu universitaire auprès du NomCom. En plus du délégué choisi par le Conseil, il y a eu de nombreux délégués du milieu universitaire dans chaque NomCom.

    Attendu que, en 2010, le Conseil a chargé le BGC de créer une procédure pour identifier les entités de sélection, et que le BGC a manifesté sa préoccupation vis-à-vis de l'identification et l'évaluation de l'entité de sélection.

    Attendu que le BGC a déterminé que la communauté peut fournir des indications pour une entité de sélection appropriée ou des paramètres permettant d'identifier ou d'évaluer l'entité de sélection.

    Attendu que, au cas où le commentaire de la communauté n'informerait pas l'identification ou l'approbation d'une entité de sélection appropriée, le BGC peut recommander que l'article VII 2.8.c. soit supprimé des Statuts. Si désormais, le secteur universitaire était sous-représenté au sein du NomCom, la création d'un mécanisme serait considérée afin de garantir que le secteur universitaire soit pris en compte pour la sélection des dirigeants de l'ICANN.

    RÉSOLU (2011.04.21.04), le Conseil approuve le démarrage d'une période de 30 jours pour les commentaires publics afin d'obtenir un avis concernant le travail futur du BGC sur l'identification d'une entité responsable des nominations au NomCom tel que prévu dans Article VII, Section 2.8.c des Statuts. Les commentaires publics aborderont également les réformes potentielles aux Statuts proposées pour ce qui est de la suppression de cette prévision des Statuts au cas où la procédure des commentaires publics n'arriverait pas à identifier une entité appropriée.

    FONDEMENTS DE LA RÉSOLUTION 2011.04.21.04:

    Depuis l'introduction du formulaire actuel des statuts de l'ICANN, il existe une disposition pour que le NomCom inclue un membre avec droit de vote sélectionné par une « entité désignée par le Conseil afin de représenter le milieu universitaire et des organisations similaires » (Entité de sélection). Le Conseil n'a pas réussi à identifier l'entité de sélection; malgré a 2003 identification of a Selecting Entity, de 2005, aucun candidat n'a été identifié et le Comité de gouvernance du Conseil d'administration (Board Governance Committee - BGC) a proposé une recommandation directe pour nommer un délégué avec droit de vote au sein du NomCom après avoir recherché les candidats. En 2007, le président a signalé que BGC had not been successful in identifying a Selecting Entity, et en 2010 Board directed que la création d'une procédure pour choisir l'entité de sélection à travers le BGC devait être proposée au Conseil d'administration.

    Malgré les limitations rencontrées par le Conseil pour identifier une entité de sélection, la représentation du secteur universitaire auprès de chaque NomCom a été cohérente, outre les personnes recommandées directement par le BGC. Historiquement, en plus des délégués désignés appartenant au secteur universitaire, chaque NomCom récent a au moins deux membres affiliés aux institutions académiques.

    Le NomCom, et la méthode de sélection des délégués qui travaillent au service du NomCom, sont des composants importants pour le leadership et la gouvernance de l'ICANN et le fait de donner à toute entité la responsabilité de sélectionner un délégué avec droit de vote au sein du NomCom aura des effets durables pour l'organisation. Lorsque le BGC a entrepris la création d'une procédure pour identifier une entité de sélection, il a discuté sur la difficulté d'identifier des critères pour choisir une entité, notamment sur la manière d'évaluer et de sélectionner une entité appropriée au cas où il y en aurait plus d'une ayant été proposée ou suggérée. Le BGC a également identifié une question fondamentale: en fonction de l'histoire des voix du secteur universitaire présentes au sein du NomCom, est-il toujours nécessaire de distinguer qu'un délégué spécifique demeure comme une partie de la composition du NomCom?

    En conséquence, le BGC recommande que l'opinion de la communauté ait son mot à dire pour la révision de ce point de décision. Le BGC demandera l'avis de la communauté sur: Quelles sont les entités pouvant ou devant servir comme une entité pour désigner un membre du secteur universitaire ou d'une organisation similaire pour le NomCom? Quels sont les paramètres à utiliser pour l'évaluation des entités en concurrence? Quelle serait la procédure de sélection ou d'évaluation appropriée? Une communauté serait-elle mieux servie si l'on supprimait les dispositions des statuts demandant à une telle entité de sélectionner un délégué?

    Il est à noter que le Conseil a donné des instructions au BGC de ne pas identifier un délégué pour le NomCom actuel (2010-2011) afin de remplir ce rôle. À ce jour, l'ICANN ignore s'il y a eu des plaintes découlant du fait que l'absence d'un représentant du secteur universitaire ait empêché le travail du NomCom.

    Au cas où la consultation à la communauté ne pourrait pas identifier une procédure d'évaluation ou de sélection appropriée, ou une entité appropriée, le BGC recommandera la suppression de ces dispositions des Statuts. Si la disposition est supprimée, la composition future du NomCom devra être révisée afin de garantir que le secteur universitaire ait toujours une représentation. Si, dans l'avenir, le secteur universitaire est sous-représenté, une révision sur la manière d'assurer le mieux possible la représentation du secteur universitaire au sein du NomCom sera initiée.

    Les commentaires de la communauté sur cette question aideront le Conseil dans son évaluation de l'impact de tout changement dans la composition du NomCom. Il n'y aura pas d'impact sur la sécurité, la stabilité et la résilience du système des noms de domaine suite à cette action.

    2.5 À propos du BGC – Approbation des membres du groupe de travail des relations techniques du Conseil

    Attendu que, on 18 March 2011, 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 ».

    Considérant que, le Conseil a donné des directives au Comité de gouvernance du Conseil afin qu'il recommande cinq membres pour le groupe de travail des relations techniques du Conseil, afin de soumettre la question à la considération du Conseil lors de cette réunion.

    Attendu que, lors de la réunion du 12 avril 2011 le BGC a révisé la composition potentielle du groupe de travail des relations techniques du Conseil et qu'il a donné des recommandations au Conseil pour nommer les membres proposés ci-dessous pour former ce groupe:

    (i) Gonzalo Navarro, Président;

    (ii) Thomas Narten;

    (iii) Thomas Roessler;

    (iv) Reinhard Scholl; et

    (v) Jonne Soininen.

    RÉSOLU (2011.04.21.05), le Conseil approuve la désignation des membres recommandés pour le groupe de travail des relations techniques du Conseil et leur demande de mener à bien les tâches établies dans la résolution du Conseil en date du 18 mars 2011, comme indiqué dans la charte du groupe de travail.

    FONDEMENTS DE LA RÉSOLUTION 2011.04.21.05:

    La recommandation du Comité de gouvernance du Conseil est conforme à la résolution du Conseil du 18 mars 2011. Le travail de révision du TLG, jusqu'à ce jour, a fait l'objet des commentaires de la communauté, et l'on s'attend à ce que le groupe de travail exécute son travail via un processus de consultation avec la communauté de l'ICANN. Un faible impact fiscal est prévu, dû à la composition du groupe de travail, y compris les ressources pour le personnel et les coûts potentiels encourus pour faciliter le travail du groupe de travail. Il n'y aura pas d'impact sur la sécurité, la stabilité et la résilience du système des noms de domaine suite à cette action.

    2.6 À propos du SIC – Approbation de la mise en œuvre des actions de révision du ccNSO

    Attendu que, le 18 mars 2011 le Conseil a résolu de recevoir le rapport final du groupe de travail de révision du ccNSO et a donné des instructions au Comité des améliorations structurelles (Structural Improvements Commitee – SIC) de « présenter une série d'actions pour leur approbation lors de la réunion du Conseil du 24 juin 2011, ainsi que d'aborder les conclusions et les recommandations formulées dans le rapport final de ce groupe de travail », à http://www.icann.org/en/minutes/resolutions-05aug10-en.htm#2.f.

    Attendu que, les membres du personnel de l'ICANN travaillant dans les révisions organisationnelles et dans le ccNSO ont identifié une série de mesures dans le document « rapport final du groupe de travail de révision du ccNSO: étapes de mise en œuvre », du mois d'avril 2011, afin d'aborder les recommandations et les conclusions du groupe de travail et de les présenter au SIC.

    Attendu que, le SIC trouve que les mesures incluses dans ce document sont adéquates et qu'il propose au personnel de travailler en coordination avec le SIC pour achever un plan de mise en œuvre, y compris les coûts estimés, basés sur ce document, et de présenter ce plan final au Conseil pour sa réception et prise en compte.

    RÉSOLU (2011.04.21.06), le Conseil approuve ce document présenté par le SIC et donne des instructions au SIC pour que, en coordination avec le personnel, présente au Conseil un plan final de mise en œuvre, y compris les coûts estimés, pour se conformer aux mesures recommandées par le SIC afin d'aborder les conclusions et les recommandations du rapport final du groupe de travail de révision du ccNSO.

    FONDEMENTS DE LA RÉSOLUTION 2011.04.21.06:

    L'action proposée répond directement à une demande du Conseil et sert à avancer la mise en œuvre des résultats de la révision du ccNSO. Le développement d'un plan de mise en œuvre détaillé est essentiel pour préparer la mise en œuvre en temps opportun. Il n'existe aucune raison pour retarder cette action du fait que, per se, elle n'aurait pas de conséquences budgétaires. Le plan détaillé de la mise en œuvre devra traiter explicitement l'estimation des ressources, qui seront ensuite examinées et décidées par le Conseil une fois la tâche de planification accomplie et les propositions présentées.

    2.7 À propos du BFC – Formalisation du Comité de planification pour les comptes d'épargne-retraite des employés existants (401K)

    Considérant que, le plan d'épargne-retraite de l'ICANN (Plan) a été introduit en l'an 2000 pour le personnel basé aux États-Unis.

    Considérant que, à la lumière du nombre croissant de participants et des actifs résultant du Plan, les meilleures pratiques suggèrent la formation d'un comité pour gérer l'administration du plan, en choisissant des vendeurs, en identifiant les options d'investissements que les employés pourront choisir ainsi que d'autres responsabilités fiduciaires.

    Considérant que, le BFC a recommandé au Conseil d'approuver la formalisation du Comité du Plan 401(k) et d'autoriser le PDG à trouver du personnel et à superviser les activités du Comité du Plan.

    RÉSOLU (2011.04.21.07), le Conseil approuve la formalisation du Comité du Plan 401(k) et autorise le PDG à trouver du personnel et à superviser les activités du Comité du Plan.

    FONDEMENTS DE LA RÉSOLUTION 2011.04.21.07:

    Les employés bases aux États Unis participent du Plan d'épargne-retraite de l'ICANN (aussi connu comme le Plan 410 (k)) (le « Plan ») suivant lequel la Société fait des contributions au Plan au nom des employés, et les employés peuvent faire des contributions au Plan, sur la base de taxes différées, pour leur propre compte. Jusqu'il y a peu de temps, le plan était relativement réduit et un Comité formel n'était pas nécessaire. Cependant, récemment, le Plan a atteint les 100 participants actifs et un niveau d'actifs pour lequel les bonnes pratiques conseillent la formation d'un Comité du Plan pour la surveillance de plusieurs aspects du Plan.

    2.8 Approbation pour la redélégation de .KP (République populaire démocratique de Corée),

    Attendu que, KP est le code de pays à deux lettres ISO 3166 désigné pour la République populaire démocratique de Corée.

    Considérant que l'ICANN a reçu une demande de redélégation de .KP en faveur de Star Joint Venture Company;

    Considérant que l'ICANN a examiné la demande et a déterminé que la redélégation proposée répond aux intérêts des communautés Internet locales et mondiales;

    RÉSOLU (2011.04.21.08), la redélégation proposée du domaine .KP en faveur de Star Joint Venture Company est approuvée.

    FONDEMENTS DE LA RÉSOLUTION 2011.04.21.08:

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

    Le Personnel soumet à la considération du Conseil les requêtes de délégation et redélégation des domaines de code de pays. Après avoir satisfait les demandes du personnel en fournissant une candidature dûment complétée, le candidat a une probabilité raisonnable d'obtenir l'approbation du Conseil. Conformément aux engagements de l'ICANN visant à effectuer de manière efficiente le traitement des demandes liées à la fonction IANA et, notamment, à la zone racine DNS, le Conseil de l'ICANN cherche à évaluer ces demandes lors de sa prochaine assemblée extraordinaire.

    Quelles sont les propositions à l'étude?

    Il est proposé d'approuver la demande à l'IANA de changer ou de désigner l'organisation de parrainage (connue également sous le nom de gestionnaire ou administrateur) d'un domaine de premier niveau de code de pays. Conformément à la pratique établie, le Conseil de l'ICANN est impliqué dans la décision de procéder à de telles demandes comme une étape de ce processus multi- étapes.

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

    Dans le cadre de l'évaluation d'une demande de délégation, le personnel de l'ICANN consulte le candidat, l'opérateur actuel (le cas échéant), et d'autres parties directement concernées. Conformément à la pratique de l'ICANN de maintenir la confidentialité des demandes de modification de la zone racine, l'ICANN n'a pas effectué de consultation ouverte sur cette question.

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

    Quelques préoccupations ou questions concernant cette action ont été soulevées dans le rapport public qui sera bientôt publié. Ce rapport, qui sera publié au site Web de l'IANA ( http://www.iana.org /) est censé mener à bonne fin le traitement définitif des demandes de modifications de la zone racine, normalement 1 ou 2 mois après la décision du Conseil.

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

    Le Conseil participe à l'évaluation de demandes impliquant une diversité de critères d'intérêt public. Ce critère vise à établir l'admissibilité des codes de pays (p. ex. énumérés dans la norme ISO 3166-1); à établir la proposition d'un administrateur soutenu par la communauté Internet locale; la compétence opérationnelle et technique de l'opérateur proposé; l'opération de l'administrateur proposé depuis une base locale et en vertu de la loi locale; à établir qu'il opère de manière juste et équitable; à ce que, au cas où il y aurait un transfert des opérations, un plan approprié soit mis en place pour préserver la continuité de la stabilité du domaine; et à établir que l'action soit compatible avec toutes les règlementations et les lois locales applicables. Lors du processus de compilation du personnel, le candidat est prié de fournir une variété de documents à l'appui de ces différents aspects. Toute information pertinente sur ces documents fournis et d'autres recherches du personnel est adressée au Conseil et publiée dans un rapport public à la fin de la mise en œuvre d'une demande approuvée.

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

    Le Conseil tient compte des facteurs décrits dans le rapport public, à l'égard des principes fondamentaux de délégation de domaine de code de pays décrits précédemment.

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

    L'approbation en temps opportun des administrateurs de noms de domaine de code de pays répondant aux divers critères d'intérêt public est positive vis-à-vis de la mission globale de l'ICANN et les communautés locales, dont les domaines de premier niveau de code de pays sont désignés pour desservir.

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

    La gestion de délégations des codes de pays dans la zone racine du DNS fait partie des fonctions de l'IANA, et le processus de délégation ne devrait pas produire une variation significative des dépenses prévues. L'ICANN n'est pas censé évaluer l'impact financier des opérations internes des domaines de premier niveau de code de pays au sein d'un pays; l'ICANN doit seulement assurer que l'opérateur réside dans le pays et qu'il possède les mécanismes appropriés pour permettre à la communauté Internet locale de surveiller correctement la continuité de ses opérations de domaine.

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

    Pour les délégations de domaine de premier niveau de code de pays, l'ICANN cherche à approuver les demandes qui abordent de façon satisfaisante les préoccupations raisonnables, et puisque le nouvel administrateur proposé a fait preuve de ses compétences opérationnelles et techniques, ces préoccupations devraient être peu significatives.

    2.9 Approbation du suivi de la politique globale pour les mécanismes d'affectation d'IPv4 après l'épuisement des adresses par l'IANA

    Attendu que, l'Board's Review Procedures for Global Internet Number Resource Policies Forwarded for Ratification by the ASO Address Council in Accordance with the ASO MoU, stipule que « Lorsque, conformément à l'étape 1 du processus de développement de la politique globale du ASO MoU (Annexe A, article 1), le personnel de l'ICANN travaillant en liaison avec la communauté d'adressage prend conscience du développement de politique globale dans le domaine de compétence de l'ASO MoU, le personnel de l'ICANN informe le Conseil d'administration de ce développement. Le Conseil décide, si cela est approprié, que ce développement devrait être suivi par le personnel de l'ICANN et donne des instructions au PDG de l'ICANN d'affecter du personnel pour mener à bien cette tâche. Le personnel de l'ICANN affecté en informera les organismes de soutien de l'ICANN et les Comités consultatifs, créera une page Web de l'ICANN devant être mise à jour et rédigera un rapport préalable devant être mis à jour dans sa politique globale de développement. Ce rapport préalable sera présenté au Conseil comme demandé ».

    Attendu que, le personnel de l'ICANN a informé le Conseil sur le développement d'une proposition de politiques dénommée « Politique globale pour les mécanismes d'affectation d'IPv4 après l'épuisement des adresses par l'IANA » et que cette Proposition a entamé l'adoption des premières étapes avec les RIR individuels et qu'elle a été reconnue par le Conseil d'adressage de l'ASO comme une Proposition de politique globale valide.

    Attendu que, la Proposition est identifiée comme un développement de politiques globales qui relève du champ d'application du protocole d'entente (MoU) entre l'ICANN et l'ASO.

    RÉSOLU (2011.04.21.09), le Conseil d'administration demande que le développement de la proposition de politiques dénommée « Politique globale pour les mécanismes d'affectation d'IPv4 après l'épuisement des adresses par l'IANA » soit suivi par le personnel de l'ICANN conformément aux procédures de révision du Conseil d'administration pour ces propositions de politiques et donne des instructions au PDG de l'ICANN d'affecter du personnel pour mener à bien cette tâche.

    FONDEMENTS DE LA RÉSOLUTION 2011.04.21.09:

    La Proposition de politiques globales est arrivée à l'étape de discussions dans tous les Registres Internet régionaux et le moment est adéquat pour démarrer la production et la publication des rapports préalables sur le statut proposé. Les instructions données au personnel pour mener le travail de suivi requis sont conformes aux obligations de l'ICANN sous le MoU avec le Review Procedures for Global Internet Number Resource Policies du Conseil et de l'ASO.

    Il y aura un impact budgétaire nominal du fait du suivi de la Proposition par le personnel, parce que le personnel de l'ICANN est déjà affecté à l'ASO et que le suivi des propositions, dans cette étape, nécessite d'un effort limité du personnel. Si cela est approuvé, la future mise en œuvre peut provoquer des impacts additionnels sur le budget et sur les questions liées à la sécurité/stabilité publique, mais cela n'est pas en mesure d'être évalué à ce jour. La demande du suivi par le personnel lors de cette étape permettra aussi la préparation anticipée de la future demande de l'ASO pour ratifier cette Proposition.

Programme principal

  1. À propos du BFC – Approbation de l'augmentation des frais d'accréditation et de candidature des bureaux d'enregistrement

    Conflits d'intérêts potentiels (tel qu'identifiés par le Conseil Général):

    Bruce Tonkin – pour plus de détails, voir la publication du résumé des déclarations d'intérêt – http://www.icann.org/en/board/summary-soi-16mar11-en.htm.

    Considérant que, dans sa résolution 01.65 le Conseil a approuvé des frais d'accréditation de la candidature d'USD 2 500, sans tenir compte du nombre de domaines de premier niveau pour lesquels la candidature est sollicitée, pour les candidatures présentées au plus tard le 1 er. juillet 2001;

    Attendu que, depuis juillet 2001, les frais d'accréditation n'ont subi aucun changement;

    Attendu que, le 22 novembre 2010, l'ICANN a publié dans son site Web une proposition pour compléter un devoir de diligence raisonnable et pour augmenter les frais d'application de candidature, avec une description des devoirs de diligence raisonnable et la raison de l'augmentation des frais de candidature;

    Considérant que, une période de commentaires publics a été fixée pour que la communauté puisse présenter ses commentaires sur la proposition;

    Considérant que, le commentaire public reçu soutient les améliorations proposées;

    RÉSOLU (2011.04.21.10), les frais d'application pour être accrédité par l'ICANN comme bureau d'enregistrement seront d'USD 3 500 pour les applications présentées au plus tard le 1 er. juillet 2011.

    RÉSOLU 2011.04.21.11) que le Conseil affecte du personnel pour faire une révision des coûts associés à la procédure d'accréditation de la candidature du bureau d'enregistrement afin de déterminer si les frais actuels couvrent ces coûts.

    Fondements de la résolution 2011.04.21.10-11

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

    Cela a fait l'objet de discussions au sein de la communauté comme un moyen d'améliorer la sécurité sans besoin de développer une politique intégrale ou de modifier le contrat. Cela a été revu par le Comité des finances, et une décision sera prise avant le début de la prochaine année fiscale.

    Quelles sont les propositions à l'étude?

    Le Conseil considère s'il approuvera ou non l'augmentation des frais d'accréditation de candidature des bureaux d'enregistrement d'USD 2 500 à USD 3 500; c'est la première augmentation en dix ans. De même, le Conseil a donné des instructions au personnel pour faire une révision des coûts associés à l'accréditation des candidatures afin de garantir que les frais et les coûts soient cohérents.

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

    Les améliorations proposées au processus de candidature des bureaux d'enregistrement et l'augmentation des frais ont fait l'objet de commentaires publics depuis le 22 novembre 2010 jusqu'au 21 janvier 2011; quatre commentaires ont été reçus; l'un d'eux n'avait pas compris complètement la proposition et les trois autres ont manifesté leur soutien absolu à la proposition. Les changements proposés au processus de candidature et aux frais de candidature ont été présentés au groupe des parties prenantes des bureaux d'enregistrement lors de la réunion de l'ICANN à Cartagena, sans commentaires négatifs.

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

    Le seul commentaire négatif concernant l'augmentation des frais a été présenté par un registraire qui a mal compris la proposition; il a pensé qu'il s'agissait d'une augmentation des frais annuels payés par les bureaux d'enregistrement. Aucun autre commentaire n'a été reçu à propos des frais de candidature.

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

    Un document du Conseil expose en détail la proposition et un Annexe contient les fondements de l'augmentation des frais liée aux coûts ainsi que la poursuite des vérifications par un fournisseur tiers.

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

    Les recommandations de la communauté améliorant la diligence raisonnable doivent être entreprises dans la procédure de révision de la candidature des bureaux d'enregistrement. Le Comité de financement du Conseil d'administration a revu et approuvé les fondements financiers pour l'augmentation et a statué qu'ils étaient neutres en termes de revenus. Ultérieurement, le BFC a recommandé une résolution supplémentaire disant que l'étude devrait porter sur le coût total de traitement ce qui nous permettra d'établir si les coûts sont en ligne avec les frais. Finalement, pendant la durée du forum des commentaires publics, aucune opposition n'a été présentée.

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

    Les révisions améliorées de la diligence raisonnable grâce à l'augmentation des frais permettront d'améliorer le processus de révision, notamment parce que l'on s'attend à une augmentation des accréditations des bureaux d'enregistrement avec l'introduction des nouveaux gTLD.

    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'augmentation des frais est conçue pour être neutre en termes de revenus alors que les vérifications du contexte seront ajoutées au processus de révision des candidatures.

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

    Les vérifications proposées à la diligence raisonnable ont été introduites en réponse aux questions liées à la sécurité relevées par la communauté de l'ICANN et comme un souhait pour que les processus d'accréditation des nouveaux registraires soient améliorés par le biais de ces vérifications à la due diligence et qu'ils soient neutre en termes de revenus.

  2. À propos du SIC – Approbation de la charte du groupe de travail des relations techniques du Conseil

    Attendu que, le 18 mars 2011 le Conseil a résolu de recevoir le rapport final de la révision TLG et d'établir un groupe de travail des relations techniques du Conseil; qu'il a aussi donné des instructions au Comité des améliorations structurelles (Structural Improvements Commitee – SIC) pour développer une charte destinée à ce groupe de travail « basée sur le rapport de révision de TLG, sur les commentaires à cette révision et sur tout autre information disponible, qui sera soumise à la considération du Conseil lors de la réunion du 21 avril 2011 », à http://www.icann.org/fr/minutes/resolutions-18mar11-fr.htm#7.

    Attendu que, le SIC a développé une charte proposée pour le groupe de travail BTR.

    Attendu que, lors de sa réunion du 11 avril 2011, le SIC a accordé à l'unanimité de recommander au Conseil d'administration la charte proposée pour le groupe de travail BTR pour son adoption.

    RÉSOLU (2011.04.21.12), le Conseil approuve la charte pour le groupe de travail BTR, proposée par le SIC, qui sera soumise à un ajustement final afin d'inclure une révision ultérieure et a donné des instructions au SIC pour que, en coordination avec le personnel, soutienne le travail du groupe de travail et s'occupe de faire le suivi.

    Fondements de la résolution 2011.04.21.12:

    L'action proposée répond directement à une demande du Conseil et sert à avancer la mise en œuvre des résultats de la révision du TLG en ligne avec la direction établie par le Conseil. Alors que l'avis de la communauté n'a pas été considéré nécessaire pour la rédaction de cette Charte, le groupe de travail devra consulter avec la communauté pour atteindre ses recommandations. Le fonctionnement du groupe de travail BTR aura besoin du soutien du personnel existant et de certaines dépenses limitées. Il n'existe aucune raison pour retarder cette action du fait qu'elle n'aurait pas de conséquences marginales sur le budget. Cette action n'aura aucune incidence sur la sécurité ou la stabilité du DNS.

  3. Révision de l'intégration verticale pour les opérateurs de registre gTLD existants.

    Considérant que, le 5 novembre 2010 le Conseil a résolu que l'ICANN ne limiterait pas la propriété croisée entre les registres et les bureaux d'enregistrement pour les nouveaux gTLD et que « l'ICANN permettra aux opérateurs de registre existants de changer vers la nouvelle forme de contrat de registre, sauf le cas où des conditions additionnelles seraient nécessaires et appropriées pour aborder des circonstances particulières des registres établis ».

    Considérant que, les contrats de registre des gTLD actuels incluent des restrictions à la propriété croisée.

    Considérant que, l'ICANN a reçu des demandes de renseignement de plusieurs opérateurs concernant le processus d'annulation des restrictions à la propriété croisée dans leur contrat de registre et/ou leur capacité de présenter leur candidature pour devenir un registraire accrédité de l'ICANN.

    Considérant que, la suppression des restrictions sur la propriété croisée pour les opérateurs est fondée, en premier lieu, sur l'approbation du programme pour les nouveaux gTLD, et deuxièmement, sur l'approbation du Conseil d'un processus de transition vers la nouvelle forme de contrat de registre ou d'une demande de modification des contrats de registre existants.

    Considérant que, le Conseil a anticipé qu'il prendrait en considération le programme des nouveaux gTLD et le lancement des nouveaux gTLD lors de sa réunion à Singapour, en juin 2011;

    RÉSOLU (2011.04.21.13), le Conseil donne des instructions au PDG de développer un processus pour que les opérateurs de registre gTLD existants puissent changer vers la nouvelle forme de contrat de registre ou demander des modifications à leurs contrats de registre afin de supprimer les restrictions sur la propriété croisée. Ce processus devrait être disponible pour les opérateurs existants dès que le Conseil aura approuvé le programme des nouveaux gTLD.

    FONDEMENTS DE LA RÉSOLUTION 2011.04.21.13

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

    Le Conseil a décidé d'aborder maintenant cette question car il est prévu pour le 20 juin 2011de soumettre à considération le Guide de Candidature pour les nouveaux gTLD. Le 4 novembre 2010, le Conseil de l'ICANN a résolu qu'il devrait y avoir un moyen, destiné aux opérateurs de registre des gTLD existants (« Opérateurs »), capable de faciliter la transition vers la nouvelle forme de contrat de Registre, comprenant aussi la suppression des restrictions à la propriété croisée des registres par les bureaux d'enregistrement et vice versa. Les Opérateurs soutiennent qu'ils ont besoin de supprimer leurs restrictions actuelles sur la propriété croisée en temps opportun pour être à même de concurrencer sur un pied d'égalité avec les registraires qui envisagent de poser leur candidature pour l'opération des nouveaux gTLD. L'approbation d'un processus de continuité pour que les opérateurs existants suppriment les restrictions à leur propriété croisée en temps opportun, conjointement avec l'approbation du Conseil du programme de nouveaux gTLD obligerait l'ICANN à comparaître pour donner une réponse aux demandes des Opérateurs.

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

    Les Opérateurs soutiennent leur besoin de supprimer les restrictions actuelles sur la propriété croisée en temps opportun pour être à même de concurrencer avec les bureaux d'enregistrement qui envisagent de présenter leur candidature pour opérer les nouveaux gTLD. Actuellement, il n'existe aucune restriction empêchant les registraires de poser leur candidature pour opérer les registres des nouveaux gTLD.

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

    Les impacts sur la communauté sont positifs du fait que les opérateurs de registre de gTLD existants seraient en mesure de supprimer leurs restrictions de propriété croisée et de préserver leur concurrence équitable avec les opérateurs de registre des nouveaux gTLD.

    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 cette Résolution n'a pas d'impact fiscal prévisible sur le Plan stratégique, le Plan opérationnel et/ou le Budget. Jusqu'à présent, aucune information sur les impacts fiscaux prévisibles sur la communauté ou le public n'est disponible.

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

    A l'heure actuelle, il n'existe aucun problème concernant la sécurité, la stabilité ou la résilience du DNS.

  4. ATRT

    6.1 Gestion du Conseil sur les recommandations de l'ATRT

    Considérant que, le rapport de propose 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, la mise en œuvre de ces recommandations exigera au Conseil d'entreprendre d'importants travaux ainsi qu'une coordination étroite avec le personnel et les groupes communautaires clés (y compris le Comité Consultatif Gouvernemental);

    RÉSOLU (2011.04.21.14), le Conseil demande aux Comités de mise en œuvre d'aborder les recommandations ATRT spécifiées dans le document ci-joint [PDF, 86 KB].

    FONDEMENTS DE LA RÉSOLUTION 2011.04.21.14:

    Tel que requis par l'affirmation d'engagements, les recommandations de (ATRT) ont été transmises au Conseil et publiées pour être soumises aux commentaires publics. Les commentaires publics étaient en faveur du rapport de l'ATRT et la diligence due du personnel a donné lieu à la recommandation pour que l'ICANN continue à faire les efforts nécessaires afin de mettre en œuvre les recommandations de l'ATRT. Le personnel a proposé des plans initiaux, ayant démontré la capacité de l'ICANN pour mettre en œuvre les recommandations et a fourni une estimation des coûts des ressources. Le Conseil a demandé au personnel de travailler avec les organisations concernées et d'élaborer des plans de mise en œuvre pour être soumis à 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.

    La mise en œuvre des 27 recommandations exigera au Conseil de réaliser d'importants travaux ainsi qu'une coordination étroite avec le personnel et les groupes communautaires clés (y compris le Comité Consultatif Gouvernemental). Pour aider à assurer la diligence due lors de cette mise en œuvre, le Conseil a délégué le travail de mise en œuvre des recommandations aux comités pertinents et a créé un Conseil GAC temporaire qui abordera conjointement avec le GAC les dites recommandations.

    6.2 Impact budgétaire estimé des recommandations de l'ATRT sur le budget de l'année fiscale 2012

    Attendu que le Conseil considère que les recommandations de l'équipe de révision de la responsabilité et transparence (ATRT) sont potentiellement capables de promouvoir les objectifs de transparence et de responsabilité de l'ICANN et peuvent être mises en œuvre par l'ICANN après un examen attentif et transparent, avec le soutien et les ressources nécessaires;

    Considérant que, environ 2 600 000 d'USD seront nécessaires pour compléter les activités de mise en œuvre de l'ATRT pour l'année fiscale 2012;

    Résolu (2011.04.21.15), le Conseil demande à la BFC de considérer les fonds nécessaires à la mise en œuvre de l'ATRT pour l'année fiscale 2012 comme détaillé par le personnel et de faire un rapport au Conseil d'administration lors de sa prochaine réunion.

    FONDEMENTS DE LA RÉSOLUTION 2011.04.21.15

    Le Conseil a signalé au préalable que les 27 recommandations des ATRT 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 attentif et transparent et avec le soutien et les ressources nécessaires. 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. Le Conseil fait preuve de diligence raisonnable sur la mise en œuvre des recommandations et des besoins afin de veiller à ce que le budget de l'année fiscale 2012, qui sera bientôt clôturé, inclue les fonds nécessaires à ces activités.

    Le Conseil a approuvé l'inclusion d'un financement supplémentaire dans le budget de l'année fiscale 2012 pour la mise en œuvre des recommandations ATRT et réaffirme son engagement à promouvoir la responsabilisation et la transparence de l'ICANN.

  5. DÉLÉGATIONS DES IDN ccTLD

    7.1 Délégation de الجزائر (« Al Jazair »), représentant l'Algérie en arabe

    Considérant que l'Algérie figure actuellement dans la norme ISO 3166-1;

    Considérant que, الجزائر (« al-Jazair »), codé comme « xn--lgbbat1ad8j », est une chaîne qui a été jugée à juste titre représentant l'Algérie lors de la progression de la procédure IDN accélérée;

    Considérant que l'ICANN a reçu une demande de délégation de .الجزائر au Centre de Recherche sur l'information Scientifique et Technique (CERIST);

    Considérant que l'ICANN a examiné la demande et a déterminé que la délégation proposée répond aux intérêts des communautés Internet locales et mondiales;

    RÉsolu (2011.04.21.16), que la délégation proposée dudomaine de premier niveau .الجزائر au CERIST est approuvée.

    FONDEMENTS DE LA RÉSOLUTION 2011.04.21.16

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

    Le Personnel soumet à la considération du Conseil les requêtes de délégation et redélégation des domaines de code de pays. Après avoir satisfait les demandes du personnel en fournissant une candidature suffisamment complète, le candidat a une probabilité raisonnable d'obtenir l'approbation du Conseil. Conformément aux engagements de l'ICANN visant à effectuer de manière efficiente le traitement des demandes liées à la fonction IANA et, notamment, à la zone racine DNS, le Conseil de l'ICANN cherche à évaluer ces demandes lors de sa prochaine assemblée extraordinaire.

    Quelles sont les propositions à l'étude?

    Il est proposé d'approuver la demande à l'IANA de changer ou de désigner l'organisation de parrainage (connue également sous le nom de gestionnaire ou administrateur) d'un domaine de premier niveau de code de pays. Conformément à la pratique établie, le Conseil de l'ICANN est impliqué dans la décision de procéder à de telles demandes comme une étape de ce processus multi- étapes.

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

    Dans le cadre de l'évaluation d'une demande de délégation, le personnel de l'ICANN consulte le candidat, l'opérateur actuel (le cas échéant), et d'autres parties directement concernées. Conformément à la pratique de l'ICANN de maintenir la confidentialité des demandes de modification de la zone racine, l'ICANN n'a pas effectué de consultation ouverte sur cette question.

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

    Quelques préoccupations ou questions concernant cette action ont été soulevées dans le rapport public qui sera bientôt publié. Ce rapport, qui sera publié au site Web de l'IANA (http://www.iana.org/) est censé mener à bonne fin le traitement définitif des demandes de modifications de la zone racine, normalement 1 ou 2 mois après la décision du Conseil.

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

    Le Conseil participe à l'évaluation de demandes impliquant une diversité de critères d'intérêt public. Ce critère vise à établir l'admissibilité des codes de pays (p. ex. énumérés dans la norme ISO 3166-1); à établir la proposition d'un administrateur soutenu par la communauté Internet locale; la compétence opérationnelle et technique de l'opérateur proposé; l'opération de l'administrateur proposé depuis une base locale et en vertu de la loi locale; à établir qu'il opère de manière juste et équitable; à ce que, au cas où il y aurait un transfert des opérations, un plan approprié soit mis en place pour préserver la continuité de la stabilité du domaine; et à établir que l'action soit compatible avec toutes les règlementations et les lois locales applicables. Lors du processus de compilation du personnel, le candidat est prié de fournir une variété de documents à l'appui de ces différents aspects. Toute information pertinente sur ces documents et d'autres recherches du personnel est présentée au Conseil et publiée dans un rapport public à la fin de la mise en œuvre d'une demande approuvée.

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

    Le Conseil tient compte des facteurs décrits dans le rapport public, à l'égard des principes fondamentaux de délégation de domaine de code de pays décrits précédemment.

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

    L'approbation en temps opportun des administrateurs de noms de domaine de code de pays répondant aux divers critères d'intérêt public est positive vis-à-vis de la mission globale de l'ICANN et les communautés locales, dont les domaines de premier niveau de code de pays sont désignés pour desservir.

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

    La gestion de délégations des codes de pays dans la zone racine du DNS fait partie des fonctions de l'IANA, et le processus de délégation ne devrait pas produire une variation significative des dépenses prévues. L'ICANN n'est pas censé évaluer l'impact financier des opérations internes des domaines de premier niveau de code de pays au sein d'un pays; l'ICANN doit seulement assurer que l'opérateur réside dans le pays et qu'il possède les mécanismes appropriés pour permettre à la communauté Internet locale de surveiller correctement la continuité de ses opérations de domaine.

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

    Pour les délégations de domaine de premier niveau de code de pays, l'ICANN cherche à approuver les demandes qui abordent de façon satisfaisante les préoccupations raisonnables, et puisque le nouvel administrateur proposé a fait preuve de ses compétences opérationnelles et techniques, ces préoccupations devraient être peu significatives.

    7.2 Délégation de المغرب (« al-Maghrib »), représentant le Maroc en arabe

    Considérant que, المغرب (« al-Maghrib »), codé comme « xn--mgbc0a9azcg » est une chaîne qui a été jugée à juste titre représentant le Maroc lors de la procédure IDN accélérée;

    Considérant que l'ICANN a reçu une demande de délégation de .المغرب à l'Agence Nationale de Réglementation des Télécommunications;

    Considérant que l'ICANN a examiné la demande et a déterminé que la délégation proposée répond aux intérêts des communautés Internet locales et mondiales;

    RÉsolu (2011.04.21.17), la délégation proposée du domaine .المغرب à l'Agence Nationale.

    FONDEMENTS DE LA RÉSOLUTION 2011.04.21.17

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

    Le Personnel soumet à la considération du Conseil les requêtes de délégation et redélégation des domaines de code de pays. Après avoir satisfait les demandes du personnel en fournissant une candidature dûment complétée, le candidat a une probabilité raisonnable d'obtenir l'approbation du Conseil. Conformément aux engagements de l'ICANN visant à effectuer de manière efficiente le traitement des demandes liées à la fonction IANA et, notamment, à la zone racine DNS, le Conseil de l'ICANN cherche à évaluer ces demandes lors de sa prochaine assemblée extraordinaire.

    Quelles sont les propositions à l'étude?

    Il est proposé d'approuver la demande à l'IANA de changer ou de désigner l'organisation de parrainage (connue également sous le nom de gestionnaire ou administrateur) d'un domaine de premier niveau de code de pays. Conformément à la pratique établie, le Conseil de l'ICANN est impliqué dans la décision de procéder à de telles demandes comme une étape de ce processus multi- étapes.

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

    Dans le cadre de l'évaluation d'une demande de délégation, le personnel de l'ICANN consulte le candidat, l'opérateur actuel (le cas échéant), et d'autres parties directement concernées. Conformément à la pratique de l'ICANN de maintenir la confidentialité des demandes de modification de la zone racine, l'ICANN n'a pas effectué de consultation ouverte sur cette question.

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

    Quelques préoccupations ou questions concernant cette action ont été soulevées dans le rapport public qui sera bientôt publié. Ce rapport, qui sera publié au site Web de l'IANA (http://www.iana.org/) est censé mener à bonne fin le traitement définitif des demandes de modifications de la zone racine, normalement 1 ou 2 mois après la décision du Conseil.

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

    Le Conseil participe à l'évaluation de demandes impliquant une diversité de critères d'intérêt public. Ce critère vise à établir l'admissibilité des codes de pays (p. ex. énumérés dans la norme ISO 3166-1); à établir la proposition d'un administrateur soutenu par la communauté Internet locale; la compétence opérationnelle et technique de l'opérateur proposé; l'opération de l'administrateur proposé depuis une base locale et en vertu de la loi locale; à établir qu'il opère de manière juste et équitable; à ce que, au cas où il y aurait un transfert des opérations, un plan approprié soit mis en place pour préserver la continuité de la stabilité du domaine; et à établir que l'action soit compatible avec toutes les règlementations et les lois locales applicables. Lors du processus de compilation du personnel, le candidat est prié de fournir une variété de documents à l'appui de ces différents aspects. Toute information pertinente sur ces documents fournis et d'autres recherches du personnel est adressée au Conseil et publiée dans un rapport public à la fin de la mise en œuvre d'une demande approuvée.

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

    Le Conseil tient compte des facteurs décrits dans le rapport public, à l'égard des principes fondamentaux de délégation de domaine de code de pays décrits précédemment.

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

    L'approbation en temps opportun des administrateurs de noms de domaine de code de pays répondant aux divers critères d'intérêt public est positive vis-à-vis de la mission globale de l'ICANN et les communautés locales, dont les domaines de premier niveau de code de pays sont désignés pour desservir.

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

    La gestion de délégations des codes de pays dans la zone racine du DNS fait partie des fonctions de l'IANA, et le processus de délégation ne devrait pas produire une variation significative des dépenses prévues. L'ICANN n'est pas censé évaluer l'impact financier des opérations internes des domaines de premier niveau de code de pays au sein d'un pays; l'ICANN doit seulement assurer que l'opérateur réside dans le pays et qu'il possède les mécanismes appropriés pour permettre à la communauté Internet locale de surveiller correctement la continuité de ses opérations de domaine.

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

    Pour les délégations de domaine de premier niveau de code de pays, l'ICANN cherche à approuver les demandes qui abordent de façon satisfaisante les préoccupations raisonnables, et puisque le nouvel administrateur proposé a fait preuve de ses compétences opérationnelles et techniques, ces préoccupations devraient être peu significatives.

    7.3 Délégation du domaine .срб (« srb ») représentant la Serbie en cyrillique

    Considérant que la Serbie figure actuellement dans la norme ISO 3166-1;

    Considérant que, срб (« srb »), codé comme « xn--90a3ac » est une chaîne qui a été jugée à juste titre représentant la Serbie lors de la progression de la procédure IDN accélérée;

    Considérant que l'ICANN a reçu une demande de délégation de .срб au Registre National Serbe des Noms de Domaine d'Internet (RNIDS);

    Considérant que l'ICANN a examiné la demande et a déterminé que la délégation proposée répond aux intérêts des communautés Internet locales et mondiales.

    RÉSOLU (2011.04.21.18), la délégation proposée du domaine de premier niveau .срб au Registre National Serbe des Noms de Domaine Internet est approuvée.

    FONDEMENTS DE LA RÉSOLUTION 2011.04.21.18

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

    Le Personnel soumet à la considération du Conseil les requêtes de délégation et redélégation des domaines de code de pays. Après avoir satisfait les demandes du personnel en fournissant une candidature suffisamment complète, le candidat a une probabilité raisonnable d'obtenir l'approbation du Conseil. Conformément aux engagements de l'ICANN visant à effectuer de manière efficiente le traitement des demandes liées à la fonction IANA et, notamment, à la zone racine DNS, le Conseil de l'ICANN cherche à évaluer ces demandes lors de sa prochaine assemblée extraordinaire.

    Quelles sont les propositions à l'étude?

    Il est proposé d'approuver la demande à l'IANA de changer ou de désigner l'organisation de parrainage (connue également sous le nom de gestionnaire ou administrateur) d'un domaine de premier niveau de code de pays. Conformément à la pratique établie, le Conseil de l'ICANN est impliqué dans la décision de procéder à de telles demandes comme une étape de ce processus multi- étapes.

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

    Dans le cadre de l'évaluation d'une demande de délégation, le personnel de l'ICANN consulte le candidat, l'opérateur actuel (le cas échéant), et d'autres parties directement concernées. Conformément à la pratique de l'ICANN de maintenir la confidentialité des demandes de modification de la zone racine, l'ICANN n'a pas effectué de consultation ouverte sur cette question.

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

    Quelques préoccupations ou questions concernant cette action ont été soulevées dans le rapport public qui sera bientôt publié. Ce rapport, qui sera publié au site Web de l'IANA (http://www.iana.org/) est censé mener à bonne fin le traitement définitif des demandes de modifications de la zone racine, normalement 1 ou 2 mois après la décision du Conseil.

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

    Le Conseil participe à l'évaluation de demandes impliquant une diversité de critères d'intérêt public. Ce critère vise à établir l'admissibilité des codes de pays (p. ex. énumérés dans la norme ISO 3166-1); à établir la proposition d'un administrateur soutenu par la communauté Internet locale; la compétence opérationnelle et technique de l'opérateur proposé; l'opération de l'administrateur proposé depuis une base locale et en vertu de la loi locale; à établir qu'il opère de manière juste et équitable; à ce que, au cas où il y aurait un transfert des opérations, un plan approprié soit mis en place pour préserver la continuité de la stabilité du domaine; et à établir que l'action soit compatible avec toutes les règlementations et les lois locales applicables. Lors du processus de compilation du personnel, le candidat est prié de fournir une variété de documents à l'appui de ces différents aspects. Toute information pertinente sur ces documents fournis et d'autres recherches du personnel est adressée au Conseil et publiée dans un rapport public à la fin de la mise en œuvre d'une demande approuvée.

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

    Le Conseil tient compte des facteurs décrits dans le rapport public, à l'égard des principes fondamentaux de délégation de domaine de code de pays décrits précédemment.

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

    L'approbation en temps opportun des administrateurs de noms de domaine de code de pays répondant aux divers critères d'intérêt public est positive vis-à-vis de la mission globale de l'ICANN et les communautés locales, dont les domaines de premier niveau de code de pays sont désignés pour desservir.

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

    La gestion de délégations des codes de pays dans la zone racine du DNS fait partie des fonctions de l'IANA, et le processus de délégation ne devrait pas produire une variation significative des dépenses prévues. L'ICANN n'est pas censé évaluer l'impact financier des opérations internes des domaines de premier niveau de code de pays au sein d'un pays; l'ICANN doit seulement assurer que l'opérateur réside dans le pays et qu'il possède les mécanismes appropriés pour permettre à la communauté Internet locale de surveiller correctement la continuité de ses opérations de domaine.

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

    Pour les délégations de domaine de premier niveau de code de pays, l'ICANN cherche à approuver les demandes qui abordent de façon satisfaisante les préoccupations raisonnables, et puisque le nouvel administrateur proposé a fait preuve de ses compétences opérationnelles et techniques, ces préoccupations devraient être peu significatives.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."