Module 7 Procédures d’évaluation de chaîne et de candidature

La série 2026 du programme des nouveaux gTLD représente une évolution critique de l’infrastructure de l’Internet. Bien que l’enthousiasme pour de nouvelles extensions de noms de domaine potentielles soit élevé, le processus d’évaluation des chaînes et des candidatures est conçu pour préserver la stabilité du DNS tout en répondant aux préoccupations des parties prenantes. Chaque chaîne doit être méticuleusement analysée pour vérifier son unicité, sa clarté et les risques de confusion potentielle avec des chaînes ou marques existantes, afin de s’assurer qu’elle ne compromet pas l’intégrité globale du DNS.

Pour certains types spécifiques de candidatures, il est particulièrement critique d’évaluer l’implication du candidat auprès de la communauté, ainsi que son engagement envers la transparence et la responsabilité.

Le module 7 décrit le processus d’évaluation, notamment :

La présentation des types de candidatures et des méthodes de traitement.
L’examen des types de TLD, comme les noms géographiques et les noms de domaine internationalisés.
Les stratégies pour atténuer les collisions de noms.
L’évaluation de similarité de chaînes.

Ce module fournit un aperçu détaillé de ce processus essentiel et soigneusement conçu pour assurer la stabilité et la sécurité du DNS.

7.1 Types de chaînes et de candidatures

Les candidats peuvent rencontrer des exigences et des étapes de traitement différentes selon le type de candidature ou de chaîne pour lesquels ils se portent candidats. Ces variations peuvent affecter les aspects suivants :

Questions du dossier de candidature : certains types de candidatures exigeront que le candidat réponde à des questions spécialisées dans le cadre de sa candidature (par exemple, des questions liées aux objectifs communautaires du candidat).
Établissement des priorités : certains types de candidatures peuvent se voir accorder la priorité dans le tirage au sort effectué pour établir l’ordre dans lequel les candidatures seront traitées (par exemple, un IDN).¹
Évaluation : la nature, l’objet ou l’objectif d’une candidature peut nécessiter une évaluation spécialisée (par exemple, pour un nom géographique).
Conflit : les procédures de résolution de conflits peuvent être spécifiques en fonction du type de candidature (par exemple, pour l’évaluation de la priorité communautaire).
Contrat de registre : certains types de candidatures peuvent être considérés comme exemptés de certaines dispositions, tandis que d’autres peuvent être tenus d’inclure des dispositions spécialisées dans leurs contrats de registre de base (par exemple, dérogation au code de conduite).
Frais : des frais supplémentaires d’évaluation ou de candidature peuvent être exigés (par exemple, pour des évaluations conditionnelles comme l’évaluation de la priorité communautaire).

Les candidats doivent prendre connaissance des informations contenues dans cette section pour comprendre la possibilité d’exigences différentes pour les différents types de candidature.²

7.1.1 Candidatures générales

Une candidature est dite « générale » lorsqu’elle ne relève d’aucun des types spécifiques énumérés à la Section 7.1.2 Candidatures spécifiques et qu’elle est soumise à la série d’exigences standard énoncées dans le présent Guide de candidature.

7.1.2 Candidatures spécifiques

Les candidatures spécifiques sont celles qui peuvent être soumises à des exigences différentes en fonction de la candidature (par exemple, une candidature pour un gTLD communautaire), de la chaîne (par exemple, un IDN) ou du type de candidat (par exemple, une OIG ou un candidat au programme de soutien aux candidats). Cette section fournit un aperçu de ces types de candidatures spécialisées. Une candidature peut être admissible à plusieurs désignations simultanément ; par exemple, une candidature pourrait être classée à la fois comme IDN et comme candidature communautaire.

7.1.2.1 Candidatures à des gTLD communautaires

Au moment du dépôt de la candidature, un candidat peut désigner une chaîne faisant l’objet d’une candidature à un nouveau gTLD comme gTLD communautaire.³ Un tel candidat doit exploiter la chaîne au profit d’une communauté clairement délimitée (voir la Section 5.4 Évaluation de la priorité communautaire). Les candidats déposant une candidature communautaire sont soumis à des exigences supplémentaires tout au long des différentes étapes du cycle de vie de la candidature, notamment :

Questions du dossier de candidature : les candidats qui désignent leur candidature comme étant une candidature communautaire devront répondre à une série de questions spécifiques aux candidatures communautaires.⁴ Les réponses à ces questions seront évaluées si le candidat choisit de participer à la CPE. Voir l’Annexe 1 Questions du dossier de candidature (Questionnaire 7 des gTLD communautaires).
Évaluation : l’évaluation des politiques d’enregistrement communautaire (« politiques d’enregistrement communautaire ») – par le biais de l’évaluation des engagements du registre (RCE) – proposées pour être incluses dans le contrat de registre et concernant l’exploitation d’un gTLD communautaire faisant l’objet de la candidature aura lieu pendant l’évaluation de la candidature, sauf si le candidat communautaire choisit de participer à la CPE, qui est une option disponible uniquement pour la résolution de litiges entre candidatures communautaires. Si le candidat choisit de participer à la CPE, la RCE aura lieu plus tôt, avant l’évaluation de la candidature car cette évaluation doit avoir lieu avant que la candidature ne soit admissible à participer à la CPE. Voir la Section 7.8 Engagements d’intérêt public, engagements volontaires des opérateurs de registre et politiques d’enregistrement communautaire.
Conflit : en cas de conflit avec d’autres candidatures pour la même chaîne, le candidat peut choisir de participer à l’évaluation de la priorité communautaire (voir la Section 5.4) et potentiellement à une enchère de l’ICANN. Se reporter à la Section 5.2 Conflits de chaînes et procédures de résolution.
Passation de contrats : le candidat doit énumérer les politiques d’enregistrement communautaire qui sont évaluées et approuvées par l’ICANN et, le cas échéant, évaluées pendant la CPE, dans la spécification 12 de son contrat de registre de base. Se reporter à la Section 1.2.15 Passation de contrat. Voir aussi la Section 7.8.4 Politiques d’enregistrement communautaire ci-dessous concernant l’évaluation des politiques d’enregistrement communautaire.
Frais : si un candidat choisit de participer à la CPE, il doit payer des frais d’évaluation supplémentaires. Voir la Section 3.3 Frais et paiements.

L’ICANN évaluera toutes les politiques d’enregistrement communautaire proposées par les candidats aux gTLD communautaires pour inclusion dans le contrat de registre applicable lors de l’évaluation de la candidature. Au minimum, ces politiques doivent couvrir l’admissibilité des titulaires de nom de domaine et la sélection des noms. L’évaluation des politiques d’enregistrement communautaire s’aligne sur l’approche de l’ICANN pour évaluer tous les engagements supplémentaires proposés par les candidats en utilisant un cadre uniforme. Pour de plus amples renseignements sur ce cadre, voir la Section 7.8 Engagements d’intérêt public, engagements volontaires de l’opérateur de registre et politiques d’enregistrement communautaire.

Pour être prises en compte lors de la CPE, les politiques d’enregistrement communautaires proposées pour être incluses dans le contrat de registre doivent être évaluées au préalable dans le cadre de l’évaluation des engagements de l’opérateur de registre (RCE). Cette étape garantit que l’ICANN et le candidat s’accordent sur les engagements à inclure dans le contrat de registre applicable. Si de tels engagements ne peuvent pas être convenus, ils ne seront pas pris en considération lors de la CPE.

Tout candidat désignant sa candidature comme étant une candidature communautaire sera tenu, si celle-ci est approuvée, d’inclure les politiques d’enregistrement communautaire convenues avec l’ICANN lors de l’évaluation de la candidature dans la spécification 12 du contrat de registre de base applicable. Cette exigence s’applique même s’il n’y a pas de candidats en lice ou si un candidat ayant une candidature communautaire choisit de ne pas participer à la CPE pour résoudre un conflit. En résumé, l’approbation des politiques d’enregistrement communautaire est requise non seulement pour qu’une candidature communautaire puisse participer à une CPE, mais aussi pour poursuivre le processus de candidature après la RCE. Si aucune politique d’enregistrement communautaire ne peut être validée par l’ICANN pour être incluse dans le contrat de registre, la candidature communautaire ne pourra poursuivre — que la candidature soit ou non en conflit avec une autre ou que le candidat choisisse ou non de participer à la CPE⁵.

Voir la Section 5.4 Évaluation de la priorité communautaire pour plus de renseignements sur l’évaluation de la priorité communautaire et la Section 7.8 Engagements d’intérêt public, engagements volontaires des opérateurs de registre et politiques d’enregistrement communautaire.⁶

Il y aura également des frais associés au processus d’évaluation des engagements de l’opérateur de registre (RCE) de la Spécification 12 (voir la Section 3.3 Frais et paiements).

7.1.2.2 Candidatures à des noms géographiques

Un candidat peut qualifier sa candidature de « nom géographique »⁷. Il incombe au candidat de déterminer si la chaîne faisant l’objet de sa candidature à un nouveau gTLD appartient à l’une des catégories de noms géographiques déjà définies (voir la Section 7.5 Noms géographiques), de mener des consultations auprès des gouvernements ou les des autorités publiques concernés et de déterminer le niveau de soutien gouvernemental requis.

En outre, lors de l’évaluation initiale des chaînes, l’ICANN procède systématiquement à une vérification qui vise à déterminer si une chaîne faisant l’objet d’une candidature constitue un nom géographique, comme décrit plus loin dans la présente section. Si un candidat ne désigne pas lui-même sa candidature comme portant sur un nom géographique et que par la suite, c’est l’ICANN qui le fait, la candidature restera soumise aux exigences supplémentaires relatives aux noms géographiques. Des exigences différentes peuvent s’appliquer aux candidats dans les domaines suivants du cycle de vie de la candidature :

Questions du dossier de candidature : des questions supplémentaires seront posées au candidat concernant le nom géographique sur lequel porte sa candidature. Voir l’Annexe 1 Questions du dossier de candidature.
Évaluation : le candidat à un nom géographique doit présenter des documents de soutien ou de non-objection de l’entité gouvernementale concernée. Un panel de noms géographiques (GNP) déterminera si la chaîne gTLD faisant l’objet d’une candidature représente un nom géographique et vérifiera la pertinence et l’authenticité des documents de soutien, le cas échéant. Voir la Section 7.5.3.2 Examen des noms géographiques.
Frais : des frais conditionnels sont associés à l’examen des noms géographiques (Section 7.5.3.2). Voir la Section 3.3 Frais et paiements.

7.1.2.3 Candidatures à des noms réservés

Toutes les chaînes faisant l’objet d’une candidature à un nouveau gTLD sont comparées aux listes de noms réservés et bloqués. Bien que les noms bloqués ne puissent pas faire l’objet d’une candidature, les entités éligibles peuvent se porter candidates à un nom réservé comme défini dans la Section 7.2 Noms bloqués et réservés.⁸ Pour demander un nom réservé, le candidat doit suivre la procédure décrite à la Section 7.2.2.2.1, Procédure d’exception concernant la candidature à un nom réservé. Les candidats qui déposent une candidature à un nom réservé peuvent s’attendre à trouver des exigences différentes dans les domaines suivants du cycle de vie de la candidature :

Questions du dossier de candidature : le candidat devra répondre à des questions supplémentaires concernant le nom réservé pour lequel il dépose sa candidature. Voir l’Annexe 1 Questions du dossier de candidature.
Évaluation : le candidat à un nom réservé doit soumettre des documents, y compris l’acte constitutif de la société et une lettre de l’organisation mère, ainsi que des documents de soutien ou de non-objection, qui peuvent inclure une lettre signée, le cas échéant. Voir la Section 7.2.2 Noms réservés.

7.1.2.4 Candidatures à des TLD de marque

Un candidat a la possibilité de désigner lui-même sa candidature en tant que TLD de marque. Ce type de candidature permet à un candidat d’utiliser son nom de société ou de marque comme TLD.⁹ Un TLD de marque est une chaîne identique aux éléments textuels (par exemple, un nom, un mot ou une phrase) d’une marque déposée valide en vertu de la loi applicable,¹⁰ et que le candidat exploite en tant que TLD de marque.¹¹ Les candidats soumettant des candidatures à un TLD de marque doivent anticiper des exigences différentes dans les domaines suivants du cycle de vie de la candidature :

Questions du dossier de candidature : des questions supplémentaires seront posées au candidat sur sa candidature si celle-ci concerne un TLD de marque (par exemple, sa marque/marque déposée). Voir l’Annexe 1 Questions du dossier de candidature.
Évaluation : les candidatures à des TLD de marque sont examinées afin de déterminer leur éligibilité à l’obtention du statut de TLD de marque.¹² Se reporter à la Section 7.3 Évaluation d’admissibilité au statut de TLD de marque.
Conflit : en cas de conflit avec d’autres candidatures pour la même chaîne, un candidat à un TLD de marque peut avoir la possibilité de demander à changer la chaîne faisant l’objet de sa candidature afin de résoudre le conflit. Se reporter à la Section 5.2 Conflit de chaînes et procédures de résolution ¹³.
Passation de contrats : si le candidat est éligible, la spécification 13 sera incluse dans le contrat de registre de base qui sera signé¹⁴. Se reporter à la Section 1.2.15 Passation de contrat.
Frais : des frais conditionnels sont associés à l’évaluation d’éligibilité au TLD de marque. Voir la Section 3.3 Frais et paiements.

Si un candidat à un TLD de marque remplit les conditions requises pour ce type de TLD, la spécification 13 sera incluse dans son contrat de registre applicable et une dérogation au code de conduite lui sera accordée. Cependant, dans certains cas, un candidat à un TLD de marque peut obtenir une dérogation au CoC mais ne pas être éligible à la spécification 13.

7.1.2.5 Candidatures à des noms de domaine internationalisés

Les candidats auront la possibilité de présenter une candidature pour des IDN. Les candidatures à des IDN doivent être conformes aux exigences définies à la Section 3.1.9 Noms de domaine internationalisés, et les candidats peuvent s’attendre à trouver des exigences différentes dans les domaines suivants du cycle de vie de la candidature :

Établissement des priorités : sous réserve des limites et des exigences identifiées à la Section 3.7 Ordre de traitement des candidatures et tirage au sort pour l’établissement des priorités de traitement, les candidatures à des IDN peuvent bénéficier d’un traitement prioritaire par rapport aux candidatures à des non-IDN.

7.1.2.6 Candidatures à des variantes de gTLD existants

Les opérateurs de registre existants auront la possibilité de demander des variantes de chaînes allouables de gTLD existants.¹⁵ Les candidatures à ces variantes de chaînes doivent être conformes aux exigences définies à la Section 3.1.9 Noms de domaine internationalisés, et des exigences différentes peuvent s’appliquer aux candidats dans les domaines suivants du cycle de vie de la candidature :

Questions du dossier de candidature : des questions supplémentaires concernant la variante de chaîne pour laquelle il présente sa candidature seront posées au candidat. Voir l’Annexe 1 Questions du dossier de candidature.
Établissement de priorités : sous réserve des limites et des exigences identifiées à la Section 3.7 Ordre de traitement des candidatures et tirage pour l’établissement des priorités de traitement, les candidatures à des variantes de chaînes allouables peuvent bénéficier d’un traitement prioritaire par rapport aux candidatures à des non-IDN.
Évaluation : un candidat à une variante allouable d’un gTLD existant sera soumis à révision par un panel et devra fournir une justification de la nécessité de la variante (par exemple, expliquer comment les chaînes principales et leur variante sont considérées identiques).¹⁶ Les exigences supplémentaires peuvent inclure l’utilisation du même RSP pour le registre de variante et le registre principal. Voir l’Annexe 1 Questions du dossier de candidature et la Section 7.10 Évaluation de la similarité des chaînes.
Passation de contrats : la spécification 14 sera ajoutée au contrat de registre de base pour exécution. Se reporter à la Section 1.2.15 Passation de contrat.
Frais : les opérateurs de registre existants qui souhaitent obtenir des variantes de chaînes allouables de gTLD existants bénéficient d’une exemption des frais de candidature de base pour un maximum de quatre variantes de chaînes¹⁷ ; les candidatures à plus de quatre variantes de chaînes entraîneront des frais supplémentaires. Voir la Section 3.3 Frais et paiements.¹⁸

7.1.2.7 Candidatures à de nouveaux IDN comprenant une ou plusieurs variantes

Les candidats auront la possibilité de postuler pour un nouveau TLD IDN plus ses variantes de chaînes allouables. Les candidatures à un nouveau TLD IDN et ses variantes de chaînes allouables doivent être conformes aux exigences définies dans la Section 3.1.9 Noms de domaine internationalisés, et des exigences différentes peuvent s’appliquer aux candidats dans les domaines suivants du cycle de vie de la candidature :

Questions du dossier de candidature : des questions supplémentaires seront posées au candidat sur les TLD IDN et ses variantes de chaînes allouables faisant l’objet de sa candidature. Voir l’Annexe 1 Questions du dossier de candidature.
Établissement de priorités : sous réserve des limites et des exigences identifiées à la Section 3.7 Ordre de traitement des candidatures et tirage au sort pour l’établissement des priorités de traitement, les candidatures à des TLD IDN, y compris les variantes de chaînes allouables, peuvent bénéficier d’un traitement prioritaires par rapport à des non-IDN.
Évaluation : un candidat à un nouveau TLD IDN et à ses variantes de chaînes sera soumis à une révision par un panel et devra justifier dans sa candidature la nécessité de la variante (par exemple, en expliquant comment les chaînes principales et les variantes de chaînes sont considérées identiques)¹⁹. Des exigences supplémentaires peuvent s’appliquer, par exemple l’utilisation du même RSP pour le registre de variante que pour le registre principal, ainsi que la garantie que les types de TLD sont cohérents dans la chaîne principale et les variantes de chaîne. Voir la Section 7.10 Évaluation de la similarité de chaînes.
Passation de contrats : la spécification 14 sera ajoutée au contrat de registre de base pour exécution. Se reporter à la Section 1.2.15 Passation de contrat.
Frais : les nouveaux candidats à une chaîne principale et ses variantes de chaînes n’encourront pas de frais de candidature supplémentaires au-delà des frais de base pour un maximum de quatre variantes de chaînes. En revanche, les candidatures à une chaîne principale et quatre variantes de chaînes entraîneront des frais supplémentaires. Voir la Section 3.3 Frais et paiements.²⁰

7.1.2.8 Candidatures émanant d’organisations intergouvernementales ou d’entités gouvernementales

Une candidature émanant d’organisations intergouvernementales (OIG)²¹ ou d’entités gouvernementales²² sera acceptée. Les candidats de cette catégorie doivent tenir compte des exigences relatives aux noms géographiques définies à la Section 7.5 Noms géographiques, ainsi que des exigences relatives aux noms réservés spécifiées à la Section 7.2 Noms bloqués et réservés. Ces candidats peuvent s’attendre à trouver des exigences différentes dans les domaines suivants du cycle de vie de la candidature :

Questions du dossier de candidature : des questions supplémentaires peuvent être posées à ces entités concernant la manière spécifique dont elles sont organisées. Voir l’Annexe 1 Questions du dossier de candidature.
Évaluation : toute entité de ce type sera tenue de fournir des documents pour vérifier son statut d’organisation intergouvernementale ou gouvernementale, le cas échéant. Voir la Section 7.5.3.2 Examen des noms géographiques et la Section 7.2.2.2, Identification des noms réservés.

7.1.2.9 Candidatures des candidats éligibles au soutien aux candidats

Avant l’ouverture de la série actuelle, les candidats potentiels avaient l’occasion de postuler pour participer au programme de soutien aux candidats. Les candidats qui se sont portés candidats ont été évalués en fonction des critères énoncés dans le Manuel du programme de soutien aux candidats. Une candidature au soutien aux candidats est différente d’une candidature à un nouveau gTLD. Les candidats qui reçoivent ce soutien doivent également répondre aux exigences et critères d’éligibilité pour une candidature à un nouveau gTLD, comme cela est défini dans le présent Guide de candidature.

Les candidats éligibles au soutien aux candidats peuvent s’attendre à trouver des exigences différentes dans les domaines suivants du cycle de vie de la candidature :

Conflit : les candidats au programme de soutien aux candidats qui participent à une enchère de l’ICANN recevront un crédit d’offre. Voir la Section 5.6.5 Crédit d’enchère pour les candidats bénéficiant du Programme de soutien.
Passation de contrats : si un candidat bénéficiaire du programme de soutien prévaut dans une enchère, il lui sera interdit de céder le contrat de registre ou de procéder à un changement de contrôle pendant au moins trois ans. Se reporter à la Section 1.2.15 Passation de contrat.
Frais : un candidat bénéficiaire du programme de soutien sera éligible à des frais de candidature réduits ainsi qu’à des frais d’évaluation conditionnelle réduits. Voir la Section 3.3 Frais et paiements ainsi que le Manuel du programme de soutien aux candidats pour de plus amples renseignements.²³

7.1.3 Modification des types de candidatures

Dans certains cas, un candidat peut souhaiter modifier son type de candidature. Cela peut être autorisé ou non, selon le type de candidature. Par exemple, un candidat ne sera pas autorisé à modifier une désignation de gTLD communautaire. Se reporter à la Section 3.8 Demande de modification de dossier de candidature pour de plus amples informations sur les modifications de candidature ou de chaîne autorisées.

7.2 Aperçu des noms bloqués et réservés

Certains noms sont bloqués et ne peuvent donc pas être utilisés comme chaînes gTLD. L’élaboration de la liste des noms bloqués repose sur diverses sources et contributions, détaillées ci-après. D’autres noms sont réservés au premier niveau sur la base d’une politique de consensus et maintenus sur une liste par l’ICANN.²⁴

Remarque : la liste intitulée « chaînes non éligibles à la délégation » du Guide de candidature de la série 2012 est maintenant appelée Liste de noms réservés, et la liste précédemment dénommée « Liste de noms de premier niveau réservés » est désormais connue sous le nom de Liste de noms bloqués.

Dans le cadre de la Section 3.1.8 Validation des chaînes préalables au dépôt, toutes les chaînes gTLD faisant l’objet d’une candidature et leurs variantes de chaînes sont comparées aux listes de noms réservés et bloqués. Cette comparaison garantit que la chaîne faisant l’objet d’une candidature à un nouveau gTLD n’apparaît pas dans l’une ou l’autre liste. Les candidats auront la possibilité d’interroger le système TAMS en y saisissant une chaîne proposée afin de vérifier sa présence éventuelle sur les listes des noms bloqués ou réservés.

En outre, les noms bloqués et réservés qui ne sont pas conformes au cadre des caractères DNS autorisés seront convertis en étiquettes DNS qui ne contiennent que des lettres, des chiffres et des traits d’union conformément à la politique de consensus.²⁵

7.2.1 Noms bloqués

Les chaînes gTLD et leurs variantes allouables sur la liste des noms bloqués ne sont pas éligibles pour une candidature dans la série actuelle ou dans toute série de dépôt de candidatures future, conformément à la politique de consensus. Cependant, la liste ne s’applique pas aux gTLD qui ont déjà été délégués dans la zone racine.

Les chaînes gTLD suivantes et leurs variantes de chaînes allouables figurent sur la liste des noms bloqués (voir les notes en bas de page pour les listes réelles) et ne peuvent pas faire l’objet d’une candidature :

Noms de domaine à usage spécial : il s’agit de chaînes spécifiques réservées par les normes techniques à des fins incompatibles avec la délégation, comme indiqué explicitement dans le registre des noms de domaine à usage spécial de l’IANA.²⁶^,²⁷^,²⁸
Normes techniques : pour de plus amples détails, voir la Section 3.1.8.3 Examen de la stabilité du DNS.
Noms de pays ou de territoires liés à des noms géographiques : voir la Section 7.5 Noms géographiques.

Entités liées à l’ICANN, à l’IANA et à l’IETF et infrastructure Internet : cette catégorie englobe notamment les Organisations de soutien (SO) et les Comités consultatifs (AC) de l’ICANN,²⁹ les Registres Internet régionaux,³⁰ les organes de l’IETF et³¹ des identificateurs de système intégrés par le biais de politiques de consensus.³²^,³³

Tableau 7-1 Entités liées à l’ICANN, à l’IANA et à l’IETF et infrastructure Internet

