Résolutions préliminaires du Conseil | Réunion spéciale du Conseil d'administration 25 août 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-25aug11-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. Ordre du jour approuvé
   • 1.1. Approbation du procès verbal de la réunion du Conseil spécial de l'ICANN du 28 juillet 2011
   • 1.2. Approbation de la recommandation du Conseil de la GNSO de l'IRTP Partie B
     • Fondements des Résolutions 2011.08.25.02-05
   • 1.3. Approbation de réception du Groupe de travail de TR
     • Fondements de la résolution 2011.08.25.06
2. Approbation du Président du NomCom et du Président élu
   • Fondements de la résolution 2011.08.25.07
3. Approbation de la demande de reconsidération 11-1 du BGC
   • Fondements de la résolution 2011.08.25.08
4. Étapes du processus pour considérer la rémunération du Conseil
   • Fondements de la résolution 2011-08-25-09 – 15
5. Mise à jour des TDL IDN d'un seul caractère
   • Fondements de la résolution 2011.08.25.16

 

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 28 juillet 2011

   Résolu (2011.08.25.01), le Conseil approuve les procès-verbaux de la Réunion du Conseil de l'ICANN du 28 juillet 2011.

   1.2. Approbation de la recommandation du Conseil de la GNSO de l'IRTP Partie B

   Attendu que, le 24 juin 2009, le Conseil de la GNSO a lancé un processus de développement stratégique (PDP) sur la politique de transfert des noms de domaine entre bureaux d'enregistrement Partie B (IRTP Partie B) abordant cinq questions relatives à la charte, qui figurent sur https://community.icann.org/display/gnsoirtpb/3.+WG+Charter;

   Attendu que le PDP a suivi les étapes prévues dans les statuts, qui ont donné lieu au rapport final délivré le 30 mai 2011 ;

   Attendu que le groupe de travail IRTP Partie B (GT) a atteint un consensus total sur les recommandations concernant chacune des cinq questions énoncées dans la Charte ;

   Considérant que le Conseil de la GNSO a révisé et discuté les recommandations du groupe de travail IRTP Partie B, et qu'il a adopté les recommandations le 22 juin 2011 par majorité qualifiée et à l'unanimité (voir : http://gnso.icann.org/resolutions/#201106);

   Considérant que le vote du Conseil de la GNSO a atteint et même dépassé le nombre de voix nécessaires pour imposer de nouvelles obligations aux parties contractantes de l'ICANN.

   Considérant que, après le vote du Conseil de la GNSO, une période de commentaires publics de 30 jours sur les recommandations approuvées a été établie, et que les commentaires ont été résumés et considérés (http://www.icann.org/en/public-comment/irtp-b-recommendations-08jul11-en.htm).

   Résolu (2011.08.25.02) le Conseil d'administration adopte les recommandations qui modifient la politique de transfert de noms de domaine entre bureaux d'enregistrement stipulées dans http://www.icann.org/fr/transfers/policy-fr.htm.

   Résolu (2011.08.25.03) le PDG développera et complètera un plan de mise en œuvre pour ces recommandations et la communication continue avec la communauté concernant ces travaux.

   Résolu (2011.08.25.04) le PDG a reçu des instructions pour entreprendre les études identifiées par le Conseil de la GNSO à [identifier les résolutions ici] afin de faciliter les futurs travaux en la matière.

   Résolu (2011.08.25.05), le Conseil encourage la GNSO, l'ALAC et d'autres membres de la communauté de l'ICANN à travailler ensemble afin de promouvoir les mesures énoncées dans le guide du titulaire de noms de domaine du SSAC rapport A visant à protéger l'enregistrement des comptes de noms de domaine (SAC 044), tel qu'il a été établi dans les résolutions du Conseil de la GNSO.

   Fondements des Résolutions 2011.08.25.02-05

   Pourquoi le Conseil aborde-t-il cette question maintenant ?
   La politique de transfert de noms de domaine entre bureaux d'enregistrement (IRTP) s'agit d' une politique de consensus adoptée en 2004 qui met à disposition des titulaires de noms de domaine un processus simple afin qu'ils puissent transférer les noms de domaine entre bureaux d'enregistrement. Le Conseil de la GNSO a établi une série de cinq groupes de travail (Parties A à E) pour examiner et considérer plusieurs révisions à cette politique.

   L'IRTP PDP Partie B est le deuxième d'une série de cinq secteurs d'adressage PDP pour améliorer la politique existante. Le groupe de travail de l'IRTP Partie B a traité cinq problématiques portant plus particulièrement sur le piratage de noms de domaine, l'annulation urgente d'un transfert non approprié et l'utilisation du statut de verrouillage. Le rapport final de l'IRTP Parti B PDP a reçu le consensus unanime du groupe de travail IRTP Partie B ainsi que du Conseil de la GNSO. Suite à la clôture de la période de commentaires publics le 8 août, lors de la prochaine étape, tel que prévu dans l'Annexe A des statuts de l'ICANN, le Conseil d'administration de l'ICANN prendra en considération les recommandations. 

   Quelles sont les propositions à l'étude ?
   Les options suivantes sont prises en considération :

   • Demander aux bureaux d'enregistrement de fournir un contact de transfert des actions d'urgence (Transfer Emergency Action Contact - TEAC). À ces fins, les textes de la section 4 (coordination des bureaux d'enregistrement) et la section 6 (exigences pour les registres) de la politique de transfert entre bureaux d'enregistrement ont été modifiés (pour plus de détails, voir l'Annexe). Le contact de transfert des actions d'urgence (TEAC) est un mécanisme que vise à faciliter les communications urgentes concernant les transferts. L'objectif du TEAC est d'établir le plus vite possible les communications en temps réel entre les représentants des bureaux d'enregistrement en cas d'urgence ; par exemple un transfert suite à la fraude sur un nom de domaine, de sorte que le bureau d'enregistrement puisse décider les actions à suivre afin de trouver une solution au problème.  Le TEAC s'occupe seulement d'établir cette communication ; en aucun cas il ne pourra résoudre les disputes pouvant découler de l'application d'autres politiques et procédures.
   • Modifier la section 3 de l'IRTP afin que le bureau d'enregistrement/bureau d'enregistrement perdant notifie le nom du titulaire de nom enregistré/registrant du transfert. Le bureau d'enregistrement peut accéder à l'information de contact et il peut modifier les systèmes afin d'envoyer automatiquement le formulaire standardisé pour les registraires perdants (« Confirmation FOA ») au registrant. Cette notification obligatoire mettra le registrant en garde, à un stade précoce, de la demande d'un transfert ; cela permettra de détecter tout conflit potentiel avant qu'un transfert ait été complété et pourra réduire, en conséquence, la quantité de conflits entre le contact admin et le registrant qui demande de défaire un transfert.
   • Modifier le motif de refus numéro 6 comme suit : objection écrite expresse au transfert par le contact de transfert autorisé. L'objection pourrait être une demande spécifique (soit en support papier ou par voie électronique) faite par le contact de transfert pour refuser une demande particulière de transfert, ou une objection générale à toutes les demandes de transfert reçues par le bureau d'enregistrement, soit de manière temporaire ou indéterminée. Dans tous les cas, l'objection doit compter avec le consentement explicite et éclairé du contact de transfert autorisé sur une base souscrite et sous demande du contact de transfert autorisé ; le bureau d'enregistrement doit enlever le verrouillage ou bien fournir une méthode raisonnablement accessible pour que le contact de transfert autorisé puisse annuler le verrouillage dans les cinq (5) jours calendaires. Le texte actuel du motif de refus numéro 6 n'est pas clair et peut donner lieu à différentes interprétations, notamment en ce qui concerne le terme ‘volontairement',si bien qu'il est recommandé de le reformuler et de le clarifier afin de le cibler explicitement au verrouillage spécifique aux registrants (c'est-à-dire non-EPP) et de bien préciser que le registrant doit s'engager à donner son consentement formel pour l'application d'un tel verrouillage et qu'il doit pouvoir faire enlever ledit verrouillage moyennant un préavis raisonnable et une authentification.
   • L'élimination du motif de refus numéro 7 est une raison de refus valable sous la section 3 de l'IRTP du fait qu'il n'est pas techniquement possible d'initier le transfert d'un nom de domaine verrouillé qui ne peut donc pas être refusé, ce qui rend obsolète le motif de ce refus.

   Quelles parties intéressées ou autres ont été consultées?
   Les forums de commentaires du public figurent dans initiation of the PDP, the Initial Report, proposed Final Report et the recommendations subject to Board Consideration, additionnellement aux mises à jour du conseil de la GNSO ainsi que comme ateliers pour informer et demander l'opinion de la communauté de l'ICANN lors des réunions de l'ICANN (voir par exemple, Brussels Meeting et San Francisco Meeting). Les déclarations des regroupements et du groupe des parties prenantes ont été soumises (voir https://community.icann.org/display/gnsoirtpb/IRTP+Part+B). Tous les commentaires reçus ont été révisés et étudiés par le groupe de travail IRTP Partie B PDP (voir section 6 du IRTP Part B Final Report [PDF, 1.04 MB]). De plus, tel que stipulé dans les statuts de l'ICANN, un public comment forum a été inclus dans les recommandations pour la considération du Conseil d'administration de l'ICANN.

   Quelles sont les préoccupations ou les questions qui ont été soulevées par la communauté ?
   La seule préoccupation identifiée dans le forum des commentaires publics sur les recommandations devant être considérée par le Conseil de l'ICANN a trait au temps de réponse de quatre heures requis comme une partie de la recommandation du contact de transfert des actions d'urgence (TEAC). Le commentateur signale que cela signifierait ‘un lourd fardeau pour les bureaux d'enregistrement de taille petite et moyenne. Cependant, le commentaire semble supposer que l'on demande une résolution dans les quatre heures ('une solution/ résolution peut aussi avoir lieu après 1 ou 2 jours') au lieu d'une réponse initiale, à savoir la seule exigence requise sous le TEAC proposé. Tel que le groupe de travail IRTP Parti B PDP l'a mentionné dans son rapport final ‘l'objectif du TEAC est d'établir rapidement le temps de communication réel entre les représentants du bureau d'enregistrement pouvant s'occuper de résoudre cette question, mais cette politique mentionne seulement que cette communication ne résoudra aucune dispute pouvant survenir'. En ce qui concerne le temps de réponse de quatre heures, le groupe de travail IRTP Partie B PDP signale que ‘même les bureaux d'enregistrement plus petits peuvent tout simplement alterner cette fonction entre le personnel d'opérations, de la même manière qu'ils alternent d'autres aspects « urgents » de leur activité. Les requêtes du TEAC semblent être peu nombreuses et peu fréquentes ; mais, dès qu'il y en a une, il s'agit d'une véritable urgence qu'il faut régler immédiatement'. Il est à noter que les bureaux d'enregistrement, soient-ils de petite ou de grande taille, ont participé des délibérations du groupe de travail IRTP Partie B et qu'ils ont donné leur soutien aux recommandations.

   Quels sont les documents importants qui ont été révisés par le Conseil ?
   Le Conseil a révisé le rapport du conseil de la GNSO au Conseil d'administration, ainsi que la synthèse des commentaires publics et la réponse de l'équipe à ces commentaires.

   Quels sont les facteurs que le Conseil a trouvés significatifs ?
   Les recommandations ont été élaborées selon le processus d'élaboration de la politique de la GNSO, telle que décrite dans l'annexe A des statuts de l'ICANN et ont reçu l'appui unanime de la GNSO Comme indiqué dans les statuts de l'ICANN, le soutien unanime de cette motion par le Conseil (majorité qualifié) oblige le Conseil a adopter la recommandation, sauf si, par un vote de plus de 66%, le Conseil détermine que la politique concernée n'est pas dans le meilleur intérêt de la communauté de l'ICANN ou de l'ICANN. En outre, les questions liées au transfert sont le premier domaine de plainte selon les données de conformité de l'ICANN.  Des améliorations faites à la politique de transferts inter opérateur de registre (IRTP) ont le potentiel de réduire le nombre de plainte et d'offrir davantage de clarté et de prévisibilité aux registrants et aux bureaux d'enregistrement.

   Cela a-t-il des effets positifs ou négatifs pour la communauté ?
   Des améliorations faites à la politique de transferts inter opérateur de registre (IRTP) ont le potentiel de réduire le nombre de plainte et d'offrir davantage de clarté et de prévisibilité aux registrants et aux bureaux d'enregistrement. L'adoption des recommandations exigera des changements dans les processus des bureaux d'enregistrement mais ils sont considérés comme ayant un impact minimal et comme nécessaire pour aborder les questions qui font partie de ce processus de développement politique. Les recommandations, si elles sont appliquées, pourraient être utiles pour préciser et consolider l'IRTP, pour le bénéfice de toutes les parties concernées.

   Cela a-t-il un impact au niveau fiscal sur l'ICANN (plan stratégique, plan opérationnel, budget), la communauté ou le public ?
   En dehors de ces changements nécessaires dans le processus pour les bureaux d'enregistrement comme indiqué ci-dessus, aucune autre répercussion fiscale ou conséquences ne sont attendues pour l'ICANN, pour la communauté et ou pour le public.

   Y a-t-il des questions de sécurité, de stabilité ou de résilience concernant le DNS ?
   Il n'y a aucun problème de sécurité, de stabilité ou de résilience lié au DNS si le Conseil approuve les recommandations proposées.

   1.3 Approbation de réception du Groupe de travail de TR

   Attendu que le 18 mars 2011, le Conseil a reçu un rapport final de l'examinateur indépendant pour la révision du groupe de liaison technique (TLG) et a décidé d'établir un groupe de travail du Conseil de relations techniques, le BTRWG, pour aborder les recommandations du rapport final de révision du groupe de liaison technique (TLG). (Résolutions 2011.03.18.28-31)

   Attendu que le 21 avril 2011, le Conseil a décidé d'adopter la composition du BTRWG et la charte du groupe de travail du BTR. (Résolutions 2011.04.21.05 et 2011.04.21.12).

   Attendu que le groupe de travail du BTR a remis son rapport final préliminaire « Rapport final préliminaire du groupe de travail des relations techniques du Conseil ».

   RÉSOLU (2011.08.25.06), le Conseil accuse réception du document « Rapport final préliminaire du groupe de travail des relations techniques du Conseil », daté du 22 août 2011, et remercie le groupe de travail du BTR d'avoir effectué son travail en temps opportun et demande au comité d'amélioration structurelle (SIC) d'analyser le rapport et de proposer une action.

   Fondements de la résolution 2011.08.25.06

   Les actions proposées répondent directement à une demande du Conseil et servent à avancer dans le travail d'amélioration en accord avec le chronogramme prévu. 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.

2. Approbation du Président du NomCom et du Président élu

   Attendu que le comité de gouvernance du conseil (BGC) a examiné les déclarations d'intérêt des candidats au poste de président du comité de nomination (NomCom) et de président élu.

   Attendu que le BGC a convenu d'une brève liste de candidats et a invité les membres du Conseil à participé à des entretiens avec ces candidats, ce qui a donné lieu à des recommandations du Conseil.

   Résolu (2011.08.25.07), le Conseil adopte la recommandation du BGC et nomme Vanda Scartezini présidente du NomCom 2012 et Rob Hall président élu du NomCom 2012.

   Fondements de la résolution 2011.08.25.07

   Le règlement de l'ICANN exige que le Conseil nomme le président du comité de nomination (NomCom) et le président élu du NomCom.  Voir Article VII, sections 2.1 et 2.2 à http://www.icann.org/fr/general/bylaws-fr.htm#VII. Le Conseil a délégué la responsabilité de recommander des candidats au poste de président et de président élu du NomCom pour leur approbation par le Conseil au comité de gouvernance du Conseil.  Voir la charte du BGC à http://www.icann.org/en/committees/board-governance/charter.htm. Le BGC a publié un appel à manifestation d'intérêt (EOI), et a reçu et révisé plusieurs EOI. Il a également conduit des entretiens avec certains candidats avant de formuler ses recommandations. Le Conseil a examiné les recommandations du BGC et il les approuve. 

   La nomination du président et du président élu du NomCom identifiés grâce à un processus d'EOI public affecte positivement la transparence et la responsabilité de l'ICANN. L'adoption de la recommandation du BGC n'a aucun impact financier sur l'ICANN et n'aura pas d'impact négatif sur la sécurité systémique, la stabilité et la résilience du système de nom de domaine.

   Le Conseil remarque que la coordination entre le NomCom, les organisations de soutien de l'ICANN et les comités consultatifs est nécessaire pour standardiser les descriptions de poste pour le président et le président élu du NomCom, ainsi que pour les postes dont le NomCom est responsable au sein de l'ICANN. En outre, il est nécessaire de développer, en consultation avec le comité de nomination, un ensemble standardisé de pratiques d'identification de conflits d'intérêt à l'usage des membres du NomCom.  Le comité de gouvernance du Conseil va continuer à dialoguer avec de comité de nomination sur cette question et sur d'autres problèmes, y compris la poursuite des travaux pour répondre aux recommandations de l'équipe de révision pour la responsabilité et la transparence, lors de la réunion de l'ICANN de Dakar, Sénégal.

3. Approbation de la demande de reconsidération 11-1 du BGC

   Attendu que le BGC a révisé la demande de reconsidération 11-1 soumise par Michael F. Gende le 15 juin 2011 concernant le nom de domaine zetamusic.com.

   Attendu que le BGC a déterminé que la demande de reconsidération 11-1 devait être refusée.

   Attendu que la demande de reconsidération 11-1 et la recommandation du BGC ont été publiées sur le site Internet d'ICANN : http://www.icann.org/en/committees/board-governance/requests-for-reconsideration-en.htm.

   Résolu (2011.08.25.08), le Conseil adopte la recommandation du BGC pour que la demande de reconsidération soit refusée étant donné que l'action demandée va au-delà des prérogatives de l'ICANN et que le processus de reconsidération n'est pas le forum approprié pour présenter des plaintes concernant des différends sur le nom de domaine.

   Fondements de la résolution 2011.08.25.08

   Les statuts de l'ICANN sollicitent au Comité de gouvernance du Conseil d'évaluer et de faire des recommandations concernant les demandes de reconsidération. Voir Article IV, section 3 des statuts à http://www.icann.org/fr/general/bylaws-fr.htm#V. Le Conseil a révisé et débattu en profondeur la recommandation du BGC concernant la demande de reconsidération 11-1 et considère que l'analyse est adéquate.

   Le fait d'avoir un processus de reconsidération à travers lequel le BGC effectue une révision et recommande l'approbation du Conseil affecte positivement la transparence et la responsabilité de l'ICANN. Cette approche permet à la communauté de s'assurer que le personnel et le Conseil agissent en accord avec les politiques, les statuts et les articles d'incorporation de l'ICANN.  L'adoption de la recommandation du BGC n'a aucun impact financier sur l'ICANN et n'aura pas d'impact négatif sur la sécurité systémique, la stabilité et la résilience du système de nom de domaine.

   Dans ce cas, le processus de reconsidération a été invoqué afin d'obtenir le transfert d'un enregistrement de nom de domaine et de présenter une plainte contre la réponse préalable d'ICANN indiquant que le demandeur devait contacter le registrant, le bureau d'enregistrement ou devait avoir recours à toute autre alternative appropriée susceptible de l'aider à obtenir le transfert de l'enregistrement. Étant donné que l'action demandée ne fait pas partie des prérogatives de l'ICANN, cette demande a été refusée. Le Conseil signale aussi que le processus de reconsidération n'est pas le forum approprié pour déposer des plaintes concernant les noms de domaine. Il existe d'autres mécanismes moyennant lesquels les plaintes peuvent être reçues et traitées.

   Néanmoins, la demande, en ligne avec les processus de conformité de l'ICANN, a été transmise au registrant afin d'être suivie directement avec le demandeur.

4. Étapes du processus pour considérer la rémunération du Conseil

   Attendu que l'ICANN offre actuellement une rémunération au Président de son Conseil pour les services rendus en tant que Président du Conseil d'administration

   Attendu que l'ICANN souhaite évaluer s'il convient d'appliquer la possibilité de toucher une rémunération en échange de leurs services rendus au Conseil à d'autres membres du Conseil (« Directeurs »).

   Attendu que l'ICANN est une corporation d'intérêt public à but non lucratif exonérée de l'impôt fédéral sur le revenu en vertu de la disposition §501(a) du Code fédéral américain des impôts sur les revenus (Internal Revenu Code) de 1986 amendé (le « CODE ») en tant qu'organisation décrite dans la disposition §501(a) du Code.

   Attendu que l'ICANN ne peut pas verser aux directeurs davantage de compensation que la rémunération raisonnable déterminée selon les normes énoncées dans la disposition § 53.4958 4(b) des règlements établis en vertu de la disposition § 4958 du Code (les «Règlements»).

   Résolu (2011.08.25.09), le Conseil exige au personnel de prendre toutes les mesures nécessaires pour évaluer si la rémunération des directeurs votants est pertinente.

   Résolu (2011.08.25.10), dans le cadre du processus de révision de rémunération des directeurs, le Conseil doit conserver un expert indépendant en valorisation, tel que défini dans la disposition §53.4958-1(d)(4)(iii)(C) des Règlements (un «Expert») pour être consulté et pour conseiller le Conseil sur la pertinence et les montants des rémunérations versées aux directeurs et qui délivre au Conseil un Avis justifié par écrit, tel que ce terme est défini dans la disposition §53.4958-1(d)(4)(iii)(C) des Règlements (l'«Avis»), concernant la fourchette de montants d'une rémunération raisonnable pour les services rendus par un directeur.

   Résolu (2011.08.25.11), l'avis de l'Expert doit comprendre tous les facteurs que l'Expert juge appropriés quant à la pertinence et au montant de la rémunération à verser à un directeur votant pour les services rendus à l'ICANN en tant que directeur, y compris les postes occupés au sein du conseil, l'assistance aux réunions du Conseil et du Comité, la nature de la fonction remplie dans le Conseil et dans les comités du Conseil et les données appropriées en matière de comparabilité, tel que ce terme est défini dans la disposition §53.4958-6(c)(2) des Règlements, concernant les arrangements de rémunération de directeur de la part d'organisations à but non lucratif, exonérés d'impôt et possédant une base d'employés mondiale situées sur le territoire des Etats-Unis.

   Résolu (2011.08.25.12), après avoir examiné l'avis de l'expert, le Conseil se réunit avec l'Expert afin de discuter son Avis et de lui poser des questions concernant l'Avis, les données de Comparabilité obtenues et considérées et les conclusions tirées par l'Expert.

   Résolu (2011.08.25.13), que le Conseil doit documenter adéquatement les fondements de toute décision de la Commission concernant les arrangements de rémunération des directeurs parallèlement à l'adoption de cette détermination.

   Résolu (2011.08.25.14), le Conseil général de l'ICANN est autorisé et mandaté pour conserver Towers Watson en tant qu'Expert d'évaluation indépendant du Conseil pour consulter et pour conseiller le Conseil concernant les arrangements de rémunération des directeurs et pour présenter au Conseil l'Avis justifié par écrit mentionné ci-dessus concernant la pertinence et les montants d'une rémunération raisonnable pour les services rendus par un directeur.

   Résolu (2011.08.25.15), le personnel de l'ICANN doit publier une politique de conflits d'intérêts et des statuts révisés proposés qui seront nécessaires si le Conseil approuve la recommandation proposant que les membres du Conseil éligibles soient rémunérés par les services rendus à l'ICANN en tant que directeurs de l'ICANN. 

   Fondements de la résolution 2011-08-25-09 – 15

   Au cours des dernières années, l'ICANN a considéré des questions concernant la rémunération du Conseil. Le Conseil a publiquement débattu la question et a examiné des analyses et des conseils indépendants sur ce sujet. Par exemple : (i) il y avait des demandes de la communauté concernant le cadre de responsabilité et transparence de l'ICANN pour que l'ensemble du Conseil soit rémunéré ; (ii) des discussions sur l'urgence du budget depuis FY08 ont inclut le concept d'une possible rémunération du Conseil ; (iii) des experts d'évaluation indépendants ont présenté des études sur d'autres organismes sans but lucratif et sur la rémunération des membres du conseil ; (iv) le Boston Consulting Group (« BCG ») qui a effectué la révision du Conseil a suggéré que des honoraires relativement modestes pour rémunérer les directeurs pour le temps consacré à l'ICANN pourraient être appropriés ; (v) le groupe de travail de révision du Conseil a reconnu le soutien général du BCG et de la communauté à la proposition de rémunération des directeurs, mais il a recommandé une étude plus approfondie en coordination avec le conseil général et (vi) l'équipe de révision pour la responsabilité et la transparence a spécifiquement recommandé que le Conseil devrait mettre en œuvre un programme de rémunération des directeurs votants.

   En août 2010, le Conseil a approuvé une rémunération pour le président du Conseil. Depuis ce temps, la rémunération de tous les directeurs votants à été proposée à plusieurs reprises, plus récemment, par le biais de la Recommandation 5 de l'équipe de révision pour la responsabilité et la transparence.

   L'adoption de toutes les mesures nécessaires pour assurer que la considération de la rémunération des directeurs votants se fasse en conformité avec toutes les lois, les normes et les règlements appropriés affecte positivement la responsabilité et la transparence de l'ICANN. En outre, le fait d'informer la communauté à travers l'affichage de toutes les étapes du processus suivi par le Conseil, ainsi que les révisions proposées pour la politique de conflits d'intérêts et les statuts, améliorent considérablement la transparence de l'ICANN dans cette affaire.

   Le fait de suivre ces étapes aura un impact budgétaire sur l'ICANN dans la mesure où il faudrait ajouter les honoraires de l'expert d'évaluation indépendant ; la participation de ce dernier a été budgétisée lorsque le Conseil a adopté les recommandations ATRT.  L'adoption de ces mesures n'affectera pas négativement la sécurité, la stabilité ou la résilience du système de nom de domaine.

5. Mise à jour des TDL IDN d'un seul caractère

   Attendu que la délégation de TLD IDN de manière à promouvoir la sécurité et une bonne expérience de l'utilisateur est un sujet important pour le Conseil de l'ICANN et pour la communauté mondiale.

   Attendu que le Groupe de travail des noms réservés de la GNSO a conclu que, pour les IDN, il ne doit pas exister une restriction générale sur les libellés Unicode à caractère unique et qu'une analyse au cas par cas est recommandée.

   Attendu que l'équipe de travail pour la mise en œuvre des IDN a recommandé que les gTLD à caractère unique ne devraient pas être interdits, mais que les ramifications de cette question devraient être évaluées par des organisations de développement de politiques telles que la ccNSO et la GNSO.

   Attendu que le groupe de travail conjoint de ccNSO GNSO-IDN (JIG) a recommandé que les TLD à caractère unique soient acceptés dans la procédure accélérée d'IDN ccTLD dans le cadre des recommandations de politique générale de ccPDP IDN et du programme des nouveaux gTLD.

   Attendu que la procédure accélérée d'IDN de ccTLD a été conçue pour permettre l'introduction d'un nombre limité d'IDN ccTLD non litigieux pour répondre à la demande à court terme pendant le développement de la politique globale est développée en utilisant des méthodes qui ne s'opposent pas aux résultats du processus de l'élaboration de la politique relative aux codes pays dans les IDN.

   Attendu que le rapport du JIG soulève certaines questions, y compris (a) quel processus approprié pour consultation (y compris avec les communautés linguistiques pertinentes) est nécessaire lors de la considération de chaînes IDN de TLD à caractère unique et (b) si la conclusion politique serait différente s'il était précisé que seuls les scripts idéographiques sont acceptables pour les IDN de TLD à caractère unique.

   Attendu que ces dernières considérations et toute autre considération technique et politique doivent être abordées avant la délégation d'un TLD à caractère unique quelconque.

   Attendu qu'on estime que le temps nécessaire pour considérer ces questions de façon appropriée dépasse la période de soumission de candidatures prévue pour le premier tour de candidature de gTLD.

   Résolu (2011.08.28.16), le Conseil, sur la question de la délégation des gTLD à caractère unique :

   1. Demande des conseils spécifiques à la SSAC sur des aspects de sécurité et de stabilité concernant cette question.
   2. Demande au GAC d'examiner et de donner des conseils spécifiques sur des aspects de politique publique concernant cette question.
   3. Demande des conseils spécifiques à l'ALAC sur des aspects consommateur/utilisateur final concernant cette question.
   4. Demande au personnel de consulter les autres participants appropriés et compétents de la communauté dans les différentes langues/scripts sur ce sujet et de faire parvenir au Conseil et à la communauté un rapport qui reflète cette contribution pour permettre au Conseil évaluer la délégation des IDN de TLD à caractère unique.
   5. Demande au personnel de publier un calendrier pour ce travail en indiquant clairement que les processus pour la délégation des IDN de TLD à caractère unique seront disponibles après le premier tour de candidature gTLD et la conclusion de l'élaboration de la politique relative au code pays dans les IDN.

   Fondements de la résolution 2011.08.25.16

   Pourquoi le Conseil aborde-t-il cette question maintenant ?
   Le groupe de travail conjoint ccNSO-GNSO IDN (JIG) a publié un rapport final en recommandant que les IDN à caractère unique soient délégués dans le programme de nouveaux gTLD et dans la procédure accélérée d'IDN de ccTLD. Le Conseil de la GNSO et le Conseil de la ccNSO ont approuvé le rapport le 7 avril 2011 et du 10 mai 2011, respectivement, et le rapport a été présenté au Conseil le 11 mai 2011.

   Quelles sont les propositions à l'étude ?
   Le rapport du JIG inclut les recommandations suivantes :

   a) Les IDN de TLD à caractère unique doivent être acceptables en vertu de la procédure accélérée d'IDN de ccTLD et en tant que recommandations sur la politique mondiale du ccPDP d'IDN en tenant compte des résultats du rapport;

   b) La recommandation sur la politique de la GNSO dans le rapport final pour l'introduction de nouveaux domaines génériques de premier niveau pour les IDN de TLD à caractère unique doit être mise en œuvre et

   c) La demande de chaînes d'IDN de TLD à caractère unique doit être analysée cas par cas dans le processus des nouveaux gTLD en fonction du script et de la langue. Les IDN de TLD à caractère unique doivent être acceptables mais ils ne doivent pas ressembler aux TLD d'ASCII à caractère unique ou à deux caractères pour éviter des confusions. Pour le script alphabétique d'IDN de TLD à caractère unique, il faut tenir compte d'autres aspects techniques qui peuvent donner lieu à une confusion, telle que la probabilité d'erreurs de l'utilisateur concernant les touches du clavier.

   Mettre en œuvre les recommandations du rapport se traduirait par des modifications aux versions approuvées du guide de candidature des gTLD et du plan de mise en œuvre de la procédure accélérée d' IDN de ccTLD.

   Quelles parties intéressées ou autres ont été consultées?
   Le JIG est composé de représentantsdes communautés de la ccNSOet de la GNSO. Le rapport a été publié afin de recevoir les commentaires publics de toutes les parties intéressées.

   Depuis la réception du rapport, des discussions informelles ont eu lieu avec certains membres du SSAC et du Groupe de travail de variante du Conseil concernant les aspects techniques de la proposition.

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

   Les questions soulevées par la communauté pendant le processus de consultation publique comprennent :

   • Le moment adéquat pour l'introduction potentielle des IDN de TLD à caractère unique concernant la résolution des aspects de la gestion des variantes IDN.
   • Proposition d'une Commission d'évaluation d'IDN pour réviser les candidatures d'IDN de TLD à caractère unique ou à deux caractères.
   • Procédures à suivre dans les cas où les caractères uniques représentent les noms géographiques ou d'autres intérêts.
   • Possibilité de confusion de l'utilisateur.
   • Possibles aspects concernant l'utilisation des IDN de TLD à caractère unique.
   • Distinction entre gTLD y ccTLD.

   Quels sont les documents importants ayant été révisés par le Conseil ?
   Le Conseil a révisé le rapport du JIG.

   Quels sont les facteurs que le Conseil a trouvés significatifs ?
   Le Conseilexaminera les questionstechniques,les questions de politiquepublique,et l'expérience de l'utilisateur.En conséquence, des contributions des divers comités consultatifs sont attendues.

   En ce qui concerne le programme des nouveaux gTLD, les questions soulevées dans le rapport du JIG qui pourraient être abordées lors des consultations sont : (1) Identifier un processus approprié pour la consultation (y compris avec les communautés linguistiques pertinentes) lors de la considération de chaînes IDN de TLD à caractère unique et (2) déterminer quelle serait la conclusion politique différente s'il était précisé que seuls les scripts idéographiques sont acceptables pour les TLD IDN à caractère unique.

   En ce qui concerne les IDN de ccTLD, les processus d'élaboration des politiques concernant les IDN ccTLD pourraient être décrits après une analyse plus approfondie de ces questions. La procédure accélérée d'IDN ccTLD a été conçue pour permettre l'introduction d'un nombre limité d'IDN ccTLD non litigieux pour répondre à la demande à court terme pendant le développement de la politique globale est développée en utilisant des méthodes qui ne s'opposent pas aux résultats du processus d'élaboration de la politique relative aux codes pays dans les IDN. En conséquence, la délégation des TLD à caractère unique n'est pas actuellement considérée pour la procédure accélérée. 

   Cela a-t-il des effets positifs ou négatifs pour la communauté ?
   Le Conseil sollicite des conseils supplémentaires sur les impacts possibles avant de procéder.

   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'action recommandéene devrait causer aucune déviation significative des dépensesprogrammées.

   Y a-t-il des questions de sécurité, de stabilité ou de résilience concernant le DNS ?
   L'analyse initialeindique qu'il n'yen a pas ; cependant, l'affaire est renvoyée à laSSACpour une évaluation plus détaillée.