Skip to main content
Resources

Résolutions du Conseil d’administration approuvées | 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 : https://www.icann.org/resources/board-material/resolutions-2015-09-28-en

  1. Ordre du jour approuvé :
    1. Approbation du procès-verbal de la réunion du Conseil d'administration
    2. Recommandations du Conseil de la GNSO sur la traduction et la translittération des informations de contact
    3. Renouvellement du contrat de registre .CAT
    4. Renouvellement du contrat de registre .TRAVEL
    5. Renouvellement du contrat de registre .PRO
  2. Ordre du jour principal :
    1. Conclusion du contrat pour le lieu de la réunion de l'ICANN de juin 2016
    2. La passation des contrats et les déboursements pour la nouvelle initiative d'ERP
    3. Déblocage du fonds de réserve – Coût de la transition de la supervision américaine de l'IANA
    4. Programme des nouveaux gTLD : Chemin vers les séries futures
    5. Les exigences en matière d'assurance pour le contrat d'accréditation de bureau d'enregistrement
    6. Politique de la GNSO et mise en œuvre des recommandations
    7. Nomination du président et du président élu du comité de nomination 2016 - SESSION À HUIS CLOS

  1. Ordre du jour approuvé :

    1. Approbation du procès-verbal de la réunion du Conseil d'administration

      Résolu (2015.09.28.01), le Conseil d'administration approuve les procès-verbaux des réunions du Conseil d'administration de l'ICANN du 16 et 28 juillet 2015.

    2. Recommandations du Conseil de la GNSO sur la traduction et la translittération des informations de contact

      Attendu que, le 13 juin 2013, le Conseil de la GNSO a lancé un processus d'élaboration des politiques (PDP) sur la traduction et la translittération, au sujet de deux des questions qui relèvent de la Charte, énoncés à Http://gnso.icann.org/en/issues/gtlds/transliteration-contact-charter-20nov13-en.pdf [PDF, 185 Ko].

      Attendu que, le PDP a suivi les étapes prévues dans les statuts, qui ont donné lieu au rapport final délivré le 12 juin 2015.

      Attendu que, le groupe de travail consacré à la traduction et la translittération des informations de contact (WG) est parvenu à un consensus sur sa première recommandation et un plein consensus sur le reste de ses six recommandations.1

      Attendu que, le Conseil de la GNSO a examiné et discuté les recommandations du groupe de travail consacré au PDP sur la traduction et la translittération des informations de contact et a adopté les recommandations le 24 juin 2015 par un vote unanime (voir : http://gnso.icann.org/en/council/resolutions#20150624-3).

      Attendu que, le vote du Conseil de la GNSO a dépassé le nombre de voix nécessaires (majorité qualifiée) pour imposer de nouvelles obligations aux parties contractantes de l'ICANN ; et

      Attendu que, après le vote du Conseil de la GNSO, une période de commentaires publics a été lancée au sujet des recommandations approuvées, et que les commentaires reçus ont été résumés et étudiés (https://www.icann.org/public-comments/irtp-d-recommendations-2014-10-20-en).

      Résolu (2015.09.28.02), le Conseil adopte les recommandations de politique du Conseil de la GNSO concernant la traduction et la translittération des informations de contact telles que présentées dans le rapport final.

      Résolu (2015.09.28.03), le président-directeur général ou son/ses représentant(s), est chargé de développer et de compléter un plan de mise en œuvre de ces recommandations et de poursuivre la communication et la coopération avec l'équipe de révision de la mise en œuvre de la GNSO et la communauté sur le travail de mise en œuvre.

      Fondements des résolutions 2015.09.28.02 et 2015.09.28.03

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

      La poursuite de l'internationalisation des systèmes de noms de domaine signifie qu'une proportion plus grande que jamais des utilisateurs d'Internet n'utilisent pas (ou ne sont même pas familiarisés) avec US ASCII, le terme technique pour le script latin utilisé en anglais et beaucoup d'autres langues d'Europe de l'Ouest.

      La précision et la cohérence des données des informations de contact sont cruciales pour en faire une source utile pour ceux qui cherchent des renseignements concernant les bureaux d'enregistrement de nom de domaine. Ce PDP WG a examiné l'importante question de savoir si les données traduites et/ou translittérées ou à des données soumises dans le script mieux connu par le titulaire de nom de domaine est plus susceptible de fournir ces exigences, compte tenu également du montant des demandes pour de telles données et les frais associés à une couverture de traduction ou translittération.

      Le rapport final du PDP sur la traduction et la translittération a reçu un appui de consensus sur sa première recommandation et un consensus complet sur les six autres restantes. Il a également reçu le soutien unanime du Conseil de la GNSO.

      Après la clôture de la période de commentaires publics, la prochaine étape consistera pour le Conseil d'administration à étudier ces recommandations, comme prévu dans l'annexe A des statuts de l'ICANN.

      Quelle est la proposition à l'étude ?

      Les recommandations suivantes ont été adoptées :

      Recommandation 1 Le Groupe de travail recommande de ne pas rendre obligatoire la transformation des coordonnées. Toute partie réclamant la transformation est libre d'y procéder ponctuellement en dehors du WHOIS ou de tout système de remplacement, tel que le protocole d'accès aux données d'enregistrement des noms de domaine (RDAP). Si le bureau d'enregistrement/l'opérateur de registre ne procède pas volontairement à la transformation (voir Recommandation 5), il revient alors à la partie requérante d'y procéder.

      Recommandation 2Tout en faisant remarquer qu'un système de remplacement du WHOIS devrait être en mesure de recevoir des informations sous la forme d'information de contact dans un script autre que l'ASCII, le Groupe de travail recommandent que ses champs de données soient stockés et affichés de façon à identifier plus facilement ce que les différentes entrées représentent et le script et la langue utilisés par le titulaire de nom de domaine enregistré.

      Recommandation 3 Le Groupe de travail recommande que les scripts et langues sélectionnés par les titulaires de noms de domaine pour soumettre leurs informations de contact soient choisis conformément aux modèles commerciaux du fournisseur du gTLD.

      Recommandation 4 Le Groupe de travail recommande qu'indépendamment des scripts et langues utilisés, il soit garanti que les champs de données soient conformes aux normes définies dans le Contrat d'accréditation de bureau d'enregistrement (RAA), la politique de consensus applicable, la politique relative aux informations WHOIS supplémentaires et tout autre politique en vigueur. Les coordonnées saisies sont validées conformément aux politiques et contrats susmentionnés et les scripts/langues utilisés doivent être facilement identifiables.

      Recommandation 5 Le Groupe de travail recommande, s'il est procédé à la transformation des informations de contact et si le système de remplacement du WHOIS est en mesure d'afficher plus d'un ensemble de données par entrée de titulaire de nom de domaine enregistré, que ces données soient présentées dans des champs supplémentaires (en sus des champs de script local faisant autorité fournis par le titulaire de nom de domaine) et que ces champs soient marqués comme transformés et que leurs sources soient précisées.

      Recommandation 6 Le Groupe de travail recommande que tout système de remplacement du WHOIS, par exemple le RDAP, reste suffisamment flexible pour pouvoir ajouter les informations de contact dans les nouveaux scripts et/ou langues et développe ses capacités en scripts/langues afin de recevoir, stocker et afficher les données sur les informations de contact.

      Recommandation 7 Le Groupe de travail recommande que ces recommandations soient coordonnées avec les autres modifications du WHOIS lorsque nécessaire et soient mises en œuvre et/ou appliquées dès qu'un système de remplacement du WHOIS en mesure de recevoir, stocker et afficher des caractères non-ASCII, sera opérationnel.

      Conclusions concernant la question 2 relative à la Charte Sur le fondement des recommandations 1 à 7, la question de savoir quelle entité devra choisir l'organe chargé de traduire ou translittérer les informations de contact en un seul script commun est controversée.

      La recommandation 1 a été accompagnée par une déclaration minoritaire, disant comme suit : Un membre du Groupe de travail, Petter Rindforth, conformément à la position prise par son unité constitutive des représentants de la propriété intellectuelle (ICP),2 Recommande une traduction et/ou translittération (transformation) obligatoire des informations de contact dans tous les domaines génériques de premier niveau (gTLD).

      Bien que conscient qu'il existe des situations pour lesquelles les coordonnées dans la langue locale du titulaire de nom de domaine constituent la version principale, afin de pouvoir identifier le titulaire de nom de domaine dans le cadre de la préparation d'une action en justice au niveau local, il existe également des cas où une recherche WHOIS globale, donnant accès aux informations le plus uniformément possible, s'avère nécessaire afin que le service d'enregistrement des informations atteigne ses objectifs de transparence et de responsabilité dans le DNS. Voir aussi 5.1.1 [Du Rapport Final] expliquant les arguments sur lesquels le Groupe de travail appuie la transformation obligatoire des informations de contact dans tous les domaines génériques de premier niveau.

      Quelles parties prenantes ou autres entités ont-elles été consultées ?

      Des consultations régulières ont eu lieu avec les parties prenantes au cours de la durée de vie de ce PDP, plus précisément au cours de trois réunions de l'ICANN (ICANN 49, 50 et 51), ainsi que des périodes de commentaires publics pour le rapport thématique préliminaire, lerapport initialainsi qu'avant son examen par le Conseil d'administration.

      Quelles sont les inquiétudes ou questions soulevées par la communauté ?

      La principale préoccupation qui a été soulevée par la Communauté a été qu'une base de données multiscript et/ou multilangue conduira à moins de transparence, car les scripts autres que le Latin pourraient être moins compréhensibles pour la majorité des utilisateurs d'Internet. Il permettrait également de réduire la capacité de recherche des données. On craint également que les titulaires de nom de domaine frauduleux puissent masquer leur identité derrière différents scripts/langues.

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

      Le Conseil d'administration a étudié le Rapport final, les recommandations qui lui ont été adressées par le Conseil de la GNSO, ainsi que la synthèse des commentaires publics et des réponses du personnel à ces commentaires.

      Quels sont les facteurs jugés significatifs par le Conseil ?

      Les recommandations ont été élaborées selon le PDP de la GNSO, tel que décrit dans l'Annexe A aux Statuts constitutifs de l'ICANN, et ont reçu l'appui unanime du Conseil de la GNSO. Comme indiqué dans les Statuts, le vote de cette motion à la majorité qualifiée ( le conseil a voté unanimement pour ) du Conseil de la GNSO oblige le Conseil d'administration à adopter la recommandation, à moins qu'il ne détermine, par un vote de plus des deux tiers de ses membres, que la politique concernée n'est pas dans l'intérêt de la communauté ICANN ou de l'ICANN. En outre, poursuivre l'internationalisation du système des noms de domaine est un domaine important des travaux de l'ICANN. Les recommandations ont le potentiel d'améliorer la convivialité et l'exactitude des informations de contact données dans un DNS véritablement mondialisé.

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

      Certains des impacts positifs identifiés dans le rapport final comprennent (mais ne se limitent pas à) :

      • Les titulaires de nom de domaine qui ne sont pas familiers avec US-ASCII seront en mesure d'enregistrer des noms de domaine en utilisant le script qu'ils connaissent le mieux;
      • Les bureaux d'enregistrement ne sont pas contraints de traduire ou de translittérer les données, mais ils doivent valider les données indépendamment des scripts qu'ils soutiennent - la décision sur ceux-là sera régie par la demande et l'offre ;
      • Les coûts d'enregistrement n'augmenteront pas parce que demander aux bureaux d'enregistrement la traduction ou la translittération de toutes les informations de contact dans un script3 mènera inévitablement à des coûts qui peuvent être transmis aux titulaires de nom de domaine ;
      • Autoriser les titulaires de nom de domaine à utiliser la langue/script avec lesquels ils sont le plus à l'aise lors de l'enregistrement de domaines aura un impact positif sur l'exactitude des données.

      Certaines des incidences négatives identifiées dans le rapport final sont les suivantes :

      • Ceux qui souhaitent rechercher des données d'informations de contact et opèrent en US-ASCII pourraient avoir à traduire ou à transcrire les données pour être en mesure de communiquer avec les titulaires de nom de domaine (mais cela est vrai pour ceux qui cherchent de l'information sans être à l'aise avec US-ASCII même si la traduction ou la translittération sont obligatoires).

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

      Il n'y aura aucun impact fiscal pour l'ICANN. Les membres de la communauté et le grand public pourraient avoir à payer un professionnel pour une traduction ou une translittération d'informations de contact . Toutefois, ces coûts sont à comparer avec les coûts éventuels qui existeraient si en vertu d'une exigence générale chaque contact qui est fourni dans un script autre que US-ASCII devrait être traduit ou translittéré.

      Y a-t-il des implications en termes de sécurité, stabilité ou résilience du DNS ?

      Le protocole WHOIS actuel n'est pas conçu pour les scripts autres que US-ASCII. Toutefois, le protocole d'accès aux données d'enregistrement des noms de domaine (RDAP) est actuellement mis en œuvre comme un remplacement du WHOIS et il [le RDAP] est entièrement compatible avec les différents scripts. Une fois le RDAP mis en œuvre - ou tout autre remplacement qui est capable de traiter les scripts autres que US-ASCII - il n'y aura aucun problème de sécurité, de stabilité ou de résilience lié au DNS si le Conseil approuve les recommandations proposées.

    3. Renouvellement du contrat de registre .CAT

      Attendu que l'ICANN a commencé une période de commentaires publics du 28 mai 2015 au 7 juillet 2015 <Https://www.icann.org/public-comments/cat-renewal-2015-05-28-en> sur un renouvellement proposé du contrat de registre TLD .CAT<Https://www.icann.org/resources/unthemed-pages/cat-2012-02-25-en>.

      Attendu que, le projet de renouvellement du contrat de registre .CAT comprend des dispositions modifiées pour mettre le contrat de registre .CAT en conformité avec la forme de contrat de registre des nouveaux gTLD.

      Attendu que le forum de commentaire public sur le projet de renouvellement du contrat de registre s'est conclu le 7 juillet 2015, avec l'ICANN recevant quinze (15) commentaires, par les particuliers comme par les organisations/groupes. Un résumé et une analyse des commentaires ont été fournis au Conseil.

      Attendu que le renouvellement du contrat de registre a été mis à jour pour inclure les dispositions existantes concernant le WHOIS.

      Résolu (2015.09.28.04), le projet de renouvellementdu contrat de registre .CATf[PDF, 621 ko] est approuvé, et le président et directeur général, ou son/ses représentant(s), est autorisé à prendre les mesures appropriées afin de finaliser et d'exécuter le contrat.

      Fondements de la résolution 2015.09.28.04

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

      L'ICANN et Fundació puntCAT (l » « Opérateur de registre ») ont conclu un contrat de registre le 23 septembre 2005 pour l'exploitation du domaine de premier niveau. L'actuel contrat de registre .CAT expire le 19 décembre 2015. Le renouvellement proposé (le « renouvellement de contrat de registre » ou « Contrat ») a été publié pour commentaires publics entre le 28 mai 2015 et 7 juillet 2015. Donc, en ce moment, le Conseil est en cours d'approbation du renouvellement de contrat de registre pour une exploitation continue du TLD .TRAVEL par l'Opérateur de registre.

      Quelle est la proposition à l'étude ?

      Le renouvellement de contrat de registre approuvé par le Conseil comprend des dispositions modifiées pour rendre le contrat en conformité avec la forme du contrat de registre de nouveaux gTLD. Les modifications comprennent : la mise à jour des spécifications techniques ; exigeant l'inclusion de certaines garanties GAC dans les engagements d'intérêt public (qui sont soumises à exécution par la procédure de règlement des différends relative à l'intérêt public) ; exigeant l'utilisation de bureaux d'enregistrement en vertu du contrat d'accréditation de bureau d'enregistrement 2013 après l'atteinte d'un certain seuil ; et mettre à jour les frais d'enregistrement.

      Afin de tenir compte de la nature spécifique du TLD .CAT, unTLD sponsorisé, les dispositions pertinentes dans lecontrat de registre des TLD sponsorisées du 23 septembre 2005ont été inclus dans le renouvellement de contrat de registre. Plus précisément, les dispositions de la Charte décrivant la communauté linguistique et culturelle catalane sur Internet qui sont compris dans la définition de la communauté et sont admissibles à l'enregistrement identifié dans la spécification 12. Le renouvellement de contrat de registre reflète également les autorisations précédentes concernant des noms réservés.

      Quelles parties prenantes ou autres entités ont-elles été consultées ?

      L'ICANN a lancé une période de commentaires publics sur le renouvellement du contrat de registre .CAT du 28 mai 2015 au 7 juillet 2015, suite à laquelle les commentaires ont été résumés et analysés. De plus, l'ICANN a engagé des négociations bilatérales avec l'opérateur de registre pour convenir de l'ensemble de termes à inclure dans le renouvellement du contrat de registre affiché pour commentaires publics.

      Quelles sont les inquiétudes ou questions soulevées par la communauté ?

      Quinze (15) membres de la communauté ont participé à la période de commentaires publics. Les membres de la communauté ont soulevé trois préoccupations principales dans leurs commentaires :

      • Transition des TLD historiques vers la forme de contrat de registre des nouveaux gTLD :  Certains commentaires publics ont exprimé leur préoccupation concernant le processus de l'ICANN d'utiliser le contrat de registre des nouveaux gTLD comme point de départ pour le renouvellement des RA pour les gTLD historiques. Ces commentateurs suggèrent qu'une telle position a pour effet de transformer les Procédures de règlement de litiges après délégation des nouveaux gTLD (p. ex., la Procédure de règlement de litiges après délégation des marques déposées et la Procédure de règlement de litiges relatifs aux engagements d'intérêt public), et le système uniforme de suspension rapide (URS) en politiques de consensus de facto sans suivre les procédures énoncées dans les statuts de l'ICANN pour leur création. D'autre part, d'autres commentaires ont appuyé la recherche de l'ICANN d'une uniformité dans les contrats de registre et noté que la transition à la nouvelle forme de contrat faisait partie de négociations bilatérales admissibles.
      • L'inclusion du Système uniforme de suspension rapide (URS) et de la procédure de règlement des différends de marques (PDDRP) pour les renouvellements des TLD historiques sans passer par un processus d'élaboration de politiques (PDP) : La plupart des commentaires reçus ont exprimé leur opposition à l'inclusion de l'URS au projet de renouvellement du contrat de registre .CAT, prétendant que l'URS peut devenir une politique de consensus uniquement après un processus d'élaboration de politique (PDP) complet engagé par l'ensemble de la communauté des parties prenantes de l'ICANN. Ces commentateurs ont également suggéré que l'imposition de l'URS à un gTLD historique par le processus de contrat est une intervention du personnel inacceptable dans le processus d'élaboration des politiques. D'autre part, certains commentateurs ont exprimé leur appui à l'inclusion de l'URS dans le renouvellement de contrat de registre, indiquant que les opérateurs de registre sont libres d'aller au-delà des protections des droits minimum et ne demandent pas un PDP.

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

      Dans le cadre de ses délibérations, le Conseil d'administration a examiné plusieurs documents, notamment :

      Quels facteurs ont-ils été jugés significatifs par le Conseil ?

      Le Conseil a examiné attentivement les commentaires publics reçus pour le contrat de renouvellement du registre, ainsi que le résumé et l'analyse de ces commentaires. Le Conseil a également examiné les termes convenus par l'opérateur de registre dans le cadre des négociations bilatérales avec l'ICANN. Alors que la Commission reconnaît les préoccupations exprimées par certains membres de la communauté en ce qui concerne l'inclusion de l'URS dans le renouvellement de contrat de registre, le Conseil d'administration note que l'inclusion de l'URS dans le contrat de renouvellement du registre est fondée sur les négociations bilatérales entre l'ICANN et l'opérateur de registre, où l'opérateur de registre a exprimé son intérêt à renouveler son accord de registre basé sur le contrat de registre des nouveaux gTLD.

      Le Conseil note que l'URS a été recommandé par l'équipe de révision de la mise en œuvre (IRT) comme un mécanisme obligatoire de protection des droits (RPM) pour tous les nouveaux gTLD. On a demandé à la GNSO de fournir son avis sur la question de savoir si certains mécanismes proposés de protection des droits (qui comprennent l'URS) étaient cohérents avec la politique proposée de la GNSO sur l'introduction de nouveaux gTLD et ont été l'option appropriée et efficace pour atteindre les principes énoncés et les objectifs de la GNSO. Le STI a examiné cette question et a conclu que « l'utilisation de l'USR doit être un RPM obligatoire pour tous les nouveaux gTLD. » Après cela, la GNSO a déclaré que l'URS n'était pas incompatible avec l'une quelconque de ses recommandations de politique existantes.

      Bien que l'URS a été développé et peaufiné dans le cadre du processus décrit ici, y compris l'examen public et la discussion dans la GNSO, il n'a pas été adopté en tant que politique de consensus et l'ICANN n'a pas la possibilité de le rendre obligatoire pour tous les TLDs autre que les candidats aux nouveaux gTLD qui ont présenté leur candidature au cours de la série 2012 des nouveaux gTLD.

      En conséquence, l'approbation par le Conseil du renouvellement de contrat de registre n'est pas un accord visant à rendre l'URS obligatoire pour tous les TLD historiques, et il serait inapproprié de le faire. Dans le cas de .CAT, l'inclusion de l'URS a été élaborée dans le cadre de la proposition dans des négociations bilatérales entre l'opérateur du registre et l'ICANN.

      En outre, le Conseil a examiné les commentaires concernant la transition des TLD historiques vers la nouvelle forme de contrat de registre. Le Conseil note que le contrat de registre existant appelle une présomption de renouvellement du contrat à son expiration dès lors que certaines exigences sont satisfaites. La convention de renouvellement est soumise à la négociation des modalités de renouvellement raisonnablement acceptable par l'ICANN et l'opérateur de registre. Les modalités de renouvellement approuvées par le Conseil sont le résultat de négociations bilatérales demandées dans l'actuel contrat de registre, et la transition vers la nouvelle forme de contrat de registre n'enfreindrait pas établi la politique de la GNSO. Comme décrit ci-dessous, la nouvelle forme de contrat de registre fournit certains avantages opérationnels, en plus d'avantages aux titulaires de nom de domaine et à la communauté de l'Internet y compris les engagements d'intérêt public, nécessitant l'utilisation des bureaux d'enregistrement en vertu du 2013 RAA, et la capacité de l'ICANN de désigner en urgence un opérateur de registre provisoire dans le cas où des seuils d'urgence pour les services de registre critiques sont atteints.

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

      Dans le cadre du processus de renouvellement, l'ICANN a mené une révision des performances récentes de l'opérateur de registre dans le cadre de l'actuel contrat de registre .CAT. L'opérateur de registre a été déclaré pour avoir en grande partie satisfait à ses exigences contractuelles.

      L'approbation du Conseil du renouvellement de contrat de registre propose aussi des avantages opérationnels et techniques positifs. Conformément au renouvellement de contrat de registre, dans le cas où l'un des seuils d'urgence pour les fonctions de registre est atteint, l'opérateur de registre accepte que l'ICANN puisse désigner un opérateur de registre provisoire d'urgence du registre pour le TLD qui permettrait d'atténuer les risques pour la stabilité et la sécurité du système des noms de domaine. En outre, l'intégration technique de l'opérateur de registre pour se conformer aux dispositions du contrat des nouveaux gTLD permettra au Registre d'utiliser des processus uniformes et automatisés, ce qui facilitera le fonctionnement du TLD. Le renouvellement de contrat de registre comprend également des garanties sous la forme d'engagements d'intérêt public dans la spécification 11.

      Il y aura également des répercussions positives sur les registres et les titulaires. La transition vers le contrat de registre des nouveaux gTLD offrira une cohérence de tous les registres menant à un environnement plus prévisible pour les utilisateurs finaux et aussi le fait que la proposition de renouvellement de contrat de registre exige de l'opérateur de registre qu'il utilise uniquement des bureaux d'enregistrement accrédités par l'ICANN qui sont parties au contrat d'accréditation de bureau d'enregistrement 2013 (RAA) offrira plus d'avantages pour les bureaux d'enregistrement et les titulaires.

      La protection des détenteurs de droits : Le contrat des nouveaux gTLD permettra à l'opérateur de registre d'adopter d'autres mécanismes de protection des droits pour protéger les détenteurs de droits.

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

      Aucun impact fiscal significatif n'est à prévoir suite à l'approbation par l'ICANN de la proposition du renouvellement de contrat de registre .CAT. Il convient de noter toutefois qu'à la suite de l'approbation du renouvellement de contrat de registre, les commissions de registre annuelles prévues devraient diminuer de 112 000 USD à 52 000 USD. L'impact budgétaire nominal est compensé par les avantages supplémentaires aux titulaires de nom de domaine et à la communauté de l'Internet y compris les engagements d'intérêt public, nécessitant l'utilisation des bureaux d'enregistrement en vertu du 2013 RAA, et la capacité pour l'ICANN de désigner un opérateur de registre provisoire d'urgence dans le cas où des seuils d'urgence pour des services de registre critiques seraient atteints.

      Y a-t-il des implications en termes de sécurité, stabilité ou résilience du DNS ?

      Aucun problème de sécurité, de stabilité ou de résilience du DNS n'est à prévoir suite à l'approbation par l'ICANN du renouvellement proposé de l'accord de registre .CAT. En fait, le renouvellement proposé du contrat de registre comprend des dispositions destinées à permettre la mise en place d'actions plus rapides au cas où il y aurait des menaces à la sécurité ou à la stabilité du DNS. En fait, le renouvellement du contrat de registre proposé comprend des dispositions destinées à permettre la mise en place d'actions plus rapides au cas où il y aurait des menaces à la sécurité ou à la stabilité du DNS. Dans le cadre de sa fonction administrative organisationnelle, l'ICANN a publié la proposition préliminaire du renouvellement du contrat de registre pour commentaire public le 28 mai 2015.

    4. Renouvellement du contrat de registre .TRAVEL

      Attendu que l'ICANN a commencé une période de commentaires publics du 12 mai 2015 au 5 juillet 2015 <Https://www.icann.org/public-comments/travel-renewal-2015-05-12-en> sur un renouvellement proposé pour le contrat de registre pour le TLD .TRAVEL<Https://www.icann.org/resources/unthemed-pages/travel-2012-02-25-en>.

      Attendu que, le renouvellement de contrat de registre .TRAVEL proposé comprend des dispositions modifiées pour mettre le contrat de registre .TRAVEL en ligne avec la forme du contrat de registre de nouveaux gTLD.

      Attendu que le forum de commentaire public sur le renouvellement de contrat de registre a fermé le 5 juillet 2015, et l'ICANN a reçu quinze (15) commentaires, tant par les particuliers que par d'organisations/groupes. Un résumé et une analyse des commentaires ont été fournis au Conseil.

      Attendu que le Conseil n'a déterminé qu'aucune révision au contrat de renouvellement de registre .TRAVEL ne sera nécessaire après avoir pris en considération les commentaires.

      Résolu (2015.09.28.05), le renouvellement proposé du contrat de registre .TRAVEL[PDF, 621 ko] est approuvé, et le président-directeur général, ou son/ses représentant(s), est autorisé à prendre les mesures appropriées afin de finaliser et d'exécuter le contrat.

      Fondements de la résolution 2015.09.28.05

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

      L'ICANN et Tralliance Registry Management Company, LLC (l' « Opérateur de registre ») ont conclu un contrat de registrel e 5 Mai 2005 pour le fonctionnement du domaine de premier niveau .TRAVEL. L'actuel contrat de registre .TRAVEL expire le 19 octobre 2015. Le renouvellement proposé (le « Contrat de renouvellement de registre » ou « contrat ») a été publié pour commentaires publics entre le 12 mai 2015 et le 5 juillet 2015. Donc, en ce moment, le Conseil est en cours d'approbation du renouvellement de contrat de registre pour une exploitation continue du TLD .TRAVEL par l'Opérateur de registre.

      Quelle est la proposition à l'étude ?

      Le renouvellement de contrat de registre approuvé par le Conseil comprend des dispositions modifiées pour rendre le contrat en conformité avec la forme du contrat de registre de nouveaux gTLD. Les modifications comprennent : la mise à jour des spécifications techniques ; exigeant l'inclusion de certaines garanties GAC dans les engagements d'intérêt public (qui sont soumises à exécution par la procédure de règlement des différends relative à l'intérêt public) ; exigeant l'utilisation de bureaux d'enregistrement en vertu du contrat d'accréditation de bureau d'enregistrement 2013 après l'atteinte d'un certain seuil ; et mettre à jour les frais d'enregistrement.

      Afin de tenir compte de la nature spécifique du TLD .TRAVEL, unTLD sponsorisé, les dispositions pertinentes dans lecontrat de registre TLD sponsorisé du 5 mai 2005ont été incluses dans le renouvellement de contrat de registre. Plus précisément, les dispositions de la Charte décrivant les secteurs de l'industrie du voyage qui sont comprises dans la définition de la communauté et sont admissibles à l'enregistrement sont identifiées dans la spécification 12. Le renouvellement de contrat de registre reflète également les autorisations précédentes concernant des noms réservés.

      Quelles parties prenantes ou autres entités ont-elles été consultées ?

      L'ICANN a lancé une période de commentaires publics sur la proposition du renouvellement de contrat de registre .TRAVEL du 12 mai 2013 au 5 juillet 2015, à la suite de laquelle les commentaires ont été résumés et analysés. De plus, l'ICANN a engagé des négociations bilatérales avec l'opérateur de registre pour convenir de l'ensemble de termes à inclure dans le renouvellement du contrat de registre affiché pour commentaires publics.

      Quelles sont les inquiétudes ou questions soulevées par la communauté ?

      Quinze (15) membres de la communauté ont participé à la période de commentaires publics. Les membres de la communauté ont soulevé deux préoccupations principales dans leurs commentaires :

      • La transition des TLD historiques vers la forme de contrat de registre des nouveaux gTLD : Certains commentaires publics ont exprimé leur préoccupation concernant le processus de l'ICANN d'utiliser le contrat de registre des nouveaux gTLD comme point de départ pour le renouvellement des RA pour les gTLD historiques. Ces commentateurs suggèrent qu'une telle position a pour effet de transformer les Procédures de règlement de litiges après délégation des nouveaux gTLD (p. ex., la Procédure de règlement de litiges après délégation des marques déposées et la Procédure de règlement de litiges relatifs aux engagements d'intérêt public), et le système uniforme de suspension rapide (URS) en politiques de consensus de facto sans suivre les procédures énoncées dans les statuts de l'ICANN pour leur création. D'autre part, d'autres commentaires ont appuyé la recherche de l'ICANN d'une uniformité dans les contrats de registre et noté que la transition à la nouvelle forme de contrat faisait partie de négociations bilatérales admissibles.
      • L'inclusion du Système uniforme de suspension rapide (URS) et de la procédure de règlement des différends de marques déposées (PDDRP) pour les renouvellements des TLD historiques sans passer par un processus d'élaboration de politiques (PDP) : La plupart des commentaires reçus ont exprimé leur opposition à l'inclusion de l'URS au projet de renouvellement du contrat de registre .TRAVEL, prétendant que l'URS peut devenir une politique de consensus uniquement après un processus d'élaboration de politique (PDP) complet engagé par l'ensemble de la communauté des parties prenantes de l'ICANN. Ces commentateurs ont également suggéré que l'imposition de l'URS à un gTLD historique par le processus de contrat est une intervention du personnel inacceptable dans le processus d'élaboration des politiques. D'autre part, certains commentateurs ont exprimé leur appui à l'inclusion de l'URS dans le renouvellement de contrat de registre, indiquant que les opérateurs de registre sont libres d'aller au-delà des protections des droits minimum et ne demandent pas un PDP.

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

      Dans le cadre de ses délibérations, le Conseil d'administration a examiné plusieurs documents, notamment :

      Quels facteurs ont-ils été jugés significatifs par le Conseil ?

      Le Conseil a examiné attentivement les commentaires publics reçus pour le contrat de renouvellement du registre, ainsi que le résumé et l'analyse de ces commentaires. Le Conseil a également examiné les termes convenus par l'opérateur de registre dans le cadre des négociations bilatérales avec l'ICANN. Bien que le Conseil reconnaît les préoccupations exprimées par certains membres de la communauté en ce qui concerne l'inclusion de l'URS dans le renouvellement de contrat de registre, il note que l'inclusion de l'URS dans le contrat de renouvellement du registre est fondée sur les négociations bilatérales entre l'ICANN et l'opérateur de registre, où l'opérateur de registre a exprimé son intérêt à renouveler son accord de registre basé sur le contrat de registre des nouveaux gTLD.

      Le Conseil note que l'URS a été recommandé par l'équipe de révision de la mise en œuvre (IRT) comme un mécanisme obligatoire de protection des droits (RPM) pour tous les nouveaux gTLD. On a demandé à la GNSO de fournir son avis sur la question de savoir si certains mécanismes proposés de protection des droits (qui comprennent l'URS) étaient cohérents avec la politique proposée de la GNSO sur l'introduction de nouveaux gTLD et ont été l'option appropriée et efficace pour atteindre les principes énoncés et les objectifs de la GNSO. Le STI a examiné cette question et a conclu que « l'utilisation de l'USR doit être un RPM obligatoire pour tous les nouveaux gTLD. » Après cela, la GNSO a déclaré que l'URS n'était pas incompatible avec l'une quelconque de ses recommandations de politique existantes.

      Bien que l'URS a été développé et peaufiné dans le cadre du processus décrit ici, y compris l'examen public et la discussion dans la GNSO, il n'a pas été adopté en tant que politique de consensus et l'ICANN n'a pas la possibilité de le rendre obligatoire pour tous les TLDs autre que les candidats aux nouveaux gTLD qui ont présenté leur candidature au cours de la série 2012 des nouveaux gTLD.

      En conséquence, l'approbation par le Conseil du renouvellement de contrat de registre n'est pas un accord visant à rendre l'URS obligatoire pour tous les TLD historiques, et il serait inapproprié de le faire. Dans le cas de .TRAVEL, l'inclusion de l'URS a été élaborée dans le cadre de la proposition dans le cadre de négociations bilatérales entre l'exploitant du registre et de l'ICANN.

      En outre, le Conseil a examiné les commentaires concernant la transition des TLD historiques vers la nouvelle forme de contrat de registre. Le Conseil note que le contrat de registre existant appelle une présomption de renouvellement du contrat à son expiration dès lors que certaines exigences sont satisfaites. La convention de renouvellement est soumise à la négociation des modalités de renouvellement raisonnablement acceptable par l'ICANN et l'opérateur de registre. Les modalités de renouvellement approuvées par le Conseil sont le résultat de négociations bilatérales demandées dans l'actuel contrat de registre, et la transition vers la nouvelle forme de contrat de registre n'enfreindrait pas établi la politique de la GNSO. Comme décrit ci-dessous, la nouvelle forme de contrat de registre fournit certains avantages opérationnels, en plus d'avantages aux titulaires de nom de domaine et à la communauté de l'Internet y compris les engagements d'intérêt public, nécessitant l'utilisation des bureaux d'enregistrement en vertu du 2013 RAA, et la capacité de l'ICANN de désigner en urgence un opérateur de registre provisoire dans le cas où des seuils d'urgence pour les services de registre critiques sont atteints.

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

      Dans le cadre du processus de renouvellement, l'ICANN a mené une révision des performances récentes de l'opérateur de registre dans le cadre du contrat actuel de registre .TRAVEL. L'opérateur de registre a été déclaré pour avoir en grande partie satisfait à ses exigences contractuelles.

      L'approbation du Conseil du renouvellement de contrat de registre propose aussi des avantages opérationnels et techniques positifs. Conformément au renouvellement de contrat de registre, dans le cas où l'un des seuils d'urgence pour les fonctions de registre est atteint, l'opérateur de registre accepte que l'ICANN puisse désigner un opérateur de registre provisoire d'urgence du registre pour le TLD qui permettrait d'atténuer les risques pour la stabilité et la sécurité du système des noms de domaine. En outre, l'intégration technique de l'opérateur de registre pour se conformer aux dispositions du contrat des nouveaux gTLD permettra au Registre d'utiliser des processus uniformes et automatisés, ce qui facilitera le fonctionnement du TLD. Le renouvellement de contrat de registre comprend également des garanties sous la forme d'engagements d'intérêt public dans la spécification 11.

      Il y aura également des répercussions positives sur les registres et les titulaires. La transition vers le contrat de registre des nouveaux gTLD offrira une cohérence de tous les registres menant à un environnement plus prévisible pour les utilisateurs finaux et aussi le fait que la proposition de renouvellement de contrat de registre exige de l'opérateur de registre qu'il utilise uniquement des bureaux d'enregistrement accrédités par l'ICANN qui sont parties au contrat d'accréditation de bureau d'enregistrement 2013 (RAA) offrira plus d'avantages pour les bureaux d'enregistrement et les titulaires.

      La protection des détenteurs de droits : Le contrat des nouveaux gTLD permettra à l'opérateur de registre d'adopter d'autres mécanismes de protection des droits pour protéger les détenteurs de droits.

      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 ?

      Aucun impact fiscal significatif n'est à prévoir suite à l'approbation par l'ICANN du renouvellement proposé du contrat de registre .TRAVEL. Il convient de noter toutefois qu'à la suite de l'approbation du renouvellement de contrat de registre, les commissions de registre annuelles prévues devraient diminuer de 46 000 USD à 26 000 USD. L'impact budgétaire nominal est compensé par les avantages supplémentaires aux titulaires de nom de domaine et à la communauté de l'Internet y compris les engagements d'intérêt public, nécessitant l'utilisation des bureaux d'enregistrement en vertu du 2013 RAA, et la capacité pour l'ICANN de désigner un opérateur de registre provisoire d'urgence dans le cas où des seuils d'urgence pour des services de registre critiques seraient atteints.

      Y a-t-il des implications en termes de sécurité, stabilité ou résilience du DNS ?

      Aucun problème de sécurité, de stabilité ou de résilience du DNS n'est à prévoir suite à l'approbation par l'ICANN de la proposition de renouvellement de contrat de registre .TRAVEL. En fait, le renouvellement proposé du contrat de registre comprend des dispositions destinées à permettre la mise en place d'actions plus rapides au cas où il y aurait des menaces à la sécurité ou à la stabilité du DNS. Dans le cadre de sa fonction administrative organisationnelle, l'ICANN a publié la proposition préliminaire du renouvellement du contrat de registre pour commentaire public le 12 mai 2015.

    5. Renouvellement du contrat de registre .PRO

      Attendu que l'ICANN a commencé une période de commentaires publics du 28 mai 2015 au 7 juillet 2015 <Https://www.icann.org/public-comments/pro-renewal-2015-05-28-en> sur un renouvellement proposé pour le .accord de registre TLD PRO. <Https://www.icann.org/resources/unthemed-pages/pro-2012-02-25-en>.

      Attendu que, le projet de renouvellement du contrat de registre .PRO comprend des dispositions modifiées pour mettre le contrat de registre .PRO en conformité avec la forme de contrat de registre des nouveaux gTLD.

      Attendu que le forum de commentaire public sur le projet de renouvellement du contrat de registre s'est conclu le 7 juillet 2015, avec l'ICANN recevant quatorze (14) commentaires, par les particuliers comme par les organisations/groupes. Un résumé et une analyse des commentaires ont été fournis au Conseil.

      Attendu que le registre de renouvellement a été mis à jour pour inclure les dispositions existantes concernant les enregistrements de domaine de troisième niveau.

      Résolu (2015.09.28.06), le projet de renouvellementdu contrat de registre .PRO[PDF, 621 ko] est approuvé, et le président et directeur général, ou son/ses représentant(s), est autorisé à prendre les mesures appropriées afin de finaliser et d'exécuter le contrat.

      Fondements de la résolution 2015.09.28.06

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

      L'ICANN et la société du service de registre (l » « Opérateur de registre ») ont conclu un contrat de registre le 22 avril 2010 pour l'exploitation du domaine de premier niveau .PRO. L'actuel contrat de registre .PRO expire le 20 octobre 2015. Le renouvellement proposé (le « renouvellement de contrat de registre » ou « Contrat ») a été publié pour commentaires publics entre le 28 mai 2015 et 7 juillet 2015. En ce moment, le Conseil est dans le processus d'approbation du contrat de renouvellement du registre pour que l'opérateur de registre poursuive l'exploitation du TLD .PRO par l'opérateur de registre.

      Quelle est la proposition à l'étude ?

      Le renouvellement de contrat de registre approuvé par le Conseil comprend des dispositions modifiées pour rendre le contrat en conformité avec la forme du contrat de registre de nouveaux gTLD. Les modifications comprennent : la mise à jour des spécifications techniques; exigeant l'inclusion de certaines garanties GAC dans les engagements d'intérêt public (qui sont soumises à exécution par la procédure de règlement des différends concernant l'intérêt public) ; exigeant l'utilisation de bureaux d'enregistrement en vertu du contrat d'accréditation de bureau d'enregistrement 2013 après l'atteinte d'un certain seuil ; et de retirer la limite maximum sur les frais que le registre peut faire payer aux bureaux d'enregistrement.

      Plus précisément, les restrictions à l'enregistrement à l'annexe 11 du contrat .PRO pourraient être remplacées avec l'ensemble des engagements en matière d'intérêt public standard applicable à tous les nouveaux TLD génériques. Toutefois, la proposition de renouvellement de contrat de registre a été mise à jour pour inclure des dispositions concernant l'enregistrement des noms de domaine de troisième niveau. En outre, les garanties 1 à 3 de catégorie 1 du GAC sont ajoutées à la spécification 11. Le contrat de renouvellement du registre élimine également le montant maximum pour les frais de service que le registre est en mesure de transmettre aux bureaux d'enregistrement concernant les noms de domaine, et reflète les approbations antérieures concernant des noms réservés.

      Quelles parties prenantes ou autres entités ont-elles été consultées ?

      L'ICANN a lancé une période de commentaires publics sur le renouvellement du contrat de registre .PRO du 28 mai 2015 au 7 juillet 2015, suite à laquelle les commentaires ont été résumés et analysés. De plus, l'ICANN a engagé des négociations bilatérales avec l'opérateur de registre pour convenir de l'ensemble de termes à inclure dans le renouvellement du contrat de registre affiché pour commentaires publics.

      Quelles sont les inquiétudes ou questions soulevées par la communauté ?

      Quatorze (14) membres de la communauté ont participé à la période de commentaires du public. Les membres de la communauté ont soulevé deux préoccupations principales dans leurs commentaires :

      • Transition des TLD historiques pour la forme de contrat de registre des nouveaux gTLD : Certains commentaires publics ont exprimé leur préoccupation concernant le processus de l'ICANN d'utiliser le contrat de registre des nouveaux gTLD comme point de départ pour le renouvellement des RA pour les gTLD historiques. Ces commentateurs suggèrent qu'une telle position a pour effet de transformer les Procédures de règlement de litiges après délégation des nouveaux gTLD (p. ex., la Procédure de règlement de litiges après délégation des marques déposées et la Procédure de règlement de litiges relatifs aux engagements d'intérêt public), et le système uniforme de suspension rapide (URS) en politiques de consensus de facto sans suivre les procédures énoncées dans les statuts de l'ICANN pour leur création. D'autre part, d'autres commentaires ont appuyé la recherche de l'ICANN d'une uniformité dans les contrats de registre et noté que la transition à la nouvelle forme de contrat fait partie de négociations bilatérales admissibles.
      • L'inclusion du Système uniforme de suspension rapide (URS) et de la procédure de règlement des différends de marques déposées (PDDRP) pour les renouvellements des TLD historiques sans passer par un processus d'élaboration de politiques (PDP) : La plupart des commentaires reçus ont exprimé leur opposition à l'inclusion de l'URS au projet de renouvellement du contrat de registre .TRAVEL, prétendant que l'URS peut devenir une politique de consensus uniquement après un processus d'élaboration de politique (PDP) complet engagé par l'ensemble de la communauté des parties prenantes de l'ICANN. Ces commentateurs ont également suggéré que l'imposition de l'URS à un gTLD historique par le processus de contrat est une intervention du personnel inacceptable dans le processus d'élaboration des politiques. D'autre part, certains commentateurs ont exprimé leur appui à l'inclusion de l'URS dans le renouvellement de contrat de registre, indiquant que les opérateurs de registre sont libres d'aller au-delà des protections des droits minimum et ne demandent pas un PDP.

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

      Dans le cadre de ses délibérations, le Conseil d'administration a examiné plusieurs documents, notamment :

      Quels facteurs ont-ils été jugés significatifs par le Conseil ?

      Le Conseil a examiné attentivement les commentaires publics reçus pour le contrat de renouvellement du registre, ainsi que le résumé et l'analyse de ces commentaires. Le Conseil a également examiné les termes convenus par l'opérateur de registre dans le cadre des négociations bilatérales avec l'ICANN. Alors que la Commission reconnaît les préoccupations exprimées par certains membres de la communauté en ce qui concerne l'inclusion de l'URS dans le renouvellement de contrat de registre, le Conseil d'administration note que l'inclusion de l'URS dans le contrat de renouvellement du registre est fondée sur les négociations bilatérales entre l'ICANN et l'opérateur de registre, où l'opérateur de registre a exprimé son intérêt à renouveler son accord de registre basé sur le contrat de registre des nouveaux gTLD.

      Le Conseil note que l'URS a été recommandé par l'équipe de révision de la mise en œuvre (IRT) comme un mécanisme obligatoire de protection des droits (RPM) pour tous les nouveaux gTLD. On a demandé à la GNSO de fournir son avis sur la question de savoir si certains mécanismes proposés de protection des droits (qui comprennent l'URS) étaient cohérents avec la politique proposée de la GNSO sur l'introduction de nouveaux gTLD et ont été l'option appropriée et efficace pour atteindre les principes énoncés et les objectifs de la GNSO. Le STI a examiné cette question et a conclu que « l'utilisation de l'USR doit être un RPM obligatoire pour tous les nouveaux gTLD. » Après cela, la GNSO a déclaré que l'URS n'était pas incompatible avec l'une quelconque de ses recommandations de politique existantes.

      Bien que l'URS a été développé et peaufiné dans le cadre du processus décrit ici, y compris l'examen public et la discussion dans la GNSO, il n'a pas été adopté en tant que politique de consensus et l'ICANN n'a pas la possibilité de le rendre obligatoire pour tous les TLDs autre que les candidats aux nouveaux gTLD qui ont présenté leur candidature au cours de la série 2012 des nouveaux gTLD.

      En conséquence, l'approbation par le Conseil du renouvellement de contrat de registre n'est pas un accord visant à rendre l'URS obligatoire pour tous les TLD historiques, et il serait inapproprié de le faire. Dans le cas de .PRO, l'inclusion de l'URS a été élaborée dans le cadre de la proposition dans des négociations bilatérales entre l'opérateur du registre et l'ICANN.

      En outre, le Conseil a examiné les commentaires concernant la transition des TLD historiques vers la nouvelle forme de contrat de registre. Le Conseil note que le contrat de registre existant appelle une présomption de renouvellement du contrat à son expiration dès lors que certaines exigences sont satisfaites. La convention de renouvellement est soumise à la négociation des modalités de renouvellement raisonnablement acceptable par l'ICANN et l'opérateur de registre. Les modalités de renouvellement approuvées par le Conseil sont le résultat de négociations bilatérales demandées dans l'actuel contrat de registre, et la transition vers la nouvelle forme de contrat de registre n'enfreindrait pas établi la politique de la GNSO. Comme décrit ci-dessous, la nouvelle forme de contrat de registre fournit certains avantages opérationnels, en plus d'avantages aux titulaires de nom de domaine et à la communauté de l'Internet y compris les engagements d'intérêt public, nécessitant l'utilisation des bureaux d'enregistrement en vertu du 2013 RAA, et la capacité de l'ICANN de désigner en urgence un opérateur de registre provisoire dans le cas où des seuils d'urgence pour les services de registre critiques sont atteints.

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

      Dans le cadre du processus de renouvellement, l'ICANN a mené une révision des performances récentes de l'opérateur de registre dans le cadre de l'actuel contrat de registre .PRO. L'opérateur de registre a été déclaré pour avoir en grande partie satisfait à ses exigences contractuelles.

      L'approbation du Conseil du renouvellement de contrat de registre propose aussi des avantages opérationnels et techniques positifs. Conformément au renouvellement de contrat de registre, dans le cas où l'un des seuils d'urgence pour les fonctions de registre est atteint, l'opérateur de registre accepte que l'ICANN puisse désigner un opérateur de registre provisoire d'urgence du registre pour le TLD qui permettrait d'atténuer les risques pour la stabilité et la sécurité du système des noms de domaine. En outre, l'intégration technique de l'opérateur de registre pour se conformer aux dispositions du contrat des nouveaux gTLD permettra au Registre d'utiliser des processus uniformes et automatisés, ce qui facilitera le fonctionnement du TLD. Le renouvellement de contrat de registre comprend également des garanties sous la forme d'engagements d'intérêt public dans la spécification 11 y compris les garanties 1 à 3 de catégorie 1 du GAC.

      Il y aura également des répercussions positives sur les registres et les titulaires. La transition vers le contrat de registre des nouveaux gTLD offrira une cohérence de tous les registres menant à un environnement plus prévisible pour les utilisateurs finaux et aussi le fait que la proposition de renouvellement de contrat de registre exige de l'opérateur de registre qu'il utilise uniquement des bureaux d'enregistrement accrédités par l'ICANN qui sont parties au contrat d'accréditation de bureau d'enregistrement 2013 (RAA) offrira plus d'avantages pour les bureaux d'enregistrement et les titulaires.

      La protection des détenteurs de droits : Le contrat des nouveaux gTLD permettra à l'opérateur de registre d'adopter d'autres mécanismes de protection des droits pour protéger les détenteurs de droits.

      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 ?

      Aucun impact fiscal significatif n'est à prévoir suite à l'approbation par l'ICANN du renouvellement proposé du contrat de registre .PRO.

      Y a-t-il des implications en termes de sécurité, stabilité ou résilience du DNS ?

      Aucun problème de sécurité, de stabilité ou de résilience du DNS n'est à prévoir suite à l'approbation par l'ICANN du renouvellement proposé de l'accord de registre .PRO. En fait, le renouvellement du contrat de registre proposé comprend des dispositions destinées à permettre la mise en place d'actions plus rapides au cas où il y aurait des menaces à la sécurité ou à la stabilité du DNS. Dans le cadre de sa fonction administrative organisationnelle, l'ICANN a publié la proposition préliminaire du renouvellement du contrat de registre pour commentaire public le 28 mai 2015.

  2. Ordre du jour principal :

    1. Conclusion du contrat pour le lieu de la réunion de l'ICANN de juin 2016

      Attendu que l'ICANN a l'intention d'organiser sa deuxième réunion publique de 2016 dans la région Amérique latine et Caraïbes.

      Attendu que, le personnel a effectué un examen exhaustif des sites proposés en Amérique latine/Caraïbes et a trouvé que celui de Panama City au Panama serait le plus approprié.

      Résolu (2015.09.03.02) le Conseil d'administration autorise le président et PDG de l'ICANN, ou son/ses représentant(s), à s'occuper au mieux des contrats et des dépenses nécessaires à pour l'hôtel/centre de convention pour la réunion publique de l'ICANN de juin 2016 à Panama City, Panama dans la limite d'un montant de 1,1 million de dollars.

      Résolu (2015.09.28.08) les points spécifiques de cette résolution resteront confidentiels à des fins de négociation, conformément au chapitre III, article 5.2 des Statuts constitutifs de l'ICANN, jusqu'à ce que le président et PDG en autorise la divulgation.

      Fondements des résolutions 2015.09.28.07 et 2015.04.28.08

      Dans le cadre de son calendrier de réunions publiques, qui est de trois réunions par an actuellement, l'ICANN organise ces réunions dans des régions géographiques différentes (tel que défini dans ses Statuts constitutifs). La 56e réunion, prévue du 27 au 25 juin 2015, doit avoir lieu dans la région Amérique latine et Caraïbes. Un appel à recommandations concernant le site de la réunion pour cet événement a été publié le 23 mai 2015. L'ICANN a reçu de nombreuses propositions.

      Le personnel les a examinées avec attention, de même que d'autres sites. Il a ensuite rédigé un document afin de déterminer les sites qui remplissaient les Critères de sélection pour le site de la réunion (http://meetings.icann.org/location-selection-criteria). Basé sur les propositions et à l'analyse, l'ICANN a identifié la ville de Panama comme le site de l'ICANN 56.

      Le Conseil d'administration a examiné la présentation du personnel quant à la réunion à Panama City et la détermination que la proposition répondait aux facteurs importants des Critères de sélection du lieu de réunion, ainsi que les coûts liés au lieu choisi pour la réunion publique de l'ICANN de juin 2016.

      Les frais d'organisation de la réunion auront un impact financier sur l'ICANN, ainsi que sur la communauté, car cela implique des frais de réception et logistique de même des frais de voyage pour se déplacer jusqu'au lieu de la réunion. Cet impact est à prévoir indépendamment de l'emplacement de la réunion. Cette décision n'aura aucune incidence sur la sécurité ou la stabilité du DNS.

      Le Conseil d'administration remercie tous ceux qui ont adressé des propositions de lieux pour la 56e réunion de l'ICANN.

      Il s'agit d'une fonction administrative et organisationnelle qui ne nécessite pas de commentaire public.

    2. La passation des contrats et les déboursements pour la nouvelle initiative d'ERP

      Attendu que l'ICANN a établi un besoin d'acquérir un système intégré de planification des ressources d'entreprise (ERP) de solution.

      Attendu que lors de sa réunion du 11 septembre 2015, le Comité des finances du Conseil a examiné les incidences financières d'une nouvelle initiative d'ERP, et a envisagé les solutions de rechange.

      Alors que certains membres du comité du Conseil d'administration consacré aux risques ont examiné la solution ERP suggérée et ont fourni des avis au personnel sur les risques et les mesures d'atténuation utiles.

      Attendu que, d'une part le personnel et le Comité des finances du Conseil ont recommandé que le Conseil d'administration autorise le président directeur général, ou son/ses représentant(s), de prendre toutes les mesures nécessaires pour exécuter les contrats pour une nouvelle initiative d'ERP, tel que reflété dans les documents de référence à ce document, et, au besoin, permettre tous les déboursements liés à ces contrats.

      Résolu (2015.09.28.09), le conseil autorise le président-directeur général ou son/ses représentant(s), à prendre toutes les mesures nécessaires pour exécuter les contrats pour une nouvelle solution ERP, comme reflétée dans les documents de référence à ce document, et, au besoin, permettre tous les déboursements liés à ces contrats.

      Résolu (2015.09.28.10) les points spécifiques de cette résolution resteront confidentiels à des fins de négociation, conformément au chapitre III, article 5.2 des Statuts constitutifs de l'ICANN, jusqu'à ce que le président directeur général décide que la confidentialité de ces informations est levée.

      Fondements des résolutions 2015.09.28.09 et 2015.09.28.10

      L'ICANN a grandi en taille et en complexité au cours des cinq dernières années de nombreuses façons, y compris, mais pas limité à ce qui suit : (i) un personnel multiplié par trois ; (ii) une présence mondiale élargie à trois quartiers généraux et plusieurs centres d'engagement ; et (iii) un processus devenu plus complexe et global. Entre-temps, l'infrastructure d'un back-office distinct pour les finances, les RH et les systèmes d'approvisionnement soutenant l'organisation actuelle a été conçue et mise en œuvre il y a au moins cinq ans. La sécurisation et la mise en œuvre d'une solution intégrée de planification des ressources d'entreprise ERP sous un système d'enregistrement unique améliorera la capacité des systèmes, les capacités d'analyse et de rapports globaux, et la productivité et l'efficience interfonctionnels et accroîtra les contrôles internes, accélérant ainsi les progrès de l'ICANN vers l'excellence opérationnelle.

      Le personnel a effectué une analyse approfondie des deux options disponibles : (i) la rénovation de l'ensemble des systèmes existant pour améliorer à la marge leurs capacités avec la conception des interfaces dans la mesure du possible; et (ii) la mise en œuvre d'une solution ERP intégrée. Si le coût de l'option de rétroadaptation est inférieur la première année, le total des coûts sur cinq ans excéderont sensiblement les l'option d'une solution ERP intégrée, parce que la rétroadaptation aura toujours besoin d'une mise à niveau importante au cours de ces cinq années. En outre, la rétroadapation n'aurait qu'une incidence marginale sur l'amélioration des capacités et de l'efficacité du back-office et exigerait le développement d'interfaces coûteuses, complexes et demandant une maintenance élevée avec un ensemble de capacités de beaucoup inférieur à la solution intégrée.

      Par conséquent, la solution ERP intégrée est considérée comme une solution viable, et plus rentable.

      Le projet de solution ERP intégrée a été conçu comme suit :

      Ressources internes : Le projet a été examiné tôt puis retardé jusqu'à ce que du personnel plus senior avec une vaste expérience ait été disponible et que chaque unité opérationnelle impliquée ait atteint le niveau de maturité adéquat (IT, finances, RH, approvisionnement). Avec l'embauche d'un directeur principal de l'informatique en 2014 et d'un vice-président, Finances, en mars 2015, les deux ayant une vaste expérience des grands projets de mise en œuvre de systèmes, les conditions ont été remplies. Les ressources internes comprennent :

      1. Trois équipes d'expert sujet : chacune comprenant deux niveaux d'experts (un leader, et des experts pour chaque fonction)
      2. Quatre ressources humaines couvrant la période de conception et de mise en œuvre pour assurer que les opérations quotidiennes sont effectuées pendant que des experts se concentrent sur le projet ERP
      3. Un gestionnaire de projets dédié (entrepreneur) avec une vaste expérience de mise en œuvre ERP.
      4. Trois ressources informatiques : un directeur principal de l'informatique (surveillance et gestion), l'un Analyste IT et un manager IT (un pour les RH, l'autre pour les Finances/approvisionnement)
      5. Un comité de direction comprenant : CIIO, COO, CFO et un administrateur principal d'IT
      6. Une ressource pour la gestion de changement en matière RH (à être embauchés)
      7. Des révisions par ERM intégré depuis le lancement du projet.

      Ressources externes :

      1. Les grands fournisseurs ERP ont un vaste réseau de partenaires d'entreprises certifiées ainsi que de consultants internes dont l'ICANN se nourrit.
      2. L'ICANN va choisir les consultants techniciens les plus qualifiés grâce à un processus d'entrevues individuelles.

      Solution technique: Un modèle Logiciel en tant que service (SaaS) :

      1. Une plate-forme prête à configurer basée sur le Web, utilisé par tous les clients du fournisseur de solutions
      2. Chaque client configure un large éventail de capacités, pour les besoins de ses unités opérationnelles (pas de développement de logiciels, pas de personnalisation)
      3. Pour chaque fonction, la gamme des processus standards et optionnels est conçue sur la base des meilleures pratiques de processus et de contrôles, prête à être configurée.
      4. La plate-forme est régulièrement mise à jour et possède une riche carte routière de nouvelles capacités mises à la disposition de tous les clients de la plate-forme sans frais supplémentaires
      5. Le rendement du système est surveillé et géré par fournisseur SaaS selon des accords de niveau de service (SLA)

      Sécurité du système :

      1. Transfert de données : conçu par une stratégie de conversion de données multiétape, y compris les tests, la réconciliation et le processus de validation.
        1. L'ICANN sera convertir les données historiques des transactions et toutes les données du fichier principal.
        2. Tous les programmes de conversion seront testés de manière approfondie pour en vérifier l'exactitude et l'exhaustivité.
        3. L'ICANN effectuera les tests d'unité, deux pilotes de salle de conférence (CRP), qui teste nos processus opérationnels de la configuration du système à la conversion de fichiers de données.
        4. ICANN va effectuer un pilote de fonctionnement, qui simulera des processus opérationnels réels du début à la fin (par exemple, processus p2p) ainsi que qu'une évaluation complète de la conversion des données fichier maître et historique.
      2. Sécurité des données : Le processus de RFP inclut des démonstrations sur la récupération après sinistre, la gestion des opérations du centre de données, le cryptage des données, les registres de données, l'environnement ERP exclusif à l'ICANN :
        1. L'ICANN va configurer selon des normes de calibre international pour la sécurité des données, qui comprennent le chiffrement des données, la gestion des contrôles d'accès, l'accès et l'examen des journaux système et la configuration de la sécurité d'accès fondée sur de bons contrôles internes.

      En outre, le Conseil a revu les recommandations du personnel et du comité des finances du Conseil pour une autorité contractante pour les déboursements pour une nouvelle solution ERP.

      Il y aura un impact financier pour l'ICANN lors de la mise en œuvre d'une nouvelle solution ERP. Cet impact est actuellement inclus dans le plan opérationnel et le budget 2016 approuvé par le Conseil le 25 juin 2015. Cette action n'aura pas d'impact direct sur la sécurité, la stabilité et la résilience du système des noms de domaine.

      Il s'agit d'une fonction administrative et organisationnelle qui ne nécessite pas de commentaire public.

    3. Déblocage du fonds de réserve – Coût de la transition de la supervision américaine de l'IANA

      Attendu que, le 26 avril 2015, le Conseil a autorisé le retrait de fonds sur le fonds de réserve pour couvrir les frais encourus au cours de l'exercice 2015 par l'initiative de transition de la supervision des fonctions USg IANA d'un montant ne devant pas dépasser 7 millions de dollars des États-Unis.

      Attendu que l'ICANN a encouru des coûts réels au cours de l'exercice 2015 de 8,7 millions de dollars américains, y compris les coûts imprévus pour un avis juridique indépendant, coûts s'élevant à environ US$3,1 millions.

      Attendu que, le Conseil réitère la déclaration faite le 25 juin 2015 stipulant que le Conseil est » engagé à soutenir la communauté dans l'obtention de l'avis dont elle a besoin dans l'élaboration de recommandations à l'appui du processus de transition, et note également l'importance de veiller à ce que les fonds confiés à l'ICANN par la communauté soient utilisés dans manière responsable et efficace. Il est encouragé de s'assurer de la continuité des mesures de contrôle des coûts pour les travaux futurs du conseil indépendant. » (VoirHttps://www.icann.org/resources/board-material/resolutions-2015-06-25-en#2.c).

      Attendu que, le comité des finances du Conseil a recommandé que le Conseil d'administration autorise le déblocage de fonds sur le fonds de réserve pour couvrir les coûts réels encourus au cours de l'exercice 2015 liés à l'initiative de transition de la supervision de l'IANA/USG d'un montant de 8,7 millions de dollars américains, et le Conseil est d'accord.

      Résolu (2014.09.28.11), le Conseil d'administration autorise le Président-directeur général, ou son/ses représentant(s), à utiliser le fonds de réserve pour les coûts engagés pour l'exercice fiscal 2015 dans l'initiative de transition de la supervision de l'IANA pour un montant de 8 millions de dollars américains.

      Fondements de la résolution 2015.09.28.11

      L'initiative de transition de la supervision de l'IANA du gouvernement des États-Unis est une initiative majeure pour laquelle la communauté de l'ICANN entière consacre du temps et des ressources. Il est essentiel pour l'ICANN de soutenir le travail de sa communauté en vue de la réussite totale de ce projet, qui comprend l'élaboration de la proposition de transition de la supervision de l'IANA/USG et le travail de responsabilité et sa réussite est critique pour l'ICANN.

      Considérant sa nature exceptionnelle et le montant significatif de frais qui vont être engendrés, le financement de ce projet ne peut être fait par les recettes annuelles de l'ICANN. Par conséquent, lorsque le Conseil d'administration a approuvé le plan opérationnel et le budget de l'exercice fiscal 2015, il y a inclus le coût prévu du projet (sept millions de dollars) en déduisant la somme correspondante du fonds de réserve.

      Étant donné que ces dépenses sont engagées pendant l'exercice fiscal 2015, le conseil a approuvé le retrait de fonds de la réserve pour couvrit les coûts réels de l'exercice 2015 liés à l'initiative de transition de la supervision IANA/USG pour un montant de 7 millions de dollars américains prévu dans le plan opérationnel et le budget de 2015 approuvé par le conseil d'administration.

      Comme le total des coûts réels encourus au cours de l'exercice 2015 pour ce projet s'élevaient au total à US$8.7 millions en dépassant ainsi le montant total de7 millions de dollars de retrait du fonds de réserve que le Conseil avait autorisé dans sa décision 2015.04.26.17, l'ICANN demande de procéder, avec l'autorisation du Conseil, à retirer des fonds du Fonds de réserve pour le montant total des coûts réels supportés de 8,7 millions de dollars américains.. Cette action n'aura pas d'impact sur la sécurité, la stabilité et la résilience du système des noms de domaine.

      Il s'agit d'une fonction administrative et organisationnelle de l'ICANN qui ne nécessite pas de commentaire public.

    4. Programme des nouveaux gTLD : Chemin vers les séries futures

      Attendu que, la résolution du Conseil de2012.02.07.05 a réaffirmé l'engagement de l'ICANN d'ouvrir une série supplémentaire du programme des nouveaux gTLD aussi rapidement que possible.

      Attendu que, les révisions de la série 2012 du programme des nouveaux gTLD sont en cours.

      Attendu que, le Conseil encourage la participation des parties prenantes dans le processus ascendant de révision et de développement des futures séries du programme des nouveaux gTLD.

      Résolu (2015.09.28.12) le Conseil ordonne au personnel de l'ICANN de continuer les révisions du programme de nouveaux gTLD comme prévu, et encourage la communauté des parties prenantes à participer et à appuyer un processus de révision significatif et robuste.

      Résolu (2015.09.28.13), le Conseil d'administration suivra le travail de la communauté avec intérêt et examinera l'orientation des futures séries une fois le processus d'examen et le processus d'élaboration potentiel des politiques de la GNSO atteignent un stade plus avancé.

      Fondements des résolutions 2015.09.28.12 et 2015.09.28.13

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

      De nombreux examens et activités communautaires et sont actuellement en cours qui informera vraisemblablement lorsque la prochaine série aura lieu et la façon dont elle sera menée. Le Conseil a été invité à considérer un processus et calendrier pendant une série supplémentaire du programme des nouveaux gTLD afin d'aider l'ICANN dans la planification à long terme, l'analyse et la budgétisation nécessaire à la réalisation d'une nouvelle série efficace.

      Quelles sont les propositions à l'étude ?

      Le conseil examine dans quelle mesure les nombreux processus de révision et les activités communautaires en cours informeront sur le moment et la manière dont la prochaine série du programme des nouveaux gTLD sera entreprise. Trois options ont été envisagées. La première crée une date cible pour la participation communautaire dans les prochaines séries et fournit un calendrier approximatif pour l'achèvement du processus d'examen et éventuellement du PDP. Il n'engage aucune partie à un délai strict pour l'achèvement d'un examen ou de l'élaboration de politiques, mais fournit plutôt un calendrier approximatif pour aider toutes les parties à préparer leur planification. La deuxième option établit un processus prévu selon lequel le Conseil considérera d'abord les résultats de l'examen avant de demander au personnel d'élaborer des plans de mise en œuvre avec leurs échéanciers. La troisième diffère de l'établissement d'un calendrier ou un ensemble de conditions préalables pour la prochaine série jusqu'à ce que le processus d'examen et/ou PDP atteignent un stade plus avancé.

      En ce moment, le conseil prend des mesures afin d'encourager la poursuite de l'exécution et la participation dans les processus actuels d'examen et pour reporter l'examen de la planification de la prochaine sérier jusqu'à ce que les examens en soient à un stade plus avancé.

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

      À compter de septembre 2014, le personnel de l'ICANN a publié et recueilli des commentaires sur le projet de plan de travail pour l'examen du programme des nouveaux gTLD.4 Le groupe de discussion de la GNSO sur de nouvelles procédures gTLD a joué un grand rôle dans la discussion des implications politiques et le développement pour le programme des nouveaux gTLD. Bien que la GNSO n'a pas été formellement consultée, un thème récurrent dans les discussions du groupe s'est centré sur quels processus futurs devraient être pris en considération pour déterminer le développement de la future série. En outre, les parties prenantes communautaires telles que les parties contractuelles, les nouveaux opérateurs de registres, les FAI et les opérateurs IP, et les membres de la communauté d'utilisateurs finaux ont toutes donné leurs perspectives sur le calendrier de la prochaine série.

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

      Le Conseil a examiné le projet de plan de travail, l'affirmation des engagements (AoC), le calendrier prévu pour l'achèvement de l'examen fondé sur les estimations initiales des activités décrites dans le Plan de travail, le rapport préliminaire thématique des discussions des GNSO du 31 août 2015 de la GNSO ainsi que les discussions de la GNSO sur lesquelles il est basé, résolutions 2012.02.07.05 et 2014.11.17.10 - 2014.11.17.12 en ce qui concerne les engagements d'ouvrir une deuxième série aussi rapidement que possible et en consultation avec les groupes de parties prenantes pertinentes, et la révision des mécanismes de protection des droits des garanties mises en place pour atténuer les problèmes éventuels du programme des nouveaux gTLD.

      Quels sont les facteurs jugés significatifs par le Conseil ?

      Étant donné que les résultats du processus d'examen sont inconnus et qu'un PDP peut être lancé, il n'est pas réaliste à ce stade précoce d'établir un calendrier pour l'ouverture d'une série supplémentaire du programme des nouveaux gTLD. Le Conseil comprend que le désir d'obtenir plus de certitude existe dans une grande partie de la communauté des parties prenantes, mais ils considèrent comme une priorité à ce stade de conduire des révisions significatives de la série actuelle. Il réexaminera les discussions des échéanciers et des processus pour les séries à venir à un stade ultérieur.

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

      Certains membres de la communauté seront probablement frustrés par le manque d'engagement envers un calendrier ou une procédure définitif. Toutefois, l'action du conseil tente de s'assurer que l'attention voulue est accordée au processus de révision afin d'évaluer pleinement les résultats de la première série du programme des nouveaux gTLD. Cela peut être considéré par certaines unités constitutives comme une non-réactivité à des questions sur la façon dont les divers examens et processus actuellement en cours devraient aboutir à l'ouverture d'une deuxième série. Toutefois, cette approche permet de poursuivre un dialogue communautaire concernant les domaines critiques à traiter pour créer ce jeu d'étapes. Aller trop vite à une deuxième série sans prendre le temps pour la révision peut inhiber la communauté de tenir dûment compte des leçons tirées de la première série dans le cadre de l'élaboration de la prochaine série. En outre, s'engager vers un échéancier ou un processus attendu peut créer des attentes irréalistes de la part des communautés de parties prenantes quant au moment où une deuxième série peut espérer avoir lieu.

      Y a-t-il des répercussions financières sur l'ICANN (plan stratégique, plan opérationnel, budget), sur la communauté et/ou sur le grand public ?

      Certaines révisions du programme nécessiteront l'expertise de spécialistes et des fonds ont été alloués à ces activités dans le budget de l'exercice fiscal 2015. Toutefois, on ne prévoit aucune incidence sur le budget supplémentaire résultant de cette résolution qui ne soit déjà prévue et/ou attribuée.

      Existe-t-il des problèmes de sécurité, stabilité et résilience liés au DNS ?

      Il n'y a pas de répercussions immédiates pour la sécurité, la stabilité ou la résilience du DNS résultant de cette résolution, mais il convient de noter que la sécurité, la stabilité et la résilience du DNS sont l'un des domaines de recherche proposés.

      S'agit-il d'un processus d'élaboration de politiques défini au sein des organisations de soutien de l'ICANN ou bien d'une fonction organisationnelle administrative de l'ICANN nécessitant une consultation publique ou ne nécessitant pas de commentaires du public ?

      Ce n'est pas un processus de politique bien défini, comme les résultats de la première série du programme des nouveaux gTLD doivent encore être évalués et un processus politique précis n'a encore été établi. Il est probable, toutefois, que ces examens et PDP seront soumis aux commentaires publics une fois terminés.

    5. Les exigences en matière d'assurance pour le contrat d'accréditation de bureau d'enregistrement

      Attendu que, la déclaration de l'ICANN de la politique d'accréditation (« La politique d'accréditation »), adoptée en 1999, prévoit que les bureaux d'enregistrement doivent avoir et conserver une police d'assurance sur la responsabilité générale commerciale (« CGL ») avec des limites d'au moins 500 000 USD, ou un montant moins élevé si le bureau d'enregistrement peut démontrer qu'une limite inférieure offrira une indemnisation raisonnable en cas d'un sinistre couvert.

      Attendu que, les contrats d'accréditation des bureaux d'enregistrement exigent que les bureaux d'enregistrement maintiennent une couverture au niveau de 500 000 USD (sans référence aux limites potentiellement plus basses de la politique d'accréditation).

      Attendu que, les retours ont informés l'ICANN du fait que ces exigences d'assurance RAA CGL n'encourage pas l'intention de la déclaration de politique de l'accréditation des bureaux d'enregistrement d'une assurance CGL offrant aux titulaires de nom de domaine un remède dans le cas d'actes fautifs d'un bureau d'enregistrement et constitue un obstacle pour le développement du marché des bureaux d'enregistrement.

      Attendu que, l'ICANN a sollicité deux séries de commentaires publics sur ce sujet enmai 2014etjanvier 2015.

      Résolu (2015.09.28.14), l'exigence l'assurance CGL du RAA 2009 et 2013 est supprimée, et le président-directeur général, ou son/ses représentant(s), est chargée de prendre les mesures nécessaires pour mettre en œuvre cette résolution.

      Résolu (2015.09.28.15), la GNSO est priée d'examiner la question de savoir si le travail de politique sur les exigences d'assurance de remplacement devrait être effectué à la lumière de la déclaration de la politique d'accréditation des bureaux d'enregistrement.

      Fondements des résolutions 2015.09.28.14 et 2015.09.28.15

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

      Les contrats d'accréditation des bureaux d'enregistrement 2009 et 2013 exigent que les bureaux d'enregistrement obtiennent une assurance CGL avec une limite de politique d'au moins 500 000 dollars américains. Cette exigence est fondée sur la formulation de la déclaration de l'ICANN sur la politique d'accréditation des bureaux d'enregistrement, qui stipule que les bureaux d'enregistrement doivent avoir et maintenir une police d'assurance de responsabilité civile générale (RCG) avec des limites d'au moins 500 000 USD, ou un montant moins élevé si le bureau d'enregistrement peut démontrer qu'une limite inférieure fournirait encore une indemnisation raisonnable en cas d'un sinistre non couvert. L'exigence des RAA n'incorpore pas la souplesse de la déclaration de politique d'accréditation pour une plus grande latitude dans l'abaissement des limites.

      Les polices d'assurance CGL protègent normalement les entreprises contre les réclamations ayant trait à la responsabilité pour blessures corporelles et aux dommages matériels qui se produisent dans leurs locaux, ainsi qu'à la responsabilité pour la publicité et en cas de blessure personnelle dans certains cas. Toutefois, la plupart des polices CGL excluent l'assurance pour les erreurs et omissions du bureau d'enregistrement. Autrement dit, les détenteurs de noms de domaine en général ne seraient pas en mesure de recevoir une compensation auprès d'une compagnie d'assurance (en vertu d'une police CGL) pour les actes de négligence du bureau d'enregistrement, tels que la suppression accidentelle ou le non-renouvellement d'un enregistrement, ou bien l'absence de réaction face au détournement d'un nom de domaine.

      Cette obligation d'assurance pose deux défis, à la fois financiers et pratiques pour certaines entités qui cherchent à devenir un bureau d'enregistrement accrédité par l'ICANN. Les commentaires de la communauté semblent indiquer que cette exigence désavantage de façon disproportionnée les bureaux d'enregistrement actuels et éventuels dans des endroits où ce type d'assurance est inutilement cher et/ou inexistant.

      Ainsi, le conseil prend des mesures à ce moment-ci pour approuver une dérogation de l'actuelle exigence d'une assurance CGL existante dans les RAA 2009 et 2013 parce que les exigences de l'assurance responsabilité générale commerciale ne semblent pas favoriser les objectifs de leur politique et créent un fardeau indu pour les bureaux d'enregistrement éventuels. Malgré une grande consultation publique, il n'y a aucune preuve que l'exigence CGL a offert un quelconque avantage pour les inscrits.

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

      L'ICANN a reçu des commentaires de bureaux d'enregistrement éventuels indiquant que l'assurance requise dans leur région était difficile ou impossible à obtenir. L'ICANN a conduit un atelier pour discuter de cette question et d'autres sujets liés aux régions mal desservies à la réunion de l'ICANN à Singapour en 2014. L'ICANN a consulté un consultant en assurances extérieur, ainsi que de nombreux bureaux d'enregistrement actuels et éventuels. L'ICANN a sollicité deux séries de commentaires publics à ce sujet en mai 2014etjanvier 2015. Dans le cadre de son action, le Conseil encourage la GNSO pour examiner cette question.

      Quelles sont les inquiétudes ou questions soulevées par la communauté ?

      Des membres de la communauté ont signalé à l'ICANN que l'exigence existante concernant l'assurance peut être difficile ou impossible à respecter dans de nombreuses juridictions, en particulier dans des pays en dehors de l'Amérique du Nord et de l'Europe. Certaines personnes ont mentionné que l'assurance CGL n'existe absolument pas dans certains pays et, bien que disponible dans d'autres, la limite de 500 000 USD apparaît excessive (et en conséquence commercialement irréalisable), par rapport aux conditions du marché, le coût de la vie et les risques de faire des affaires dans ces régions respectives. En outre, certains commentateurs ont demandé si l'exigence est toujours nécessaire compte tenu des améliorations institutionnelles dans d'autres domaines, tels que la conformité et le dépôt légal de données. Certains membres de la collectivité ont suggéré que l'ICANN pourrait fournir aux actuels ainsi qu'aux nouveaux bureaux d'enregistrement une liste d'assureurs qui sont connus pour servir les entreprises afin que le bureau d'enregistrement puisse contracter l'assurance requise pour obtenir l'accréditation de l'ICANN.

      D'autres membres de la communauté, cependant, ont mis porter l'attention sur le fait que certains titulaires de nom de domaine pourraient se retrouver sans protection si l'exigence CGL était supprimée.

      Quels documents le Conseil a-t-il examinés au moment de prendre cette décision?

      En prenant cette décision, le Conseil a examiné deux rapports de commentaires publics sur cette question, publiée le2 septembre 2014[PDF, 405 Ko] et le 3 avril 2015[PDF, 516 Ko] et les documents de référence du Conseil d'administration. Le Conseil a également examiné l'la déclaration de politique d'accréditation des bureaux d'enregistrement, ainsi que les contrats d'accréditation des bureaux d'enregistrement de 2009 et 2013.

      Quels facteurs le Conseil a-t-il trouvés significatifs lors de cette prise de décision ?

      L'exigence d'assurance existante ne sert pas son but initial de protéger les titulaires de nom de domaine d'actes illicites commis par les bureaux d'enregistrement. En outre, cette exigence inhibe la concurrence dans les régions insuffisamment desservies du monde. Parce que l'exigence d'assurance originale concernait la politique de l'ICANN, la GNSO est l'organe approprié pour décider si une exigence de remplacement est appropriée.

      Quelles sont les répercussions financières de cette décision ?

      Cette décision n'a aucune incidence financière sur l'ICANN. Éliminer l'exigence pourrait réduire les coûts pour les bureaux d'enregistrement actuels et éventuels qui choisissent de ne pas maintenir l'assurance responsabilité générale commerciale.

      Quelles sont les répercussions de cette décision sur la communauté ?

      Sur la base des renseignements reçus à ce jour, il semble qu'il n'y aura pas d'impact négatif sur les titulaires de nom de domaine, les autres parties prenantes, ou l'intérêt public mondial si le Conseil approuve la levée de l'obligation d'assurance.

      Cette décision aura un impact positif sur les bureaux d'enregistrement prospectifs et existants, particulièrement ceux des régions où l'assurance CGL est excessivement coûteuse ou impossible à obtenir. L'impact est susceptible d'être principalement de nature financière, mais peut aussi encourager des applications additionnelles pour l'accréditation de bureaux d'enregistrement dans à la fois les pays développés et les pays en développement.

      L'approbation par le Conseil d'une dispense de l'obligation d'assurance va favoriser les efforts de l'ICANN de promouvoir la concurrence dans un environnement mondial et à donner à la GNSO l'occasion d'examiner si une obligation d'assurance serait appropriée en remplacement.

      Quels sont les impacts sur la sécurité et la stabilité de l'Internet ?

      L'approbation de la résolution n'aura pas d'impact sur la sécurité, la stabilité ou la résilience du DNS.

    6. Recommandations sur la politique de la GNSO et sur la mise en œuvre

      Attendu que, le 17 juillet 2013, le Conseil de la GNSO a approuvé la charte pour un groupe de travail sur la politique non PDP de la GNSO et de sa mise en œuvre (Http://gnso.icann.org/en/council/resolutions#201307) chargé de fournir au Conseil de la GNSO avec un ensemble de recommandations sur :

      • un ensemble de principes visant à sous-tendre les discussions relatives aux politiques de la GNSO et leur mise en œuvre et tenant compte des procédures opérationnelles existantes de la GNSO.
      • un processus pour l'élaboration des politiques de la GNSO, peut-être sous forme d'« orientations politiques », comprenant entre autres les critères permettant d'établir quand il serait approprié d'utiliser un tel processus (pour élaborer des politiques autres que les « politiques de consensus ») au lieu du processus d'élaboration de politiques de la GNSO.
      • un cadre pour les discussions liées à la mise en œuvre des recommandations de la GNSO en matière de politique.
      • les critères servant à déterminer à quel moment une action doit être abordée par le biais d'un processus de politique et à quel moment elle doit être considérée comme une mise en œuvre.
      • une orientation supplémentaire sur la manière dont les équipes de révision de la mise en œuvre de la GNSO devraient fonctionner et opérer conformément aux termes du Manuel du PDP.

      Attendu que, le groupe de travail sur la politique de la GNSO et de sa mise en œuvre a publié son rapport de recommandations initiales pour commentaires publics le 19 janvier 2015 (voirHttps://www.icann.org/public-comments/policy-implementation-2015-01-19-en).

      Attendu que, le groupe de travail sur la politique de la GNSO et de sa mise en œuvre a examiné les commentaires reçus (voiroutil d'examen des commentaires publics[DOC, 267 KB]) et mis à jour le rapport en conséquence résultant en un rapport de recommandations finales, qui a été soumis au Conseil de la GNSO le 2 juin 2015.

      Attendu que, le rapport de recommandations finales (voirHttp://gnso.icann.org/en/drafts/policy-implementation-recommendations-01jun15-en.pdf[PDF, 1,53 Mo]) a été adopté à l'unanimité par le Conseil de la GNSO le 24 juin 2015.

      Attendu que, le 28 juillet 2015, le Conseil d'administration de l'ICANN a demandé au personnel de l'ICANN de poster les modifications proposées aux statuts de l'ICANN à la suite des recommandations proposées dans le rapport final de recommandations pour commentaires publics (voirHttps://www.icann.org/public-comments/bylaws-amendments-2015-07-31-en).

      Attendu que, deux commentaires ont été reçus à l'appui des recommandations proposées, y compris une Déclaration de la part de l'ALAC.

      Attendu que, l'ATRT2 a recommandé que "le Conseil doive continuer de soutenir un engagement intercommunautaire visant à développer une compréhension de la distinction entre développement et mise en œuvre des politiques. Élaborer des mécanismes complémentaires par lesquels les organisations de support et les comités consultatifs (SO/AC) peuvent consulter le Conseil sur des sujets y compris, mais non limités aux questions en matière de politique, de mise en œuvre et d'administration, sur lesquels le Conseil prend des décisions » (Recommandation 4).

      Résolu (2015.09.28.16), le Conseil approuve les modifications de statuts de l'ICANN, Article X, Section 3-9 comme affiché pour commentaires publics abordant les nouveaux seuils de vote de la GNSO résultant du processus d'orientation de la GNSO (BPO) et du processus accéléré d'élaboration de politiques de la GNSO (EPDP).

      Résolu (2105.09.28.17) le Conseil approuve les modifications de statuts de l'ICANN Annexe A telles que publiée pour commentaires publics (voirHttps://www.icann.org/en/system/files/files/bylaws-proposed-amendments-gnso-policy-implementation-31jul15-en.pdf[PDF, 656 Ko]), créant une nouvelle annexe A-1 qui décrit l'EPDP de la GNSO.

      Résolu (2015.09.28.18) le Conseil approuve les modifications de statuts de l'ICANN Annexe A telles que publiées pour commentaires publics (voirHttps://www.icann.org/en/system/files/files/bylaws-proposed-amendments-gnso-policy-implementation-31jul15-en.pdf[PDF, 656 Ko]), créant une nouvelle annexe A-2 qui décrit le GGP de la GNSO.

      Résolu (2015.09.28.19), le Comité souscrit à l'ensemble de principes/exigences de la GNSO qui se rapporte à l'élaboration de politiques et de mise en œuvre telle que décrite dans la section 4 du rapport des recommandations finales et ordonne au président-directeur général, ou son/ses représentant(s), ainsi qu'à la communauté de l'ICANN de prendre ces principes et exigences en considération lorsqu'il s'engage sur des problématiques de politique et de mise en œuvre de la GNSO.

      Résolu (2015.09.28.20), le conseil souscrit aux principes et directives de l'équipe de révision de la mise en œuvre comme énoncé à l'annexe L du rapport final de recommandation et demande au le personnel de l'ICANN ainsi que la communauté de l'ICANN de prendre ces directives et principes en considération lorsqu'ils s'engagent sur les problèmes associés à la mise en œuvre.

      Résolu (2015.09.28.21), le conseil reconnaît l'avis fourni par l'ALAC et s'engage à surveiller attentivement les activités d'élaboration des politiques de la GNSO pour s'assurer que les intérêts des utilisateurs et du public sont considérés convenablement et que la mise en œuvre de politiques complexes peut être accomplie dans des délais raisonnables.

      Résolu (2015.09.28.22) le Conseil ordonne au président-directeur général, ou son/ses représentant(s), de publier les documents pertinents sur les pages liées à la politique et la mise en œuvre de la GNSO sur les sites Web de la GNSO et de l'ICANN, ainsi qu'à rechercher et à incorporer les commentaires sur les améliorations et les documents supplémentaires à l'appui le cas échéant.

      Résolu (2015.09.28,23), le conseil estime que la recommandation 4 de l'ATRT2 est complétée par la présente et invite l'ATRT3 à examiner les recommandations adoptées à la lumière des conclusions et recommandations de l'ATRT2.

      Résolu (2015.09.28,24), le Conseil d'administration tient à remercier la communauté de la GNSO et les autres parties impliquées pour leur travail acharné sur cet effort.

      Fondements des résolutions 2015.09.28.16 et 2015.04.28.24

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

      Suite notamment aux discussions qui ont vu le jour à partir d'un certain nombre de problèmes liés à la mise en œuvre du programme des nouveaux noms de domaine génériques de premier niveau (gTLD), l'accent a été de plus en plus mis sur la question de savoir quels sont les dossiers relevant de la politique et quels sont ceux relevant de la mise en œuvre. Le débat a également porté sur les procédures à appliquer ainsi que sur le moment et la manière dont devraient être traitées les questions faisant l'objet d'opinions différentes au cours du processus de mise en œuvre. Après plusieurs discussions, y compris la publication d'un document de travail du personnel et une session communautaire au cours de la réunion ICANN46, le conseil de l'organisation de soutien aux extensions génériques (GNSO) a décidé en juillet 2013 de former un groupe de travail (WG) qui avait été chargé d'élaborer un ensemble de recommandations sur :

      • Un ensemble de principes qui appuiera les discussions de politiques et de mise en œuvre, en tenant compte des procédures opérationnelles de la GNSO.
      • un processus pour l'élaboration des politiques des gTLD, peut-être sous forme de « conseils de politique », comprenant entre autres les critères permettant d'établir quand il est approprié d'utiliser un tel processus (pour élaborer des politiques autres que les « politiques de consensus ») au lieu du Processus d'élaboration de politiques de la GNSO ;
      • un cadre pour les discussions liées à la mise en œuvre des recommandations de la GNSO en matière de politique ;
      • les critères servant à déterminer à quel moment une action doit être considérée en tant que processus de politique et à quel moment elle doit être considérée comme relevant de la mise en œuvre ; et
      • une orientation supplémentaire sur la manière dont les équipes de révision de la mise en œuvre de la GNSO devraient fonctionner et opérer conformément aux termes du Manuel du PDP.

      Les recommandations du Groupe de travail ont été adoptées à l'unanimité par le Conseil de la GNSO le 24 juin 2015 et soumises ensuite au Conseil d'administration de l'ICANN pour son examen.

      En outre, cette question a également été identifiée par l'équipe de révision de la responsabilité et de la transparence 2 (ATRT2) comme une priorité : « Le Conseil devra continuer de soutenir l'engagement inter communautaire visant à développer une compréhension de la distinction entre l'élaboration des politiques et la mise en œuvre des politiques. Élaborer des mécanismes complémentaires selon lesquels les organisations de soutien et les comités consultatifs (SO/AC) peuvent consulter le Conseil sur des sujets, y compris, mais non limités aux questions en matière de politique, mise en œuvre et administratives, sur lesquels le Conseil prend des décisions » (Recommandation 4).

      Quelle est la proposition à l'étude ?

      L'action du Conseil aujourd'hui est d'adopter les recommandations de la GNSO concernant la politique et la mise en œuvre. Ces recommandations incluent, entre autres, trois nouveaux processus pour la GNSO, dont deux - le processus d'orientation de la GNSO (GGP) et le processus accéléré d'élaboration de politiques de la GNSO (EPDP) - nécessitent l'introduction de modifications dans les Statuts de l'ICANN. L'action du Conseil approuve les modifications nécessaires aux statuts constitutifs pour mettre en œuvre le processus d'orientation de la GNSO et du processus accéléré d'élaboration des politiques de la GNSO. Ces nouveaux processus sont destinés à donner au conseil de la GNSO plus de souplesse pour aborder les questions de politiques par le biais de processus formels pour être utilisés si des critères spécifiques sont respectés. En outre, la Commission prend des mesures pour approuver les principes et directives de la politique et mise en œuvre pour guider plus avant le personnel ainsi que le travail communautaire lié à la politique et mise en œuvre de la GNSO.

      Quelles parties prenantes ou autres entités ont-elles été consultées ?

      Après plusieurs discussions, y compris la publication d'un document de travail du personnel (voirHttps://gnso.icann.org/en/correspondence/policy-implementation-framework-08jan13-en.pdf[PDF, 195 Ko] etHttp://forum.icann.org/lists/comments-policy-implementation-31jan13/) et une session communautaire pendant la réunion de l'ICANN46 (voir Http://beijing46.icann.org/node/37133) le Conseil de l'organisation de soutien des noms génériques (GNSO) a décidé en juillet 2013 en consultation avec d'autres SO/AC (voirHttp://gnso.icann.org/en/correspondence/robinson-to-so-ac-leadership-23apr13-en.pdf[PDF, 236 Ko]) de former un GW de la GNSO pour aborder un certain nombre de problèmes ayant trait à la politique et la mise en œuvre de la GNSO. Le Groupe de travail de la GNSO a sollicité des apports initiaux de toutes les SO/AC de l'ICANN et les SG/C de la GNSO à un stade précoce (voirhttps://community.icann.org/x/iSmfAg). La publication du rapport initial a été accompagnée par un forum de commentaires publics (voirHttps://www.icann.org/public-comments/policy-implementation-2015-01-19-en) ainsi qu'une session communautaire pendant l'ICANN52 (voir https://singapore52.icann.org/en/schedule/wed-policy-implementation). Le WG a examiné et traité tous les commentaires reçus comme démontré dans l'outil de révision des commentaires publics (voirhttps://community.icann.org/x/iSmfAg). À la suite de l'adoption unanime par le Conseil de la GNSO du rapport final de recommandations, le Conseil de l'ICANN ademandéau personnel de l'ICANN de publier les modifications proposées aux statuts de l'ICANN pour commentaires publics (voirHttps://www.icann.org/public-comments/bylaws-amendments-2015-07-31-en). Deux commentaires, y compris une déclaration d'avis de la part de l'ALAC, ont été reçus à l'appui des recommandations (voirHttp://forum.icann.org/lists/comments-bylaws-amendments-31jul15/).

      Quelles sont les inquiétudes ou questions soulevées par la communauté ?

      Le WG a examiné et traité tous les commentaires reçus comme démontré dans l'outil de révision des commentaires publics (voirhttps://community.icann.org/x/iSmfAg). L'ALAC, dans sa déclaration d'avis en réponse au forum de commentaires publics lancée par le Conseil de l'ICANN, a appuyé les recommandations, mais il a également recommandé que le Conseil d'administration de l'ICANN surveille attentivement les activités d'élaboration des politiques de la GNSO pour s'assurer que les intérêts du public et des utilisateurs sont considérés convenablement et que la mise en œuvre de politiques complexes peut être accomplie dans des délais raisonnables.

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

      Le Conseil a revu le rapport final de recommandations sur la politique et la mise en œuvre de la GNSO (voirHttp://gnso.icann.org/en/drafts/policy-implementation-recommendations-01jun15-en.pdf[PDF, 1,53 Mo]) et documents connexes.

      Quels sont les facteurs jugés significatifs par le Conseil ? Y a-t-il des effets positifs ou négatifs pour la communauté ?

      Le Conseil estime qu'il est particulièrement important que ces recommandations aient été élaborées par la communauté, en consultation avec le personnel de l'ICANN et que ces recommandations ont reçu l'appui unanime du Conseil de la GNSO. En outre, le Conseil reconnaît l'importance d'aborder cette question, comme l'a souligné l'AtRT2, et est d'avis que ces recommandations offriront au Conseil de la GNSO plus de souplesse pour aborder les questions de politiques au moyen de processus officiels ainsi que de fournir la clarté et la prévisibilité nécessaires en ce qui concerne les problématiques liées à la politique et la mise en œuvre de la GNSO.

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

      Aucun impact fiscal ou ramification ne sont envisagé à la suite de la mise en œuvre de ces recommandations.

      Y a-t-il des implications en termes de sécurité, stabilité ou résilience du DNS ?

      Aucun problème de sécurité, de stabilité ou de résilience des questions relatives au DNS n'a été identifié en relations de ces recommandations.

    7. Nomination du président et du président élu du comité de nomination 2016 - SESSION À HUIS CLOS

      Attendu que, le BGC a examiné les expressions d'intérêt de candidats pour le président élu du comité de nomination 2016 (« NomCom »), a examiné les résultats d'une évaluation à 360 degrés du leadership du NomCom 2015 et effectué les entrevues des candidats.

      Attendu que, le BGC a recommandé que Stéphane VAN GELDER soit nommé Président du NomCom 2016 et Hans Petter Holen soit nommé président élu du NomCom 2016

      Résolu (2015.09.28.25), le Conseil d'administration nomme Stéphane VAN GELDER, président du comité de nomination pour 2016 et Hans Petter Holen président élu du comité de nomination 2016.

      Fondements de la résolution 2015.09.28.25

      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 l'Article VII, sections 2.1 et 2.2 sur Http://www.icann.org/en/general/bylaws.htm - VII. Le Conseil a délégué à son Comité de gouvernance la mission de recommander des candidats aux postes de président et de président élu du NomCom, ces recommandations devant être approuvées par le Conseil. Voir la charte BGC sur http://www.icann.org/en/committees/board-governance/charter.htm. Le BGC a publié un appel à manifestation d'intérêt (EOI) le 4 juin 2015 cherchant des EOI jusqu'au 30 juin 2015 (voir (Https://www.icann.org/news/announcement-2-2015-06-04-en). L'appel à manifestations d'intérêt a été prolongé par la suite jusqu'à 20 JUILLET 2015 (voirHttps://www.icann.org/news/announcement-2015-07-01-en). Le BGC a reçu et examiné plusieurs manifestations d'intérêt, a supervisé une évaluation à 360 degrés du leadership du NomCom 2015 et à conduit des entretiens avec des candidats avant de faire ses recommandations. Le Conseil a étudié et concorde avec la recommandation du BGC pour le président du NomCom 2016 et le Président élu du NomCom 2016. Le Conseil d'administration voudrait remercier tous ceux qui ont manifesté leur intérêt à participer au leadership du NomCom 2016.

      La désignation du président du NomCom et du président élu du NomCom, sélectionnés par un processus public d'EOI, a un effet positif sur la responsabilité et la transparence de l'ICANN, et soutient l'intérêt public. L'adoption de la recommandation du BGC n'a aucun impact financier sur l'ICANN qui n'ait été prévu, et n'aura pas d'impact négatif sur la sécurité, la stabilité et la résilience du système des noms de domaine.


1 Pour une définition des niveaux de consensus voir http://gnso.icann.org/en/council/annex-1-gnso-wg-guidelines-07apr11-en.pdf [PDF, 344 Ko] (p.8).

2 voir aussi 5.1.1 et l'outil de révision des commentaires publics (l'annexe B [du rapport final]).

3 De nombreuses personnes supposent que ce serait l'anglais US-ASCII si les arguments pour les autres scripts peuvent être convaincants.

4 Voir https://www.icann.org/news/announcement-3-2014-09-22-en

resolutions-28sep15-fr.pdf  [239 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."