Entités liées à l’ICANN, à l’IANA et à l’IETF et infrastructure Internet
AFRINIC	GNSO	INTERNIC	NRO	TLD
ALAC	GTLDSERVERS	INTERNAL	PTI	WHOIS
APNIC	IAB	IETF	RFCEDITOR	WWW
ARIN	IANA	IRTF	RIPE
ASO	IANASERVERS	ISTF	ROOTSERVERS
ccNSO	ICANN	LACNIC	RSSAC
GAC	IESG	NIC	SSAC
Remarque : les chaînes de la liste sont bloquées uniquement sous la forme présentée ci-dessus.

Autres chaînes non autorisées :
- TLD délégués ; ³⁴
- chaînes gTLD ayant fait l’objet d’une candidature lors d’une série précédente et dont le traitement est en cours ;³⁵
- ccTLD existants ayant réussi l’évaluation ;
- chaînes actuellement sollicitées en tant que ccTLD IDN ;
- toute autre chaîne ASCII à un ou deux caractères.

7.2.1.1 Identification des noms bloqués

Lorsque le candidat saisit le nom de la chaîne faisant l’objet de sa candidature, le système vérifie automatiquement si cette chaîne et ses variantes apparaissent sur la liste des noms bloqués. Si la chaîne y figure, le système empêchera le candidat de poursuivre. Pour continuer, le candidat devra modifier sa saisie et opter pour une autre chaîne, non bloquée.

7.2.1.1.1 Contestation de l’identification des noms bloqués

Lorsqu’un candidat estime être empêché de soumettre sa candidature, ou être tenu de fournir des pièces justificatives supplémentaires, parce qu’une erreur du processus automatisé d’identification des noms bloqués a conduit à classer à tort sa chaîne parmi les noms bloqués et l’a empêché de poursuivre sa candidature, il a la possibilité de déposer une contestation. Celle-ci doit être déposée au plus tard 14 jours avant la clôture de la période de dépôt des candidatures³⁶ (voir la Section 1.2.14.2 Contestation d’évaluation et la Section 3.1.8.4 Contestation de la validation des chaînes préalable au dépôt).

7.2.2 Noms réservés

Le processus d’évaluation des noms réservés comporte deux parties : l’identification des noms réservés, une vérification automatisée qui identifie si une chaîne de noms faisant l’objet de la candidature apparaît dans la liste des noms réservés, et l’examen des noms réservés, qui comprend à la fois la procédure d’exception permettant de déposer une candidature à un nom international limité d’une OIG-OING et la vérification de la documentation requise.³⁷

Les chaînes des OIG-OING internationales limitées suivantes figurent sur la liste des noms réservés et ne peuvent faire l’objet d’une candidature par le biais d’une procédure d’exception que par l’entité concernée, à condition qu’elle fournisse la documentation appropriée comme indiqué à la Section 7.2.2.2 Identification des noms réservés ci-dessous :

Les noms ajoutés sur la base des recommandations du groupe de travail du PDP relatif aux OIG-OING³⁸ concernant la protection des identificateurs des OIG-OING dans tous les gTLD,³⁹ ⁴⁰ y compris leurs variantes de chaînes allouables, sont éligibles à la délégation après vérification. Il s’agit notamment du nom de la Croix-Rouge et le Croissant-Rouge (CRCR)⁴¹, du Comité international olympique (CIO)⁴², des noms d’organisations internationales gouvernementales (OIG)⁴³ et des noms d’organisations internationales non gouvernementales (OING).⁴⁴

7.2.2.2 Identification des noms réservés

Lorsque le candidat saisit le nom de la chaîne faisant l’objet de sa candidature, le système vérifie automatiquement si cette chaîne, ainsi que ses variantes allouables, apparaissent dans la liste de noms réservés. Si la chaîne y figure, la procédure d’exception est alors enclenchée : le candidat est invité à téléverser les documents justifiant qu’il est bien l’entité pour laquelle le nom est réservé.

En plus de ce contrôle, le système vérifiera également si la chaîne est une variante d’un nom réservé. Dans de tels cas, le candidat ne pourra poursuivre que si le nom réservé lui-même fait l’objet de la candidature comme chaîne principale, ou si le candidat confirme qu’il est l’opérateur de registre du TLD correspondant au nom réservé.

7.2.2.2.1 Contestation de l’identification des noms réservés

Si un candidat estime qu’une erreur du système dans le processus automatisé d’identification des noms réservés a entraîné une classification incorrecte de sa chaîne comme nom réservé, il peut lancer un mécanisme de contestation de l’évaluation. La contestation doit être déposée au plus tard sept jours avant la fin de la période de dépôt de candidatures.

L’ICANN examinera la contestation de l’évaluation. Si l’ICANN détermine qu’une erreur du système a conduit à la classification incorrecte de la chaîne en tant que nom réservé, l’erreur du système sera corrigée, ce qui permettra à la candidature de passer à l’étape suivante du processus. Si aucune erreur n’est trouvée, la candidature se poursuit mais elle doit répondre aux critères de nom réservé lors de l’étape d’examen des noms réservés. Il n’y a pas de frais conditionnels associés à une contestation de l’évaluation liée aux noms réservés. Il incombe aux candidats de s’assurer de respecter toutes les exigences relatives aux noms réservés, même en cas d’erreur du système.

7.2.2.3 Examen des noms réservés

7.2.2.3.1 Procédure d’exception pour demander des noms réservés

Les candidats peuvent demander une chaîne dans la liste des noms réservés par le biais du processus d’exception. Au cours de l’examen des noms réservés, le panel évalue l’exception et vérifie les documents justificatifs du candidat pour confirmer qu’il est l’entité admissible pour exploiter le nom réservé. Se reporter à la Section 7.2.2 Noms réservés pour connaître les chaînes spécifiques incluses dans la liste de noms réservés.

Pour postuler à un nom réservé par le biais du processus d’exception, les candidats doivent soumettre les types de documents suivants au moment du dépôt de la candidature :

l’acte constitutif et, s’il y a lieu, une lettre de l’organisation mère ;
les documents de soutien ou de non-objection, y compris une lettre signée émise par l’autorité publique compétente (le cas échéant).

7.2.2.3.1.1 Vérification de la documentation présentée

Si un candidat de l’une des OIG-OING internationales limitées énumérées ci-dessus utilise le processus d’exception pour se porter candidat à un nom de la liste des noms réservés, y compris ses variantes de chaînes allouables, un processus de vérification sera mis en place. Ce processus confirmera que le candidat a fourni les documents nécessaires pour prouver qu’il peut postuler à ce TLD en particulier. Le processus de vérification de l’organisation ou de l’entité qui présente sa candidature se déroulera dans le cadre de l’étape d’évaluation de la candidature.

L’ICANN peut consulter les autorités compétentes pour une vérification plus approfondie.

Le cas échéant, pour plus de renseignements sur le gouvernement ou l’autorité publique compétents pour donner suite à sa demande, le candidat peut consulter le représentant concerné auprès du Comité consultatif gouvernemental (GAC).⁴⁵

7.2.2.3.2 Évaluation approfondie pour l’examen des noms réservés

Tout candidat qui ne fournit pas les documents adéquats attestant de son éligibilité à déposer une candidature à un TLD inscrit sur la liste des noms réservés verra sa candidature rejetée lors de l’examen des noms réservés.

Toutefois, s’il est déterminé qu’une candidature ne répond pas aux critères établis pour l’examen des noms réservés, le candidat peut demander une évaluation approfondie. Au cours de l’évaluation approfondie, des questions de clarification peuvent être posées pour obtenir des renseignements supplémentaires. Pour assurer un traitement rapide, les candidats seront encouragés à répondre dès que possible, mais au plus tard 21 jours après avoir reçu les questions de clarification. Si les renseignements supplémentaires fournis ne satisfont pas aux critères des noms réservés, la candidature ne passera pas la révision et ne sera pas retenue.

7.3 Évaluation d’admissibilité au statut de TLD de marque

Les candidats auront la possibilité de désigner eux-mêmes une candidature en tant que TLD de marque. Ce type de candidature permet à une entreprise ou à une société d’utiliser son nom de société ou de marque comme TLD. Voir la Section 3.1.6 Types de candidatures et de chaînes.

7.3.1 Éligibilité à l’évaluation d’admissibilité au statut de TLD de marque

Un candidat qui cherche à désigner sa chaîne faisant l’objet d’une candidature comme un TLD de marque doit se soumettre à l’évaluation de l’admissibilité au statut de TLD de marque. L’objectif de cette évaluation est de confirmer que le candidat remplit les critères pour accéder à la désignation de TLD de marque. Les candidatures qui réussissent l’évaluation de l’admissibilité au statut de TLD de la marque verront la spécification 13 ajoutée au contrat de registre de base applicable si la candidature aboutit à la délégation. Voir les conditions de la spécification 13 dans l’Annexe 4 Contrat de registre de base ⁴⁶.

Un candidat peut demander l’évaluation d’admissibilité au statut de TLD de marque dans sa candidature ou par le biais d’une demande de modification de dossier de candidature. Voir la Section 3.8 Demande de modification de dossier de candidature.

7.3.2 Frais conditionnels pour l’évaluation d’admissibilité au statut de TLD de marque

Un candidat qui demande l’évaluation de l’admissibilité au statut de TLD de marque doit payer des frais d’évaluation supplémentaires, comme spécifié dans la Section 3.3 Frais et paiements. L’évaluation de l’admissibilité au statut de TLD de marque ne sera pas effectuée tant que l’ICANN n’aura pas reçu les frais correspondants.

7.3.3 Évaluation et résultats de l’évaluation d’admissibilité au statut de TLD de marque

Pour être admissible au statut de TLD de marque, un candidat doit fournir un ou plusieurs fichiers SMD (Signed Mark Data) du Centre d’échange d’information sur les marques (TMCH). Consulter les lignes directrices du TMCH pour connaître les critères d’admissibilité.⁴⁷

7.3.3.1 Interaction avec le Centre d’échange d’information sur les marques avant de soumettre une candidature à un TLD de marque

Un candidat qui envisage de désigner la chaîne faisant l’objet de sa candidature comme étant un TLD de marque doit prendre des mesures préparatoires bien avant le lancement de la candidature pour s’assurer qu’il peut démontrer son éligibilité lors du dépôt de sa candidature.

Les candidatures à des TLD de marque doivent inclure un ou plusieurs fichiers SMD (Signed Mark Data) du Centre d’échange d’information sur les marques (TMCH) à l’appui de la désignation de marque. Étant donné que l’ajout ou l’ajustement des fichiers déposés au TMCH peut prendre plusieurs mois et peut impliquer des frais payés directement au TMCH, les candidats à un TLD de marque doivent examiner attentivement leurs fichiers SMD TMCH existants ou acquérir de nouveaux fichiers SMD dès que possible. Les candidats à un TLD de marque doivent suivre les étapes suivantes en ce qui concerne le TMCH (le cas échéant) avant de demander un TLD de marque :

un candidat à un TLD de marque sans relation avec le TMCH ou sans fichiers SMD couvrant les chaînes pour lesquelles il souhaite postuler doit initier la vérification du TMCH⁴⁸ ;
s’assurer que toutes les étiquettes TLD souhaitées sont répertoriées dans les éléments <mark:label> dans les fichiers SMD. Toute chaîne pour laquelle un candidat à un TLD de marque souhaite postuler doit correspondre exactement à un élément <mark:label> dans un SMD valide daté avant le dépôt de la candidature ;
s’assurer que toutes les étiquettes de variante souhaitées de la chaîne de marque principale sont répertoriées dans les éléments <mark:label> des fichiers SMD. Toutes les variantes de chaînes d’un TLD de marque faisant l’objet d’une candidature doivent correspondre exactement à un élément <mark:label> dans un SMD valide daté avant le dépôt de la candidature ;
s’assurer que les éléments <mark:goodsAndServices> sont corrects, complets et incluent un mot que le candidat pourrait utiliser en cas de changement de chaîne de TLD de marque, conformément à la Section 5.3 Demandes de changement de chaîne de TLD de marque). Les mots supplémentaires utilisés pour augmenter la chaîne de marque faisant l’objet d’une candidature doivent apparaître dans un élément <mark:goodsAndServices> d’un fichier SMD valide daté avant la soumission d’une demande de modification de chaîne de marque.

Si les mots utilisés pour augmenter la chaîne demandée n’apparaissent pas dans un fichier SMD, il est tout de même possible de soumettre une demande de changement de chaîne de TLD de marque à l’aide d’une autre documentation. Voir la Section 5.3.2 .Exigences relatives aux demandes de changement de chaîne de TLD de marque.

7.3.3.2 Critères d’évaluation de l’admissibilité au statut de TLD de marque

L’évaluation de l’admissibilité au statut de TLD de marque sera effectuée par un panel chargé de mener à bien cette évaluation. Un candidat qui cherche à obtenir la désignation de TLD de marque doit démontrer que la candidature répond aux critères suivants :

1a. La chaîne faisant l’objet d’une candidature à un gTLD doit correspondre exactement aux éléments textuels d’une marque déposée vérifiée par le TMCH dans les fichiers SMD fournis ; ou

1b. Si le candidat a modifié la chaîne qui fait l’objet de sa candidature à l’aide d’une demande de changement de chaîne de TLD de marque (section 5.3), la chaîne finale doit satisfaire à toutes les exigences qui y sont énoncées.

2. Le candidat et la chaîne finale (y compris toutes les variantes de chaînes allouables) doivent satisfaire à toutes les exigences énoncées dans la spécification 13 du contrat de registre de base. Voir l’Annexe 4 Contrat de registre de base.

Le candidat devra, dans sa candidature, faire une auto-certification confirmant sa conformité aux critères énoncés ci-dessus et à la Spécification 13 du contrat de registre de base (voir l’Annexe 4 Contrat registre de base). De plus, le candidat doit confirmer une utilisation non générique dans sa candidature. Voir le Questionnaire 13 concernant les TLD de marque et les dérogations au code de conduite à l’Annexe 1 Questions du dossier de candidature.

7.3.3.3 Questions de clarification au cours de l’évaluation d’admissibilité au statut de TLD de marque

L’ICANN peut poser des questions de clarification lors de l’évaluation de l’éligibilité des TLD de marque. Les candidats disposeront de sept jours pour répondre aux questions administratives de clarification et de 21 jours pour répondre aux questions de clarification de fond. Si le candidat ne répond pas dans ce délai défini, il peut perdre la possibilité de régler les problèmes constatés par le panel d’évaluation.

7.3.3.4 Résultats de l’évaluation d’admissibilité au statut de TLD de marque

Les résultats de l’évaluation de l’admissibilité au statut de TLD de marque seront inclus dans les rapports d’évaluation de la candidature et du candidat, comme décrit à la Section 1.2.13 Publication des rapports d’évaluation de la candidature et du candidat.

Si une candidature réussit l’évaluation d’admissibilité au statut de TLD de marque, la spécification 13 sera ajoutée au contrat de registre de base applicable au moment où la candidature aboutit à la délégation.

Si l’évaluation d’admissibilité au statut de TLD de marque aboutit à des résultats négatifs, le candidat peut choisir de poursuivre sa candidature sans la désignation de TLD de marque, c’est-à-dire sans l’ajout de la spécification 13.

Si la demande d’un TLD de marque a lieu en dehors de la période de dépôt de candidatures, par le biais d’une demande de modification de dossier de candidature, ou si un candidat souhaite retirer sa demande de désignation de TLD de marque, une période de commentaires sera ouverte pendant 30 jours.

7.3.4 Contestations et évaluation approfondie pour l’évaluation d’admissibilité au statut de TLD de marque

Les candidats auront la possibilité de soumettre les documents requis une deuxième fois si la présentation initiale de ces documents s’avère non conforme. Pour cette raison, une évaluation approfondie ou un mécanisme de contestation ne sont pas applicables à cette évaluation.

7.3.5 Conflit de chaînes et changement de chaînes

Un candidat qui réussit l’évaluation de l’admissibilité au statut de TLD de marque peut être autorisé à modifier sa chaîne principale pour éviter les conflits de chaîne. Se reporter à la Section 5.3 Demandes de changement de chaîne de TLD de marque pour de plus amples informations sur les procédures d’une demande de changement de chaîne de TLD de marque.

7.4 Évaluation d’éligibilité à une exemption au Code de conduite de l’opérateur de registre

La spécification 9 du contrat de registre de base contient le code de conduite de l’opérateur de registre. L’objectif du code de conduite est de protéger les titulaires d’un gTLD. Dans certains cas, une dérogation au code de conduite peut être demandée.

7.4.1 Admissibilité à l’évaluation d’exemption au Code de conduite

Si un opérateur de registre enregistre tous les noms de domaine dans le gTLD pour être utilisés exclusivement et uniquement par lui-même ou ses affiliés, (comme défini dans l’Annexe 4 Contrat de registre de base) et que l’opérateur de registre souhaite renoncer à la protection pour lui-même et ses affiliés, l’ICANN peut accorder à l’opérateur de registre une dérogation au code de conduite, à condition que le gTLD ne soit pas une chaîne générique (voir la Section 3.1.7 Génériques fermés) et que l’opérateur de registre puisse satisfaire à tous les critères de dérogation. Voir le texte de la spécification 9 dans l’Annexe 4 Contrat de registre de base .

Un candidat est autorisé à demander une exemption au code de conduite dans sa candidature ou, après le dépôt de la candidature, à l’aide d’une demande de changement de candidature. La demande dérogation au code de conduite est ouverte au public pour révision et commentaires au cours de la période de commentaires sur les candidatures (voir la Section 4.1.3 Prise en compte des commentaires sur les candidatures dans le processus d’évaluation).

7.4.2 Évaluation de l’exemption au code de conduite pour les variantes de chaînes

Si un candidat demande une ou plusieurs variantes de chaînes allouables d’une chaîne de gTLD principale faisant l’objet d’une candidature et demande une dérogation au code de conduite, l’évaluation de la dérogation au code de conduite couvrira à la fois les chaînes principales et les variantes de chaînes faisant l’objet la candidature.

7.4.3 Frais conditionnels pour l’évaluation de l’exemption au code de conduite

Les candidats qui demandent l’évaluation d’exemption au code de conduite doivent payer des frais supplémentaires, comme précisé à la Section 3.3 Frais et paiements. L’évaluation de l’exemption au code de conduite ne sera pas effectuée tant que les frais correspondants n’auront pas été reçus par l’ICANN.

7.4.4 Critères d’évaluation des exemptions au code de conduite

L’évaluation des exemptions au code de conduite sera effectuée par le panel d’évaluation des exemptions au code de conduite. La décision de savoir si l’ICANN accordera une exemption au code de conduite repose sur un examen des affirmations dans la demande d’exemption pour vérifier que si le candidat devient un opérateur de registre, il satisfera aux trois critères d’exemption :

tous les enregistrements de noms de domaine dans le gTLD et la ou les variante(s) de chaîne(s), le cas échéant, seront enregistrés auprès de, et maintenus par, l’opérateur de registre pour l’usage exclusif de l’opérateur de registre ou de ses affiliés (comme défini dans le contrat de registre de base) ;
l’opérateur de registre s’interdit de vendre, de distribuer ou de transférer le contrôle ou l’usage de tout enregistrement dans le gTLD et la ou les variante(s) de chaîne(s), le cas échéant, à un tiers non affilié à l’opérateur de registre ; et
l’application du code de conduite au gTLD et à la ou aux variante(s) de chaîne(s), le cas échéant, n’est pas nécessaire pour protéger l’intérêt public.

Un candidat qui demande une exemption au code de conduite devra présenter une auto-certification pour confirmer sa conformité aux critères énoncés ci-dessus. De plus, les énoncés de mission et d’objectif doivent démontrer une utilisation non générique. Afin de s’assurer que l’approbation d’une exemption au code de conduite n’entrera pas en conflit avec la spécification 11 du contrat de registre de base, qui interdit l’exploitation exclusive des gTLD génériques et des variantes de chaînes, la chaîne ne doit pas être un générique fermé tel que défini dans la Section 3.1.7 Génériques fermés.

7.4.5 Questions de clarification lors de l’évaluation de l’exemption au code de conduite

L’ICANN peut poser des questions de clarification dans le cadre de l’évaluation des exemptions au code de conduite. Le candidat disposera de sept jours pour répondre aux questions administratives de clarification et de 21 jours pour répondre aux questions de clarification de fond. Si le candidat ne répond pas dans ce délai défini, il peut perdre la possibilité de régler les problèmes constatés par le panel d’évaluation.

7.4.6 Résultats de l’évaluation des exemptions au code de conduite

Les résultats de l’évaluation des exemptions au code de conduite seront inclus dans les rapports d’évaluation des candidatures et des candidats, comme il est décrit à la Section 1.2.13 Publication des rapports d’évaluation des candidatures et des candidats.

Si une candidature réussit l’évaluation d’éligibilité à l’exemption au code de conduite, une exemption au code de conduite sera accordée.

Si une candidature ne réussit pas l’évaluation de l’exemption au code de conduite, la candidature peut se poursuivre en maintenant la spécification 9 en place.

7.4.6 Contestations et évaluation approfondie pour l’évaluation des exemptions au code de conduite

7.5 Noms géographiques

Les candidats doivent examiner attentivement les intérêts des gouvernements ou des autorités publiques en ce qui concerne les noms géographiques. Les sections suivantes décrivent les exigences et les procédures que l’ICANN suivra au cours du processus d’évaluation. Un candidat doit examiner ces exigences même s’il ne croit pas que la chaîne de gTLD qu’il souhaite utiliser soit considérée comme un nom géographique. Toutes les chaînes de gTLD faisant l’objet d’une candidature et leurs variantes de chaînes allouables seront examinées conformément aux exigences de cette section, indépendamment du fait que la candidature indique ou non qu’il s’agit d’un nom géographique.

Le traitement des noms géographiques comprend :

L’identification des noms géographiques : une vérification au niveau de la chaîne qui fait partie de l’évaluation de chaîne.
La révision des noms géographiques : vérification et révision approfondie des réponses aux questions fournies dans la candidature pour les chaînes jugées géographiques. Cette procédure se déroule pendant l’étape d’évaluation de la candidature.

En outre, un candidat à une chaîne de nom géographique peut postuler pour ses variantes de chaînes allouables. Dans ce cas, toutes les variantes de chaînes allouables doivent respecter les mêmes exigences quant à la candidature ainsi que les critères d’évaluation de la chaîne de nom géographique principale associée. Plus précisément, les mêmes exigences en matière de documentation sont appliquées. Se reporter à la Section 3.1.9 Noms de domaine internationalisés.

7.5.1 Traitement des noms de pays ou de territoires

Les candidatures à des chaînes représentant des noms de pays et de territoires ne seront pas approuvées⁴⁹. Une chaîne est considérée comme un nom de pays ou de territoire si elle répond à l’un des critères suivants :

correspond à un code alpha-3 répertorié par la norme ISO 3166-1⁵⁰ ;
correspond à la forme longue d’un nom, répertoriée par la norme ISO 3166-1, ou à la traduction de cette forme en quelque langue que ce soit ;
correspond à la forme courte d’un nom, répertoriée par la norme ISO 3166-1, ou à la traduction de cette forme en quelque langue que ce soit ;
correspond à la forme courte ou longue d’un nom associé à un code désigné comme « exceptionnellement réservé » par l’Autorité de mise à jour de la norme ISO 3166 ;
correspond à un élément séparable d’un nom de pays figurant sur la « Liste des noms de pays et de territoires séparables », ou de la traduction d’un nom de cette liste en quelque langue que ce soit. Voir l’Annexe 2 Documents relatifs aux noms géographiques ;
correspond à la permutation ou transposition des chaînes suivantes, lesquelles sont réservées et non disponibles à la délégation :

les noms au format long listés dans la norme ISO 3166-1 ;
les noms au format court listés dans la norme ISO 3166-1 ;
forme courte ou longue d’un nom associé à un code désigné comme « exceptionnellement réservé » par l’Autorité de mise à jour de la norme ISO 3166.
élément séparable d’un nom de pays figurant sur la « Liste des noms de pays séparables » ou de la traduction d’un nom de cette liste en quelque langue que ce soit.

