Procédure pour les demandes de changement des gTLD communautaires

Introduction

La procédure pour les demandes de changement d'un gTLD communautaire a été élaborée par le groupe de travail sur le processus de demande de changement des gTLD communautaires (groupe de travail) et l'organisation ICANN avec la contribution du groupe des représentants des opérateurs registres de la communauté de l'ICANN. Les lignes directrices de cette procédure, permettent à l'opérateur de registre des gTLD communautaires de demander des modifications à la spécification 12 sans supprimer les politiques d'enregistrement communautaire, élargir ou restreindre excessivement l'éligibilité du titulaire de nom de domaine et/ou les exigences de sélection du nom, ou entraîner des impacts négatifs importants pour la communauté des TLD.

L'organisation ICANN a publié la procédure préliminaire pour consultation publique en février 2018. Après avoir analysé les commentaires reçus, l'organisation ICANN et le groupe de travail ont conclu que les commentaires n'indiquent pas que la procédure soit en conflit avec la politique existante et de mises à jour de la procédure ont été débattues. En outre, le 26 avril 2018 le conseil de la GNSO a décidé [PDF, 574 KB] que « l'organisation ICANN devrait continuer à traiter le processus de demande de changement des gTLD communautaires comme une question de mise en œuvre ». Cette version publiée de la procédure a été approuvée par le groupe de travail et de l'organisation ICANN en avril 2018.

Procédure

Version : avril 2018

Demande de changement d'un gTLD communautaire

La procédure de demande de changement d'un gTLD communautaire (« la demande ») permet à un opérateur de registre d'un gTLD communautaire d'obtenir l'approbation de l'ICANN pour modifier les politiques d'enregistrement communautaire énumérées dans la spécification 12 de son contrat de registre. En vertu de l'article 2.19 des contrats de registre pour les gTLD communautaires, « l'opérateur de registre doit gérer le TLD de manière à ce que la communauté puisse discuter et participer à l'élaboration et à la modification des politiques et des pratiques relatives au TLD ». L'opérateur de registre d'un TLD communautaire peut ne pas demander la modification qui permettrait de supprimer les politiques d'enregistrement communautaire, élargir ou restreindre excessivement l'éligibilité du titulaire de nom de domaine et/ou les exigences de sélection du nom, ou entraîner des impacts négatifs importants pour la communauté des TLD.

Comme pour toutes ses procédures, l'ICANN peut examiner l'efficacité de cette procédure périodiquement avec la participation des opérateurs de registre concernés et des unités constitutives.

1. Définitions

1.1 Un gTLD communautaire est défini comme un gTLD qui a passé un contrat de registre avec l'ICANN incluant la spécification 12 le titre de la section étant « Politiques d'enregistrement communautaire » ou « Politiques TLD ».

1.2 Un changement de gTLD communautaire est défini comme un changement à la spécification 12 du contrat de registre avec l'ICANN.

1.3 Le TLD communautaire est défini par les exigences d'éligibilité énoncées dans la spécification 12 du contrat de registre avec l'ICANN.

1.4 L'opérateur de registre est défini comme une entité avec un contrat de registre dont le but est d'administrer un gTLD communautaire.

1.5 Toutes les références à des jours dans cette procédure sont définis comme des jours civils.

2. Procédure de demande de changement d'un gTLD communautaire

2.1 L'opérateur de registre présente une demande de changement d'un gTLD communautaire (la « demande »)

