Skip to main content
Resources

Résolutions approuvées par le Conseil d'administration | Réunion extraordinaire 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-27jun13-en.htm

 

  1. Ordre du jour approuvé
    1. Approbation des procès-verbaux du Conseil d'administration
    2. Nomination de Ben Butler pour le SSAC
    3. Approbation de l'accord AROS
  2. Ordre du jour principal
    1. Actualisation de la mise en œuvre de la procédure accélérée d'IDN ccTLD
    2. Approbation du RAA 2013
  3. Session exécutive
    1. Résolution confidentielle

 

  1. Ordre du jour approuvé :

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

      Resolved (2013.06.27.01), the Board approves the minutes of the 18 May 2013 Regular Meeting of the ICANN Board.

    2. Nomination de Ben Butler pour le SSAC

      Attendu que, le Comité consultatif sur la sécurité et la stabilité (SSAC) fait une révision de ses membres et, de temps en temps, fait des ajustements.

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

      Résolu (2013.06.27.02), que le Conseil d'administration nomme Ben Butler au SSAC.

      Fondements de la résolution 2013.06.27.02

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

      Le fonctionnement continu du SSAC en tant qu'entité compétente dépend de la participation soutenue d'experts en la matière qui ont consenti à consacrer un peu de leur temps et énergie pour mener à bien la mission du SSAC. Ben Butler apporte des compétences de grande valeur au SSAC. Il apporte notamment son expérience comme directeur de l'utilisation abusive des réseaux chez GoDaddy, un bureau d'enregistrement important. M. Butler apporte également son expérience comme fournisseur d'hébergement et des contacts avec d'autres fournisseurs d'hébergement, deux compléments nécessaires pour le SSAC. Enfin, il apporte sa connaissance approfondie sur les questions liées à l'usage frauduleux du DNS.

    3. Approbation de l'accord AROS

      Attendu que l'ICANN et Street Solutions ont négocié de bonne foi les termes d'une déclaration de travail proposée pour le développement du système automatique intégré pour les bureaux d'enregistrement (Automated Registrar Onboarding System — AROS)

      Attendu que, le Conseil d'administration a analysé les termes de l'énoncé des travaux proposé pour l'ICANN ;

      Attendu que, l'approbation est requise pour engager des fonds de l'ICANN pour un montant de 650 450 dollars américains.

      Attendu que, l'exécution de l'accord habilite le développement de cet outil pour supporter l'accréditation des registres et des bureaux d'enregistrement ;

      Résolu (2013.06.27.03), le Conseil d'administration autorise le PDG à conclure l'accord proposé avec Solutions Street.

      Résolu (2013.06.27.04), la demande d'approbation du contrat avec Solutions Street pour le développement du système automatique intégré pour les bureaux d'enregistrement (AROS) a été approuvée.

      Fondements des Résolutions 2013.06.27.03 et 2013.06.27.04

      La politique de dépenses de l'ICANN impose des contraintes aux membres du bureau de l'ICANN pour tout contrat ou déboursement dépassant les 500 000 USD par obligation. Par conséquent, l'ICANN adhère à cette politique lorsqu'elle cherche l'approbation du Conseil pour la conclusion de toute obligation contractuelle dépassant les 500 000 dollars par contrat. ICANN a identifié un fournisseur pour construire le système AROS et le contrat avec ce fournisseur est estimé à 650 450 dollars, licence comprise.

      La solution proposée consiste à un système automatique intégré pour les bureaux d'enregistrement (AROS) destiné aux bureaux d'enregistrement accrédités par l'ICANN. Le système décrit dans ce document est censé mettre à disposition des bureaux d'enregistrement une interface d'utilisateur leur permettant de pour gérer les informations de leur bureau d'enregistrement et, lorsqu'ils demandent l'accréditation par (essentiellement) les registres des domaines génériques de premier niveau, un espace de travail dans lequel les registres puissent gérer les demandes d'accréditation des bureaux d'enregistrement, et une interface administrative, permettant à l'administrateur désigné par l'ICANN, de gérer l'AROS.

      Le système (et ses spécificités) ont été développés par le groupe de travail formé par des représentants des groupes de parties prenantes des registres et des bureaux d'enregistrement, le personnel de l'ICANN et un consultant externe spécialisé dans le domaine des exigences de performance requises. Les représentants des groupes des registres et des bureaux d'enregistrement (trois représentants par groupe) sont des volontaires identifiés par les présidents des parties prenantes respectives. Outre l'équipe de travail décrite, le personnel a mené à deux reprises des sondages avec les registres et les bureaux d'enregistrement pour valider les exigences.

      L'approbation du Conseil d'administration pour s'engager dans cette obligation contractuelle aura un impact positif sur la communauté car cela permettra aux registres et aux bureaux d'enregistrement de passer leurs contrats de manière plus efficace et en temps opportun. Ce faisant, l'ICANN habilite un environnement plus efficace et compétitif. Des impacts fiscaux sont à prévoir sur l'ICANN mais ceux-ci ont été prévus dans le budget approuvé pour l'exercice fiscal 2013 et dans la version préliminaire du budget de l'exercice fiscal 2014. Il n'y aura aucun impact sur la sécurité, la stabilité ou la résilience du système de noms de domaine.

  2. Ordre du jour principal :

    1. Actualisation de la mise en œuvre de la procédure accélérée d'IDN ccTLD

      Attendu que le Conseil d'administration a approuvé le plan de mise en œuvre de la procédure accélérée le 30 octobre 2009 (http://www.icann.org/en/minutes/resolutions-30oct09-en.htm#2).

      Attendu qu'en vertu de la procédure accélérée des ccTLD IDN un panel indépendant réalise l'évaluation technique et de la similarité des chaînes (évaluation de la stabilité du DNS) ;

      Attendu que la ccNSO a développé et que le conseil de la ccNSO a approuvé les recommandations pour la politique de sélection des chaînes ccTLD IDN d'inclure un processus à deux panels pour évaluer la similarité des chaînes (http://ccnso.icann.org/node/38787 [PDF, 119 KB]);

      Attendu que l'ICANN a reçu un grand nombre de commentaires et d'avis de la communauté demandant plus de transparence et de cohérence dans la démarche d'évaluation de la similarité des chaînes, y compris l'avis du comité consultatif gouvernemental (GAC) ;

      Attendu que le président de la ccNSO a envoyé au Conseil d'administration de l'ICANN une demande de mise en place d'un processus à deux panels pour évaluer la similarité des chaînes dans la procédure accélérée des ccTLD IDN ;

      RESOLU (2013.06.27.05), le Conseil d'administration de l'ICANN approuve un amendement à la procédure de mise en place d'un processus à deux panels pour évaluer la similarité des chaînes dans la procédure accélérée des ccTLD IDN ; Le PDG est prié d'incorporer la modification au plan de mise en œuvre de la procédure accélérée préalablement adopté par le Conseil d'administration de l'ICANN le 30 octobre 2009 (modifié le 8 décembre 2011) et mettre en œuvre ladite modification dès que possible.

      RESOLU (2013.06.27.06), le Conseil d'administration de l'ICANN approuve l'amendement au plan accéléré de mise en œuvre qui permettra à toutes les demandes de chaînes ccTLD IDN sous la procédure accélérée d'avoir l'option de demander l'évaluation au panel de révision traitant de la procédure concernant la similarité (Extended Process Similarity Review Panel — EPSRP) dès que l'EPSRP sera formé.

      Fondements des Résolutions 2013.06.27.05 et 2013.06.27.06

      Pourquoi le Conseil d'administration aborde-t-il cette question maintenant?

      Le processus de développement de politiques (PDP) des ccTLD IDN de la ccNSO est presque terminé. Une des propositions de la recommandation de politiques est d'introduire un mécanisme à deux panels pour faire la révision des similarités propices à confusion des chaînes ccTLD IDN demandées. L'un des objectifs de l'introduction de la procédure accélérée ccTLD IDN est d'utiliser une méthodologie pour la sélection des chaînes ccTLD IDN et pouvoir ainsi informer le processus de développement de politiques de la ccNSO tout en répondant à la demande de moyen terme pour l'introduction des ccTLD IDN. L'introduction du mécanisme à deux panels comme banc d'essai de la procédure accélérée permet de tester et de mettre au point, si nécessaire, la méthodologie du mécanisme à deux panels proposé. La modification éventuelle de la procédure accélérée est censée permettre d'atteindre l'objectif de satisfaire aux demandes de moyen terme pour l'introduction continue des ccTLD IDN. Enfin, la communauté a demandé pendant longtemps une modification à la révision de la similarité des chaînes dans le cadre de la procédure accélérée. Le guide de la ccNSO dans cette démarche aidera à améliorer la responsabilité de l'ICANN.

      Quelle est la proposition à l'étude ?

      La modification proposée au plan de mise en œuvre de la procédure accélérée est d'introduire un deuxième panel d'experts indépendants consacré à la révision accélérée des similarités des chaînes ccTLD IDN pouvant se prêter à confusion. Ce deuxième panel vient renforcer les actions du panel de révision sur la similarité des chaînes existant. La proposition exige également à toutes les chaînes demandées dans la procédure accélérée ccTLD IDN y compris celles qui n'ont pas réussi à la révision de la similarité des chaînes, d'avoir l'option de demander que leur candidature soit révisée par l'EPSRP. Cela permettra à toutes les candidatures en suspens et aux futures candidatures de passer des évaluations cohérentes, tant qu'il n'y aura pas d'impact sur les candidatures ayant réussi à la procédure accélérée. Dans aucun cas, ceux ayant réussi auront besoin de se soumettre à l'EPSRP.

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

      La question de la similarité des chaînes a fait l'objet jusqu'à présent des deux révisions annuelles de la procédure accélérée des ccTLD IDN. La question a été débattue lors des sessions publiques tenues pendant les réunions de la ccNSO depuis la réunion de l'ICANN à San Francisco en mars 2011.

      En avril 2013, le conseil de la ccNSO a adopté le rapport final du processus de développement des domaines internationalisés de premier niveau géographique. (http://ccnso.icann.org/workinggroups/idn-ccpdp-final-29mar13-en.pdf [PDF, 376 KB]).

      Le rapport inclut les propositions du groupe de travail 1 du ccPDP IDN (IDN ccPDP WG 1), qui ont fait l'objet d'une longue période de consultations publiques. L'IDN ccPDP WG 1 a ciblé son développement sur les recommandations préliminaires de politique pour la sélection des ccTLD IDN associés aux territoires inclus dans la liste ISO 3166-1 qui remplacera à terme la méthodologie de la procédure accélérée des ccTLD IDN. Les propositions incluent l'introduction de deux panels pour la validation des chaînes pouvant se prêter à confusion ; le deuxième panel fera la révision finale et définitive de la chaîne sur la base d'une recherche scientifique. Les commentaires publics reçus pendant les deux révisions annuelles donnent du soutien à l'introduction du deuxième panel. En outre, le comité consultatif gouvernemental a donné son avis au Conseil de l'ICANN pour, entre autres questions :

      • reconsidérer les IDN récemment refusés par la procédure accélérée, tout particulièrement ceux proposés par les autorités publiques ou nationales.
      • créer un mécanisme d'appel permettant de contester les décisions sur la possible confusion liée aux ccTLD IDN proposés, sans préjudice du point précédent, et par souci de transparence et de responsabilité.

      Bien que l'EPSRP ne soit pas un processus d'appel, il servira pour fournir un type différent de révision de la similarité des chaînes sur une base autre que celle du panel sur la similarité des chaînes existant. L'introduction de l'EPSRP permettra de faire la révision des candidats ayant subi une procédure accélérée ccTLD IDN et n'ayant pas réussi à la révision du panel sur la similarité des chaînes existant. Ainsi, cette action permettra d'aborder les recommandations de la ccNSO basées sur la communauté ainsi que l'avis du GAC.

      Cela a-t-il des impacts fiscaux ou des répercussions sur l'ICANN ?

      Cet amendement aura une conséquence budgétaire du fait que l'ICANN devra constituer un deuxième groupe d'experts pour faire une deuxième validation finale de la chaîne ccTLD IDN demandée. Il est prévu que cette modification n'ait aucun impact sur la sécurité ou la stabilité du DNS.

    2. Approbation du RAA 2013

      Attendu que l'ICANN, un groupe sélectionné par le groupe des parties prenantes des bureaux d'enregistrement, et l'équipe de négociation des bureaux d'enregistrement ont négocié les amendements à l'accord d'accréditation des bureaux d'enregistrement 2009 Registrar Accreditation Agreement— RAA) depuis 2011.

      Attendu que les négociations ont abouti au RAA 2013, qui aborde les 12 recommandations fournies en 2009 par les organismes d'application de la loi ainsi que d'autres révisions.

      Attendu que l'ICANN s'est engagée à mettre en place le RAA 2013 avant la délégation des gTLD à travers le programme des nouveaux gTLD.

      Attendu que l'ICANN et les bureaux d'enregistrement ont besoin de suffisamment de temps pour faire la transition des termes du RAA 2013, et que le Conseil se portera garant des conditions applicables.

      Résolu (2013.06.27.07), le conseil approuve le RAA 2013.

      Résolu (2013.06.27.08), le PDG a reçu la directive de suivre toutes les démarches nécessaires pour procéder à l'exécution du RAA 2013, avec les bureaux d'enregistrement et les candidats éligibles.

      Résolu (2013.06.27.09), le Conseil remercie le groupe de parties prenantes des bureaux d'enregistrement, et notamment les membres de l'équipe de négociation de leur des bureaux d'enregistrement de leur dévouement, du temps consacré et de l'effort réalisé pour mener à bien le processus de négociation.

      Fondements des Résolutions 2013.06.27.07 et 2013.06.27.09

      Pourquoi le Conseil d'administration aborde-t-il cette question maintenant?

      Les longues négociations du RAA 2013 ont été couronnées de succès, et le RAA 2013 proposé a été présenté au Conseil d'administration. Il est important que le RAA 2013 soit approuvé à ce stade, puisque le Conseil a accepté l'avis du GAC du communiqué de Beijing disant que « l'accord d'accréditation des bureaux d'enregistrement 2013 devrait être conclu avant que tout contrat d'un nouveaux gTLD soit approuvé ». L'approbation du RAA 2013 permet au Conseil de respecter cet avis. En outre, l'ICANN s'est engagée à plusieurs reprises auprès de la communauté à ce que le RAA 2013 serait en place avant la délégation des nouveaux gTLD. L'approbation du RAA 2013 assure à l'ICANN et aux bureaux d'enregistrement que les nouveaux termes seront applicables et permet aussi bien à l'ICANN qu'aux bureaux d'enregistrement d'aller de l'avant avec les travaux de mise en œuvre pour répondre aux nouvelles obligations. Enfin, la communauté de l'ICANN a attendu pendant longtemps le nouveau RAA après avoir suivi les négociations depuis la fin 2011.

      Quelle est la proposition à l'étude ?

      Le RAA 2013 inclut des dispositions visant à protéger les registrants au moyen d'un cadre contractuel mis à jour. Le RAA 2013 reflète des concessions âprement conquises sur de nombreuses questions clés soulevées lors des négociations, ainsi que lors des commentaires publics. Le RAA 2013 représente un progrès significatif par rapport à la version 2009 en vigueur et il augmente de manière significative les exigences liées à la performance pour chaque bureau d'enregistrement accrédité par l'ICANN, ce qui implique des progrès considérables pour l'écosystème des noms de domaine.

      Les points principaux de ce RAA 2013 proposé comprennent ce qui suit :

      • les 12 Recommandations sur l'application de la loi qui ont servi de base à ces négociations ont été abordées dans la version préliminaire proposée. Le résumé de la charte sur l'application de la loi ci-joint identifie la section ou la spécification du RAA 2013 qui aborde chaque recommandation. Quelques-uns des aspects principaux comprennent la création d'un point de contact d'abus dans chaque bureau d'enregistrement, les conditions de vérification et de validation du Whois chez le registrant et les niveaux des titulaires des comptes, un langage plus tranchant sur les obligations des bureaux d'enregistrement pour les revendeurs et de nouvelles obligations de rétention de données.

      • des outils de conformité améliorés qui comprennent d'autres outils de suspension et de résiliation, la clarification des droits d'audit et l'accès à l'information pour faciliter les recherches en cours, ainsi que les conditions de certification annuelle.

      • un document sur les droits et les responsabilités du registrant qui établit, avec un langage clair et simple, les droits et les responsabilités inclus dans le RAA 2013, tels que les types d'information dont les registrants peuvent s'attendre à disposer sur les termes et les conditions d'enregistrement, les frais et les processus du service client. Le document met aussi l'accent sur le rôle du registrant pour fournir une information de contact exacte et la responsabilité pour le maintien des enregistrements des noms de domaine. Ces droits et responsabilités ne sont pas exhaustifs quant à la totalité des droits et responsabilités du registrant énoncés dans la politique de consensus, même si ce document est étroitement lié aux termes du RAA 2013.

      • responsabilité du bureau d'enregistrement quant à la conformité du revendeur par rapport à tous les termes pertinents du RAA.

      • consolidation avec l'accord de registre pour les nouveaux gTLD Le cas échéant, l'ICANN et l'équipe de négociation des bureaux d'enregistrement se sont mis d'accord pour refléter le langage de l'accord d'enregistrement et permettre ainsi que les contrats soient mieux alignés. L'accord de registre des nouveaux gTLD et le RAA 2013 sont censés se compléter entre eux alors que les registres et les bureaux d'enregistrement évoluent vers des accords qui reflètent le mieux les changements du marché.

      • exigences concernant les fournisseurs de services proxy et de confidentialité provisoires. L'ICANN et l'équipe de négociation des bureaux d'enregistrement se sont mis d'accord quant aux protections provisoires à mettre en place pour les services proxy/de confidentialité offerts par les bureaux d'enregistrement. Ces protections provisoires exigent que l'information soit disponible pour des questions telles que les processus du service client et le moment auquel le fournisseur transmettra l'information des données d'enregistrement sous-jacentes de l'utilisateur du nom de domaine. Bien qu'elles n'incluent pas celles que l'on a demandé de mettre en place pour les fournisseurs de services proxy/de confidentialité, ces protections provisoires permettront d'avoir un marché plus responsable tant qu'un programme formel d'accréditation soit développé.

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

      Les négociations du RAA ont été entamées en raison des propositions avancées par la communauté d'application de la loi. Au cours des négociations, l'ICANN et le bureau d'enregistrement NT ont consulté des représentants des organismes d'application de la loi et le Comité consultatif gouvernemental (GAC) sur la façon dont les 12 recommandations d'application de la loi ont été mises en œuvre. Un récapitulatif de l'intégration des recommandations d'application de la loi au RAA 2013 est disponible sur http://www.icann.org/en/news/public-comment/proposed-raa-22apr13-en.htm. Le GAC s'est félicité des améliorations apportées au RAA intégrant les Recommandations du GAC de 2009 pour l'application de la loi et a également signalé qu'il était satisfait des progrès effectués concernant la possibilité de vérification et d'amélioration de l'exactitude des données des registrants ; il a également confirmé son soutien aux efforts continus destinés à déterminer un mécanisme préventif permettant de prévenir des activités criminelles ou d'autres activités illicites.

      En plus des consultations sur les applications de la loi et le GAC, l'ICANN a organisé des séances publiques interactives sur les négociations du RAA pendant les réunions du Costa Rica, de Prague, Toronto et Beijing. Sur demande, des représentants du personnel de l'ICANN ont également fait des présentations devant le Conseil de la GNSO, les groupes de travail d'At-large, plusieurs regroupements et groupes de parties prenantes au sein de la GNSO, et des représentants de l'application de la loi. En outre, l'ICANN a publié trois versions du RAA, avec les commentaires publics demandés en mars et en avril 2013. Le commentaire public du 22 avril 2013 traitait du RAA 2013 définitif proposé, qui comprend tous les accords entre l'ICANN et le bureau d'enregistrement NT. Dix-neuf commentateurs ont participé au forum de commentaires du 22 avril 2013, notamment des représentants du groupe des parties prenantes des bureaux d'enregistrement, l'ALAC, le regroupement de la propriété intellectuelle et le regroupement commercial. En soutien de la publication du RAA 2103 définitif proposé, l'ICANN a organisé un séminaire Web interactif en mai 2013 auquel se sont joints plus de 100 participants par téléphone et sur Adobe Connect.

      Après révision des commentaires publics, l'ICANN a également consulté l'équipe de négociation des bureaux d'enregistrement pour confirmer le soutien des bureaux d'enregistrement aux modifications identifiées.

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

      Tout au long des négociations, des inquiétudes ont surgi sur la quantité de questions dans le cadre du RAA proposé, qui ont été prises en compte lors de ces négociations. Par exemple, il y avait une inquiétude significative dans certaines parties de la communauté concernant le surdéveloppement des normes des services proxy et de confidentialité, en-dehors du processus de développement de politiques. En conséquence, l'ICANN et le bureau d'enregistrement NT ont trouvé une solution définissant des normes minimum pour les bureaux d'enregistrement à imposer aux services proxy et de confidentialité offerts à l'enregistrement, tout en déterminant un processus pour favoriser l'implication de la communauté dans l'élaboration d'un Programme proxy/de confidentialité d'accréditation. Toutefois, cela n'atténue pas toutes les inquiétudes dans ce domaine, et toutes les inquiétudes n'étaient pas non plus en mesure d'être traitées de cette façon.

      Avec cette dernière publication du RAA 2013 proposé, les principaux sujets d'inquiétude évoqués étaient les suivants :

      • pour l'exactitude des données du WHOIS, le regroupement de la propriété intellectuelle (IPC), le regroupement commercial (BC) et d'autres commentateurs ont soutenu l'utilisation d'une vérification pré-résolution, plutôt que de laisser une fenêtre 15 jours durant, après la résolution, dans laquelle pourrait se produire la vérification. Cette demande de vérification pré-résolution a été évoquée précédemment dans les négociations et en raison du potentiel d'un vaste changement pour le processus d'enregistrement des noms de domaine, ainsi que du travail continu pour créer une nouvelle méthode de traitement des données d'enregistrement des gTLD, il a été déterminé — et expliqué à la communauté — qu'en ce moment il n'est pas possible de faire la vérification de la pré-résolution sans un travail et un développement de la communauté plus approfondi.

      • de la même manière, il y a eu des demandes de vérification à la fois pour un courrier électronique et un numéro de téléphone, à propos d'inquiétudes relatives aux bureaux d'enregistrement et autres éléments, affirmant qu'il n'est pas toujours faisable — et dans certaines régions du monde pratiquement impossible — de réaliser des vérifications téléphoniques. Des changements plus approfondis dans ces domaines ont également été reportés pour privilégier les travaux en cours sur les données d'enregistrement des gTLD.

      • pour les enregistrements au travers des fournisseurs de services proxy/de confidentialité, de nombreux commentateurs ont réclamé (comme ils l'avaient fait tout au long du processus d'élaboration du RAA) une vérification des données sous-jacentes du client. Ainsi que nous l'avons expliqué précédemment à la communauté, le prochain travail sur la politique d'un Programme d'accréditation pour les services proxy/de confidentialité sera entrepris pour traiter ce type de demandes, lorsque les lignes d'application seront plus claires dans ce type de situation. En outre, de nombreuses personnes dans la communauté se sont opposées à la présentation de ce type de demande pour le moment. De même, la communauté n'a pas obtenu pour l'instant de consensus sur un mécanisme d'exigences plus explicites destinées à révéler et relayer les données sous-jacentes des clients, et bien qu'il y ait eu de nombreux commentaires mentionnant que l'ICANN devrait mettre en place ce type d'exigences immédiatement, ces travaux ont également été ajournés en vue du travail sur la politique d'accréditation basé sur la communauté. Une inquiétude commune récemment soulevée quant aux obligations liées au service proxy/de confidentialité établies dans le RAA 2013 indique qu'il nous faut être plus clairs au sujet de l'applicabilité envers les revendeurs, mais l'ICANN a pris en charge ce changement qui est reflété dans le RAA 2013 tel qu'il a été approuvé par le Conseil.

      • certains commentateurs ont soulevé des inquiétudes à propos du document sur les nouveaux droits des registrants et leurs responsabilités, en mentionnant qu'il n'était pas suffisamment élaboré en matière de reconnaissance de droits et de responsabilités d'ordre plus général. En raison de l'objectif spécifique des droits des registrants et de la spécification des responsabilités — qui consiste à faire le suivi des conditions du RAA 2013 — nous avons clarifié l'énoncé du document. Si la communauté souhaite produire une déclaration élargie des droits et des responsabilités, absolument rien dans le RAA 2013 ne devrait exclure ces travaux.

      • des commentaires ont signalé que les processus de modifications mis en place étaient très onéreux pour l'ICANN dans le cas où elle souhaiterait effectuer une modification à l'objection des bureaux d'enregistrement. Toutefois, l'ICANN croit que les processus des modifications approuvées par le Conseil et reflétées dans le RAA 2013 sont équilibrés, que le rôle du développement de politiques du modèle multipartite est reconnu et que, bien que complexe, un puissant mécanisme est disponible au cas où il serait nécessaire.

      • alors que les commentaires soutiennent en général le RAA 2013 et les améliorations qu'il entraîne, il y en a qui mettent en évidence une insatisfaction vis-à-vis du processus qui a conduit à l'élaboration du RAA 2013. De nombreuses personnes se sont montrées insatisfaites par rapport au caractère bilatéral des négociations, sans même donner à la communauté une possibilité d'observation lors des séances de négociation, sans parler de la possibilité de proposer une langue lors des négociations. Alors qu'il est trop tard pour modifier le processus utilisé précédemment, il est important de rappeler que le RAA lui-même ne comportait aucune voie vers la négociation ; le processus à utiliser n'était pas clair. Pour donner à la communauté la garantie de faire entendre sa voix dans les futures modifications du RAA, celui-ci incorpore actuellement des demandes spécifiques issues des commentaires publics lorsque des modifications sont à l'étude ou que des négociations ont été entamées.

      Ci-joint, un récapitulatif de quelques-unes des inquiétudes clés ayant été soulevées. Un récapitulatif complet et une analyse des commentaires sur le RAA définitif proposé (publié sur [insérer le lien]) a également été considéré dans le cadre de la décision sur le RAA. Ce récapitulatif et cette analyse ont également identifié des domaines où le RAA 2013 reflète les modifications répondant aux commentaires reçus.

      Quels sont les documents importants examinés par le Conseil ?

      Le Conseil a fait une révision :

      • du RAA 2013 et des spécifications incorporées
      • du récapitulatif des modifications entre le RAA 2013 et la version du 22 avril 2013
      • des clarifications finales faites au RAA après consultation avec les bureaux d'enregistrement
      • des résumés et analyses des commentaires publics du 22 avril 2013
      • des résumés et analyses des commentaires publics de mars 2013
      • du récapitulatif des recommandations des organismes d'application de la loi
      • du communiqué du GAC de Beijing

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

      Le Conseil a constaté que de nombreux facteurs significatifs conduisent à prendre cette décision. En premier lieu, il y a l'intense participation du bureau d'enregistrement NT et les déclarations de soutien effectuées par la communauté des bureaux d'enregistrement pour ce RAA 2013. Deuxièmement, le fait que le RAA 2013 incorpore les 12 recommandations d'application de la loi du GAC, qui ont été la base de l'ouverture des négociations, ainsi que le soutien du GAC pour les résultats des négociations, est un facteur essentiel pour le soutien du RAA 2013. De plus, bien qu'il y ait des domaines où la communauté de l'ICANN souhaiterait apporter des modifications au RAA 2013, les déclarations de la communauté sont plus que largement favorables aux progrès réalisés dans ce nouveau RAA. Le fait qu'il y ait des voies pour poursuivre les travaux dans les domaines essentiels identifiés par la communauté comme étant des sources d'inquiétude, notamment le groupe de travail d'experts sur les données d'enregistrement des gTLD et les travaux axés sur un programme d'accréditation des services proxy/de confidentialité, permet à la communauté de poursuivre le débat sur les questions les plus épineuses soulevées pendant la négociation et n'ayant pas été résolues suivant le souhait de certains membres de la communauté. Les améliorations dans le RAA 2013, y compris les outils améliorés de mise en conformité, les progrès réalisés en matière du WHOIS, des obligations plus claires pour les revendeurs, sont tout à fait opportunes et devraient être effectives avant la délégation des nouveaux gTLD afin que tous les gTLD saisis dans le programme des nouveaux gTLD soient couverts par ces conditions.

      Enfin, le Conseil a considéré qu'il était important que le groupe des parties prenantes des bureaux d'enregistrement soutienne le RAA 2013.

      Quelles sont les alternatives examinées par le Conseil ?

      En raison du processus pris par le RAA 2013 pour parvenir au Conseil, ce dernier n'a pas tenu compte de toutes les alternatives si ce n'est celle retardant l'approbation de l'accord. Toutefois, le Conseil a soigneusement examiné, en tant qu'alternatives, les recommandations de la communauté concernant les éléments qui devraient être ajoutés ou retirés du RAA 2013

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

      Il est prévu que la présentation du RAA 2013 aura des impacts positifs, tout comme il est prévu que les modifications qui vont être effectuées pour les obligations améliorées, entraînera une amélioration du rôle des bureaux d'enregistrements dans le DNS. Le RAA 2013 fournira des outils à l'ICANN, aux bureaux d'enregistrement et aux registrants pour clarifier la compréhension et les obligations, les droits et l'accès à l'information. Le plus gros risque de créer des impacts négatifs proviendra du manque de compréhension des nouvelles obligations — les registrants et les bureaux d'enregistrement devront également faire face aux nouvelles exigences. Des efforts au niveau de la formation peuvent aider à bloquer ces impacts négatifs.

      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 ?

      Les nouvelles obligations en vertu du RAA 2013 imposeront des conséquences fiscales aux bureaux d'enregistrement car ils auront de nouvelles obligations opérationnelles à respecter en vertu de l'accord et devront pour cela revoir leurs systèmes et processus. Le RAA 2013 inclut une condition transitoire pour donner un temps d'exécution à la mise en œuvre. De même, l'ICANN devra revoir ses efforts contractuels en matière d'application, ce qui peut avoir un léger impact fiscal, car la croissance de l'équipe de conformité contractuelle a déjà été intégrée au budget. La sensibilisation au niveau de la formation nécessaire pour permettre de garantir que les bureaux d'enregistrements tout comme les registrants comprennent ces nouvelles obligations, obligera également à demander des ressources fiscales à l'ICANN. Il est possible que l'augmentation des coûts opérationnels des bureaux d'enregistrement entraîne une augmentation des prix pour les consommateurs, mais il n'y a aucune documentation disponible en ce moment pour étayer cette théorie.

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

      Le RAA 2013, qui inclut des exigences techniques telles que le soutien des IDN du DNSSEC, contribuera au maintien de la sécurité, de la stabilité et de la résilience du DNS.

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

  3. Session exécutive

    1. Résolution confidentielle

      [Résolution supprimée]

      Résolu (2013.06.27.13), les points spécifiques de cette résolution seront confidentiels comme une « action concernant la problématique du personnel ou de l'emploi », en vertu de l'article III, section 5.2 des statuts de l'ICANN, et la totalité de la résolution restera confidentielle en vertu des mêmes statuts en attendant la décision du Président-directeur général de rendre publique la partie non-confidentielle de la résolution.

      Fondements des Résolutions 2013.06.27.10 et 2013.06.27.13

      [Fondements éliminés]

resolutions-27jun13-fr.pdf  [261 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."