Les chaînes résultant de permutations et transpositions de codes alpha-3 de la norme ISO 3166-1 peuvent être déléguées, à moins que les chaînes résultant des permutations et transpositions ne figurent elles-mêmes sur cette liste⁵¹ ;

correspond à un nom de pays communément utilisé et reconnu de fait par un organisme intergouvernemental ou une organisation de traité international.

7.5.2 Noms géographiques nécessitant des documents de la part d’un gouvernement ou d’une autorité publique

Certains types de chaînes faisant l’objet d’une candidature, y compris leurs variantes allouables, sont considérés comme des noms géographiques et doivent être accompagnés d’une documentation de soutien ou de non-objection émanant des gouvernements ou des autorités publiques concernés. Ces types sont les suivants :

chaînes qui représentent, dans quelque langue que ce soit, le nom de la capitale d’un pays ou territoire répertorié dans la norme ISO 3166-1.
noms de villes où les candidats déclarent leur intention d’utiliser le gTLD à des fins se rapportant au nom de la ville.

Les noms de villes peuvent présenter des défis parce qu’ils peuvent aussi être des termes génériques ou des noms de marque, et ils ne sont souvent pas uniques. Contrairement à d’autres types de noms géographiques, les noms de villes n’ont pas de listes établies pour des références objectives pendant l’évaluation. Ce qui fait que les noms de ville ne sont pas universellement protégés. Cependant, le processus prévoit un moyen pour les villes et les candidats qui souhaitent collaborer.

Une candidature à un nom de ville sera soumise aux exigences relatives aux noms géographiques (exigera des documents justificatifs ou de non-objection de la part des gouvernements ou des autorités publiques concernés) si :

le candidat indique clairement dans sa candidature qu’il utilisera le TLD principalement à des fins associées au nom de la ville ; et
la chaîne faisant l’objet de la candidature est un nom de ville répertorié sur les documents officiels de celle-ci⁵².

Chaînes identiques à des nom de subdivision administrative (comté, province, État, etc.) répertoriés par la norme ISO 3166-2.
Chaîne répertoriée comme région de l’UNESCO⁵³ ou figurant dans la section « Régions géographiques » de la ressource « Codes standard des pays et des zones à usage statistique (M49) ».⁵⁴

Les traductions des régions figurant sur la liste susmentionnée seront limitées aux langues qui y sont spécifiées. Les noms de région non conformes au cadre des caractères autorisés dans le DNS seront convertis en étiquettes DNS qui ne contiennent que des lettres, des chiffres et des traits d’union, comme indiqué dans les règles de génération d’étiquettes pour la zone racine (RZ-LGR)⁵⁵.

Pour les chaînes figurant sur ces listes, une documentation de soutien ou de non-objection sera requise de la part d’au moins 60 % des gouvernements nationaux respectifs de la région, et pas plus d’une objection écrite à la candidature de la part des gouvernements concernés de la région ou des autorités publiques associées au continent ou à la région.

Lorsque la règle du 60 % est appliquée dans un cas où des régions sont communes aux deux listes, la composition régionale contenue dans les « Codes standard des pays et des zones à usage statistique (M49) » prévaut.

Toute chaîne faisant l’objet d’une candidature à un nouveau gTLD et appartenant à l’une des quatre catégories ci-dessus est réputée représenter un nom géographique. En cas de doute, il est conseillé au candidat de consulter les gouvernements et les autorités publiques concernés pour obtenir leur soutien ou leur non-objection avant de déposer sa candidature. Cette approche proactive peut aider à prévenir d’éventuelles objections et à clarifier toute ambiguïté concernant la chaîne et les exigences applicables.

Les chaînes qui incluent, mais ne correspondent pas exactement à un nom géographique tel que défini dans la présente section ne seront pas considérées comme des noms géographiques. Par conséquent, les documents attestant du soutien ou de la non-objection du gouvernement pendant le processus d’évaluation ne seront pas nécessaires.

Pour chaque candidature, le panel de noms géographiques identifiera les gouvernements ou autorités publiques concernés sur la base des contributions du candidat, de celles des gouvernements, et de ses propres recherches et analyses. Si un ou plusieurs gouvernements ou autorités publiques sont concernés par la chaîne faisant l’objet d’une candidature à un gTLD, le candidat doit fournir des documents émanant de chacun d’eux, attestant de leur soutien ou de leur non-objection. Cela s’appliquerait notamment aux noms de subdivisions administratives.

Il incombe au candidat :

d’établir si sa chaîne faisant l’objet d’une candidature à un gTLD relève de l’une des catégories ci-dessus ;
d’identifier et de consulter les gouvernements et autorités publiques concernés ; et
de déterminer le niveau du soutien requis de la part du gouvernement.

Remarque : le niveau au sein du gouvernement et l’organisme administratif compétent pour les demandes de lettres de soutien ou de non-objection sont déterminés par chaque administration nationale. Les candidats doivent se renseigner auprès de l’autorité concernée afin de déterminer le niveau de soutien requis.

L’obligation d’inclure des documents justifiant le soutien ou la non-objection pour certaines candidatures n’empêche pas ou ne dispense pas les candidatures de faire l’objet d’objections pour des motifs communautaires (voir la Section 4.5.1.4 Motif d’objection : opposition communautaire). Les candidatures peuvent tout de même être rejetées si les objections faisant valoir une opposition substantielle de la part de la communauté ciblée aboutissent.

7.5.2.1 Documents requis

Les pièces justifiant le soutien ou la non-objection doivent inclure une lettre signée par le(s) gouvernement(s) ou la/les autorité(s) publique(s) concernée(s). Étant entendu que ces documents varieront d’une juridiction à l’autre, la lettre peut être signée par le ministre en charge de l’administration des noms de domaine, des TIC, des affaires étrangères, ou par le cabinet du Premier ministre ou du président de la juridiction concernée, ou encore par un haut représentant de l’agence ou du département en charge de l’administration des noms de domaine, des TIC, des affaires étrangères ou du cabinet du Premier ministre. Pour identifier le/les gouvernement(s) ou la/les autorité(s) publique(s) pertinente(s) pour un nom géographique potentiel, le candidat peut consulter le représentant du Comité consultatif gouvernemental (GAC) concerné.⁵⁶

La lettre doit exprimer sans équivoque le soutien ou la non-objection du gouvernement ou de l’autorité publique à la candidature et démontrer leur compréhension de la chaîne sollicitée et de l’usage qui en est prévu.

Par ailleurs, la lettre doit indiquer que le gouvernement ou les autorités publiques comprennent que la chaîne est sollicitée dans le cadre du processus de dépôt de candidature aux gTLD et que le candidat est disposé à accepter les conditions de mise à disposition de la chaîne, notamment la signature d’un contrat de registre avec l’ICANN imposant la conformité avec les politiques de consensus et le paiement des frais. Voir la Section 1.2.16 Après la passation de contrats et la Section 2.10 Obligations fondamentales des opérateurs de registre vis-à-vis des bureaux d’enregistrement pour en savoir plus sur les obligations d’un opérateur de registre de gTLD.

Un exemple de lettre de soutien ou de non-objection d’une entité gouvernementale/d’une autorité publique est disponible à l’Annexe 2 Documents relatifs aux noms géographiques.

Les candidats et les gouvernements peuvent échanger au sujet du soutien ou de la non-objection à une candidature à tout moment. Les candidats sont encouragés à entamer ces échanges dès que possible, afin de permettre aux autorités concernées de suivre les processus nécessaires pour examiner, approuver et produire une lettre de soutien ou de non-objection. Une nouvelle lettre sera requise si la lettre originale date de plus de quatre mois avant l’ouverture de la période de dépôt de candidatures au programme des nouveaux gTLD. Toutefois, les candidats doivent fournir les coordonnées d’une personne désignée au cas où le panel de noms géographiques (GNP) aurait besoin de précisions ou aurait des questions.

Un gouvernement ou une autorité publique n’est pas obligé de fournir des documents de soutien ou de non-objection en réponse à une demande d’un candidat. Si le soutien ou la non-objection sont retirés au cours du processus de candidature, celle-ci échouera à l’examen des noms géographiques.

Les candidats doivent noter que l’ICANN s’est engagée auprès des gouvernements⁵⁷ de manière que, en cas de litige entre un gouvernement (ou une autorité publique) et un candidat ou après délégation, si un opérateur de registre a soumis des documents faisant état du soutien du gouvernement ou de l’autorité publique en question, l’ICANN se conformera à la décision exécutoire d’un tribunal de la juridiction dont dépend le gouvernement ou l’autorité publique ayant apporté son soutien au candidat. Si le soutien est retiré par une décision judiciaire exécutoire, le candidat ou l’opérateur de registre n’aura plus la documentation nécessaire et le candidat ne passera pas aux étapes suivantes du processus de candidature ou, si cela se produit après la délégation, les processus de transition entre opérateurs de registre⁵⁸ mentionnés dans le contrat de registre seront suivis.

7.5.3 Traitement des noms géographiques

7.5.3.1 Identification des noms géographiques

Dans le cadre de l’identification des noms géographiques, le panel de noms géographiques examinera toutes les chaînes faisant l’objet de candidatures pour identifier celles qui peuvent être considérées comme des noms géographiques. Ce processus est distinct du processus de vérification plus approfondi mené au cours de la révision des noms géographiques qui a lieu dans le cadre de la candidature (voir le Module 7) et de l’évaluation du candidat (voir le Module 6).

Les noms de villes qui ne font pas partie des catégories définies aux sections 1, 3 et 4 des noms géographiques nécessitant une documentation du gouvernement ou de l’autorité publique (voir la section 7.5.2) ne seront pas classés comme noms géographiques lors de l’identification des noms géographiques. Toutefois, si le candidat indique son intention d’utiliser la chaîne faisant l’objet de la candidature comme nom de ville, tel que décrit à la section 2 des Noms géographiques nécessitant des documents du gouvernement ou de l’autorité publique (voir la Section 7.5.2), la candidature sera évaluée par le panel de noms géographiques au cours de l’étape d’évaluation de la candidature et du candidat. Cette évaluation comprendra une évaluation de l’objectif visé et toute la documentation requise.

7.5.3.2 Examen des noms géographiques

Pour chaque chaîne faisant l’objet d’une candidature à un nouveau gTLD, un panel de noms géographiques (GNP) déterminera si la chaîne représente un nom géographique et, le cas échéant, vérifiera la pertinence et l’authenticité des documents de soutien.

Le GNP examinera toutes les candidatures reçues, sans se limiter à celles où le candidat a indiqué que la chaîne faisant l’objet d’une candidature à un nouveau gTLD correspond à un nom géographique. Toute candidature pour laquelle le GNP conclut que la chaîne faisant l’objet de la candidature à un nouveau gTLD correspond à un nom de pays ou de région (comme défini dans le présent module) sera rejetée lors de la révision des noms géographiques. Aucune autre révision ne sera disponible.

Toute candidature pour laquelle le GNP conclut que la chaîne faisant l’objet de la candidature à un nouveau gTLD ne correspond pas à un nom géographique nécessitant le soutien ou la non-objection d’un gouvernement (comme décrits dans le présent module) sera validée, lors de la révision des noms géographiques, sans nécessiter de démarches ou de frais supplémentaires.

Pour toute candidature où le GNP conclut que la chaîne faisant l’objet de la candidature à un nouveau gTLD correspond à un nom géographique nécessitant le soutien ou la non-objection d’un gouvernement, il vérifiera que le candidat a fourni le document exigé, établi par le gouvernement ou les autorités publiques concernés, et que ce document est légitime et contient les éléments requis. L’ICANN peut confirmer l’authenticité du document en consultant les autorités diplomatiques compétentes, ou les représentants du gouvernement ou de l’autorité publique concernée auprès du Comité consultatif gouvernemental de l’ICANN, pour connaître l’entité compétente et le point de contact de leur administration pour ce type de document.

Le GNP peut également communiquer avec l’entité signataire de la lettre, afin de se faire confirmer l’intention de cette dernière et sa compréhension des conditions selon lesquelles le soutien ou la non-objection sont accordés à la candidature.

7.5.3.2.1 Évaluation approfondie pour l’examen des noms géographiques

L’examen des noms géographiques sera admissible à une évaluation approfondie dans les cas suivants :

Problèmes relatifs aux documents présentés : si un candidat n’a pas fourni les documents requis, il sera contacté afin d’être informé de cette obligation ainsi que du délai limité dont il disposera pour présenter lesdits documents. Si le candidat est en mesure de fournir ces pièces avant la clôture de la période d’évaluation et qu’elles satisfont aux exigences, la candidature aura réussi l’examen des noms géographiques. Sinon, le candidat peut choisir l’évaluation approfondie où il aura davantage de temps pour obtenir la documents requis ; cependant, si le candidat n’a pas présenté les documents requis à la date requise (au moins 90 jours à compter de la date de l’avis), il n’aura pas de temps ou d’occasions supplémentaires pour ce faire au cours de la série de candidatures actuelle. Le candidat peut, s’il le souhaite, se réinscrire aux séries de candidatures ultérieures, sous réserve d’acquitter les frais et de répondre aux conditions spécifiques. Voir le Module 6 Procédures d’évaluation des candidats et le Module 7 Procédures d’évaluation de chaînes et de candidatures sur la contestation de l’évaluation pour plus de renseignements.
Soutien contradictoire ou absence d’objection pour le même nom géographique : comme indiqué à la Section 5.5 Résolution des conflits pour les candidatures à des noms géographiques, dans le cas où il y a plus d’une candidature pour une chaîne qui représente le même nom géographique et a reçu des documents de soutien ou de non-objection de la part de différents gouvernements ou autorités publiques, comme déterminé par le panel des noms géographiques, ces candidatures feront également l’objet d’une évaluation approfondie. Si, au cours de l’évaluation approfondie, le panel des noms géographiques est convaincu que les autorités de soutien de toutes les candidatures pertinentes satisfont aux critères requis et conviennent que ces candidatures peuvent faire l’objet d’une résolution de conflits, il passera soit à la vente aux enchères, soit à la CPE, si l’une des candidatures est une candidature communautaire et choisit de subir une CPE.

7.6 Évaluation des variantes de chaînes

Une variante de chaîne est considérée comme étant la « même » que la chaîne principale faisant l’objet d’une candidature à un nouveau gTLD ou un gTLD existant (« chaîne principale ») par la communauté partageant une écriture, comme défini dans les règles de génération d’étiquettes pour la zone racine (RZ-LGR).⁵⁹ L’ensemble des règles RZ-LGR détermine les domaines de premier niveau valides et leurs variantes de chaînes.⁶⁰ Un candidat souhaitant obtenir une ou plusieurs variantes allouables d’un IDN principal faisant l’objet d’une candidature, ou d’un gTLD existant, doit justifier la nécessité de chaque variante. Cette justification sera évaluée par un panel sur la base d’une norme générale de caractère raisonnable, fondée sur les critères suivants, dans le contexte du gTLD IDN principal ou du gTLD existant faisant l’objet de la candidature :

Le sens ou le sens voulu (pour les mots non issus du dictionnaire) de chacune des variantes de chaînes faisant l’objet d’une candidature est cohérent, comme le démontrent les sources fournies par le candidat.
La variante de chaîne est reconnue comme équivalente par la communauté d’utilisateurs concernée.
Les avantages et les communautés d’utilisateurs qui bénéficieront de l’introduction de la variante de chaîne faisant l’objet d’une candidature.
Les mesures que le candidat prendra pour minimiser les complexités opérationnelles et de gestion des variantes de gTLD et des variantes de noms de domaine qui en résultent et qui ont une incidence sur les bureaux d’enregistrement, les revendeurs ou les titulaires de nom de domaine.

les engagements pris par un candidat afin de minimiser les complexités constatées au niveau opérationnel et de gestion seront la base des exigences contractuelles à inclure dans le contrat de registre applicable.

Le candidat doit satisfaire à chaque critère pour chaque variante de chaîne faisant l’objet d’une candidature pour continuer dans le programme. Le résultat de l’évaluation d’une variante de chaîne faisant l’objet d’une candidature n’aura aucune incidence sur le résultat de l’évaluation d’un IDN principal ou de toute autre variante de chaîne faisant l’objet d’une candidature.

La capacité à gérer les variantes de chaînes faisant l’objet d’une candidature ainsi que l’IDN principal faisant l’objet d’une candidature ou le gTLD existant sera évaluée à la fois d’un point de vue technique et opérationnel, comme décrit dans le Manuel RSP.⁶¹

7.6.1 Exigences supplémentaires pour les candidatures à des variantes de chaînes

Une variante de chaîne faisant l’objet d’une candidature sera soumise aux mêmes exigences relatives à la candidature et aux critères d’évaluation que l’IDN principal faisant l’objet d’une candidature ou le gTLD existant. Plus précisément, les mêmes exigences en matière de documentation s’appliquent à la fois à l’IDN principal et à ses variantes de chaînes faisant l’objet de la candidature. Par souci de clarté, une chaîne principale faisant l’objet d’une candidature et ses variantes de chaînes faisant l’objet d’une candidature seront évaluées comme un ensemble, mais nécessiteront la documentation pertinente pour chaque variante de chaîne, le cas échéant.

En ce qui concerne les trois types de candidatures spécialisés suivants :

Les candidats aux IDN communautaires et leurs variantes de chaînes doivent présenter la même approbation pour les variantes de chaînes faisant l’objet d’une candidature que celle requise pour l’IDN principal. Si un IDN communautaire est en conflit (voir la Section 5.2 Conflit de chaînes et procédures de résolution) et choisit de participer à l’évaluation de la priorité communautaire (CPE), alors l’IDN communautaire et ses variantes de chaînes faisant l’objet de la candidature seront évalués comme un ensemble (voir la Section 5.4 Évaluation de la priorité communautaire).
Le candidat à un nom géographique IDN et ses variantes de chaînes doit présenter des documents de soutien ou de non-objection à sa chaîne principale faisant l’objet de la candidature et à ses variantes de chaînes provenant des gouvernements ou des autorités publiques compétents. Autrement dit, la documentation de soutien ou de non-objection doit faire référence à la fois à l’IDN faisant l’objet de la candidature et à ses variantes de chaînes demandées. Voir la Section 7.5 Noms géographiques.
Le candidat à un IDN de TLD de marque et ses variantes de chaînes est tenu de fournir la preuve que sa chaîne principale et ses variantes de chaînes faisant l’objet de la candidature sont identiques aux marques déposées détenues et utilisées par le candidat. Autrement dit, toute variante de chaîne faisant l’objet d’une candidature doit également démontrer qu’elle est identique à des marques déposées détenues et utilisées par le candidat. Se reporter à la Section 7.3 Évaluation d’admissibilité au statut de TLD de marque.

7.6.2 Candidatures à des variantes de chaînes de la liste de noms réservés

Lorsqu’un nom réservé est la chaîne principale, seule l’organisation associée à ce nom réservé (voir la Section 7.2.2 Noms réservés) est autorisée à appliquer ses variantes de chaînes au premier niveau. Bien que la variante de chaîne ne doive pas obligatoirement être un nom réservé, elle est générée en tant que variante de chaîne du nom réservé à l’aide des RZ-LGR. Une candidature pour les variantes de chaînes d’un nom réservé ne peut pas précéder une candidature pour le nom réservé, qui sert de chaîne principale pour générer les variantes de chaînes.

7.6.3 Dépendance supplémentaire des variantes de chaînes

Toutes les variantes de chaînes dépendent de leur IDN principal pour l’évaluation de la candidature. Si un IDN principal faisant l’objet d’une candidature est disqualifié pour quelque raison que ce soit, comme décrit dans la présente section ou dans d’autres sections pertinentes du Guide de candidature, toutes les variantes de chaînes associées seront également disqualifiées. Dans de tels cas, la candidature, dans son ensemble, ne pourra pas être traitée.

Toutefois, si des variantes de chaînes faisant l’objet d’une candidature sont disqualifiées et ne peuvent pas être poursuivies, le candidat doit déposer une demande de changement de candidature (ACR) pour supprimer la variante de chaîne faisant l’objet d’une candidature disqualifiée afin que la candidature puisse être poursuivie. Si l’ACR réussit, l’IDN principal faisant l’objet d’une candidature correspondant et toutes les variantes de chaînes demandées restantes qui ne sont pas disqualifiées pourront continuer.

7.7 Collisions de noms

La délégation de presque tous les nouveaux gTLD comporte un certain risque de collision de noms. La collision de noms fait référence à la situation où un nom de ressource destiné à être résolu dans un système de nommage⁶² est résolu par mégarde dans un autre système de nommage, pouvant entraîner un comportement inattendu, tel que l’interruption ou la redirection de la communication vers un destinataire autre que celui prévu.⁶³

Afin d’évaluer et d’atténuer le risque de collision de noms entre le DNS mondial et d’autres systèmes de nommage, l’ICANN a mis en œuvre le cadre de gestion des risques de collision de noms, conformément aux recommandations du rapport de la deuxième étude du projet d’analyse de la collision de noms,⁶⁴ comme demandé par le Conseil d’administration de l’ICANN le 7 septembre 2024.⁶⁵

Toutes les chaînes de gTLD faisant l’objet d’une candidature doivent être évaluées dans ce cadre avant d’être approuvées pour la passation de contrats et la délégation. La présente section décrit ce cadre et les procédures qui seront utilisées pour l’évaluation et, le cas échéant, atténuer les risques de collision de noms associés à ces chaînes.

7.7.1 Accès des candidats aux données de risques longitudinales

Avant l’ouverture de la période de dépôt de candidatures, l’ICANN publiera des ensembles de données liés à toutes les chaînes au-dessus d’un certain seuil de volume de requêtes qui peuvent aider les candidats à évaluer les risques de collision de noms.

Les indicateurs d’une chaîne faisant l’objet d’une candidature ne sont que l’un des nombreux facteurs, quantitatifs et qualitatifs, qui seront pris en compte lors de l’évaluation du risque associé à cette chaîne.

Sur environ 1 400 chaînes uniques ayant fait l’objet d’une candidature au cours de la dernière série, seules trois (.CORP, .HOME et .MAIL) ont été évaluées comme présentant un risque élevé.⁶⁶ Toutefois, les candidats ne doivent pas supposer que si les ensembles de données indiquent un faible volume d’occurrences de collision de noms, la chaîne sera évaluée comme sûre pour être déléguée.

7.7.2 Évaluation initiale de la collision de noms

Chaque chaîne faisant l’objet d’une candidature et toute variante de chaîne allouable seront soumises à l’évaluation initiale de la collision de noms à l’aide d’ensembles de données pertinents pouvant être obtenus, par exemple, des journaux du serveur racine et des journaux du serveur récursif du DNS, en utilisant à la fois le volume et la diversité des requêtes, les origines, les noms de requêtes (étiquettes) et les types de requêtes ; les ensembles de données des indicateurs de santé des technologies des identificateurs (ITHI)⁶⁷ ; et les preuves qualitatives qui peuvent aider à déduire la gravité du préjudice. Le but de cette évaluation, qui sera effectuée conformément à la procédure opérationnelle d’évaluation initiale de la collision de noms,⁶⁸ est d’identifier de façon préliminaire les chaînes à risque élevé.

L’évaluation initiale aura lieu après le jour de confirmation de chaîne (Section 3.6) et sera supervisée par l’équipe de révision technique (TRT). L’ICANN publiera un rapport d’évaluation initiale décrivant l’évaluation, sa méthodologie et ses conclusions, une fois terminée. Une période de commentaires publics sera organisée pour le rapport afin de permettre à la communauté de présenter des commentaires sur la méthodologie et les conclusions.

7.7.3 Délégation temporaire et évaluation finale

Les chaînes (ainsi que leurs variantes) qui ne sont pas identifiées comme présentant un risque élevé lors de l’évaluation initiale de la collision de noms (Section 7.7.2) sont placées en file d’attente pour une délégation temporaire La délégation temporaire commence dès la clôture de l’évaluation initiale, même si d’autres évaluations relevant de l’évaluation de la chaîne sont encore en cours. L’ordre de priorité pour la délégation temporaire sera déterminé par le numéro de priorité attribué à la candidature.⁶⁹ La durée de la délégation temporaire sera décrite dans la procédure opérationnelle de délégation temporaire de collision de noms.⁷⁰ La conclusion de la délégation temporaire n’est pas nécessaire pour d’autres évaluations ou pour la résolution de conflits. Toutefois, une candidature ne pourra passer à la signature du contrat que lorsque la délégation temporaire sera conclue et que le plan d’atténuation aura été mis en œuvre (le cas échéant).