L'opérateur de registre peut présenter une demande à tout moment. La demande doit être présentée à ICANN par écrit, accompagnée d'un questionnaire de demande de changement d'un gTLD communautaire (voir Annexe A) [PDF, 38 KB], et doit inclure la documentation à l'appui pour le changement par la communauté des TLD (y compris les entités représentant tout projet d'extension de la communauté des TLD, le cas échéant), ainsi que par le représentant des organes directeurs, le cas échéant.

2.2 Révision préliminaire de la demande par l'ICANN

Après réception d'une demande, l'ICANN devra mener une vérification d'exhaustivité et informer l'opérateur de registre, par écrit, de tout manquement à cet égard dans les 5 jours. L'opérateur de registre peut à tout moment soumettre une demande révisée à l'ICANN pour qu'elle soit à nouveau traitée. Si tous les éléments du questionnaire ont été abordés et les documents ont été présentés, la demande sera considérée comme complète.

Après la vérification d'exhaustivité, l'ICANN effectuera un examen préliminaire et préparera la demande et la modification préliminaire pour une période de consultation publique dans les 10 jours. Si au cours de la révision préliminaire l'ICANN détermine que la demande n'entre pas dans le champ d'application de cette procédure ou identifie des préoccupations qui seraient susceptibles d'entraîner le rejet de la demande, l'ICANN peut identifier ces préoccupations et initier une période de consultation avec l'opérateur de registre avant la période de commentaires.

2.3 Période de consultation sur la demande de changement

Après avoir mené la révision préliminaire de la demande, l'ICANN publiera la demande et la modification préliminaire pour une période de commentaires de 30 jours.

2.4 Période de réponse de l'opérateur de registre

Au le cas où des questions seraient soulevées à propos de la demande au cours de la période de commentaires, l'ICANN lancera une période de consultation avec l'opérateur de registre et demandera sa réaction aux commentaires reçus dans les 15 jours suivant la demande de l'ICANN. Pendant ce temps, l'ICANN peut également consulter l'opérateur de registre pour obtenir des précisions sur le(s) commentaire(s) pouvant avoir une incidence négative sur l'approbation de la demande et/ou répondre directement aux commentaires reçus, le cas échéant.

3. Révision et détermination de l'ICANN

3.1 Révision de l'ICANN

L'ICANN analysera si la demande doit être approuvée ou rejetée et son évaluation sera fondée sur les critères suivants :

1. Description de la communauté des TLD – Y a-t-il une description claire des exigences d'admissibilité du TLD et de son impact sur la demande ?
2. Preuve de la sensibilisation et du soutien à la communauté des TLD – Y a-t-il une des preuves raisonnables de sensibilisation dans la communauté des TLD montrant des efforts de l'opérateur de registre pour « exploiter un TLD de manière à permettre à la communauté des TLD de discuter et participer à l'élaboration et la modification des politiques et pratiques pour le TLD » ? Y a-t-il des preuves raisonnables du soutien à la demande de la part de la communauté des TLD ?
3. Avantages pour la communauté des TLD – Est-ce que les réponses fournies aux points 1.3 et 1.4 de la demande de changement expliquent convenablement comment la demande serait bénéfique pour la communauté des TLD ? La permission pour faire la modification serait au détriment de la communauté des TLD ?
4. Préoccupations soulevées au cours de la période de commentaires – Y a-t-il eu des préoccupations significatives identifiées au cours de la période de commentaires comme portant préjudice à la communauté TLD ou la communauté Internet ? L'opérateur de registre a-t-il répondu de manière adéquate à ces préoccupations ? Une réponse adéquate peut comprendre des éléments de preuve à l'appui de l'opérateur de registre disant (1) qu'il n'y aura pas de dommages à la réputation de la communauté ; (2) qu'il n'y a pas d'interférence avec les principales activités de la communauté ; ou (3) qu'il n'y a pas de dommages économiques pour la communauté.

3.2 Détermination de l'ICANN

3.2.1 Approbation

Si l'ICANN détermine que la demande est approuvée, l'ICANN devra présenter l'approbation à l'opérateur de registre dans un délai de 30 jours à compter de la clôture de la période de commentaires ou de la réponse de l'opérateur de registre aux préoccupations soulevées au cours de la période de commentaires. En cas de retard, l'ICANN devra fournir une explication écrite et indiquer la nouvelle date butoir.

Avec l'approbation, l'ICANN devra fournir un amendement pour l'exécution. Si cela s'avérait nécessaire, l'ICANN pourra modifier l'amendement pour la mise en œuvre de la demande approuvée et la présentera à l'opérateur de registre pour révision avant l'exécution.

3.2.2 Rejet

Si l'ICANN détermine que la demande est rejetée, l'ICANN devra présenter son rejet à la demande de changement et présenter clairement ses fondements dans un délai de 30 jours à compter de la clôture de la période de commentaires ou de la réponse de l'opérateur de registre aux préoccupations soulevées au cours de la période de commentaires. En cas de retard, l'ICANN devra fournir une explication écrite et indiquer la nouvelle date butoir.

ANNEXE A : Questionnaire sur la demande de changement des gTLD communautaires [PDF, 38 KB]