Skip to main content
Resources

Résolutions adoptées par le Conseil d'administration | Réunion ordinaire du Conseil d'administration de l'ICANN

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/groups/board/documents/resolutions-11apr13-en.htm

 

  1. Ordre du jour approuvé
    1. Approbation des procès-verbaux du Conseil d'administration
    2. Amendements aux statuts du RSSAC
    3. Bureau de liaison à Istanbul, Turquie
    4. Date effective de mise en œuvre des Statuts de structures de responsabilité
    5. .CAT Demande de retrait des restrictions à la propriété hybride
    6. Confirmation du Processus appliqué pour la redélégation du domaine .GA représentant le Gabon
    7. Modification au nom du comité de participation publique
    8. Demande accélérée de budget aux organisations de soutien et des comités consultatifs 13
    9. Résolutions de remerciement aux membres de la communauté sortants
    10. Remerciement aux sponsors de la 46ème réunion de l'ICANN
    11. Remerciement aux scribes, aux interprètes, au personnel, aux équipes de l'hôtel et aux personnes chargées de l'organisation de la 46ème réunion de l'ICANN
    12. Remerciement aux sponsors locaux de la 46ème réunion de l'ICANN
  2. Ordre du jour principal:
    1. Procédure de règles de génération d'étiquettes (LGR) de racine TLD de variante IDN et recommandations basées sur l'étude d'expérience de l'utilisateur
    2. Demande PIA-CC pour la formation de nouveaux regroupements
    3. Questions diverses

 

  1. Ordre du jour approuvé:

    1. Approbation des procès-verbaux du Conseil d'administration

      Résolu (2013.04.11.01), le Conseil d'administration approuve le compte-rendu de la réunion extraordinaire du Conseil d'administration de l'ICANN du 28 février 2013.

    2. Amendements aux statuts du RSSAC

      Attendu que dans sa résolution 2011.01.25.10 le Conseil d'administration a approuvé les étapes de mise en œuvre du rapport final de révision du comité consultatif du système des serveurs racine (RSSAC) et a chargé le Comité pour les améliorations structurelles (SIC) de fournir au Conseil d'administration, en coordination avec le personnel, un plan final de mise en œuvre des recommandations et les conclusions finales de la révision du RSSAC.

      Attendu qu'en juillet et en août 2012, un groupe de travail constitué de membres du RSSAC et du SIC a été créé afin de rédiger une charte révisée du RSSAC où soient prises en compte les recommandations de la révision du RSSAC. La charte du RSSAC figure dans l'article XI, section 2.3 des statuts de l'ICANN.

      Attendu que le 4 décembre 2012, le SIC a examiné les révisions proposées aux statuts et a recommandé que les modifications suggérées à l'article XI, section 2.3 fassent l'objet d'une consultation publique. Le Conseil d'administration a approuvé la consultation publique le 20 décembre 2012 et la période de commentaires a été ouverte le 3 janvier 2013. Aucun commentaire n'a été reçu.

      Attendu que le 28 mars 2013, le Comité pour les améliorations structurelles (SIC) a recommandé au Conseil d'administration d'adopter les modifications à l'article IX, section 2.3 des statuts.

      Résolu (2013.04.11.02), le Conseil d'administration adopte les modifications proposées à l'article XI, section 2.3 des statuts de l'ICANN qui s'avèrent nécessaires pour modifier la charte du RSSAC conformément aux recommandations découlant de la révision organisationnelle du RSSAC.

      Fondements de la résolution 2013.04.11.02

      Ces amendements des Statuts de l'ICANN clarifieront l'objectif permanent du Comité consultatif du système des serveurs racines (RSSAC). Ces amendements ont été recommandés par le groupe de travail conjoint RSSAC-SIC créé pour mettre en œuvre le rapport final du groupe de travail de révision du RSSAC: étapes de mises en œuvre [PDF, 448 KB], approuvé par le Conseil d'administration le 25 janvier 2011. Les amendements proposés ont été publiés pour commentaires publics et aucune réponse à cette demande n'a été reçue. L'absence de commentaires publics indique que ces modifications sont souhaitables pour que le RSSAC améliore son efficacité dans le contexte actuel. Les révisions des statuts sont destinées à laisser le temps au RSSAC de coordonner les nouvelles modalités à mettre en œuvre pour les membres du RSSAC, qui sont requises en vertu des statuts, sachant que, conformément à la nouvelle disposition des statuts, le premier mandat complet commence à compter du 1er juillet 2013.

      L'approbation des révisions de ces statuts est une fonction administrative organisationnelle pour laquelle des commentaires publics ont été demandés. Bien que l'approbation des modifications des Statuts n'ait pas d'incidence sur le budget lui-même, il est prévu que les révisions des statuts auront un impact sur les dépenses du RSSAC. Habilité par la modification des statuts révisés, le RSSAC contribuera à renforcer la sécurité, la stabilité et la résilience du DNS.

      Il s'agit d'une fonction administrative et organisationnelle pour laquelle des commentaires publics ont été reçus.

    3. Bureau de liaison à Istanbul, Turquie

      Résolu (2013.04.11.03), le Président-directeur général est autorisé à mettre en œuvre les résolutions relatives à un bureau de liaison ou les résolutions relatives à la filiale, ce qui sera considéré par le Président-directeur général comme étant la solution la plus appropriée, et d'ouvrir les comptes bancaires nécessaires pour soutenir ce bureau en Turquie.

      (i) Attendu que la Société pour l'attribution des noms de domaine et des numéros sur Internet, une entité juridique dûment constituée et existant sous les lois de l'État de Californie et des États-Unis d'Amérique, dont le siège principal est situé à 12025 E. Waterfront Drive, Suite 300, Los Angeles, en Californie, USA 90094 («ICANN»), a décidé d'établir une filiale («Branch Office») à Istanbul, Turquie.

      Résolu (2013.04.11.04), David Olive, titulaire d'un passeport des Etats-Unis, numéro [SUPPRIMÉ], est nommé représentant de la filiale avec l'entière autorité d'agir individuellement au nom de la filiale par devant, y compris mais non limité à, tous les tribunaux et toutes les institutions privées et publiques.

      (ii) Attendu que la Société pour l'attribution des noms de domaine et des numéros sur Internet, une entité juridique dûment constituée et existant sous les lois de l'État de Californie et des États-Unis d'Amérique, dont le siège principal est situé à 12025 E. Waterfront Drive, Suite 300, Los Angeles, en Californie, USA 90094 (« ICANN »), a décidé d'établir un bureau de liaison (« Liaison Office») à Istanbul, Turquie.

      Résolu (2013.04.11.05), David Olive, [information portant sur son identification personnelle SUPPRIMÉE], est nommé représentant du Bureau de liaison avec l'entière autorité d'agir individuellement pour le compte du Bureau de liaison par devant, y compris mais non limité à, tous les tribunaux et toutes les institutions privées et publiques.

      Fondements des résolutions 2013.04.11.03 – 2013.04.11.05

      L'ICANN s'engage à continuer d'élargir sa portée mondiale et sa présence dans tous les fuseaux horaires à travers le globe. Un des aspects clés de l'internationalisation de l'ICANN est d'établir des bureaux en Turquie et à Singapour. Un autre aspect essentiel de l'internationalisation de l'ICANN est de veiller à ce que tous les membres de la haute direction de l'ICANN se trouvent dans le bureau de Los Angeles. À cette fin, un des responsables de l'ICANN, David Olive, a accepté de déménager à Istanbul et d'être le représentant de la filiale désignée.

      Afin d'établir officiellement un bureau à Istanbul, l'ICANN doit s'inscrire pour être autorisée à réaliser des activités commerciales en Turquie. L'inscription pour être autorisé à réaliser des activités commerciales en Turquie nécessite une résolution spécifique du Conseil instituant la filiale et désignant le représentant de la filiale, ce qui explique la raison pour laquelle le Conseil d'administration a adopté cette résolution.

      L'établissement des bureaux de liaison à travers le monde sera une étape positive pour la communauté de l'ICANN car cela fournira une plus grande couverture mondiale à tous les membres de la communauté. Il y aura un impact financier sur l'ICANN qui a été pris en compte dans le budget de l'exercice fiscal 2013 et qui sera pris en compte lors de l'approbation du budget de l'exercice fiscal 2014 et au-delà. Cette résolution n'est pas censée avoir un impact sur la sécurité, la stabilité et la résilience du DNS ; cependant elle pourrait fournir une couverture supplémentaire à travers le monde pouvant permettre de régler plus rapidement les questions liées à la sécurité, la stabilité ou la résilience.

      Il s'agit d'une fonction administrative et organisationnelle qui n'exige pas de commentaires publics.

    4. Date effective de mise en œuvre des Statuts de structures de responsabilité

      Attendu que les recommandations 23 et 25 de l'équipe de révision de la responsabilité et de la transparence suggéraient à l'ICANN de faire appel à des experts indépendants afin d'examiner les structures de responsabilité de l'ICANN et l'historique du travail réalisé sur ces structures.

      Attendu que l'ICANN a convoqué le panel d'experts des structures de la responsabilité (Accountability Structures Expert Panel – ASEP), composé de trois experts internationaux sur les questions de gouvernance d'entreprise, de responsabilité et de résolution des différends internationaux qui, après la recherche et l'examen du processus de révision indépendant et de reconsidération de l'ICANN et de multiples possibilités de participation du public, a produit un rapport en octobre 2012.

      Attendu que le rapport de l'ASEP a fait l'objet d'une consultation publique, tout comme les révisions proposées aux statuts pour répondre aux recommandations du rapport.

      Attendu qu'après l'examen de l'ASEP et du Conseil d'administration et la considération des commentaires publics reçus, le 20 décembre 2012, le Conseil d'administration a approuvé la révision des statuts pour rendre effectives les recommandations de l'ASEP, et a ordonné des travaux de mise en œuvre supplémentaires qui devront être suivis d'une recommandation du personnel pour la date de mise en œuvre des statuts révisés.

      Attendu que, comme envisagé dans la résolution du Conseil et comme en témoignent les commentaires publics, d'autres modifications mineures sont nécessaires pour permettre aux statuts de garantir une certaine flexibilité dans la composition d'un panel permanent pour le processus d'examen indépendant (Independent Review process – IRP).

      Résolu (2013.04.11.06), les révisions des statuts de l'article IV, Section 2 (réexamen) et l'article IV, section 3 (révision indépendante), tel qu'approuvé par le Conseil d'administration et sous réserve d'une modification mineure pour tenir compte des commentaires publics concernant la composition d'un panel permanent pour l'IRP, entreront en vigueur le 11 avril 2013.

      Fondements de la résolution 2013.04.11.06

      La décision du Conseil d'administration d'accepter le rapport du Panel d'experts des structures de responsabilité (ASEP) et d'approuver les révisions des statuts associés s'inscrit dans le cadre de l'engagement pris par le Conseil de mettre en œuvre les recommandations de l'équipe de révision de la responsabilité et de la transparence (ATRT). Le recours à l'ASEP avait été préconisé dans les recommandations 23 et 25 de l'ATRT, et la tâche réalisée, y compris une révision des recommandations issues du travail du président du comité stratégique pour l'amélioration de la confiance institutionnelle, est en ligne avec la révision demandée par l'ATRT.

      L'adoption du travail de l'ASEP représente un pas en avant dans l'engagement de l'ICANN en matière de responsabilité à l'égard de sa communauté. Les mécanismes révisés adoptés aujourd'hui faciliteront l'accès aux processus de reconsidération et de révision indépendante grâce à la mise en œuvre de formulaires, l'emploi de termes bien définis pour éliminer toute imprécision et la possibilité d'établir des demandes collectives. Un nouveau critère de reconsidération a été incorporé, qui donne à la communauté davantage de moyens pour exiger au Conseil d'administration de rendre des comptes sur ses décisions. Les révisions visent une plus grande prévisibilité dans les processus et une plus grande certitude dans la prise de décisions de l'ICANN, tout en établissant très clairement les cas où une décision peut être révisée. Les statuts administratifs tels que révisés ultérieurement abordent également un domaine potentiel de préoccupation soulevée par la communauté lors des commentaires publics sur cette question, concernant la capacité de l'ICANN de maintenir un panel permanent pour les procédures de révision indépendante. Si un panel permanent ne peut pas être constitué ou ne peut pas demeurer constitué, les statuts permettent désormais que des membres sélectionnés individuellement effectuent les procédures de révision indépendante.

      L'adoption de ces recommandations aura un impact financier sur l'ICANN, en ce sens qu'il y a des coûts prévus associés au maintien d'un président du panel permanent pour le processus d'examen indépendant et des coûts potentiels pour retenir d'autres membres du panel. Toutefois, les recommandations devraient aboutir à une procédure moins longue et moins coûteuse, ce qui sera positif pour l'ICANN, pour la communauté, et pour ceux qui souhaitent une révision sous ces structures de responsabilité. Des impacts positifs sur l'ICANN et sur la communauté sont prévus comme résultat de ce travail, grâce à la disponibilité accrue de mécanismes de reddition de comptes. Cette action n'est pas censée avoir d'incidence sur la sécurité, la stabilité ou la résilience du DNS.

      Il s'agit d'une fonction administrative et organisationnelle du Conseil pour laquelle des commentaires publics ont été reçus.

    5. li.CAT Demande de retrait des restrictions à la propriété hybride

      Attendu qu'en décembre 2012, La Fundació puntCAT a demandé de supprimer les restrictions à la propriété hybride contenues dans l'accord signé le 23 septembre 2005 entre l'ICANN et la Fundació puntCAT.

      Attendu que la demande faisait suite à la « Procédure de traitement des demandes de suppression des restrictions à la propriété hybride sur les opérateurs de gTLD existants » adoptée par le Conseil d'administration le 18 octobre 2012.

      Attendu que l'ICANN a réalisé une révision de la concurrence conformément au processus approuvé par le Conseil et a déterminé que la requête ne soulève aucune question importante en matière de concurrence.

      Attendu qu'une période de consultation publique a eu lieu entre le 22 décembre 2012 et 11 février 2013 et qu'un seul commentaire a été reçu, qui appuyait la demande de Fundació puntCAT.

      Résolu (2013.04.11.07), l'amendement pour le retrait de la restriction à la propriété hybride de la Fundació puntCAT de l'accord de registre signé le 23 septembre 2005 est approuvé, et le Président-directeur général ainsi que le conseiller juridique sont autorisés à appliquer ces décisions comme cela leur semblera approprié pour mettre en œuvre ledit accord.

      Fondements de la résolution 2013.04.11.07

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

      La suppression de la propriété hybride des registres existants a fait l'objet de discussions approfondies au sein du Conseil et de la communauté. C'est la première fois qu'un registre existant a fait la demande selon la procédure approuvée par le Conseil d'administration adoptée le 18 octobre 2012. Toutefois, le Conseil d'administration est susceptible de recevoir d'autres demandes dans le futur. Dans le cadre de la procédure du Conseil d'administration adoptée en octobre 2012 visant à lever les restrictions existantes sur la propriété hybride, les opérateurs de registre gTLD pourraient demander une modification de leur contrat de registre existant ou demander une transition vers la nouvelle forme de contrat de registre pour les nouveaux gTLD. Bien que Fundació puntCAT ait demandé une modification de son contrat de registre, elle aura toujours la possibilité de faire la transition à la nouvelle forme de contrat de registre pour les nouveaux gTLD. La suppression des restrictions à la propriété hybride pour .BIZ, .INFO et .ORG est à l'étude dans le cadre de leurs négociations globales de renouvellement. L'ICANN mène également des discussions préliminaires avec .MOBI et .PRO portant sur la suppression des restrictions à la propriété hybride.

      Quelle est la proposition à l'étude?

      Un amendement à l'Accord de registre du 23 septembre 2005 signé entre l'ICANN et Fundació puntCAT.

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

      Une période de consultation publique a eu lieu entre le 22 décembre 2012 et le 11 février 2013.

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

      Pendant la période de commentaires publics un seul commentaire a été reçu. Ce commentaire était en faveur de la demande de Fundació puntCAT.

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

      L'ICANN a effectué une analyse de la concurrence conformément à la procédure approuvée par le Conseil pour traiter les demandes de levée des restrictions à la propriété hybride dans les accords de registre. L'ICANN a déterminé que la demande ne soulève pas de problèmes de concurrence importants.

      Y a-t-il des impacts financiers ou des répercussions à prévoir sur l'ICANN (plan stratégique, plan opérationnel, budget), la communauté ou le public?

      Il n'y a pas d'impact financier pour l'ICANN.

      Y a-t-il des implications sur la sécurité, la stabilité ou la résilience du DNS?

      Il n'y a pas de questions identifiées en matière de sécurité, stabilité et résilience.

      Est-ce que ce processus politique défini au sein des organisations de soutien de l'ICANN ou la décision de la fonction administrative organisationnelle de l'ICANN nécessitent la consultation publique ou est-ce que celle-ci n'est pas nécessaire?

      Cette demande a suivi le « processus pour gérer les requêtes en matière de retrait des restrictions à la propriété hybride des opérateurs de gTLD existants » approuvé par le Conseil le 18 octobre 2012.

      Il s'agit d'une fonction administrative et organisationnelle pour laquelle des commentaires publics ont été reçus.

    6. Confirmation du Processus appliqué pour la redélégation du domaine .GA représentant le Gabon

      Résolu (2013.04.11.08), l'ICANN a examiné et a évalué la demande et la documentation montre que le processus a été suivi et que la redélégation répond aux intérêts des communautés Internet locales et mondiales.

      Fondements de la résolution 2013.04.11.08

      Dans le cadre des fonctions de l'IANA, l'ICANN reçoit des demandes pour déléguer et redéléguer des domaines de premier niveau géographique. Le personnel de l'ICANN a examiné et évalué une demande de redélégation pour ce domaine et a fourni un rapport au Conseil de l'ICANN indiquant que les procédures correctes ont été suivies pour cette évaluation. La supervision du processus par le Conseil permet de s'assurer que l'ICANN exerce correctement ses responsabilités quant au fonctionnement stable et sécurisé des systèmes d'identifiant unique d'Internet et conformément au Contrat définissant les fonctions de l'IANA.

      L'assurance que le processus est bien suivi contribue à la responsabilité de l'ICANN. Cette action n'aura pas d'impact financier sur l'ICANN ou la communauté, et aura un impact positif sur la sécurité, la stabilité et la résilience du système de noms de domaine.

      Il s'agit d'une fonction administrative et organisationnelle qui n'exige pas de commentaires publics.

    7. Modification au nom du comité de participation publique.

      Attendu que l'article XII des statuts établit que « le Conseil d'administration peut mettre en place un ou plusieurs comité(s) en son sein, dont l'existence perdure jusqu'à ce que le Conseil d'administration décide d'y mettre un terme ».

      Attendu que le 7 novembre 2008, le Conseil d'administration a créé un comité appelé le comité de participation publique conformément à son autorité en vertu de l'article XII des statuts.  

      Attendu que le comité de participation publique désire maintenant modifier son nom et adopter celui de « Comité d'engagement du public et des parties prenantes», qui sera compatible avec la nouvelle orientation de l'engagement des parties prenantes adoptée par l'ICANN.

      Attendu que, le comité de gouvernance du Conseil a recommandé que le Conseil approuve cette modification du nom.

      Résolu (2013.04.11.09), le Conseil approuve le remplacement du nom de comité de participation publique par celui de comité d'engagement du public et des parties prenantes.

      Fondements de la résolution 2013.04.11.09

      Le changement de nom proposé est cohérent avec la décision de l'ICANN de se concentrer maintenant sur l'engagement des parties prenantes au niveau mondial.

      Cette résolution vise seulement un changement de nom du comité, et non un changement dans la structure ou la portée dudit comité. Comme le Comité de gouvernance du Conseil d'administration (Board Governance Committee – BGC) a l'intention de procéder ultérieurement cette année à un examen complet de la structure et portée de tous les comités, la résolution actuelle vise uniquement le changement de nom du comité de participation publique.

      Cette action aura un impact positif sur la communauté de l'ICANN et garantit que le nom du comité reflète adéquatement le niveau mondial de la portée et de l'engagement en vertu duquel l'ICANN fonctionne et le comité supervise. En outre, cette résolution n'aura aucun impact financier sur l'ICANN ou sur sa communauté. Cette action n'aura pas d'impact sur la sécurité, la stabilité et la résilience du système de noms de domaine.

      Il s'agit d'une fonction administrative et organisationnelle qui n'exige pas de commentaires publics.

    8. Demande accélérée de budget aux organisations de soutien et des comités consultatifs

      Attendu qu'un groupe de travail sur les améliorations budgétaires, qui comprend des membres du personnel de l'ICANN et de la communauté, a identifié la nécessité d'une décision plus précoce sur le financement des demandes spécifiques de la communauté de l'ICANN ayant demandé un financement au début de l'exercice.

      Attendu qu'une procédure accélérée de demandes de budget supplémentaires de la part des organisations de soutien et des comités consultatifs a été mise en place en réponse à la suggestion des groupes de travail. Ladite procédure a été conçue pour faciliter la collecte, l'analyse et la présentation des demandes de budget au Comité des finances du Conseil et au Conseil pour leur examen.

      Attendu que des demandes de la communauté de l'ICANN présentées en temps opportun ont été examinées par un panel de membres du personnel représentant la politique, l'engagement des parties prenantes et le personnel des finances.

      Attendu que le comité de révision a recommandé 12 demandes de budget accélérées représentant 279 000 USD correspondant à des demandes d'approbation.

      Attendu que le comité des finances du Conseil s'est réuni le 5 avril 2013, a examiné la procédure appliquée et les recommandations du personnel, et a recommandé au Conseil d'approuver les recommandations du personnel.

      Résolu (2013.04.11.10), le Conseil approuve l'inclusion dans le budget de l'exercice 2014 de l'ICANN d'une certaine quantité de fonds correspondant aux 12 demandes identifiées par la communauté dans le cadre d'une procédure accélérée de demandes de budget supplémentaires des organisations de soutien et des comités consultatifs.

      Fondements de la résolution 2013.04.11.10

      Les procédures rapides de demandes de budget additionnel des organisations de soutien et des comités consultatifs conduisant à l'approbation du budget plus tôt que d'habitude représentent un accommodement raisonnable pour des activités qui commencent au début de l'exercice 2014. Cette légère augmentation dans la procédure d'application du budget établi de l'ICANN et de son calendrier permet de faciliter le travail de la communauté et du personnel de l'ICANN, et ne crée pas de dépenses supplémentaires. Le montant des frais engagés résultant de cette résolution est considéré comme suffisamment faible pour ne pas exiger que des ressources soient spécifiquement identifiées et approuvées séparément.

      Aucun impact n'est prévu sur la sécurité, la stabilité et la résilience du système des noms de domaine suite à cette action.

      Il s'agit d'une fonction administrative et organisationnelle pour laquelle aucun commentaire public n'a été reçu.

    9. Résolutions de remerciement aux membres de la communauté sortants

      Attendu que l'ICANN tient à remercier la communauté des parties prenantes pour l'énergie et les compétences que ses membres mettent au service du processus de l'ICANN.

      Attendu qu'en reconnaissance de leurs contributions l'ICANN souhaite remercier les membres de la communauté lorsque leur mandat au sein des organisations de soutien et des comités consultatifs s'achève.

      Attendu que, le membre suivant du regroupement d'utilisateurs commerciaux et d'affaires (BC) et des utilisateurs de l'organisation de soutien aux politiques des noms génériques (GNSO) quitte son poste à la fin de son mandat:

      Marilyn Cade

      Il est résolu (2013.04.11.11) que les services de Marylin Cade pendant son mandat lui ont valu la profonde appréciation du Conseil d'administration et que celui-ci lui souhaite beaucoup de succès dans ses projets à venir.

      Attendu que les membres suivants du conseil de soutien aux politiques de codes de pays (Country Code Names Supporting Organization – ccNSO) quittent leurs fonctions à la fin de leur mandat:

      Fernando Espana, .us
      Paulos Nyirenda, .mw
      Rolando Toledo, .pe

      Il est résolu (2013.04.11.12) que les services de Fernando Espana, Paulos Nyirenda et Rolando Toledo leur ont valu la profonde appréciation du Conseil d'administration et que celui-ci leur souhaite beaucoup de succès dans leurs projets à venir.

    10. Remerciement aux sponsors de la 46ème réunion de l'ICANN

      Le Conseil tient à remercier les sponsors suivants:

      Verisign, Inc., Afilias Limited, .ORG, The Public Interest Registry, HiChina Zchicheng Technology Limited, .PW Registry, Community.Asia, Iron Mountain, Zodiac Holding Limited, Minds + Machines, Neustar Inc., KNET Co., Ltd., Deloitte Bedrijfsrevisoren BV ovve CVBA, JSC Regional Network Information Center (RU-CENTER), UniForum SA T/A ZA Central Registry, CORE Internet Council of Registrars, Symantec, APNIC Pty Ltd, NCC Group, APTLD (Asia Pacific Top Level Domain Association), Freedom Registry B.V., Uniregistry Corp., Afnic, ICANN WIKI et nos sponsors locaux CNNIC, CONAC et Internet Society of China.

    11. Remerciement aux scribes, aux interprètes, au personnel, aux équipes de l'hôtel et aux personnes chargées de l'organisation de la 46ème réunion de l'ICANN

      Le Conseil exprime sa gratitude aux scribes, aux interprètes, aux équipes techniques et à l'ensemble du personnel de l'ICANN pour les efforts réalisés afin de faciliter le bon déroulement de la réunion. Le Conseil souhaite également remercier la direction et le personnel du Beijing International Hotel pour avoir mis à disposition ces merveilleuses installations pour la réalisation de l'événement. Des remerciements particuliers sont adressés à Li Yun, premier directeur des ventes, au Beijing International Hotel et à Nick Yang, directeur des services de Convention du Beijing International Hôtel.

    12. Remerciement aux sponsors locaux de la 46ème réunion de l'ICANN

      Hôtes locaux de la réunion de Beijing. Le Conseil tient à exprimer ses remerciements à l'organisateur de l'hôte local, M. Bing Shang, ministre du ministère de l'Industrie et des Technologies de l'Information, Mme Xia HAN, Directrice du Bureau de réglementation des télécommunications du MIIT, M. Er- Wei SHI, vice-président de l'Académie chinoise des sciences, M. Tieniu TAN, vice-secrétaire général de l'Académie chinoise des sciences, M. HUANG Xiangyang, directeur du CNNIC, M. Xiaodong Lee, directeur exécutif de CNNIC, M. Feng WANG, vice-ministre du Bureau de la Commission d'Etat pour la réforme du secteur public, M. Ning, FU Président du Conseil du CONAC, M. Ran ZUO, vice-président du Conseil du CONAC, M. SONG Qing, directeur général du CONAC, Mme Qiheng HU, Présidente de l'Internet Society de la Chine, M. Xinmin GAO, vice-président de l'Internet Society of China, M. Wei LU, secrétaire général de l'Internet Society of China.

  2. Ordre du jour principal:

    1. Procédure de règles de génération d'étiquettes (LGR) de racine TLD de variante IDN et recommandations basées sur l'étude d'expérience de l'utilisateur

      Attendu que les IDN ont été une priorité du Conseil d'administration depuis plusieurs années pour permettre aux utilisateurs d'Internet d'accéder à des noms de domaine dans leur propre langue, et que le Conseil reconnaît que les variantes IDN sont un élément important pour certaines chaînes TLD IDN;

      Attendu que le Conseil a décidé au préalable que les gTLD de variantes IDN et les ccTLD de variantes IDN ne seront pas délégués jusqu'à ce que le travail pertinent soit achevé;

      Attendu que depuis décembre 2010 l'ICANN travaille à trouver des solutions pour assurer une délégation sûre et stable des variantes TLD IDN, et que le programme TLD de variantes IDN a fait l'objet d'une participation importante de la communauté dans le développement de la procédure pour développer et maintenir les règles de génération d'étiquettes pour la zone racine en matière d'étiquettes IDNA et le rapport sur les implications de l'expérience des utilisateurs de variantes TLD actives.

      Résolu (2013.04.11.13), le Conseil demande au personnel d'engager la procédure pour développer et maintenir les règles de génération d'étiquettes pour la zone racine en matière d'étiquettes IDNA [PDF, 772 KB], y compris la mise à jour du guide de candidature gTLD et du processus de ccTLD IDN pour intégrer les règles de génération d'étiquettes pour la zone racine en matière d'étiquettes IDNA dans les processus d'évaluation respectifs.

      Résolu (2013.04.11.14), le Conseil demande que, d'ici le 1er juillet 2013, les organisations de soutien et les comités consultatifs intéressés fournissent au personnel la contribution et les conseils qu'ils sont en mesure de fournir afin que ceux-ci soient pris en compte dans la mise en œuvre des recommandations du rapport sur les implications de l'expérience des utilisateurs des variantes TLD actives [PDF, 1.38 MB].

      Fondements des résolutions 2013.04.11.13 – 2013.04.11.14

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

      Les variantes TLD IDN sont, depuis plusieurs années, le sujet d'intérêt d'un bon nombre d'utilisateurs d'IDN. Le programme des variantes TLD IDN a travaillé avec des experts en la matière au sein de la communauté pour développer des solutions permettant une délégation sécurisée et stable des variantes TLD IDN. Le programme a achevé le travail sur deux éléments clés de la solution: la procédure pour développer et maintenir les règles de génération d'étiquettes pour la zone racine en matière d'étiquettes IDNA et le rapport sur les implications de l'expérience des utilisateur des variantes actives de TLD, ci-après dénommée la procédure. La procédure est maintenant prête à être examinée pour son adoption en tant que mécanisme, entre autres choses, pour évaluer le potentiel des chaînes TLD IDN et identifier leurs variantes (le cas échéant). Les recommandations du rapport sur les implications de l'expérience des utilisateurs de variantes actives de TLD sont maintenant prêtes à être mises en œuvre avec les contributions et l'aide que les organisations de soutien et les comités consultatifs intéressés peuvent fournir.

      Quelle est la proposition à l'étude?

      La procédure décrit comment remplir et maintenir les règles de génération d'étiquettes pour la zone racine en matière d'étiquettes IDNA, un élément qui est appelé à devenir un facteur clé dans le traitement des candidatures TLD IDN.

      La procédure exige la participation des communautés concernées comme un élément central.

       La procédure comprend des protections pour assurer une participation maximale de la communauté d'un groupe linguistique donné et pour éviter la domination d'une seule partie, et exige la participation d'experts techniques pour assurer l'exactitude technique et linguistique du contenu des règles. Le rapport sur les implications de l'expérience des utilisateurs de variantes TLD actives comprend une série de recommandations visant à permettre une bonne expérience de l'utilisateur dans le domaine des variantes TLD IDN.

      Quelles parties prenantes ou autres ont été consultées?

      Le développement de la procédure et le rapport comprenaient la pleine participation de plusieurs membres de la communauté. Les deux documents sont aussi passés par deux processus de consultation publique et un certain nombre de présentations publiques durant lesquels des informations ont été recueillies.

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

      Des préoccupations ont été soulevées au sujet de l'idée que les variantes sont en général inappropriées dans la zone racine, en admettant que certains cas spécifiques pourraient être acceptables. Il y avait également des préoccupations concernant la résolution des conflits et la gouvernance de la procédure. Cependant, en ayant une exigence de consensus au sein et entre les panels, le problème de résolution des conflits semble être atténué. En ce qui concerne la gouvernance de la procédure, il est prévu que le fait que le panel d'intégration soit contracté par l'ICANN permettra le retrait d'un panéliste ayant un comportement non constructif.

      Des préoccupations ont aussi été exprimées à propos du fait que les problèmes mentionnés dans le rapport peuvent effrayer les lecteurs et les convaincre de ne pas soutenir les variantes, et le rapport ne met pas en évidence les risques (problèmes et questions de sécurité) qui existent si les variantes ne sont pas prises en charge ou activées. Toutefois, afin d'assurer une expérience sûre, stable et acceptable, ces questions doivent être analysées par les parties respectives. La nécessité de variantes est bien présentée par les rapports de problèmes individuels, de sorte que le problème est en dehors du champ de la présente étude.

      Quels sont les documents importants que le Conseil a révisés?

      Un document du Conseil et des documents de référence décrivant la proposition, la procédure pour développer et maintenir les règles de génération d'étiquettes pour la zone racine en matière d'étiquettes IDNA, et le rapport sur les implications de l'expérience des utilisateurs de variantes actives de TLD.

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

      Le Conseil a jugé que les règles de production d'étiquettes pour la zone racine en matière d'étiquettes IDNA permettront d'améliorer le processus actuel pour évaluer les chaînes IDN à l'aide d'un processus pré-approuvé, déterministe pour définir les points de code qui sont autorisés à la racine. Le Conseil a aussi jugé important que les règles soient un élément clé pour identifier systématiquement les variantes des candidatures aux chaînes IDN. La procédure considère la participation des communautés concernées comme un aspect fondamental. En outre, les recommandations visent à permettre une bonne expérience de l'utilisateur en ce qui concerne les variantes TLD IDN.

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

      L'adoption de la procédure et par conséquent les règles de génération d'étiquettes pour la zone racine en matière d'étiquettes IDNA seront utiles pour les futurs candidats TLD car elles leur permettront de vérifier si la chaîne qu'ils ont l'intention de demander est autorisée. Les règles permettront également l'identification déterministe de variantes IDN pour la chaîne demandée. La mise en œuvre des recommandations permettra une bonne expérience des utilisateurs dans le domaine des variantes TLD IDN.

      Cela a-t-il un impact financier ou des répercussions sur l'ICANN (Plan stratégique, Plan opérationnel, Budget), sur la communauté ou sur le public?

      Aucun impact financier ou répercussion n'est prévu sur l'ICANN comme conséquence de l'adoption de cette résolution.

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

      L'adoption du règlement et de la mise en œuvre des recommandations devrait avoir un impact positif sur la sécurité du DNS en assurant un processus techniquement solide avec de multiples points de contrôle, y compris l'examen du public, des points de code et leurs variantes (le cas échéant) qui seront autorisés dans la zone racine, et le déploiement de mesures permet d'éviter la confusion des utilisateurs en ce qui concerne les variantes TLD IDN.

      Est-ce qu'un processus stratégique défini au sein des organisations de soutien de l'ICANN ou la décision de la fonction administrative organisationnelle de l'ICANN requièrent une consultation publique ou bien est-ce que celle-ci n'est pas nécessaire?

      Il s'agit d'une fonction administrative et organisationnelle qui n'exige pas de commentaires publics.

    2. Demande PIA-CC pour la formation de nouveaux regroupements

      Attendu que le Conseil de l'ICANN veut encourager la participation d'un large éventail de groupes communautaires existants et potentiels aux procédures et aux activités de l'ICANN.

      Attendu que le Conseil de l'ICANN a établi une procédure pour la reconnaissance de nouveaux regroupements de la GNSO qui comprend des critères d'éligibilité objectifs, qui encourage la collaboration et confie les décisions concernant les demandes, en première instance, aux communautés qui seront directement touchées par le nouveau regroupement potentiel.

      Attendu que l'Association Cybercafé de l'Inde (Cybercafé Association of India – CCAOI) a déposé une demande de reconnaissance formelle d'un nouveau regroupement de la GNSO appelé « Accès public à l'Internet / Ecosystème cybercafé (PIA / CC) » au sein du Groupe des parties prenantes non commerciales de la GNSO (NCSG).

      Attendu que le personnel de l'ICANN a mis en œuvre un forum de consultation publique de 68 jours pour l'examen de la communauté et l'analyse de la réaction à la proposition de PIA / CC.

      Attendu que la direction du NCSG et le personnel de l'ICANN effectuent des consultations collaboratives et dialoguent avec les partisans de PIA / CC.

      Attendu que le leadership du NCSG et le personnel de l'ICANN ont suivi la procédure et que le NCSG a informé le Comité pour les améliorations structurelles du Conseil de sa décision de rejeter la demande parce que la candidature ne satisfait pas aux critères établis par le Conseil.

      Résolu (2013.04.11.15), la décision du NCSG de refuser la demande de PIA / CC est ratifiée et il est considéré que la décision est sans préjudice et que les partisans de ce regroupement ont le droit de présenter une nouvelle demande.

      Résolu (2013.04.11.16), le Président-directeur général est prié de poursuivre les discussions en collaboration avec les partisans de PIA / CC pour effectuer davantage de recherches et envisager d'autres options pour l'engagement communautaire au sein de la communauté de l'ICANN et de ses procédures.

      Fondements des résolutions 2013.04.11.15 – 2013.04.11.16

      La procédure de reconnaissance de nouveaux regroupements de la GNSO a été conçue pour fournir des critères spécifiques et objectifs de candidature et pour confier les décisions sur la reconnaissance de nouveaux regroupements de la GNSO, en première instance, aux groupes communautaires qui sont les mieux placés pour évaluer ces demandes. Dans le cas présent, le processus a été suivi et le NCSG a pris sa décision.

      Il est important de noter que la ratification par le Conseil de la décision du NCSG de rejeter la demande liée à PIA / CC est sans préjudice du droit de ses partisans à soumettre une nouvelle demande. Le Conseil espère que d'autres discussions avec les partisans de PIA / CC pourront conduire à un plan d'action qui permettra aux intérêts liés à la demande de PIA / CC d'être effectivement intégrés dans les activités et les procédures de l'ICANN.

      Cette action n'aura pas d'impacts immédiats ou substantiels sur les ressources de l'ICANN. Cette action n'est pas censée avoir d'incidence sur la sécurité, la stabilité ou la résilience du DNS.

      Il s'agit d'une fonction administrative et organisationnelle pour laquelle aucun commentaire public n'a été reçu.

    3. Questions diverses

      Aucune résolution n'a été prise.

resolutions-11apr13-fr.pdf  [252 KB]

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