La vitesse à laquelle les chaînes seront temporairement déléguées sera limitée pour garantir que le nombre de TLD délégués dans la zone racine du DNS n’augmente pas de plus d’environ 5 % par mois. Il est prévu qu’au début, cette limite au rythme de délégation soit d’environ 75 délégations temporaires par mois et qu’elle augmente à mesure que de nouveaux gTLD seront temporairement délégués. Toutefois, comme les délégations permanentes ont la priorité sur les délégations temporaires, ce nombre peut varier d’un mois à l’autre.

Pendant la délégation temporaire, la chaîne faisant l’objet d’une candidature à un nouveau gTLD sera déléguée aux serveurs de noms DNS gérés par l’ICANN afin de collecter des données sur le volume et la nature du trafic DNS pour cette chaîne. Quatre méthodes d’évaluation différentes pour la notification et la production de données seront utilisées lors de la délégation temporaire. Celles-ci sont décrites dans l’Annexe 2 du rapport de la deuxième étude du projet d’analyse de la collision de noms, à savoir : pas d’interruption (NI) ; interruption contrôlée (CI) ; interruption visible (VI) ; interruption visible et notification (VIN). L’évaluation sera supervisée par l’équipe de révision technique (TRT), qui est composée d’experts internes des départements pertinents de l’ICANN. La TRT déterminera au cas par cas la ou les méthodes qui seront utilisées pour chaque évaluation.

La TRT évaluera les données collectées lors de la délégation temporaire, qui comprennent les requêtes DNS vers les serveurs TLD, la diversité des requêtes, les origines, les noms des requêtes (étiquettes), les types de requêtes, etc., ainsi que les données collectées à l’aide des méthodes d’évaluation, afin de déterminer si la chaîne sera :

désignée comme présentant un risque élevé, auquel cas la chaîne sera immédiatement supprimée de la zone racine ;
admissible à poursuivre le reste du traitement de la candidature.

Quel que soit le résultat de la délégation temporaire, la TRT élaborera un rapport de délégation temporaire décrivant les conclusions, qui sera publié pour révision par les candidats et les autres parties intéressées.

7.7.4 Liste des chaînes en collision

L’ICANN maintiendra une liste des chaînes en collision, à savoir, une liste de chaînes que l’ICANN a déterminée comme présentant un risque élevé de collision de noms.

Une chaîne faisant l’objet d’une candidature sera ajoutée à la liste de chaînes en collision si (1) aucun plan d’atténuation n’est soumis pour cette chaîne, (2) le plan d’atténuation échoue à l’évaluation du plan d’atténuation ou (3) le plan d’atténuation n’est pas effectif.

7.7.5 Évaluation du plan d’atténuation de risques élevés de collision de noms

Le candidat à une chaîne inscrite sur la liste des chaînes en collision qui a résolu le conflit peut modifier sa candidature pour ajouter un plan d’atténuation lié à une chaîne à risque élevé, qui sera ensuite évalué. Cette évaluation sera effectuée conformément à la procédure opérationnelle d’évaluation du plan d’atténuation de risques élevés de collision de noms⁷¹ et est soumise à des frais supplémentaires. Voir la Section 3.3 Frais et paiements.

Les candidats doivent soumettre une demande de modification de dossier de candidature pour ajouter un plan d’atténuation dans les 90 jours (pouvant être prorogés sur demande raisonnable jusqu’à 180 jours) suivant (a) la désignation de la chaîne comme étant à risque élevé ou, en cas d’ensemble conflictuel, (b) la résolution d’un conflit (le cas échéant). Si la demande de changement de candidature n’est pas soumise dans ce délai, le statut de la candidature passera à « écartée ». Voir la Section 3.9 Statut d’une candidature.

Le candidat recevra les données pertinentes générées au cours de l’évaluation initiale ou de la délégation temporaire de la chaîne pour l’aider à élaborer le plan d’atténuation, sous réserve des exigences applicables en matière de protection des données. Lorsque les données comprennent des données personnelles et que les sauvegardes techniques, comme l’anonymisation ou l’agrégation, ne peuvent pas être effectivement appliquées, l’ICANN peut demander à conclure un contrat de traitement de données (DPA) avec le candidat.

Le plan d’atténuation soumis par le candidat doit contenir au minimum les éléments suivants :

Un résumé des conclusions de l’évaluation initiale et, le cas échéant, des conclusions de l’équipe de révision technique au cours de la délégation temporaire.
Une analyse des causes profondes et toute autre preuve pertinente qui identifient les raisons sous-jacentes pour lesquelles des collisions de noms peuvent se produire pour la chaîne.
Un plan d’atténuation détaillant des mesures préventives et correctives spécifiques que le candidat mettra en œuvre pour atténuer le risque de collision de noms, y compris les communications destinées aux utilisateurs finaux concernés. Chaque mesure d’atténuation doit s’inscrire dans un calendrier de mise en œuvre précis. La durée totale ne doit pas dépasser deux ans.

Le plan d’atténuation sera évalué par un panel d’experts techniques, qui pourra conseiller le candidat sur les améliorations possibles. Si des modifications sont nécessaires, un délai supplémentaire de 90 jours sera accordé pour ces modifications. L’évaluation permettra de déterminer si le plan a) identifie correctement la cause profonde des collisions et b) a une forte probabilité d’être efficace.

L’ICANN publiera le plan d’atténuation et les résultats de l’évaluation du plan d’atténuation pour commentaires. Le panel examinera tous les commentaires reçus et en tiendra compte avant de rendre sa décision définitive. Dans le plan d’atténuation, les candidats peuvent identifier les sections qui contiennent des renseignements qui, s’ils étaient publiés, pourraient nuire à l’efficacité du plan, par exemple lorsqu’ils pourraient permettre à un acteur malveillant d’interférer avec les mesures d’atténuation, et marquer ces sections pour expurgation. Si le panel est d’accord, les sections marquées seront expurgées avant la publication.

Si le plan d’atténuation prévoit des activités d’atténuation qui ont lieu avant la délégation de la chaîne, la candidature ne sera pas traitée tant que ces activités n’auront pas eu lieu et que leur efficacité n’aura pas été confirmée par le panel d’évaluation en utilisant les mêmes critères que ceux utilisés lors de l’évaluation initiale.

Dans les cas où le panel d’évaluation détermine qu’une mesure d’atténuation doit, pour des raisons techniques, être mise en œuvre après que l’opérateur de registre a délégué la chaîne (après que l’évaluation a été finalisée), par exemple, si les problèmes de collision de noms se limitent à un nom de second niveau que le registre accepte de ne jamais déléguer, la candidature peut être autorisée à suivre son cours tant que le candidat accepte d’ajouter les exigences du plan d’atténuation applicables à son contrat de registre.

Si le panel d’évaluation constate que le plan d’atténuation (a) ne permet pas d’identifier correctement la cause profonde des collisions ou (b) n’a pas une forte probabilité d’être efficace, la candidature ne pourra pas se poursuivre et le statut de la candidature passera à « écartée ».

7.7.5.1 Contester l’évaluation du plan d’atténuation

Le candidat aura la possibilité de contester le résultat d’une évaluation du plan d’atténuation en ce qui concerne sa propre candidature s’il croit que le panel a commis une erreur de fait ou de procédure lorsqu’il a déterminé que le plan d’atténuation a) n’identifie pas correctement la cause profonde des collisions ou b) n’a pas une forte probabilité d’être efficace. Pour amorcer une procédure de contestation de l’évaluation, le candidat doit déposer une contestation dans les 21 jours suivant la date de transmission de la décision d’évaluation. Un panel chargé de la contestation, composé des mêmes personnes responsables de l’évaluation initiale du plan, procède à la révision de la contestation.

La contestation sera évaluée au regard du seul critère de l’« erreur manifeste ». Plus précisément, le panel chargé de la contestation doit accepter la décision du panel d’évaluation à moins que le panel d’évaluation : 1) n’ait pas suivi les procédures appropriées, ou (2) n’ait pas pris en considération/sollicité les éléments de preuve ou les renseignements importants nécessaires.

La date limite pour déposer une contestation sera de 21 jours à compter de la date à laquelle le candidat reçoit l’avis de la décision d’évaluation qu’il cherche à contester. Le panel chargé de la contestation communiquera le résultat de la procédure de contestation dans les 30 jours suivant le dépôt d’une telle contestation par le candidat.

Si le panel chargé de la contestation constate une erreur de fait ou de procédure, le plan d’atténuation sera réévalué. Le panel d’évaluation procèdera à la réévaluation et fournira les résultats à l’ICANN. L’ICANN publiera les résultats et offrira une période de commentaires de 30 jours. Une fois la période de commentaires terminée, l’ICANN examinera toutes les informations disponibles et prendra une décision finale sur l’acceptation ou le rejet du plan d’atténuation. Si le plan est rejeté, le statut de la candidature passe à l’état « écartée ».

Si le panel chargé de la contestation ne constate pas d’erreur de fait ou de procédure dans l’évaluation initiale du plan d’atténuation, la candidature ne pourra pas être traitée et son état passera à l’état « écartée ».

7.7.6 Interaction avec les variantes de chaînes

Toutes les chaînes principales faisant l’objet d’une candidature, y compris les variantes de chaînes allouables faisant l’objet d’une candidature, seront évaluées en ce qui concerne le risque de collision de noms au moyen des processus d’évaluation initiale et de délégation temporaire décrits ci-dessus.

Si une chaîne principale ou une variante de chaîne allouable s’avère à haut risque, la candidature ne peut pas continuer tant que le processus d’évaluation du plan d’atténuation n’a pas été exécuté. Toutefois, dans le cas d’une variante de chaîne allouable, la candidature peut être modifiée pour supprimer cette chaîne, ce qui permet à la candidature modifiée de continuer. La suppression d’une variante de chaîne allouable peut se produire à tout moment tant que l’état de la candidature n’est pas passé à l’état « écartée ».

7.8 Engagements d’intérêt public, engagements volontaires des opérateurs de registre et politiques d’enregistrement communautaire

La mission de l’ICANN est de garantir un fonctionnement stable et sécurisé des systèmes d’identificateurs uniques de l’Internet⁷². Le programme des nouveaux gTLD soutient cette mission avec de nombreuses protections intégrées, y compris une évaluation rigoureuse des chaînes faisant l’objet d’une candidature, des candidatures, des opérateurs et le respect de la conformité avec le contrat de registre.

Les engagements d’intérêt public (PIC), en particulier les PIC obligatoires (voir la Section 7.8.1) et les PIC à des fins de protection (voir la Section 7.8.2), constituent une protection importante intégrée dans le programme des nouveaux gTLD. Ces PIC sont des engagements contraignants de la spécification 11 du contrat de registre, et l’ICANN veille à leur conformité. Les PIC obligatoires et les PIC à des fins de protection sont uniformes dans tous les contrats de registre pertinents et ont été mis en œuvre en réponse aux préoccupations du Comité consultatif gouvernemental (GAC) concernant les candidatures dans le cadre de la série de candidatures de 2012. Les principales questions abordées comprennent la protection des consommateurs, les droits de propriété intellectuelle et les secteurs réglementés du marché tels que les finances, la santé et les organismes de bienfaisance.⁷³

En plus des PIC, un candidat sera autorisé à proposer un ou plusieurs engagements volontaires des opérateurs de registre (RVC) (voir la Section 7.8.3) afin de fournir des garanties supplémentaires en ce qui concerne l’exploitation d’une chaîne faisant l’objet d’une candidature à un nouveau gTLD. Un candidat peut proposer un RVC pour répondre à des préoccupations qui ne sont pas déjà traitées par les PIC obligatoires ou à des fins de protection ou par d’autres moyens. Comme il est précisé plus en détail à la Section 7.8.3 Engagements volontaires des opérateurs de registre, les RVC proposés font l’objet d’un processus d’évaluation distinct, à savoir l’évaluation des engagements d’un opérateur de registre (RCE). L’ICANN n’approuvera une proposition de RVC que si :(1) le RVC répond aux critères RCE (voir la Section 7.8.3.3) ; et (2) le candidat et l’ICANN conviennent chacun que le RVC proposé, s’il est inclus dans le contrat de registre, serait applicable en vertu des statuts constitutifs de l’ICANN et dans la pratique. Comme pour les PIC, les RVC (une fois approuvés et incorporés dans le contrat de registre) sont des engagements contraignants dans la spécification 11 du contrat de registre de base.⁷⁴

Les PIC et les RVC sont tous deux soumis à la procédure de règlement de litiges relatifs aux engagements d’intérêt public (PICDRP).⁷⁵

Comme détaillé dans la Section 7.1 Types de chaînes et de candidatures, un candidat peut choisir de désigner une chaîne faisant l’objet d’une candidature à un nouveau gTLD comme gTLD communautaire. Si le candidat identifie une chaîne faisant l’objet d’une candidature à un nouveau gTLD comme un gTLD communautaire, il doit proposer des politiques d’enregistrement communautaire (voir la Section 7.8.4) pour inclusion dans le contrat de registre applicable, qui seront évaluées par l’ICANN en appliquant les critères RCE (voir la Section 7.8.3.3).

7.8.1 Engagements d’intérêt public obligatoires

Les PIC obligatoires sont inclus dans chaque contrat de registre. Les PIC obligatoires obligent chaque opérateur de registre à mettre en œuvre des mesures visant à protéger les titulaires de gTLD et les utilisateurs d’Internet de manière plus générale, et comprennent des obligations liées à l’atténuation des activités abusives, les contrôles de sécurité et la transparence dans l’exploitation. Les PIC obligatoires sont inclus dans la spécification 11, section 3(a)-(d) du contrat de registre de base (voir l’Annexe 4), à savoir :

l’opérateur de registre inclura dans son contrat entre opérateurs de registre et bureaux d’enregistrement une disposition en vertu de laquelle les bureaux d’enregistrement doivent inclure dans leurs contrats d’enregistrement une disposition interdisant aux titulaires de noms enregistrés la diffusion de logiciels malveillants, l’exploitation abusive de réseaux zombies, l’hameçonnage, la piraterie, la violation de marques ou de propriété intellectuelle, les pratiques frauduleuses ou nuisibles, les contrefaçons ou autres activités contraires aux lois applicables, et prévoyant (conformément aux lois applicables et aux procédures y afférentes) les sanctions pour ce type d’activités, y compris la suspension du nom de domaine.
l’opérateur de registre procèdera périodiquement à une analyse technique afin d’évaluer si les domaines du TLD sont utilisés à des fins d’utilisation malveillante du DNS. l’opérateur de registre devra assurer des rapports statistiques sur l’utilisation malveillante du DNS identifiée et les mesures prises à la suite des contrôles périodiques en matière de sécurité. l’opérateur de registre devra maintenir ces rapports pour la durée du contrat, sauf si un délai plus court est requis par la loi ou approuvé par l’ICANN, et il les présentera à l’ICANN sur demande.⁷⁶
L’opérateur de registre exploitera le TLD de manière transparente, conformément aux principes généraux de transparence et de non-discrimination en établissant, en publiant et en adhérant à des politiques d’enregistrement claires.
L’opérateur de registre d’un TLD de « chaîne générique » ne peut imposer de critères d’éligibilité pour l’enregistrement de noms dans le TLD qui limitent les enregistrements exclusivement à une seule personne ou entité et/ou aux « sociétés affiliées » de cette personne ou entité (tel que défini à l’article 2.9 (c) du contrat de registre de base). Le terme « chaîne générique » correspond à une chaîne composée d’un mot ou d’un terme qui désigne ou décrit une catégorie générale de biens, de services, groupes, d’organisations ou de choses, par opposition à une marque spécifique de biens, de services, de groupes, d’organisations ou de choses qui se distingue des autres.

Pour de plus amples informations sur les chaînes génériques, voir la Section 3.1.7 Chaînes à usage exclusif (génériques fermés).

7.8.2 Engagements en faveur de la protection de l’intérêt public

Les PIC à des fins de protection sont des dispositions requises dans certains contrats de registre, en plus des PIC obligatoires inclus dans tous les contrats de registre.

Les gTLD nécessitant des PIC à des fins de protection sont regroupés en quatre groupes en fonction du risque :

Secteurs réglementés/conditions d’admission libre : des chaînes qui invoquent la confiance des consommateurs, mais avec des risques accrus.
Secteurs hautement réglementés/exigences d’admission restrictives : des chaînes associées à des secteurs nécessitant une licence ou une accréditation.
Risque de cyberintimidation/harcèlement : des chaînes qui pourraient faciliter le harcèlement.
Fonctions intrinsèquement gouvernementales : des chaînes liées aux domaines gouvernementaux.

Pour de plus amples informations, voir les exemples énumérés dans le tableau de la Section 7.8.2.2 PIC à des fins de protection applicables par catégorie de chaîne.

Si l’ICANN détermine au cours de l’évaluation qu’une chaîne faisant l’objet d’une candidature à un nouveau gTLD appartient à une ou plusieurs des catégories définies dans la Section 7.8.2.2 PIC à des fins de protection applicables par catégorie de chaîne, les PIC à des fins de protection applicables (voir la Section 7.8.2.3) doivent être inclus dans la spécification 11 du contrat de registre de base applicable sans modification.⁷⁷

Les PIC à des fins de protection ont été élaborés et mis en œuvre conformément à l’avis consensuel du GAC, énoncé dans le Communiqué de Beijing⁷⁸ de l’ICANN46, et à la résolution ultérieure du Conseil d’administration de l’ICANN⁷⁹ lors de la série de 2012 du Programme des nouveaux gTLD.⁸⁰

7.8.2.1 Détermination du groupe de chaînes

Dans le dossier de candidature, le candidat doit répondre à des questions pour évaluer quels PIC à des fins de protection, le cas échéant, seraient exigés dans le contrat de registre (voir le Questionnaire 10 - Évaluation des mesures de protection / Mission et objet à l’Annexe 1 Questions du dossier de candidature). Les réponses du candidat seront publiées avec la candidature.

À la clôture d’une période de commentaires sur les candidatures, l’ICANN déterminera si chaque chaîne faisant l’objet d’une candidature à un nouveau gTLD appartient ou non à l’un des quatre groupes des PIC à des fins de protection. Cette détermination conclut l’évaluation et sert de contribution à la procédure de passation de contrats. Elle ne peut être contestée dans le cadre de l’évaluation approfondie et la contestation de l’évaluation (Section 1.2.14), car elle n’a pas d’incidence sur la progression de la candidature.

Se reporter à la Section 4.1 Commentaires sur les candidatures pour plus d’informations sur les périodes de commentaires sur les candidatures.

7.8.2.2 PIC à des fins de protection applicables par catégorie de chaîne

L’ICANN utilisera le cadre ci-dessous pour déterminer si une chaîne faisant l’objet d’une candidature à un nouveau gTLD nécessite des PIC à des fins de protection et, le cas échéant, quels sont les PIC à des fins de protection applicables. Le cadre identifie les quatre groupes de chaînes établis en réponse à l’avis consensuel du GAC du communiqué de Beijing de l’ICANN46 et fournit une description et des exemples pertinents.⁸¹ L’ICANN appliquera les PIC à des fins de protection aux chaînes de gTLD faisant l’objet d’une candidature qui sont identifiées comme appartenant aux groupes de chaînes définis dans le communiqué du GAC de l’ICANN46.

Le cadre identifie lequel des dix PIC à des fins de protection est appliqué à chacune des quatre catégories de chaînes.

Tableau 7-2 Cadre des PIC à des fins de protection

Groupe de chaînes N°	Groupe de chaînes	Description	Mesures de protection requises
1	Secteurs réglementés/exigences d’entrée libre dans plusieurs juridictions	La chaîne est susceptible d’invoquer un niveau de confiance implicite de la part des consommateurs La chaîne est susceptible de présenter des risques accrus de préjudice pour le consommateur La chaîne est associée à un secteur généralement ouvert, mais peut nécessiter un enregistrement limité Voir la liste non exhaustive des chaînes identifiées par le GAC comme appartenant à ce groupe dans le communiqué de Beijing de l’ICANN46.⁸² Exemples :.kid, .degree, .audio, .town	1-3
2	Secteurs hautement réglementés/exigences d’entrée fermée dans plusieurs juridictions	La chaîne est associée à une industrie où une licence ou une accréditation est requise par les gouvernements locaux, régionaux ou nationaux. Cela implique généralement une évaluation des qualifications, des inspections régulières et une surveillance continue du gouvernement Voir la liste non exhaustive des chaînes identifiées par le GAC comme appartenant à ce groupe dans le communiqué de Beijing de l’ICANN46.⁸³ Exemples :.cash, .bet, .abogado, .earth, .care	1-8
3	Risque de cyberintimidation/harcèlement	La signification implicite ou réelle de la chaîne pourrait entraîner l’utilisation d’un gTLD pour faciliter le harcèlement ou la cyberintimidation Exemples de chaînes identifiées par le GAC comme appartenant à ce groupe dans le communiqué de Beijing de l’ICANN46⁸⁴ : .fail, .gripe, .sucks, .wtf	1-9
4	Fonctions intrinsèquement gouvernementales	La chaîne est associée à une fonction qui appartient intrinsèquement au domaine gouvernemental, comme les branches militaires Exemples de chaînes identifiées par le GAC comme appartenant à ce groupe dans le communiqué de Beijing de l’ICANN46⁸⁵ : .army, .navy, .airforce	1-8 et 10

7.8.2.3 PIC à des fins de protection

Les dix PIC à des fins de protection comprennent l’obligation pour les titulaires de nom de domaine de se conformer aux lois applicables, de mettre en œuvre des mesures de sécurité appropriées, de fournir des coordonnées, de posséder les identifiants nécessaires et de signaler les changements importants apportés aux identifiants, entre autres obligations. Les PIC à des fins de protection sont présentés dans le tableau suivant :

Tableau 7-2 Types de PIC à des fins de protection

PIC à des fins de protection	Texte des PIC à des fins de protection
1	L’opérateur de registre inclura une disposition dans ses contrats entre l’opérateur de registre et le bureau d’enregistrement qui demande aux bureaux d’enregistrement d’inclure dans leurs contrats l’obligation pour les titulaires de nom de domaine de respecter toutes les lois applicables, y compris celles liées à la confidentialité, la collecte de données, la protection des consommateurs (y compris en matière de pratiques trompeuses et mensongères), le prêt équitable, le recouvrement de dettes, l’agriculture biologique, la divulgation de données et la divulgation d’informations financières.
2	L’opérateur de registre intègrera une disposition dans ses contrats avec les bureaux d’enregistrement exigeant à ces derniers d’informer les titulaires de noms de domaine, au moment de l’enregistrement, de l’obligation de se conformer à toutes les lois applicables.
3	L’opérateur de registre intègrera une disposition dans ses contrats avec les bureaux d’enregistrement qui oblige ces derniers à intégrer dans leur contrat d’enregistrement une disposition exigeant aux titulaires de nom de domaine qui collectent et conservent des données sensibles en matière de santé et des données financières de mettre en œuvre des mesures de sécurité appropriées et proportionnées à l’offre de ces services, telles que définies par les lois applicables.
4	L’opérateur de registre tracera de façon proactive un chemin clair pour la création d’une relation de travail avec les organes de réglementation ou organes d’autorégulation de l’industrie pertinents en publiant un point de contact et en invitant ces organes à établir un canal de communication, y compris dans le but de faciliter le développement d’une stratégie visant à atténuer les risques d’activités frauduleuses et illégales.
5	L’opérateur de registre intègrera une disposition dans ses contrats entre opérateur de registre et bureaux d’enregistrement visant à demander aux opérateurs de registre d’inclure dans leurs contrats de registre une disposition demandant aux titulaires de noms de domaine de fournir les coordonnées de contacts administratifs, qui doivent être tenues à jour, pour la notification de réclamations ou de rapports en matière d’enregistrements abusifs, ainsi que des détails de contact des organismes de réglementation et des organismes d’autorégulation de l’industrie pertinents au sein de leur principal siège d’activité.
6	L’opérateur de registre intègrera une disposition dans ses contrats entre opérateurs de registre et bureaux d’enregistrement visant à demander aux opérateurs de registre d’inclure dans leurs contrats de registre une disposition demandant de montrer que les titulaires de noms de domaine possèdent toutes les autorisations nécessaires, les chartes, les licences, et/ou d’autres qualifications de participation au secteur associé à la chaîne de TLD.
7	Si l’opérateur de registre reçoit une réclamation exprimant un doute sur l’authenticité des licences ou des identifiants, les opérateurs de registre devront consulter les autorités nationales pertinentes ou leurs équivalents pour en vérifier l’authenticité.
8	L’opérateur de registre intègrera une disposition dans ses contrats entre opérateurs de registre et bureaux d’enregistrement qui demande aux bureaux d’enregistrement d’inclure dans leurs contrats de registre une disposition demandant aux titulaires de noms de domaine de signaler tous les changements importants concernant la validité des autorisations, des chartes, des licences, et/ou d’autres identifiants des titulaires pour la participation au secteur associé à la chaîne de TLD de façon à s’assurer qu’ils continuent à se conformer aux réglementations appropriées, aux exigences réglementaires et conduisent généralement leurs activités dans l’intérêt des consommateurs.
9	L’opérateur de registre élaborera et publiera des politiques d’enregistrement afin de minimiser le risque de cyberintimidation et/ou de harcèlement.
10	L’opérateur de registre inclura une disposition dans ses contrats entre opérateurs de registre et bureaux d’enregistrement qui exige que les bureaux d’enregistrement incluent dans leurs contrats d’enregistrement une disposition exigeant une déclaration selon laquelle le titulaire de nom de domaine prendra des mesures raisonnables pour éviter de faire une fausse déclaration ou d’impliquer faussement que le titulaire ou son entreprise sont affiliés, parrainés ou approuvés par un ou plusieurs pays ou par les forces militaires d’un gouvernement si une telle affiliation, parrainage ou approbation n’existe pas.

7.8.3 Engagements volontaires des opérateurs de registre

Il peut y avoir des circonstances dans lesquelles la multitude de mesures de protection intégrées au processus de candidature et au contrat de registre, y compris les PIC obligatoires et les PIC à des fins de protection, ne règlent pas complètement une question précise concernant une candidature ou un contrat de registre proposé. Dans ces circonstances, un candidat peut envisager de proposer un RVC pour aider à résoudre le problème potentiel.

La décision d’un candidat de proposer un RVC est en principe facultative, sauf si l’ICANN le juge nécessaire pour lever une objection ou donner suite à un avis de consensus du GAC (voir l’explication dans la Section 7.8.3.2.3.1 Situation 1 : Engagements pris pour donner suite à des objections ou à un avis de consensus du GAC). Ces engagements seront contractuellement contraignants s’ils sont approuvés et inclus dans le contrat de registre. Les RVC peuvent varier, augmentant potentiellement les engagements liés à l’intérêt public ou codifiant les engagements des parties prenantes. Un RVC pourrait également instituer des mesures à des fins de protection qui pourraient aider à surmonter une préoccupation d’un tiers concernant une chaîne faisant l’objet d’une candidature à un nouveau gTLD. Par exemple, les candidats peuvent proposer des RVC en réponse à des objections, à des alertes précoces des membres du GAC ou à des avis consensuels du GAC, à des commentaires sur la candidature ou à d’autres questions qui pourraient avoir un impact négatif sur le processus d’évaluation de la candidature. Pour en savoir plus, voir la Section 3.8 Demande de modification de dossier de candidature et le Module 4 Commentaires de la communauté, objections et recours.

Un candidat peut inclure un RVC proposé dans sa candidature ou demander à en ajouter une ultérieurement via le processus de demande de changement de candidature (voir la Section 3.8), qui comprend une période de commentaires sur la candidature et d’autres conditions.

Tous les RVC proposés soumis avec la candidature ou comme demande de changement de candidature apparaîtront dans la section des candidatures publiques, accessible sur le site Web du programme des nouveaux gTLD⁸⁶, et seront ouverts au public pour révision et commentaires pendant la période de commentaires sur les candidatures (voir la Section 4.1 Commentaires sur les candidatures).

7.8.3.1 Facteurs à prendre en compte avant de proposer un RVC

Avant de décider de proposer un RVC, les candidats sont encouragés à examiner les statuts constitutifs de l’ICANN, les contrats pertinents de l’ICANN, y compris, mais sans s’y limiter, le contrat de registre et le contrat d’accréditation de bureau d’enregistrement (RAA), ainsi que les politiques de consensus de l’ICANN et les politiques temporaires. Les candidats et les tiers qui expriment des préoccupations au sujet de toute candidature doivent examiner si les dispositions normalisées préexistantes pourraient fournir des garanties suffisantes pour la chaîne faisant l’objet d’une candidature à un nouveau gTLD, afin d’éviter la nécessité d’évaluer et de mettre en œuvre un RVC personnalisé.⁸⁷

La communauté de l’ICANN a recommandé à l’ICANN d’inclure les PIC obligatoires dans chaque contrat de registre et d’inclure également les PIC à des fins de protection (le cas échéant) dans les contrats de registre pour les chaînes identifiées au cours du processus d’évaluation comme appartenant aux quatre groupes de chaînes définis dans la Section 7.8.2 Engagements en faveur de la protection de l’intérêt public. Dans certains cas, il peut être possible pour un candidat qui n’est pas tenu de mettre en œuvre les PIC à des fins de protection de proposer d’utiliser un ou plusieurs PIC à des fins de protection approuvés en tant que RVC afin de résoudre les problèmes ou préoccupations soulevés concernant une chaîne faisant l’objet d’une candidature à un nouveau gTLD.

De plus, un candidat doit déterminer si l’exécution d’un RVC proposé nécessite l’exploitation d’un service de registre supplémentaire.⁸⁸ Si tel est le cas, le candidat doit se concerter avec le fournisseur de services de registre (RSP) sélectionné sur pour discuter de la mise en œuvre d’un tel service de registre supplémentaire, qui doit être dans le cadre du programme RSP et recevoir l’approbation de l’ICANN. Si l’ICANN identifie une proposition de RVC dont la mise en œuvre nécessite un service de registre supplémentaire, et qu’un tel service de registre n’a pas encore été approuvé pour le RSP sélectionné par le candidat, alors le RSP doit en demander l’approbation à l’ICANN via le programme RSP avant que l’ICANN envisage d’approuver l’engagement proposé en tant que RVC.⁸⁹

Toute proposition de RVC incompatible avec les statuts constitutifs, les politiques et les contrats de l’ICANN ne sera pas approuvée, comme expliqué dans la Section 7.8.3.3 Critères d’évaluation des engagements de l’opérateur de registre.

Un candidat est encouragé à examiner s’il existe d’autres moyens, distincts du contrat de registre, qui permettraient de résoudre les problèmes soulevés concernant la chaîne faisant l’objet d’une candidature à un nouveau gTLD. Par exemple, un candidat peut envisager de répondre aux préoccupations, éventuellement en consultation avec le tiers qui les a soulevées, en incluant des engagements pertinents dans ses propres politiques de registre, ses propres conditions d’utilisation ou dans le cadre d’un accord distinct entre le candidat et le tiers. Un tel contrat séparé ne sera pas exécuté par l’ICANN, et un tel tiers ne sera pas un « tiers bénéficiaire » du contrat de registre avec l’ICANN.⁹⁰

7.8.3.2 Évaluation des engagements de l’opérateur de registre

Chaque RVC proposé pour chaque chaîne faisant l’objet d’une candidature à un nouveau gTLD (et ses variantes de chaînes allouables faisant l’objet d’une candidature, le cas échéant) sera soumis à l’évaluation et à l’approbation de l’ICANN via l’évaluation des engagements de l’opérateur de registre (RCE). La RCE a pour but de déterminer si un engagement proposé satisfait à tous les critères d’évaluation énoncés dans les critères de la RCE (voir la Section 7.8.3.3) pour l’inclure dans le contrat de registre.

Chaque politique d’enregistrement communautaire proposée pour l’inclure dans le contrat de registre applicable sera également soumise à l’évaluation des engagements de l’opérateur de registre (voir la Section 7.8.4 Politiques d’enregistrement communautaire). Voir la Section 7.8.3.5 RVC proposés pour les variantes de chaînes pour de plus amples informations sur cette évaluation pour les variantes de chaînes.

Dans la candidature, les candidats qui souhaitent soumettre des propositions de RVC et de politiques d’enregistrement communautaire pour les inclure dans le contrat de registre doivent répondre à une série de questions conçues pour faciliter l’évaluation de l’ICANN (voir l’Annexe 1 Questions du dossier de candidature).

Un candidat qui soumet des RVC ou des politiques d’enregistrement communautaire est tenu de payer un paiement unique qui couvre le coût de l’évaluation des engagements de l’opérateur de registre. Pour en savoir plus sur les frais associés à la RCE, voir la Section 3.3.2 Évaluations conditionnelles.

7.8.3.2.1 Les candidats doivent identifier l’objet du RVC proposé

Le candidat doit fournir des renseignements généraux pour expliquer pourquoi le RVC proposé est pertinent, important et nécessaire au soutien de sa candidature. L’ICANN effectuera un contrôle d’exhaustivité pour cette exigence lorsque le RVC sera proposé par le candidat, avant l’évaluation des engagements de l’opérateur de registre. Ces renseignements donnent un contexte pour le RVC proposé et, dans certains cas, peuvent être utiles si des ajustements aux conditions générales du RVC s’avéraient nécessaires pour atteindre les objectifs de l’engagement proposé tout en répondant aux critères pour qu’un RVC soit inclus dans le contrat de registre, comme expliqué à la Section 7.8.3.3 Critères d’évaluation des engagements de l’opérateur de registre.

Par exemple, si un RVC proposé répond à une objection d’un tiers, le candidat doit identifier l’objection spécifique et l’objecteur devrait fournir les références pertinentes ou les liens vers l’objection ainsi que d’autres détails pertinents. Ces détails peuvent inclure, sans s’y limiter, la façon dont le candidat a élaboré le RVC proposé pour répondre à la préoccupation, si le candidat a consulté l’objecteur dans l’élaboration du RVC proposé, et les moyens et systèmes en place pour assurer la conformité avec le RVC.

7.8.3.2.2 Règle générale : l’évaluation des RVC proposés par l’opérateur de registre n’a pas d’incidence sur la progression des candidatures

Dans des circonstances autres que celles identifiées à la Section 7.8.3.2.3 Exception: l’évaluation des RVC proposés par l’opérateur de registre a des répercussions sur la progression de la candidature, l’évaluation des engagements de l’opérateur de registre des RVC proposés n’aura aucune incidence sur la capacité de la candidature de continuer. En dehors de ces circonstances exceptionnelles, l’évaluation des engagements de l’opérateur de registre n’a aucune incidence sur l’évaluation de la capacité d’un candidat ou d’une candidature de passer à la signature du contrat, mais détermine simplement si le RVC proposé satisfait aux critères d’inclusion dans le contrat de registre applicable si la candidature avance.

L’évaluation ne déterminera pas si le RVC proposé répond avec succès aux préoccupations des tiers. Bien que l’ICANN puisse prendre en compte les commentaires sur la candidature et d’autres contributions et consulter des tiers pendant l’évaluation, ces derniers ne seront généralement pas impliqués dans cette évaluation.

Les candidats qui ont l’intention de proposer un RVC pour résoudre une objection ou une autre préoccupation de tiers sont encouragés à se concerter d’abord avec la ou les parties concernées. S’ils parviennent à se mettre d’accord sur un RVC qui résout le problème avant de soumettre une demande de changement de candidature, cela peut empêcher l’ICANN d’évaluer un RVC proposé qui, selon le tiers, ne résout pas adéquatement le problème concernant le gTLD faisant l’objet d’une candidature. Si un candidat propose un RVC au cours de la procédure d’objection pour résoudre l’objection ou la préoccupation d’un tiers, et que ce RVC est approuvé par l’ICANN, l’objecteur ou un autre tiers doit décider séparément si et comment continuer à donner suite à ses préoccupations.

Par exemple, si une candidature propose un RVC pour répondre à une objection pendant la période de « réflexion », une fois que l’évaluation des engagements de l’opérateur de registre est terminée – soit en approuvant ou en rejetant le RVC – l’objecteur peut alors décider s’il doit poursuivre l’objection. Pour donner un autre exemple, un candidat peut proposer un RVC comme demande de changement de candidature après avoir reçu une alerte précoce d’un membre du GAC afin de réduire le risque de recevoir ultérieurement des avis consensuels du GAC qui pourraient entraver la progression de la candidature. Dans ce cas, l’évaluation ne permettrait pas de déterminer si le RVC proposé serait susceptible de dissiper les préoccupations soulevées dans l’alerte précoce des membres du GAC, mais l’approbation du RVC pourrait éclairer les discussions du GAC sur l’émission d’un avis consensuel au Conseil d’administration concernant la candidature ou la chaîne faisant l’objet d’une candidature à un nouveau gTLD.

Si un candidat envisage de proposer un RVC en tant que demande de changement de candidature pour répondre à la préoccupation d’un tiers, le candidat doit garder à l’esprit les délais et les processus pertinents pour les objections, les avis consensuels du GAC, les alertes précoces des membres du GAC, les commentaires concernant la candidature, etc., s’il veut que le RVC soit pris en compte dans ces processus (voir le Module 4 Contributions de la communauté, objections et recours). Comme mentionné ci-dessus, tous les RVC proposés qui sont présentés comme demande de changement de candidature (voir la Section 3.8) sont soumis à une période de commentaires sur les candidatures.

7.8.3.2.3 Exception: l’évaluation des RVC proposés par l’opérateur de registre a des répercussions sur la progression de la candidature

Le résultat de l’évaluation des engagements de l’opérateur de registre pour un RVC proposé ne peut avoir d’incidence sur la progression de la candidature que dans deux scénarios. Voir la Section 3.9 Statut d’une candidature pour savoir à quoi s’attendre lorsqu’une candidature ne peut plus continuer.

7.8.3.2.3.1 Situation 1: engagements pris pour donner suite à des objections ou à un avis de consensus du GAC

Si un RVC est reconnu par l’ICANN pour résoudre une objection ou répondre à des avis de consensus du GAC, il sera soumis à des restrictions accrues pendant le processus de candidature et après l’exécution du contrat.

Bien que les RVC proposés dans cette circonstance soient étiquetés comme « volontaires », l’ICANN reconnaît qu’ils ne sont pas proposés uniquement à la discrétion du candidat, mais qu’ils sont des conditions nécessaires pour que la candidature soit traitée.

Un RVC doit être approuvé par l’ICANN via l’évaluation des engagements de l’opérateur de registre pour résoudre une objection ou répondre aux avis consensuels du GAC. Sans une telle approbation, la candidature ne peut pas continuer.⁹¹ Voir la Section 4.5.8.13 Objections et engagements volontaires des opérateurs de registre et la Section 4.3.3 Avis de consensus du GAC et engagements volontaires des opérateurs de registre.

Les RVC proposés pour surmonter les objections ou les avis consensuels du GAC sont ouverts au public pour révision et commentaires via une période de commentaires sur les candidatures. Si les négociations avec l’ICANN conduisent à des changements pour approbation, la proposition originale et les versions approuvées par l’ICANN seront publiées pour commentaires. Pour de plus amples informations, reportez-vous à la Section 3.8 Demande de modification de dossier de candidature.

En raison de l’objectif spécifique de ces RVC, les candidats et les opérateurs de registre ne seront généralement pas en mesure, sauf circonstances extraordinaires, de modifier ou de supprimer sensiblement ces engagements une fois qu’ils auront été approuvés par l’ICANN. Ces engagements devraient être inclus dans une sous-section distincte de la Spécification 11 afin de préciser qu’ils sont soumis à des restrictions accrues. Voir la Section 7.8.3.4 Ajouts, modifications et suppressions de RVC.

7.8.3.2.3.2 Situation 2 : demande de modification de dossier de candidature à la suite d’un rejet de RVC

Si un candidat propose un RVC dans sa présentation initiale et qu’il ne réussit pas l’évaluation des engagements de l’opérateur de registre, il doit déposer une demande de modification de dossier de candidature afin de modifier ou de retirer le RVC proposé pour que la candidature puisse être traitée. La demande de modification de dossier de candidature sera examinée par l’ICANN selon les critères publiés (voir la Section 3.8).

Sauf circonstances extraordinaires, si le candidat ne soumet pas de demande de modification au dossier de candidature dans les 30 jours suivant la notification indiquant que le RVC proposé n’a pas été retenu à l’issue de l’évaluation, la candidature ne pourra pas être traitée.

7.8.3.2.4 Calendrier d’évaluation des engagements de l’opérateur de registre et notification des résultats

En ce qui concerne les délais d’évaluation des RVC proposés dans la situation 1 : engagements des opérateurs de registre visant à répondre à des objections ou à des avis de consensus du GAC (voir la Section 7.8.3.2.3.1) et les politiques d’enregistrement communautaire (voir la Section 7.8.4) proposées par les candidats communautaires participant à l’évaluation de la priorité communautaire (CPE), l’évaluation des engagements des opérateurs de registre sera effectuée dès que possible une fois que l’ICANN aura reçu les frais applicables. L’ICANN reconnaît l’importance de mener la RCE en temps opportun pour s’assurer que les processus dépendants puissent se dérouler sans retard.

Dans tous les autres cas, l’évaluation des engagements de l’opérateur de registre doit avoir lieu plus tard dans le processus de candidature, avant la signature du contrat, après que les frais d’évaluation auront été reçus par l’ICANN.

Sauf circonstances extraordinaires, le délai estimatif pour la RCE est de 60 à 90 jours.

L’ICANN publiera et mettra régulièrement à jour les résultats de la RCE de tous les RVC soumis et des politiques d’enregistrement communautaire sur le site Web du programme des nouveaux gTLD et informera les candidats respectifs des résultats.⁹²

7.8.3.3 Critères d’évaluation des engagements de l’opérateur de registre

L’ICANN rejettera toute proposition de RVC qui ne soit pas compatible avec les statuts constitutifs de l’ICANN.⁹³ Voir le critère 5 dans le tableau ci-dessous pour plus de détails.

L’ICANN évaluera chaque RVC proposé sur la base des critères suivants, et l’approbation dépendra du respect de tous ces critères. Les candidats doivent suivre les directives associées et tenir compte de la pertinence de chaque critère lors de la préparation de leur RVC.

Chaque engagement de la politique d’enregistrement communautaire (voir la Section 7.8.4) qui est proposé pour être inclus dans le contrat de registre applicable doit également satisfaire à tous les critères d’évaluation des engagements des opérateurs de registre pour être approuvé.

Voir les instructions pour les questions 150-155 du Questionnaire 7 gTLD communautaires et du Questionnaire 11 Engagements volontaires des opérateurs de registre (RVC) à l’Annexe 1 Questions du dossier de candidature pour connaître l’approche préconisée pour la rédaction des politiques d’enregistrement communautaire proposées, ainsi que des engagements volontaires qui seront évalués par l’intermédiaire de la RCE.

Comme indiqué à la Section 7.8.3.1 Facteurs à prendre en compte avant de proposer un RVC, les candidats peuvent envisager d’inclure certains engagements en dehors du contrat de registre, dans des véhicules tels que les politiques de registre propres au candidat, les conditions d’utilisation ou dans le cadre d’un contrat distinct entre le candidat et un tiers. Tout engagement de ce genre qui n’est pas proposé pour l’inclure dans le contrat de registre ne sera pas soumis à l’évaluation des engagements de l’opérateur de registre.⁹⁴

Tableau 7-3 Critères pour l’évaluation des RVC

Critère	Description	Orientation
Le RVC doit clairement indiquer quels engagements « doivent » être mis en œuvre.	Un RVC proposé doit être un engagement ou une obligation contraignante et doit indiquer clairement quels sont les engagements que l’opérateur de registre « doit » mettre en œuvre, et non quels sont ceux que l’opérateur de registre « peut » ou « pourrait » mettre en œuvre.	Utiliser un langage catégorique : éviter les qualificatifs et exprimer de la certitude en décrivant le RVC proposé. Énoncer ce que le candidat propose et que l’opérateur de registre « doit » faire.
Le RVC doit être clair, détaillé, compris entre le candidat et l’ICANN, objectif et mesurable.	Chaque RVC doit indiquer clairement ce que le RVC exige de l’opérateur du registre, ce niveau de détail étant nécessaire pour garantir que le RVC soit applicable dans la pratique. Le RVC doit être clair, de sorte qu’en cas de problème de conformité contractuelle, les actions de l’opérateur de registre puissent être mesurées par rapport au langage objectif du RVC afin de déterminer si l’opérateur de registre s’y est conformé ou non.	Être clair : utiliser un langage simple et direct, facile à comprendre. Être précis et spécifique : éviter les déclarations vagues ou ambiguës qui pourraient conduire à des malentendus. Être détaillé : préciser quelle entité sera responsable de la mise en œuvre du RVC ; décrire les actions, les étapes ou les tâches requises pour mettre en œuvre le RVC ; décrire les actions spécifiques que l’opérateur de registre doit entreprendre pour remplir le RVC. Prendre en considération le suivi interne de la conformité de l’opérateur de registre : décrire comment l’opérateur de registre surveillera et évaluera la mise en œuvre et le respect du RVC.
Le RVC doit spécifier toutes les limitations applicables.	Le candidat doit fournir des détails sur la question de savoir si, comment et pourquoi un RVC proposé est limité dans le temps, la durée, la portée ou tout autre facteur, le cas échéant.	Définir les limites applicables au RVC proposé : par exemple, si un RVC est limité dans le temps, il doit indiquer s’il s’appliquera tout au long de la durée de vie du gTLD, uniquement pendant une période de lancement spécifique, ou pendant toute autre période définie.
Le RVC ne doit⁹⁵ pas faire double emploi ou être contraire aux exigences découlant de la législation applicable, des contrats de l’ICANN, des politiques de consensus ou des politiques temporaires de l’ICANN.	Un RVC ne doit pas faire double emploi avec les obligations qui s’appliqueraient à l’opérateur de registre en vertu du contrat de registre, des politiques de consensus et politiques temporaires de l’ICANN, et de la loi applicable. Un RVC n’est pas approuvé s’il est contraire aux contrats et aux politiques applicables de l’ICANN. L’opérateur de registre doit être en mesure de se conformer au RVC tout en se conformant aux contrats et politiques de l’ICANN applicables. Un RVC ne doit pas non plus empêcher d’autres parties (par exemple, les bureaux d’enregistrement) de se conformer aux contrats et politiques applicables de l’ICANN.⁹⁶ Si la performance d’un RVC proposé nécessite l’opération d’un service de registre supplémentaire, ce service doit être évalué par le biais du programme RSP et approuvé par l’ICANN avant que l’ICANN envisage d’approuver l’engagement proposé en tant que RVC.	Éviter le double emploi : avant de proposer un RVC, un candidat doit examiner attentivement les dispositions du contrat de registre, du contrat d’accréditation de bureau d’enregistrement, ainsi que les politiques de consensus de l’ICANN et les politiques temporaires pour voir s’il existe déjà une telle obligation. Dans l’affirmative, le candidat ne doit pas proposer le RVC. Améliorations apportées aux obligations contractuelles ou aux obligations liées aux politiques : un RVC peut renforcer, compléter ou étendre les exigences du contrat de registre et d’autres obligations applicables, pour autant que le RVC ne soit pas contraire à ces obligations applicables. Le RVC doit s’appliquer parallèlement à d’autres exigences contractuelles et politiques : un RVC ne peut pas engager un opérateur de registre à prendre des mesures qui contredisent les exigences du contrat de registre, des politiques de consensus de l’ICANN ou des politiques temporaires applicables. un RVC ne doit pas engager un opérateur de registre à inclure dans ses contrats entre l’opérateur de registre et le bureau d’enregistrement des gTLD des conditions qui obligeraient les bureaux d’enregistrement à prendre des mesures en violation du contrat d’accréditation de bureau d’enregistrement, des politiques de consensus de l’ICANN applicables, des politiques temporaires, ou de la loi applicable.

Critère	Description	Orientation
Le RVC doit être compatible avec les statuts constitutifs de l’ICANN.	L’ICANN ne peut approuver un RVC incompatible avec ses statuts constitutifs.	Un domaine particulièrement important dans le cadre de ce critère est de savoir si un RVC proposé limiterait le contenu ou l’utilisation d’une chaîne faisant l’objet d’une candidature à un nouveau gTLD.⁹⁷ Si un RVC proposé mettait l’ICANN en position de devoir faire respecter la conformité d’un opérateur de registre à une restriction sur le contenu dans le gTLD applicable, cette proposition de RVC sera rejetée.⁹⁸ Le « contenu » est la substance d’un message envoyé, tandis que les facteurs non restrictifs en matière de contenu pourraient inclure, sans s’y limiter, comment et quand le contenu est remis et par qui. La distinction entre les engagements restrictifs et les engagements non restrictifs en matière de contenu dans le contexte des RVC implique de comprendre la portée, l’orientation et l’impact des engagements : Portée : les engagements non restrictifs en matière de contenu pourraient se concentrer sur les aspects opérationnels, procéduraux et techniques de l’enregistrement et de la gestion des noms de domaine, plutôt que sur des contenus spécifiques du gTLD. Domaine d’intervention : les engagements non restrictifs en matière de contenu pourraient porter sur le respect des normes du secteur, les conditions d’éligibilité à l’enregistrement et les procédures qui ne sont pas spécifiques au contenu du gTLD. Impact : des engagements non restrictifs en matière de contenu pourraient influencer la façon dont les noms de domaine sont gérés et l’environnement opérationnel dans lequel ils existent.

Critère

Description

Orientation

Le RVC doit être compatible avec les statuts constitutifs de l’ICANN.

L’ICANN ne peut approuver un RVC incompatible avec ses statuts constitutifs.

Un domaine particulièrement important dans le cadre de ce critère est de savoir si un RVC proposé limiterait le contenu ou l’utilisation d’une chaîne faisant l’objet d’une candidature à un nouveau gTLD.⁹⁷ Si un RVC proposé mettait l’ICANN en position de devoir faire respecter la conformité d’un opérateur de registre à une restriction sur le contenu dans le gTLD applicable, cette proposition de RVC sera rejetée.⁹⁸

Le « contenu » est la substance d’un message envoyé, tandis que les facteurs non restrictifs en matière de contenu pourraient inclure, sans s’y limiter, comment et quand le contenu est remis et par qui. La distinction entre les engagements restrictifs et les engagements non restrictifs en matière de contenu dans le contexte des RVC implique de comprendre la portée, l’orientation et l’impact des engagements :

Portée : les engagements non restrictifs en matière de contenu pourraient se concentrer sur les aspects opérationnels, procéduraux et techniques de l’enregistrement et de la gestion des noms de domaine, plutôt que sur des contenus spécifiques du gTLD.

Domaine d’intervention : les engagements non restrictifs en matière de contenu pourraient porter sur le respect des normes du secteur, les conditions d’éligibilité à l’enregistrement et les procédures qui ne sont pas spécifiques au contenu du gTLD.

Impact : des engagements non restrictifs en matière de contenu pourraient influencer la façon dont les noms de domaine sont gérés et l’environnement opérationnel dans lequel ils existent.

7.8.3.4 Ajouts, modifications et suppressions de RVC

Si un RVC proposé est ajouté ou modifié après la date de dépôt de la candidature et avant la signature du contrat de registre applicable, il sera soumis au processus de demande de changement de candidature, qui comprend une période de commentaires sur la candidature pour les changements importants, comme indiqué à la Section 3.8 Demande de modification de dossier de candidature. Pour connaître les différents types de périodes de commentaires sur les RVC proposées, consulter la Section 3.8.3 Types de demandes de modification de dossier de candidature et processus requis.

Sauf circonstances extraordinaires, les RVC établis pour répondre à la situation 1 : engagements pris pour donner suite à des objections ou à un avis de consensus du GAC (voir la Section 7.8.3.2.3.1) ne peuvent généralement pas être modifiés substantiellement ou supprimés avant l’exécution du contrat.

L’ICANN n’a actuellement pas de processus permettant aux opérateurs de registre de demander la modification des RVC dans les contrats de registre qui ont été exécutés. L’ICANN peut proposer un processus permettant à la communauté de donner son avis sur les demandes de modification des RVC présentées par les opérateurs de registre après la signature du contrat.

7.8.3.5 RVC proposé pour des variantes de chaînes

Si un candidat cherche des variantes de chaînes allouables d’une chaîne principale faisant l’objet d’une candidature et prévoit de proposer un RVC avec sa candidature ou dans le cadre d’une demande de modification de dossier de candidature, le RVC proposé doit s’appliquer à la fois aux chaînes principale et aux variantes de chaîne et subir la même évaluation. Cette exigence s’applique également à la politique d’enregistrement communautaire proposée pour les chaînes principales et les variantes faisant l’objet d’une candidature à un gTLD communautaire expliquée à la Section 7.8.4 Politiques d’enregistrement communautaire.

7.8.4 Politiques d’enregistrement communautaire

Les politiques d’enregistrement communautaire pour les contrats de registre (politiques d’enregistrement communautaire) sont des conditions du contrat de registre que les opérateurs de registre de gTLD doivent imposer aux titulaires de noms de domaines au sein des gTLD communautaires. Lorsqu’une candidature à un gTLD communautaire est déposée (candidature communautaire), les candidats doivent proposer des politiques d’enregistrement communautaire à inclure dans les contrats de registre applicables. Au minimum, ces politiques doivent couvrir l’admissibilité des titulaires de nom de domaine et la sélection des noms.

Comme dans le cas des RVC proposés pour les inclure dans le contrat de registre, une politique d’enregistrement communautaire proposée par un candidat pour l’inclure dans le contrat de registre applicable doit être évaluée conformément aux critères de la RCE (voir la Section 7.8.3.3). Les résultats de son évaluation influeront sur la possibilité de faire avancer une candidature communautaire. Plus précisément, un candidat doit avoir approuvé les politiques d’enregistrement communautaire comme condition préalable pour que sa candidature puisse participer à l’évaluation de la priorité communautaire (CPE), une option disponible uniquement pour les candidatures communautaires afin de résoudre un litige.⁹⁹ Toutefois, l’approbation est requise non seulement pour qu’une candidature communautaire puisse participer à la CPE, mais aussi pour avancer dans le processus de candidature après la RCE. Autrement dit, s’il n’y a pas de politique d’enregistrement communautaire qui puisse être approuvée par l’ICANN pour l’inclure dans le contrat de registre, la candidature communautaire ne peut pas avancer, qu’elle soit en litige ou que le candidat choisisse de participer à la CPE.¹⁰⁰

Une politique d’enregistrement communautaire répondant aux critères de la RCE (voir la Section 7.8.3.3) sera incluse dans le contrat de registre applicable si la chaîne faisant l’objet de la candidature passe à l’étape de délégation. Se reporter aux questions 150-155 du Questionnaire 7 - gTLD communautaires à l’Annexe 1 Questions du dossier de candidature pour connaître en détail les éléments à respecter lors de la rédaction des projets de politiques d’enregistrement communautaire qui seront évalués dans le cadre du RCE. Comme pour les PIC et les RVC, une politique d’enregistrement communautaire approuvée sera soumise à la surveillance du département de la conformité contractuelle de l’ICANN. Les politiques d’enregistrement communautaire incluses dans le contrat de registre sont soumises à la procédure de règlement de litiges relatifs à des restrictions à l’enregistrement (RRDRP) et à la procédure de demande de changement d’un gTLD communautaire.¹⁰¹

En outre, les opérateurs de gTLD communautaires peuvent mettre en œuvre toute politique d’enregistrement supplémentaire souhaitée en dehors du contrat de registre, à condition que les politiques ne soient pas contraires aux exigences des contrats et aux politiques de l’ICANN applicables.¹⁰²

7.8.5 Mise en application par l’ICANN

L’ICANN veillera à la conformité avec les PIC, les RVC et les politiques d’enregistrement communautaire évaluées et approuvées conformément aux critères de la RCE (voir la Section 7.8.3.3) et incluses dans le contrat de registre comme toute autre obligation contractuelle. La PICDRP peut être utilisée pour traiter des plaintes alléguées selon lesquelles un opérateur de registre pourrait ne pas se conformer à un ou plusieurs de ses PIC ou des RVC. La RRDRP peut être utilisée pour traiter des cas dans lesquels l’opérateur d’un gTLD communautaire s’écarte prétendument des politiques d’enregistrement communautaire énoncées dans le contrat de registre. Voir la Section 1.2.17 Procédures de règlement de litiges après délégation pour de plus amples détails sur le PICDRP et le RRDRP.

7.9 Vérification des fournisseurs de services de registre

L’ICANN vérifiera si le candidat a sélectionné un ou plusieurs RSP évalués dans le cadre de sa candidature. Si ce n’est pas le cas, une évaluation approfondie est disponible pour qu’un candidat fournisse les informations demandées concernant le ou les RSP choisis. L’ICANN examinera également la volonté du ou des RSP de soutenir le gTLD, y compris leur capacité à soutenir le gTLD avec des service de registre supplémentaires. Voir la Section 3.1.10 Sélection du fournisseur de services de registre.

7.10 Évaluation de la similarité de chaînes

L’objectif de l’évaluation de la similarité des chaînes est d’éviter la confusion de l’utilisateur et la perte de confiance dans le DNS résultant de la délégation de chaînes visuellement similaires. Les chaînes ou leurs variantes de chaînes ne doivent pas être visuellement similaires (définies ci-dessous) à un domaine de premier niveau existant ou à ses variantes de chaînes, ou à un nom bloqué ou à ses variantes de chaînes comme indiqué plus en détail dans la Section 7.10.1 Portée de l’évaluation de la similarité de chaînes (voir la Section 7.2.1 Noms bloqués). Les variantes de chaînes sont calculées à l’aide de la version applicable des règles de génération d’étiquettes pour la zone racine (voir la Section 3.1.8.3.1.1 Version applicable des RZ-LGR, et scripts et langues pris en charge)¹⁰³.

Une candidature est basée sur la chaîne principale faisant l’objet de la candidature ou sur le gTLD existant. Chaque chaîne primaire fait partie d’un ensemble de variantes de chaînes et en crée un.¹⁰⁴ Une candidature peut contenir une ou plusieurs chaînes du même ensemble de variantes de chaînes (voir la Section 3.1.9 Noms de domaine internationalisés), selon le choix du candidat et avec d’autres contraintes applicables.¹⁰⁵ Pour toute candidature, l’évaluation de la similarité des chaînes est effectuée en utilisant toutes les chaînes de l’ensemble de variantes de chaîne même si beaucoup de ces chaînes ne font pas l’objet de la candidature, comme indiqué ci-dessous.

Dans ce contexte, le terme « visuellement similaire » s’entend de chaînes prêtant à confusion visuelle, plus précisément « des chaînes si visuellement similaires qu’elles créent un risque de confusion pour l’utilisateur si plus d’une d’entre elles est déléguée dans la zone racine ».¹⁰⁶ L’évaluation de similarité des chaînes sera menée par un panel indépendant d’évaluation de la similarité des chaînes. Si le panel constate que les chaînes faisant l’objet de la candidature ou les variantes des chaînes sont visuellement similaires, elles seront marquées et exclues de la procédure ou formeront des ensembles conflictuels. L’évaluation de la similarité des chaînes qui se produit pendant l’évaluation de la chaîne complète le processus d’objection relatif à des chaînes prêtant à confusion. Voir la Section 4.5 Objections et recours.

7.10.1 Portée de l’évaluation de la similarité de chaînes

L’évaluation de la similarité des chaînes implique une comparaison préliminaire de chaque chaîne faisant l’objet de la candidature et de ses variantes de chaînes avec les chaînes correspondantes et les variantes de chaînes dans les catégories pertinentes. L’évaluation est effectuée en utilisant toutes les chaînes de l’ensemble des variantes des chaînes, indépendamment du fait que le candidat se porte candidat ou non, comme détaillé ci-dessous. Les comparaisons sont effectuées pour déterminer si les chaînes sont visuellement similaires au point de créer une probabilité de confusion pour l’utilisateur¹⁰⁷ suivant les lignes directrices sur l’évaluation de la similarité des chaînes (voir la Section 7.10.2.3).

Pour chaque candidature, la chaîne principale (si elle n’a pas déjà été déléguée) et toutes les variantes de chaînes allouables¹⁰⁸ de son ensemble de variantes de chaînes seront comparées à ce qui suit :¹⁰⁹

les gTLD délégués existants et toutes leurs variantes de chaînes allouables et bloquées.
les chaînes de gTLD qui ont fait l’objet d’une candidature lors des séries de gTLD précédentes et qui sont toujours en cours de traitement,¹¹⁰ ainsi que toutes leurs variantes de chaînes allouables et bloquées.
les ccTLD existants évalués¹¹¹ ou délégués¹¹² avec succès et toutes leurs variantes de chaînes allouables et bloquées.
chaînes actuellement demandées en tant que ccTLD IDN¹¹³ (voir la Section 7.10.3.3 Chaînes similaires à des ccTLD évalués ou délégués avec succès ou à leurs variantes de chaînes) et toutes leurs variantes de chaînes allouables et bloquées.
D’autres chaînes gTLD faisant l’objet d’une candidature dans la série de candidatures en cours et toutes leurs variantes de chaînes allouables et bloquées.
Un sous-ensemble de noms bloqués¹¹⁴ et toutes leurs variantes de chaînes allouables et bloquées.
toutes les autres chaînes ASCII à deux caractères¹¹⁵ et toutes leurs variantes de chaînes allouables et bloquées.

En outre, pour chaque candidature, toutes ses variantes de chaînes bloquées dans son jeu de variantes de chaînes seront comparées à ce qui suit :

gTLD délégués existants et toutes leurs variantes de chaînes allouables.
Chaînes qui ont fait l’objet d’une candidature lors des séries précédentes du programme des nouveaux gTLD et qui sont toujours en cours de traitement,¹¹⁶ ainsi que toutes les variantes de chaînes allouables.
Les ccTLD existants évalués ou délégués avec succès et toutes leurs variantes de chaînes allouables.
Les chaînes faisant actuellement l’objet d’une candidature en tant que ccTLD IDN (voir la section 7.10.3.3 Chaînes similaires à des ccTLD évalués ou délégués avec succès ou à leurs variantes de chaînes) et toutes leurs variantes de chaînes allouables.
D’autres chaînes gTLD faisant l’objet d’une candidature dans la série de candidatures en cours et toutes leurs variantes de chaînes allouables et bloquées.
Un sous-ensemble de noms bloqués¹¹⁷ et toutes leurs variantes de chaînes allouables.
Toutes les autres chaînes ASCII à deux caractères et toutes leurs variantes de chaînes allouables.

À titre d’exception aux comparaisons énumérées ci-dessus, lors de l’évaluation de la similarité des chaînes, le panel d’évaluation de similarité des chaînes peut décider d’omettre certaines comparaisons avec les variantes de chaînes bloquées. Une telle décision doit être fondée sur les lignes directrices pour l’évaluation de la similarité des chaînes qui justifient une telle omission en invoquant un faible niveau de confusion entre les scripts comparés.

Le tableau ci-dessous résume les comparaisons que le panel d’évaluation de la similarité des chaînes effectuera, en fonction des catégories marquées « Oui ». Comme indiqué, le panel d’évaluation de la similarité de chaînes peut omettre les comparaisons pour les cellules grisées marquées « Oui* » s’il conclut que les scripts sont peu susceptibles d’être confondus, conformément aux lignes directrices sur l’évaluation de la similarité de chaînes (Section 7.10.2.3). Les comparaisons indiquées comme « Non » ne seront pas effectuées.

Tableau 7-4 Portée des comparaisons effectuées par le panel d’évaluation de la similarité des chaînes

Catégories pour comparaison		Chaîne faisant l’objet d’une candidature
Catégories pour comparaison		Chaîne principale	Toutes les variantes de chaînes allouables	Toutes les variantes de chaînes bloquées
gTLD existant Chaîne faisant l’objet d’une candidature à partir de la ou des séries précédentes du programme des nouveaux gTLD toujours en cours ccTLD existant IDN ccTLD demandé Une autre chaîne faisant l’objet d’une candidature Nom bloqué Tout ASCII à deux caractères	Chaîne principale	Oui	Oui	Oui*
	Toutes les variantes de chaînes allouables	Oui	Oui	Oui*
	Toutes les variantes de chaînes bloquées	Oui*	Oui*	Non

*Le panel d’évaluation de la similarité des chaînes peut omettre les comparaisons pour les cellules grisées marquées « Oui* » s’il conclut que les scripts sont peu susceptibles d’être confondus, conformément aux lignes directrices sur l’évaluation de la similarité des chaînes.

7.10.2 Méthodologie de l’évaluation de la similarité de chaînes

7.10.2.1 Mêmes chaînes principales ou variantes de chaîne

Les formes en majuscule et en minuscule des caractères ASCII sont considérées, et toute permutation entre majuscules et minuscules dans une chaîne peut être utilisée pour l’évaluation de la similarité des chaînes, par exemple, « EXEMPLE », « Exemple » ou « exemple ».

Les candidatures de différents candidats avec des chaînes du même ensemble de variantes de chaînes seront marquées comme identiques par le panel d’évaluation de la similarité des chaînes.

7.10.2.2 Regroupement de chaînes

Si la création de lots est requise, l’évaluation de la similarité des chaînes sera effectuée sur toutes les chaînes faisant l’objet d’une candidature avant l’établissement des lots prioritaires pour évaluation. Pour les candidatures identifiées comme faisant partie d’un ensemble conflictuel l’ICANN place toutes les chaînes de l’ensemble conflictuel dans le même lot selon la chaîne de priorité la plus élevée dans cet ensemble conflictuel.

7.10.2.3 Lignes directrices pour l’évaluation de similarité de chaînes

Le panel d’évaluation de similarité de chaînes effectuera l’évaluation conformément aux lignes directrices sur l’évaluation de la similarité des chaînes, qui seront affichées sur le site Web du programme des nouveaux gTLD.

7.10.2.4 Processus pour le panel d’évaluation de similarité de chaînes

L’évaluation de similarité des chaînes sera menée par un panel indépendant d’évaluation de la similarité des chaînes. Toutes les chaînes faisant l’objet d’une candidature et leurs variantes seront évaluées par rapport à d’autres chaînes ayant fait l’objet d’une candidature et leurs variantes, aux gTLD existants et aux noms bloqués, comme détaillé dans la Section 7.10.1 Portée de l’évaluation de similarité de chaînes.

Le panel d’évaluation de la similarité de chaînes effectuera l’évaluation de la similarité des chaînes en procédant comme suit :

Compiler les listes de chaînes pour comparaison :
1. gTLD existants
2. chaînes faisant l’objet d’une candidature lors des séries précédentes du programme des nouveaux gTLD et toujours en cours de traitement
3. ccTLD existants
4. ccTLD IDN demandés
5. autres chaînes faisant l’objet d’une candidature
6. Noms bloqués
7. chaînes ASCII à deux caractères
Considérer toutes les variantes allouables des chaînes ci-dessus en utilisant le RZ-LGR.
Considérer toutes les variantes de chaînes bloquées parmi les chaînes ci-dessus en utilisant le RZ-LGR qui sont dans le même script (chaînes de script mixtes pour les scripts Kana et Han comme autorisé par le RZ-LGR).
Décider quelles variantes de chaînes bloquées omettre de l’évaluation, le cas échéant, et documentez le fondement de la décision. Toute décision du panel doit être fondée sur les lignes directrices pour l’évaluation de la similarité des chaînes (voir la Section 7.10.2.3 ) sur la base d’un faible niveau de confusion entre les scripts des chaînes comparées.
Identifier les chaînes dans différentes candidatures, mais dans le même ensemble de variantes de chaînes pour déterminer les ensembles conflictuels causés par les mêmes chaînes ou variantes de chaînes.
Effectuer la comparaison des chaînes afin d’identifier tout ensemble de chaînes visuellement similaires en vous basant sur les lignes directrices pour l’évaluation de la similarité des chaînes (voir la Section 7.10.2.3) et documenter l’analyse. Les outils de similarité visuelle ne sont pas utilisés pour ce processus, mais le panel d’évaluation de la similarité des chaînes peut utiliser l’automatisation et les données fournies par la communauté respective partageant une écriture pour rendre le processus de comparaison manuelle efficace.
Déterminer et documenter (avec fondement) le résultat de l’évaluation de la similarité des chaînes.

7.10.3 Résultats de l’évaluation de la similarité de chaînes

Comme mentionné ci-dessus, le panel d’évaluation de la similarité des chaînes effectuera l’analyse et en déterminera les résultats. Ces résultats, ainsi que leur fondement, seront basés sur des comparaisons de similarité effectuées pour toutes les chaînes de gTLD faisant l’objet d’une candidature (y compris leur ensemble de variantes de chaînes), conformément aux détails dans cette section. Les résultats possibles sont les suivants :

chaîne visuellement similaire à un gTLD existant ou à ses variantes ;
chaîne visuellement similaire à une chaîne faisant l’objet d’une candidature d’une série précédente du programme des nouveaux gTLD et toujours en cours de traitement ou de ses variantes ;
chaîne visuellement similaire à un ccTLD existant ou à ses variantes ;
chaîne visuellement similaire à un ccTLD IDN faisant l’objet d’une candidature ou à ses variantes ;
chaîne identique à une autre chaîne faisant l’objet d’une candidature ou à ses variantes ;
chaîne visuellement similaire à une autre chaîne faisant l’objet d’une candidature ou à ses variantes ;
chaîne visuellement similaire à un nom bloqué ou à ses variantes ;
chaîne visuellement similaire à une chaîne ASCII à deux caractères ou à ses variantes ;
chaîne visuellement différente de l’une des catégories répertoriées.

L’ICANN publiera les résultats de l’évaluation de la similarité de chaînes sur la page des résultats de l’évaluation du site Web du programme des nouveaux gTLD.

Toutes les chaînes d’un ensemble de variantes de chaînes, comprenant la chaîne principale et toutes ses variantes allouables et bloquées, partageront le même résultat de l’évaluation de la similarité de chaînes :

si une chaîne faisant l’objet d’une candidature ou l’une de ses variantes ne peut pas continuer ou être placée dans un ensemble conflictuel en raison de la similarité visuelle, alors la chaîne demandée et toutes ses variantes (c’est-à-dire l’ensemble de variantes de chaînes) partageront le même résultat.
dans les cas où une candidature dans un ensemble conflictuel prévaut, elle s’applique à l’ensemble des variantes de chaînes de caractères, et toutes les chaînes de la candidature gagnante peuvent passer à l’étape suivante du processus de candidature. Reportez-vous à la Section 5.2.2 Résolution des conflits de chaînes.

7.10.3.1 Chaînes visuellement similaires à des gTLD existants ou à leurs variantes de chaîne

Si une chaîne faisant l’objet d’une candidature ou l’une de ses variantes est visuellement similaire à l’un des gTLD existants ou à l’une de leurs variantes, la candidature ne pourra pas continuer, sauf dans le cas indiqué ci-dessous.

L’exception se produit lorsque la chaîne faisant l’objet de la candidature est une variante allouable d’un gTLD existant, fait partie du même ensemble de variantes de chaînes que le gTLD existant, que la chaîne faisant l’objet de la candidature est visuellement similaire à ce gTLD existant ou à l’une de ses variantes, et que le candidat est le même opérateur de registre de ce gTLD existant. Dans ce cas, la candidature peut procéder à l’évaluation sous forme de variante de chaîne.

7.10.3.2 Chaînes visuellement similaires à des chaînes et variantes des séries précédentes du programme des nouveaux gTLD encore en cours de traitement

Si une chaîne principale faisant l’objet d’une candidature ou l’une de ses variantes est visuellement similaire à une chaîne principale faisant l’objet d’une candidature ou à l’une de ses variantes de chaînes qui ont été retenues lors d’une série de candidatures précédente et sont toujours en cours de traitement, la nouvelle candidature soumise sera mise en attente jusqu’à ce que le résultat de la candidature de la série précédente ait été déterminé.

Si la candidature d’une série précédente du programme des nouveaux gTLD réussit l’évaluation et est admissible à passer un contrat de registre de base, l’ensemble de variantes de chaînes de la chaîne principale nouvellement demandée n’est pas admissible à poursuivre le processus de candidature.
Si la candidature d’une série précédente est retirée ou échoue à l’évaluation, la candidature nouvellement soumise est admissible à passer à l’étape suivante du processus de candidature.

Un nouveau candidat n’est pas autorisé à postuler pour une chaîne qui fait partie du même ensemble de variantes de chaînes que la chaîne de la série précédente du programme des nouveaux gTLD qui est toujours en cours de traitement.

7.10.3.3 Chaînes visuellement similaires à des ccTLD évalués ou délégués avec succès ou à leurs variantes de chaînes

Si une chaîne faisant l’objet d’une candidature ou l’une de ses variantes est visuellement similaire à l’un des ccTLD évalués ou délégués avec succès ou à l’une de leurs variantes, la candidature au gTLD ne poursuivra pas son traitement.

7.10.3.4 Chaînes visuellement similaires à un IDN ccTLD demandé

Une chaîne ccTLD IDN peut être demandée via la procédure accélérée ccTLD IDN ou son successeur de manière continue.¹¹⁸ Le processus de candidature à une chaîne ccTLD IDN est séparé et indépendant du processus de candidature au gTLD. Si une chaîne faisant l’objet d’une candidature à un nouveau gTLD est visuellement similaire à tout autre ccTLD IDN demandé,¹¹⁹ le panel d’évaluation de la similarité des chaînes le signalera comme un conflit avec un ccTLD IDN demandé, sans former d’ensemble conflictuel, puisque ceux-ci ne sont que pour les chaînes gTLD faisant l’objet d’une candidature. L’ICANN adoptera l’approche ci-dessous pour résoudre le conflit.

Si une chaîne faisant l’objet d’une candidature à un nouveau gTLD est visuellement similaire à un ccTLD IDN demandé, l’ICANN déterminera le résultat en fonction de l’état d’avancement des processus d’évaluation respectifs. Les scénarios sont les suivants :

Une candidature à un gTLD qui a terminé avec succès toutes les étapes d’évaluation pertinentes, y compris le règlement des litiges et le conflit de chaînes, le cas échéant, et qui est éligible à la signature d’un contrat de registre de base, sera considérée comme complète et, par conséquent, cette candidature à un gTLD (chaîne principale et variantes de chaînes appliquées, le cas échéant) ne sera pas disqualifiée par une demande de ccTLD IDN nouvellement déposée. Le candidat au ccTLD IDN sera informé en conséquence.
Une chaîne ccTLD IDN principale demandée qui est validée¹²⁰ sera considérée comme complète. Par conséquent, cette chaîne ccTLD IDN (chaîne ccTLD IDN principale et variantes de chaînes demandées, le cas échéant) ne serait pas disqualifiée par une nouvelle candidature à un gTLD.

Au cas où aucune des candidatures n’aurait achevé son processus d’évaluation respectif, la candidature à un gTLD (y compris les variantes de chaînes faisant l’objet de la candidature, le cas échéant) sera mise en attente pendant que la demande de ccTLD IDN (y compris les variantes de chaînes demandées, le cas échéant) sera évaluée. La suspension pourrait être pour une période indéterminée, à condition que le candidat au ccTLD IDN fournisse suffisamment de documentation et d’informations pour compléter son processus d’évaluation, régi exclusivement par le processus d’évaluation de la candidature au ccTLD IDN. Le candidat au gTLD sera informé en conséquence de l’un des deux résultats suivants :

une fois son évaluation réussie, la candidature au ccTLD IDN prévaudra et la candidature au gTLD ne sera pas approuvée.
si le ccTLD IDN demandé n’est pas évalué avec succès, ou retiré par le candidat au ccTLD IDN, la chaîne gTLD IDN peut alors procéder à l’évaluation de la candidature.

Si le candidat au gTLD a reçu le soutien ou la non-objection du gouvernement ou de l’autorité publique, mais que sa candidature est finalement éliminée en raison de la similarité visuelle avec une chaîne demandée dans le processus de candidature au ccTLD IDN, le remboursement complet des frais d’évaluation sera émis si la candidature au gTLD a été soumise avant la publication du ccTLD.

Un candidat n’est pas autorisé à postuler à une chaîne gTLD faisant partie du même ensemble de variantes de chaînes qu’une chaîne ccTLD validée.

7.10.3.5 Chaînes identiques ou visuellement similaires à des chaînes et variantes de chaînes faisant l’objet de candidatures

Si une chaîne principale faisant l’objet de la candidature et l’une de ses variantes de chaîne sont visuellement similaires, et que ces chaînes sont sollicitées dans la même candidature, elles ne seront pas mises en conflit les unes avec les autres et peuvent continuer comme chaînes principales et variantes les unes des autres.

Si une chaîne faisant l’objet de la candidature ou l’une de ses variantes se révèle identique ou visuellement similaire à toute autre chaîne demandée ou à l’une de ses variantes, les ensembles de variantes de chaînes¹²¹ de ces candidatures seront placés dans un ensemble conflictuel par le panel d’évaluation de la similarité des chaînes. Un ensemble conflictuel contient au moins deux chaînes faisant l’objet d’une candidature qui sont identiques ou visuellement similaires l’une à l’autre ou leurs variantes. Voir le Module 5 Résolution des ensembles conflictuels pour de plus amples informations sur les ensembles conflictuels et la résolution de conflits.

Ces ensembles conflictuels incluront également des informations sur le conflit direct (la chaîne A est confondue avec la chaîne B) ou indirect via la transitivité visuelle de similarité de chaîne (la chaîne A est confondue avec la chaîne B et la chaîne B est confondue avec la chaîne C, mais la chaîne A et la chaîne C ne sont pas confondues) ou la transitivité visuelle de similarité de chaîne A (par exemple, la chaîne B-variante-1 et la chaîne B-variante-2 sont confondues avec la chaîne C). Le conflit indirect peut être résolu pour permettre à la chaîne A et à la chaîne C de continuer au cas où la chaîne B ne pourrait pas continuer, mais si la chaîne B se poursuit, ni la chaîne A ni la chaîne C ne peuvent continuer.

7.10.3.6 Chaînes visuellement similaires à un nom bloqué

Si une chaîne faisant l’objet de la candidature ou l’une de ses variantes est visuellement similaire à n’importe quel nom bloqué¹²² ou l’une de ses variantes, la candidature ne se poursuivra pas.

7.10.3.7 Chaînes visuellement similaires à une chaîne ASCII à deux caractères

Si une chaîne à deux caractères faisant l’objet de la candidature ou l’une de ses variantes est trouvée similaire à une chaîne ASCII à deux caractères ou à l’une de ses variantes, la chaîne faisant l’objet de la candidature ne se poursuivra pas.

7.10.3.8 Résultats de l’évaluation de la similarité de chaînes

Les résultats examinés ci-dessus sont résumés dans le tableau ci-dessous. Si la chaîne n’est pas considérée comme visuellement similaire à l’une des chaînes de l’une des catégories, elle peut passer à l’étape suivante du processus d’évaluation de la candidature.

Tableau 7-5 Résultats pour la candidature gTLD après évaluation de la similarité de chaînes effectuée par le panel

	Si la chaîne faisant l’objet de la candidature ou tout membre de son ensemble de variantes de chaînes est :
	Identique à	Variante de	Visuellement similaire à (mais pas une variante de)
gTLD existant	La candidature ne sera pas acceptée.	La candidature peut se poursuivre si l’opérateur de registre existant est également le candidat.	La candidature ne peut pas poursuivre le processus.
La chaîne faisant l’objet d’une candidature de la ou des séries précédentes du programme des nouveaux gTLD est toujours en cours de traitement¹²³	La candidature ne sera pas acceptée.	La candidature ne sera pas acceptée.	La candidature est mise en attente jusqu’à ce que la chaîne précédente termine l’évaluation. La candidature peut procéder à l’évaluation si la chaîne gTLD de la série précédente est retirée ou si l’évaluation n’a pas réussi.
ccTLD existant	La candidature ne sera pas acceptée.	La candidature ne sera pas acceptée.	La candidature ne peut pas poursuivre le processus.
IDN ccTLD demandé	La candidature ne sera pas acceptée si la chaîne ccTLD IDN a été validée. La candidature est mise en attente pendant l’évaluation de la chaîne ccTLD.	La candidature ne sera pas acceptée si la chaîne ccTLD IDN a été validée. La candidature est mise en attente pendant l’évaluation de la chaîne ccTLD.	La candidature peut se poursuivre si elle a terminé avec succès toutes les étapes d’évaluation pertinentes et si elle est admissible pour signer un contrat de registre de base au moment du dépôt de la demande de ccTLD IDN. Sinon, la candidature est mise en attente jusqu’à ce que l’évaluation du ccTLD soit terminée et la candidature peut continuer si le ccTLD IDN demandé est retiré ou n’est pas évalué avec succès.
Autre chaîne de gTLD faisant l’objet d’une candidature	La candidature est mise dans un ensemble conflictuel.	La candidature n’est pas mise dans un ensemble conflictuel si l’autre chaîne faisant l’objet d’une candidature est une variante de chaîne du même candidat. La candidature n’est pas mise dans un ensemble conflictuel si l’autre chaîne faisant l’objet d’une candidature provient d’un candidat différent.	La candidature est mise dans un ensemble conflictuel.
Nom bloqué	La candidature ne sera pas acceptée.	La candidature ne sera pas acceptée.	La candidature ne peut pas poursuivre le processus.
Chaîne ASCII à deux caractères	La candidature ne sera pas acceptée.	La candidature ne sera pas acceptée.	La candidature ne peut pas poursuivre le processus.

7.10.4 Contestation de l’évaluation de la similarité des chaînes

L’évaluation de la similarité de chaînes peut être contestée. Si un candidat estime que le panel d’évaluation de la similarité des chaînes a commis une erreur de fait ou de procédure – par exemple lorsqu’il a déterminé que la chaîne faisant l’objet de la candidature (ou une variante) est visuellement similaire et ne peut donc pas continuer ou devrait être placée dans un ensemble conflictuel sur la base des cas énumérés ci-dessus, le candidat peut alors déposer une contestation.

La contestation sera évaluée au regard du seul critère de l’« erreur manifeste ». Plus précisément, le prestataire du service d’évaluation de la contestation doit accepter la décision du panel d’évaluation de la similarité de chaînes, à moins que le panel d’évaluation : 1) n’ait pas suivi les procédures appropriées, ou (2) n’ait pas pris en considération/sollicité des éléments de preuve ou des renseignements importants nécessaires.

La contestation de l’évaluation peut être effectuée dans les 21 jours suivant la date à laquelle le candidat reçoit l’avis de la décision relative à l’évaluation de la similarité des chaînes. Le panel d’évaluation de la similarité des chaînes communiquera les conclusions découlant de la contestation de l’évaluation dans les 30 jours suivant le dépôt d’une telle contestation par le candidat.

Si le panel d’évaluation de la similarité des chaînes constate une erreur de fait, de procédure ou du système, l’évaluation de la similarité des chaînes pour la candidature sera réévaluée, en tenant compte des constatations de la contestation de l’évaluation.

Si le panel d’évaluation de la similarité des chaînes ne trouve aucune erreur de fait, de procédure ou du système, alors :

si la contestation est basée sur le fait qu’une chaîne faisant l’objet de la candidature est visuellement similaire à un gTLD existant, à une chaîne déjà demandée d’une série précédente du programme des nouveaux gTLD, à un ccTLD existant, à un ccTLD IDN demandé qui a été validé, à toute autre chaîne ASCII à deux caractères ou à tout autre nom bloqué, la candidature ne poursuivra pas.
si la contestation est basée sur le fait qu’une chaîne faisant l’objet de la candidature est visuellement similaire à une autre chaîne dans la même situation, la candidature reste dans l’ensemble conflictuel approprié.

7.10.5 Exception pour les TLD de marque

Si la chaîne faisant l’objet d’une candidature remplit les critères pour être qualifiée de TLD de marque (voir la Section 7.1.2.4 Candidatures à des TLD de marque) mais que ce TLD de marque est jugé similaire à un autre, comme indiqué dans le Tableau 7-5 Résultats pour la candidature gTLD après évaluation de la similarité de chaînes effectuée par le panel, et que de ce fait la candidature ne peut se poursuivre ou doit intégrer un ensemble conflictuel, alors le candidat au TLD de marque aura la possibilité de changer de chaîne. Les règles applicables au changement de chaîne pour les candidatures à des TLD de marque sont disponibles dans la Section 5.3 Demandes de changement de chaîne de TLD de marque.¹²⁴

Voir la Section 3.7.1 Tirage au sort pour l’établissement des priorités de traitement pour de plus amples informations sur le tirage au sort, qui aura lieu pour déterminer le numéro de priorité d’une candidature et l’ordre général dans lequel elle sera traitée par l’ICANN.↩︎
Différentes exigences peuvent également s’appliquer aux demandes de modification de dossier de candidature, notamment en ce qui concerne les types de désignations de candidatures qui peuvent ou ne peuvent pas être modifiés. Voir la Section 7.1.3 Modification des types de candidatures ci-dessous pour plus de renseignements ainsi que la Section 3.8 Demande de modification de dossier de candidature pour plus de détails sur les demandes de changement de candidature.↩︎
Une fois la candidature soumise, un candidat ne peut pas la modifier pour lui donner le statut de candidature communautaire ni lui retirer ce statut. Voir la Section 3.8 Demande de modification de dossier de candidature.↩︎
Les demandes de modification de dossier de candidature visant à changer le statut communautaire d’une candidature ne seront pas autorisées. Se reporter à la Section 3.8 Demande de modification de dossier de candidature pour de plus amples informations sur les demandes de modification autorisées.↩︎
Il est prévu qu’un candidat et l’ICANN négocient le langage spécifique d’une politique d’enregistrement communautaire au cours de l’évaluation des engagements de l’opérateur de registre afin d’identifier le langage proposé du contrat de registre qui répond aux critères de la RCE (voir la Section 3.8.4.2 Demandes de modification de dossier de candidature : flux de travail 2. Le candidat doit soumettre une demande de modification de candidature qui reflète le libellé du contrat de registre négocié pour la politique d’enregistrement communautaire proposée après avoir reçu la notification de l’ICANN. L’ICANN ne rejette pas catégoriquement ou automatiquement une proposition de politique d’enregistrement communautaire sans aucune communication avec un candidat. Toutefois, le défaut d’un candidat de déposer la demande de modification de dossier de candidature requise dans le délai désigné, comme défini à la Section 3.8 Demande de modification de dossier de candidature, entraînerait un résultat négatif de la RCE.↩︎
Voir les instructions applicables dans le Questionnaire 7 concernant les gTLD communautaires à l’Annexe 1 Questions du dossier de candidature pour connaître les exigences détaillées et l’approche suggérée pour la rédaction des politiques d’enregistrement communautaires à proposer, qui seront évaluées par la RCE.↩︎
Voir la Section 7.5 Noms géographiques pour une liste complète des catégories de chaînes qui pourraient être considérées comme des noms géographiques.↩︎
La section détaille une procédure d’exception qui permet aux candidats de présenter leur candidature à un nom à partir de la liste des noms réservés. Cette procédure s’applique exclusivement aux noms de la Croix-Rouge, du Croissant-Rouge (CRCR), du Comité International Olympique (CIO), des Organisations internationales gouvernementales (OIG) et des Organisations internationales non gouvernementales (OING).↩︎
Pour référence, voir la spécification 13 9.3(i) du contrat de registre de base (Annexe 4) pour de plus amples informations sur les TLD de marque et les exigences associées.↩︎
En cas de conflit avec d’autres candidats, un candidat à un TLD de marque peut avoir la possibilité de modifier sa chaîne pour ajouter un descripteur au nom de domaine, auquel cas le nom de domaine peut ne plus correspondre exactement aux éléments textuels d’une marque déposée. Voir la Section 5.3 Demandes de changement de chaîne de TLD de marque.↩︎
Une chaîne qui correspond à un nom de marque n’est pas toujours exploitée comme marque. Il est possible qu’un candidat postule pour une chaîne qui correspond à un nom de marque sans avoir l’intention de l’exploiter en tant que TLD de marque.↩︎
Dans certains cas, un candidat à un TLD de marque peut obtenir une dérogation au code de conduite (spécification 9) mais ne pas être éligible à la spécification 13.↩︎
Voir aussi la Section 3.8 Demandes de modification de dossier de candidature concernant les exigences en matière d’éligibilité et d’évaluation.↩︎
Comme indiqué ci-dessus, les candidats éligibles peuvent également demander une dérogation au code de conduite de l’opérateur de registre. Voir la Section 7.4 Évaluation d’éligibilité à une exemption au Code de conduite de l’opérateur de registre.↩︎
Les candidats auront également la possibilité de demander des variantes de « nouveaux » TLD IDN. Voir la Section 7.1.2.7 Candidatures à des nouveaux TLD IDN comprenant une ou plusieurs variantes.↩︎
Voir la recommandation 3.5 du rapport final de l’étape 1 du processus accéléré d’élaboration de politiques relatif aux noms de domaine internationalisés : https://gnso.icann.org/sites/default/files/policy/2023/correspondence/epdp-idns2-leadership-team-et-al-to-gnso-council-et-al-08nov23-en.pdf.↩︎
Ibid. Voir les recommandations 3.11 et 3.12. Le nombre total de variantes qui peuvent faire l’objet d’une candidature est basé sur le calcul des RZ-LGR (règles de génération d’étiquettes pour la zone racine).↩︎
Ibid.↩︎
Ibid. Voir la recommandation 3.5.↩︎
Voir le rapport final de l’étape 1 du processus accéléré d’élaboration de politiques relatif aux noms de domaine internationalisés : https://gnso.icann.org/sites/default/files/policy/2023/correspondence/epdp-idns2-leadership-team-et-al-to-gnso-council-et-al-08nov23-en.pdf.↩︎
Une OIG est une organisation composée principalement d’États souverains ou d’autres organisations intergouvernementales. Une OIG est créée par un traité ou tout autre accord qui lui sert de charte constitutive. On citera, à titre d’exemple, l’Organisation des Nations Unies, la Banque mondiale ou l’Union européenne. Source : Union des associations internationales, https://uia.org/faq/yb3.↩︎
Généralement défini comme un gouvernement national ou tout ministère, organisme ou subdivision de celui-ci au sein de l’autorité compétente.↩︎
Voir le Manuel du programme de soutien aux candidats : https://newgtldprogram.icann.org/en/application-rounds/round2/asp/handbook.↩︎
Pour de plus amples informations, voir le résultat du PDP relatif à la protection des identificateurs des OIG et des OING dans tous les gTLD : https://gnso.icann.org/en/group-activities/active/igo-ingo.↩︎
Pour de plus amples informations, consulter les règles de conversion d’étiquettes DNS sous la rubrique « Notes pour la mise en œuvre » : https://www.icann.org/en/contracted-parties/consensus-policies/protection-of-intergovernmental-organization-and-international-non-governmental-organization-identifiers-policy/protection-of-igo-and-ingo-identifiers-in-all-gtlds-policy-21-02-2024-en.↩︎
Voir les noms de domaine à usage spécial : https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml.↩︎
Voir le document RFC 6761 : https://tools.ietf.org/html/rfc6761.↩︎
Remarque : l’ICANN réservera les traductions des termes « test » et « exemple » dans plusieurs langues.↩︎
Voir Communauté de l’ICANN : https://www.icann.org/community.↩︎
Voir Registres Internet régionaux : https://aso.icann.org/about/aso-and-nro/rirs/.↩︎
Voir groupes de l’IETF : https://www.ietf.org/about/groups/.↩︎
Voir le rapport final du groupe de travail sur les noms réservés : https://gnso.icann.org/en/issues/new-gtlds/final-report-rn-wg-23may07.htm.↩︎
À la suite du document SAC113 et des travaux ultérieurs dirigés par le Conseil d’administration de l’ICANN, .INTERNAL a été ajouté à la liste des noms bloqués. Voir https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-113-en.pdf.↩︎
Voir la base de données de la zone racine : https://www.iana.org/domains/root/db.↩︎
Site Web de la série de 2012 du programme des nouveaux gTLD : https://gtldresult.icann.org/applicationstatus/viewstatus.↩︎
Toute contestation soumise après cette date ne sera pas acceptée. Il est donc conseillé aux candidats de commencer à remplir la ou les candidatures dès que possible et de soumettre toute contestation au plus tard 14 jours avant la fin de la période de dépôt des candidatures.↩︎
Tel qu’indiqué à la Section 7.10.1 Portée de l’évaluation de la similarité de chaînes, conformément à la motion 20251113 du Conseil de la GNSO, « [l]es identifiants pertinents [associés au Mouvement international de la Croix-Rouge et du Croissant-Rouge, au Comité international olympique et aux noms complets d’organisations gouvernementales internationales et d’organisations non gouvernementales internationales spécifiques] ne doivent pas être inclus dans l’évaluation de la similarité de chaînes dans le cadre du programme des nouveaux gTLD, et ces identifiants pertinents ne doivent pas empêcher un autre candidat de déposer une candidature à une chaîne de caractères similaire pouvant prêter à confusion lors de l’évaluation. » Voir la motion complète du Conseil de la GNSO : https://gnso.icann.org/en/council/resolutions/2020-current#20251113.↩︎
Voir le processus d’élaboration de politiques pour la protection des identificateurs des OIG et des OING dans tous les gTLD : https://gnso.icann.org/en/group-activities/active/igo-ingo.↩︎
Voir la résolution du Conseil d’administration 2014.04.30.03, https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-of-directors-30-04-2014-en#2.a.↩︎
Voir la résolution du Conseil d’administration 2019.01.27.19, https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-27-01-2019-en#2.d.↩︎
Voir les noms de la Croix Rouge : https://www.icann.org/sites/default/files/packages/reserved-names/ReservedNames.xml#red-cross1. Cette liste, ainsi que celle des noms pour le CIO et les OIG, s’applique aux noms de domaine de second niveau mais sera également réutilisée pour réserver ces mêmes noms au premier niveau dans le cadre de la série 2026 du programme des nouveaux gTLD. Se reporter à la colonne « Nom » de chaque liste associée pour connaître les noms correspondants.↩︎
Voir les noms du CIO : https://www.icann.org/sites/default/files/packages/reserved-names/ReservedNames.xml#IOC.↩︎
Voir les noms des OIG : https://www.icann.org/sites/default/files/packages/reserved-names/ReservedNames.xml#IGOs.↩︎
Voir la « Liste d’organisations non gouvernementales dotées d’un statut consultatif auprès du Conseil économique et social des Nations Unies au 31 décembre 2022 » : https://docs.un.org/en/E/2023/INF/5, ici : https://esango.un.org/civilsociety/displayConsultativeStatusSearch.do?method=search.↩︎
Voir la liste des membres du GAC : https://gac.icann.org/about/gac-members.↩︎
Les candidats admissibles peuvent également demander une dérogation au code de conduite (spécification 9) ainsi qu’une évaluation de dérogation au code de conduite en vertu de la Section 7.4.↩︎
Voir le Centre d’échange d’information sur les marques : https://trademark-clearinghouse.com/.↩︎
Voir le Centre d’échange d’information sur les marques : https://trademark-clearinghouse.com/.↩︎
Les noms de pays et de territoires sont exclus du processus sur la base des avis formulés par le Comité consultatif gouvernemental dans des communiqués précédents. Ces communiqués interprètent le Principe 2.2 des principes du GAC concernant les nouveaux gTLD en précisant que les chaînes qui sont une représentation significative ou une abréviation d’un nom de pays ou de territoire doivent être traitées par le biais d’un ccPDP, et que d’autres chaînes géographiques peuvent être autorisées dans l’espace des gTLD en accord avec le gouvernement ou l’autorité publique concernés.↩︎
Voir la liste des normes ISO 3166-1 : https://www.iso.org/obp/ui.↩︎
La permutation inclut la suppression des espaces, l’insertion de ponctuation et l’ajout ou la suppression d’articles grammaticaux tels que « le/la ». La transposition fait référence à une modification de la séquence de la forme longue ou courte du nom, par exemple, « RepublicCzech » ou « IslandsCayman ».↩︎
Les municipalités préoccupées par des chaînes constituant des doublons, un diminutif ou un rendu similaire à un nom de ville ne peuvent en aucun cas considérer le processus d’évaluation comme le principal moyen de protéger leurs intérêts vis-à-vis de la chaîne en question. Ces parties concernées, si elles sont inquiètes, peuvent plutôt choisir de déposer une objection formelle contre la candidature qui est contestée par la communauté concernée, ou soumettre leur propre candidature pour la chaîne.↩︎
Les cinq régions reconnues par l’UNESCO (dans les six langues de l’ONU) sont : l’Afrique ; les États arabes ; l’Asie-Pacifique ; l’Europe ; l’ Amérique du Nord ; l’Amérique latine et les Caraïbes (en date de mai 2025).↩︎
Voir les Codes standard des pays et des zones à usage statistique (M49) : https://unstats.un.org/unsd/methodology/m49/ publiés en décembre 2025.↩︎
Voir la version 6 des règles de génération d’étiquettes pour la zone racine : https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en.↩︎
Voir les membres du GAC : https://gac.icann.org/about/gac-members.↩︎
Voir les notes du Conseil d’administration de l’ICANN sur la fiche de suivi du GAC relative aux nouveaux gTLD du 4 mars 2011 : https://archive.icann.org/en/topics/new-gtlds/board-notes-gac-scorecard-04mar11-en.pdf.↩︎
Voir les processus de transition entre opérateurs de registre : https://www.icann.org/en/contracted-parties/registry-operators/services/registry-transition-processes.↩︎
Voir RZ-LGR : https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en.↩︎
Voir les définitions des concepts relatifs aux variantes dans le Glossaire.↩︎
Voir le Manuel du programme d’évaluation des fournisseurs de services de registre : https://newgtldprogram.icann.org/sites/default/files/documents/rsp-handbook-03jun24-en.pdf.↩︎
Voir le RFC 9499, section 2 : https://www.rfc-editor.org/rfc/rfc9499.html#name-names.↩︎
Pour des exemples de collisions de noms, voir la section 2.2 du rapport du projet d’analyse de la collision de noms (NCAP) : https://icann-community.atlassian.net/wiki/download/attachments/99319865/ncap-study-1-report-19jun20-en.pdf.↩︎
Voir le rapport de la deuxième étude du projet d’analyse de la collision de noms : https://www.icann.org/en/system/files/files/ncap-study-2-report-05apr24-en.pdf.↩︎
Voir la résolution 2024.09.07.01 du Conseil d’administration : https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-07-09-2024-en.↩︎
Pour de plus amples informations sur la façon dont les collisions de noms ont été gérées lors de la dernière série, consulter https://www.icann.org/resources/pages/name-collision-2013-12-06-en.↩︎
Voir les indicateurs de santé des technologies des identificateurs (ITHI) : https://ithi.research.icann.org/.↩︎
Cette procédure sera disponible sur le site Web du programme des nouveaux gTLD.↩︎
Pour de plus amples détails sur la manière dont les chaînes se voient attribuer une priorité, consulter la Section 3.7 Ordre de traitement des demandes et tirage au sort pour l’établissement des priorités de traitement.↩︎
Cette procédure sera disponible sur le site Web du programme des nouveaux gTLD : https://newgtldprogram.icann.org/en.↩︎
Cette procédure sera disponible sur le site Web du programme des nouveaux gTLD : https://newgtldprogram.icann.org/en.↩︎
Voir les statuts constitutifs de l’ICANN, Chapitre 1, Article 1.1(a) : https://www.icann.org/resources/pages/governance/bylaws-en/#article1.↩︎
Pour en savoir plus, voir le Communiqué du GAC de Toronto de l’ICANN45 : https://gac.icann.org/contentMigrated/icann45-toronto-communique, le communiqué du GAC de Beijing de l’ICANN46 : https://gac.icann.org/contentMigrated/icann46-beijing-communique, et la résolution ultérieure du Conseil d’administration de l’ICANN 2014.02.05.NG01 : https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-meeting-of-the-new-gtld-program-committee-05-02-2014-en; voir plus d’informations sur les avis consensuels du GAC et leur impact sur la série de 2012 du programme des nouveaux gTLD : https://newgtlds.icann.org/en/applicants/gac-advice#gac-1-applicant-advisories.↩︎
Dans les contrats de registre de base entre l’ICANN et les opérateurs de registre existants lors de la série de 2012 du programme des nouveaux gTLD, les termes « engagements volontaires des opérateurs de registre » et l’acronyme « RVC » n’existaient pas et à la place, le terme « engagements d’intérêt public spécifiques » a été utilisé (les termes « PIC volontaires » et « PIC privés » ont également été utilisés de manière informelle dans le passé). Le contrat de registre de base pour la série de 2026 du programme des nouveaux gTLD utilisera l’expression « engagements volontaires spécifiques d’intérêt public » pour désigner ce que nous désormais est appelé « engagements volontaires des opérateurs de registre » ou « RVC ». Cette approche est conforme à la structure et à la formulation existantes de la spécification 11 du contrat de registre de base, ainsi qu’à la procédure de règlement de litiges relatifs aux engagements d’intérêt public (PICDRP) de l’ICANN, qui continue d’être la procédure de règlement de litiges pour traiter les plaintes alléguées selon lesquelles un opérateur de registre pourrait ne pas se conformer à un ou plusieurs PIC obligatoires et à des fins de protection, ainsi qu’aux futurs RVC approuvés dans son contrat de registre à l’avenir. Voir la spécification 11 à l’Annexe 4 Contrat de registre de base et la Section 1.2.17 Procédures de règlement de litiges après délégation.↩︎
Voir la procédure de règlement de litiges des engagements d’intérêt public (PICDRP) : https://www.icann.org/picdrp-en.↩︎
Cet article reflète la spécification 11 du contrat de registre de base, section 3(b), telle que modifiée le 5 avril 2024. Aux fins du contrat de registre de base, « utilisation malveillante du DNS » est défini comme étant les logiciels malveillants, les réseaux zombies, l’hameçonnage, le dévoiement et le spam (lorsque le spam sert de mécanisme de livraison pour les autres formes d’utilisation malveillante du DNS), tels que définis à la section 2.1 du document SAC 115 - rapport du SSAC sur une approche interopérable pour traiter l’utilisation malveillante du DNS : https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-115-en.pdf. Voir la section 4.1, page 2, des Amendements généraux aux contrats de registre de 2024 : https://itp.cdn.icann.org/en/files/registry-agreements/base-registry-agreement-global-amendment-05-04-2024-en.pdf.↩︎
Le contrat de registre de base est le produit d’une vaste consultation de la communauté. L’ICANN n’envisagera de modifier le contrat que dans des circonstances extraordinaires, telles que des situations dans lesquelles des problèmes juridiques, juridictionnels ou réglementaires uniques empêcheraient légalement une entité d’exécuter le contrat de registre de base tel quel. Voir la Section 1.2.15 Passation de contrats.↩︎
Voir le communiqué de Beijing de l’ICANN46 : https://gac.icann.org/contentMigrated/icann46-beijing-communique.↩︎
Voir la résolution du Conseil d’administration de l’ICANN 2014.02.05.NG01 : https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-meeting-of-the-new-gtld-program-committee-05-02-2014-en.↩︎
Voir l’annexe 2 de la résolution du Conseil d’administration de l’ICANN 2014.02.05.NG01 : https://www.icann.org/en/system/files/files/resolutions-new-gtld-annex-2-05feb14-en.pdf.↩︎
Le communiqué de Beijing de l’ICANN46 (voir https://gac.icann.org/contentMigrated/icann46-beijing-communique) a identifié une liste non exhaustive de chaînes ayant fait l’objet de candidatures lors de la série de 2012 du programme des nouveaux gTLD et a conseillé au Conseil d’administration d’appliquer les PIC à des fins de protection à ces chaînes identifiées. Le GAC a organisé ces chaînes identifiées en sous-groupes applicables.↩︎
Voir le communiqué de Beijing de l’ICANN46 : https://gac.icann.org/contentMigrated/icann46-beijing-communique.↩︎
Ibid.↩︎
Ibid.↩︎
Ibid.↩︎
Voir le site Web du programme des nouveaux gTLD : https://newgtldprogram.icann.org/.↩︎
Voir les politiques de consensus actuelles de l’ICANN : https://www.icann.org/consensus-policies-en.↩︎
Les services de registre supplémentaires font référence aux services offerts par un fournisseur de services de registre en dehors des fonctions critiques (c’est-à-dire, le service DNS, la résolution DNSSEC appropriée, EPP, RDDS et l’entiercement de données). Pour plus d’explications sur le service de registre supplémentaire, voir la section 1.1A-D de la politique d’évaluation des services de registre (voir https://www.icann.org/rsep-en). Voir des informations détaillées sur les fonctions critiques à la section 6 de la spécification 10 du contrat de registre de base (Annexe 4).↩︎
Si l’exécution d’un RVC approuvé nécessite l’exploitation d’un service de registre approuvé, l’engagement lui-même doit être inclus dans la spécification 11 du contrat de registre de base applicable, mais le service de registre approuvé devrait être inclus dans l’annexe A du contrat de registre de base.↩︎
En réponse au Questionnaire 20 - Informations complémentaires et pièces justificatives de l’Annexe 1 Questions du dossier de candidature, un candidat peut inclure des renseignements supplémentaires et des documents de soutien pouvant intéresser le public ou être pertinents à la candidature. Par exemple, un candidat peut inclure des liens vers ses accords distincts avec un tiers et ses engagements supplémentaires en dehors du contrat de registre. Les réponses du candidat à cette question seront données uniquement à titre informatif : elles ne seront pas évaluées et ne seront pas contraignantes pour le candidat au titre du contrat de registre. Toutefois, ces réponses seront ouvertes au public pour révision et commentaires. Il appartient dès lors aux candidats de peser avec soin l’opportunité et la teneur des informations additionnelles qu’ils souhaitent révéler en réponse au Questionnaire 20. En effet, de telles déclarations sont à double tranchant : autant un tiers peut s’en saisir pour étayer une objection, autant elles peuvent la désamorcer en amont en dissipant les préoccupations.↩︎
Il est prévu qu’un candidat et l’ICANN négocient les termes spécifiques d’un RVC au cours de l’évaluation des engagements de l’opérateur de registre afin d’identifier les termes proposés du contrat de registre qui répond aux critères de la RCE (voir la Section 3.8.4.2 Demande de modification de dossier de candidature : flux de travail 2 : l’ICANN ne rejette pas catégoriquement ou automatiquement une proposition de RVC sans aucune communication avec un candidat.↩︎
Voir le site Web du programme des nouveaux gTLD : https://newgtldprogram.icann.org/.↩︎
Les cinq critères d’évaluation du RVC reflètent un principe fondamental reconnu par le Conseil d’administration de l’ICANN lorsqu’il a demandé à l’organisation ICANN de mettre en œuvre des critères et des processus d’évaluation pour examiner les engagements proposés par les candidats en vue de leur inclusion dans les contrats de registre applicables, à savoir : « Afin de conclure un contrat, l’ICANN doit être convaincue que les conditions proposées (dont des engagements d’intérêt public) sont compatibles avec la mission de l’ICANN, qui consiste à assurer le fonctionnement stable et sécurisé des systèmes d’identificateurs uniques de l’Internet ». (Voir le fondement des résolutions du Conseil d’administration de l’ICANN 2024.06.08.08 – 2024.06.08.10 : https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-08-06-2024-en#section2.b).↩︎
Si le candidat croit que des engagements qui n’ont pas été proposés pour être inclus dans le contrat de registre peuvent intéresser le public ou être pertinents à la candidature, il peut les inclure en réponse au Questionnaire 20 - Informations complémentaires et pièces justificatives dans l’Annexe 1 Questions du dossier de candidature pour que le public puisse les examiner et les commenter. Les réponses du candidat à cette question seront données uniquement à titre informatif : elles ne seront pas évaluées et ne seront pas contraignantes pour le candidat au titre du contrat de registre. Il appartient dès lors aux candidats de peser avec soin l’opportunité et la teneur des informations additionnelles qu’ils souhaitent révéler en réponse au Questionnaire 18. En effet, de telles déclarations sont à double tranchant : autant un tiers peut s’en saisir pour étayer une objection, autant elles peuvent la désamorcer en amont en dissipant les préoccupations.↩︎
Le mot « devrait » (par opposition au mot « doit ») est utilisé intentionnellement dans le critère 4. Voir le document RFC2119 Mots clés à utiliser dans les RFC pour indiquer les niveaux d’exigence : https://datatracker.ietf.org/doc/html/rfc2119 (« ce mot, ou l’adjectif "RECOMMANDÉ" signifie qu’il peut exister des raisons valables dans des circonstances particulières d’ignorer un élément particulier, mais toutes les implications doivent être comprises et soigneusement pesées avant de choisir un cours différent »). Un RVC qui ferait double emploi avec des exigences en vigueur pourrait, dans certaines circonstances, être approuvé à l’entière discrétion de l’ICANN, par exemple si ce RVC est nécessaire pour donner suite à un avis de consensus du GAC.↩︎
Voir l’Annexe 4 Contrat de registre de base, le contrat d’accréditation de bureau d’enregistrement : https://www.icann.org/resources/pages/registrars/registrars-en et les politiques de consensus actuelles de l’ICANN : https://www.icann.org/consensus-policies-en.↩︎
Pour de plus amples informations générales, consulter la résolution 2024.06.08.08 du Conseil d’administration de l’ICANN - 2024.06.08.10 : https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-08-06-2024-en#section2.b.↩︎
Les statuts constitutifs de l’ICANN stipulent que « l’ICANN ne doit pas réglementer (c’est-à-dire imposer des règles et des restrictions) les services qui utilisent les identificateurs uniques d’Internet ou le contenu que ces services transportent ou fournissent, en dehors du champ d’application exprès de la Section 1.1(a)… » (Voir le chapitre 1, article 1.1(c) des statuts constitutifs de l’ICANN : https://www.icann.org/resources/pages/governance/bylaws-en/#article1). Après de longues délibérations et consultations de la communauté sur l’impact des statuts sur l’évaluation des RVC, le conseil d’administration de l’ICANN a décidé que l’ICANN devait exclure des contrats de registre de la série 2026 « tout RVC et autre engagement d’opérateur de registre comparable qui restreint le contenu dans les gTLD ».↩︎
Si un candidat à un gTLD communautaire souhaite qu’une politique d’enregistrement communautaire soit notée dans l’évaluation de la priorité communautaire (CPE), il doit proposer une telle politique pour l’inclure dans la Spécification 12 du contrat de registre de base applicable lors de la présentation d’une candidature communautaire. Une telle politique est une condition préalable à la participation de la candidature à la CPE (voir la Section 5.4 Évaluation de la priorité communautaire).↩︎
Il est prévu qu’un candidat et l’ICANN négocient le langage spécifique d’une politique d’enregistrement communautaire au cours de l’évaluation des engagements de l’opérateur de registre afin d’identifier le langage proposé du contrat de registre qui répond aux critères de la RCE (voir la Section 3.8.4.2 Demandes de modification de dossier de candidature : flux de travail 2. Le candidat doit soumettre une demande de modification de candidature qui reflète le libellé du contrat de registre négocié pour la politique d’enregistrement communautaire proposée après avoir reçu la notification de l’ICANN. L’ICANN ne rejette pas catégoriquement ou automatiquement une proposition de politique d’enregistrement communautaire sans aucune communication avec un candidat. Toutefois, le défaut du candidat de soumettre la demande de changement de candidature requise dans le délai établi tel que défini à la Section 3.8, Demande de modification de dossier de candidature entraînerait un résultat négatif de la RCE.↩︎
Voir la procédure de règlement de litiges relatifs à des restrictions à l’enregistrement (RRDRP) : https://www.icann.org/rrdrp-en et la procédure de demande de changement d’un gTLD communautaire : https://www.icann.org/resources/pages/community-gtld-change-requests-en.↩︎
Si un candidat à un gTLD communautaire estime que certaines politiques d’enregistrement communautaire qu’il entend mettre en œuvre sans pour autant les inclure dans le RA applicable peuvent être d’intérêt public ou pertinentes pour sa candidature, il peut les présenter en réponse au Questionnaire 20 - Informations complémentaires et pièces justificatives dans l’Annexe 1 Questions du dossier de candidature pour révision et commentaires publics. Les réponses à cette question n’ont qu’une portée informative : elles ne sont ni évaluées (par exemple, elles ne sont pas considérées dans la notation applicable durant l’évaluation de la priorité communautaire [CPE]) ni contraignantes pour le candidat au titre du contrat de registre. Il appartient dès lors aux candidats de peser avec soin l’opportunité et la teneur des informations additionnelles qu’ils souhaitent révéler en réponse au Questionnaire 20. En effet, de telles déclarations sont à double tranchant : autant un tiers peut s’en saisir pour étayer une objection, autant elles peuvent la désamorcer en amont en dissipant les préoccupations.↩︎
Voir les règles de génération d’étiquettes pour la zone racine : https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en.↩︎
Pour toute variante de chaîne, sa chaîne principale est utilisée pour déterminer son ensemble de variantes de chaînes par les règles de génération d’étiquettes pour la zone racine. L’ensemble contient la chaîne principale, toutes les variantes de chaînes allouables et toutes les variantes de chaînes bloquées.↩︎
Par exemple, un candidat peut uniquement demander des variantes de chaînes allouables, mais ne peut pas demander de variantes de chaînes bloquées, comme calculé par les Règles de génération d’étiquettes pour la zone racine. Voir la Section 3.1.9.1 Règles applicables aux IDN et à leurs variantes.↩︎
Voir l’affirmation 24.2, Rapport final des procédures pour des séries ultérieures de nouveaux gTLD, p.108 : https://gnso.icann.org/sites/default/files/file/field-file-attach/final-report-newgtld-subsequent-procedures-pdp-02feb21-en.pdf.↩︎
De telles chaînes sont appelées visuellement similaires.↩︎
À l’avenir, après la prochaine série des nouveaux gTLD, certaines de ces variantes de chaînes allouables seront attribuées (et seront incluses dans cette catégorie).↩︎
Conformément à la motion 20251113 du Conseil de la GNSO, « [l]es identifiants pertinents [associés au Mouvement international de la Croix-Rouge et du Croissant-Rouge, au Comité international olympique et aux noms complets d’organisations gouvernementales internationales et d’organisations non gouvernementales internationales spécifiques] ne doivent pas être inclus dans l’évaluation de la similarité de chaînes dans le cadre du programme des nouveaux gTLD, et ces identifiants pertinents ne doivent pas empêcher un autre candidat de déposer une candidature à une chaîne de caractères similaire pouvant prêter à confusion lors de l’évaluation. » Voir la motion complète du Conseil de la GNSO : https://gnso.icann.org/en/council/resolutions/2020-current#20251113. Voir également la Section 7.2.2 Noms réservés.↩︎
Il s’agit de chaînes qui n’ont pas l’état suivant : « Retirée », « RA résilié » ou « Déléguée ». Toutes les chaînes en cours de traitement de la série des nouveaux gTLD de 2012 sont publiées à l’adresse suivante : https://gtldresult.icann.org/. Voir aussi les résolutions 2025.09.14.05 et 2025.09.14.06 du Conseil d’administration sur la procédure de résiliation pour les candidatures restantes de la série 2012 qui n’ont pas été retenues : https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-14-09-2025-en#section1.c.rationale.↩︎
Pour une liste de tous les ccTLD IDN évalués avec succès, voir https://www.icann.org/resources/pages/string-evaluation-completion-2014-02-19-en.↩︎
Tous les domaines de premier niveau actuellement dans la zone racine peuvent être trouvés sur https://data.iana.org/TLD/tlds-alpha-by-domain.txt (la liste est mise à jour régulièrement).↩︎
Chaînes qui font actuellement l’objet d’une candidature dans le cadre de la procédure accélérée ccTLD IDN (voir https://www.icann.org/resources/pages/fast-track-2012-02-25-en) ou une politique ccTLD IDN qui peut remplacer la procédure accélérée ccTLD IDN. Il peut y avoir une période où la procédure accélérée ccTLD IDN et une politique ccTLD IDN peuvent être exécutées simultanément. Dans ce cas, les chaînes ccTLD IDN prospectives de ces deux procédures seront prises en compte dans la portée.↩︎
La définition plus large des noms bloqués est fournie à la Section 7.2.1 Noms bloqués. Aux fins de l’évaluation de similarité de chaînes, seules deux catégories sont applicables : (i) noms de domaine à usage spécial, et (ii) organes liés à l’ICANN, à l’IANA et à l’IETF et infrastructure Internet. Les autres catégories de noms bloqués répertoriées ne seront pas utilisées dans l’évaluation de la similarité des chaînes.↩︎
Tous les codes ASCII à deux caractères sont réservés à l’attribution de codes géographiques par l’agence indépendante de gestion ISO 3166.↩︎
Une chaîne d’une série précédente du programme des nouveaux gTLD aura l’un des statuts suivants : « Actif », « En cours de contractualisation », « En attente » ou « En PDT ». Voir également la page affichant les statuts des candidatures : https://gtldresult.icann.org/application-result/applicationstatus.↩︎
La définition plus large des noms bloqués est fournie à la Section 7.2.1 Noms bloqués. Aux fins de l’évaluation de similarité de chaînes, seules deux catégories sont applicables : (i) noms de domaine à usage spécial, et (ii) organes liés à l’ICANN, à l’IANA et à l’IETF et infrastructure Internet. Les autres catégories de noms bloqués répertoriées ne seront pas utilisées dans l’évaluation de la similarité des chaînes.↩︎
La ccNSO travaille actuellement sur le processus d’élaboration de politiques de ccTLD IDN (PDP4 de la ccNSO, (dé-)sélection des ccTLD IDN), qui est destiné à remplacer le processus accéléré des ccTLD IDN. Une fois la politique du groupe de travail sur la (dé-)sélection des chaînes des domaines de premier niveau géographique internationalisés (ccTLD IDN) (IDN ccPDP4) approuvée et mise en œuvre, elle fournira un autre mécanisme pour les candidats aux ccTLD IDN et sera également applicable ici.↩︎
Une chaîne ccTLD IDN demandée est une chaîne qui a été soumise à l’ICANN par le biais du système de candidatures ccTLD IDN et fait l’objet d’une évaluation rigoureuse.↩︎
Le terme « validé » signifie essentiellement évalué avec succès. Ce terme a été initialement défini dans la mise en œuvre de la procédure accélérée des ccTLD IDN et réaffirmé dans le rapport initial du ccPDP4. Voir la section « validation des chaînes et variantes ccTLD IDN » dans le rapport initial du ccPDP4 pour plus de détails.↩︎
Tel que défini dans la Section 3.1.8.3.1.3 Choix des chaînes principales et ou de leurs variantes à l’aide des RZ-LGR.↩︎
La définition plus large des noms bloqués est fournie à la Section 7.2.1 Noms bloqués. Aux fins de l’évaluation de similarité de chaînes, seules deux catégories sont applicables : (i) noms de domaine à usage spécial, et (ii) organes liés à l’ICANN, à l’IANA et à l’IETF et infrastructure Internet. Les autres catégories de noms bloqués répertoriées ne seront pas utilisées dans l’évaluation de la similarité des chaînes.↩︎
Il s’agit de chaînes qui n’ont pas l’état suivant : « Retirée », « RA résilié » ou « Déléguée ». Toutes les chaînes en cours de traitement de la série des nouveaux gTLD de 2012 sont publiées à l’adresse suivante : https://gtldresult.icann.org/. Voir aussi les résolutions 2025.09.14.05 et 2025.09.14.06 du Conseil d’administration sur la procédure de résiliation pour les candidatures restantes de la série 2012 qui n’ont pas été retenues : https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-14-09-2025-en#section1.c.rationale.↩︎
Le processus de demande de changement de chaîne pour les TLD de marque est différente de celui de remplacement de chaînes. Se reporter à la Section 5.1 Chaînes de remplacement.↩︎