Notes relatives à la mise en œuvre de la RSEP

À compter du 17 juin 2019

Après plusieurs mois de discussions, le groupe de discussion du RySG sur les améliorations de la RSEP et l'organisation ICANN ont convenu d'établir un ensemble d'améliorations opérationnelles pour faciliter l'efficacité et la prévisibilité du processus tout en adhérant à la Politique. Cette version 2019 des notes relatives à la mise en œuvre de la RSEP reflète les changements accordés entrés en vigueur le 17 juin 2019.

Cliquez ici pour revenir à la page Web du processus RSEP.

Introduction

Le 8 novembre 2005 le Conseil d'administration de l'ICANN a indiqué la mise en œuvre de la procédure recommandée par la GNSO pour la considération des demandes de nouveaux services de registre sur la base des dispositions contenues dans le contrat de registre .NET en ce concernant les définitions des services de registre. Ces notes relatives à la mise en œuvre sont un résumé du processus de la Politique d'évaluation des services de registre(RSEP) et visent à fournir des informations de haut niveau sur la mise en œuvre de la Politique par l'organisation ICANN. L'organisation ICANN peut examiner périodiquement l'efficacité de cette mise en œuvre avec la participation des opérateurs de registre et des unités constitutives concernés.

En 2019, le groupe de discussion appartenant au groupe des représentants des opérateurs de registre (RySG) a collaboré avec l'organisation ICANN pour mettre à jour les notes relatives à la mise en œuvre sans modifier la Politique elle-même. Ces notes révisées ont été conçues pour que le processus RSEP soit plus facile à comprendre, pour améliorer sa prévisibilité et pour assurer qu'il soit en ligne avec la Politique sous-jacente.

Un opérateur de registre gTLD peut soumettre une demande RSEP à l'organisation ICANN pour ajouter un service de registre proposé, modifier un service de registre existant, ou bien supprimer un service de registre. Si l'organisation ICANN détermine qu'un service proposé dans une demande RSEP n'est pas considéré comme un service de registre tel que défini dans le contrat de registre, l'organisation ICANN en informera l'opérateur de registre et fermera la demande. L'opérateur de registre pourra retirer sa demande à tout moment.

En réponse aux différences entre la politique de consensus RSEP et les termes contractuels de certains contrats de registre gTLD historiques, l'organisation ICANN a créé une réconciliation entre la politique de consensus et les conditions contractuelles des contrats gTLD contenant le processus d'évaluation. La réconciliation vise à démontrer que la mise en œuvre de la politique de consensus se traduit par un processus qui n'est incompatible ni avec la politique de consensus ni avec aucun contrat de gTLD en cours. L'organisation ICANN tiendra compte de la réconciliation pour toutes les demandes RSEP relatives à des contrats de registre présentant ces différences.

Sauf indication contraire, les jours mentionnés seront des jours civils.

Étape 1 : soumission de la demande

Les opérateurs de registre pourront soumettre des demandes RSEP à l'organisation ICANN en utilisant le formulaire de demande approprié sur la base des critères ci-dessous :

1. Formulaire de demande RSEP standard : pour les demandes RSEP visant à ajouter un service de registre proposé, pour supprimer un service de registre existant ou modifier substantiellement un service de registre existant, les opérateurs de registre devront répondre à une série de questions standard qui fourniront à l'organisation ICANN des informations suffisantes pour évaluer la demande. Les opérateurs de registre pourront décider que l'information fournie dans la RSEP porte la mention « CONFIDENTIEL », à l'exception de toute information nécessaire pour décrire l'objectif du service de registre proposé et de l'effet de la divulgation de telles informations sur les utilisateurs du DNS.

   Afin de respecter les délais de la Politique et d'offrir davantage de prévisibilité aux opérateurs de registre, la Politique et l'organisation ICANN encouragent les opérateurs de registre à consulter l'organisation ICANN avant de soumettre un formulaire de demande RSEP standard. Cette étape ne vise pas à créer une charge supplémentaire pour l'opérateur de registre ; son intention est plutôt d'aider à assurer que l'information nécessaire soit disponible suffisamment à l'avance pour l'analyse de la demande RSEP. Ce sera également l'occasion de discuter si la demande est admissible en vertu de la Politique, d'identifier et de clarifier les préoccupations qui pourraient apparaître lors de l'examen formel de la demande, et d'accorder une version appropriée de la rédaction de l'autorisation aussi rapidement que possible.

2. Formulaire de demande RSEP simplifié : pour certains services connus (des services ayant été examinés à plusieurs reprises par l'organisation ICANN et n'ayant pas soulevé d'importantes questions en matière de sécurité ou de stabilité, ayant été approuvés auparavant et ayant un modèle de modification publié et disponible), l'opérateur de registre devra remplir un formulaire de demande simplifié et confirmer l'utilisation d'un modèle d'amendement standard sans modifications. Cette étape pourra réduire la durée de la période allant de la soumission à l'autorisation d'une demande RSEP sur un service connu.

Étape 2 : vérification d'exhaustivité de l'ICANN

Les demandes RSEP ne seront pas publiées tant que la vérification d'exhaustivité que toutes les interactions entre l'organisation ICANN et l'opérateur de registre concernant la demande RSEP restent confidentielles. Une fois qu'une demande aura été déposée, l'organisation ICANN effectuera une révision de l'exhaustivité qui devrait prendre moins de 15 jours. Une demande devra répondre aux critères suivants avant d'aborder l'étape 3, « révision de l'ICANN » :

1. Information suffisante : la demande devra inclure suffisamment d'informations pour que l'organisation ICANN prenne une détermination préliminaire informée au cours de la révision de l'ICANN. Les soumissions complètes des demandes RSEP standard incluent des réponses exhaustives à toutes les questions pertinentes, y compris une description complète du service proposé, une évaluation de l'impact sur les utilisateurs externes, une liste et une explication des dispositions contractuelles affectées par le nouveau service (le cas échéant), l'amendement proposé (si celui-ci s'avérait nécessaire), les commentaires des parties externes et de la communauté (s'il y en avait), et toutes les pièces justificatives utiles à la détermination préliminaire.

2. Document d'autorisation : à la fin de l'étape 2, l'organisation ICANN et l'opérateur de registre devraient se mettre d'accord sur le type de document d'autorisation et, pour l'amendement d'un contrat de registre (RA), sur la rédaction du dit amendement avant que la demande ne soit présentée à la révision de l'ICANN. Les raisons pour lesquelles l'organisation ICANN pourrait ne pas être d'accord pour accorder un document d'autorisation incluent les conflits du service proposé avec la politique de consensus de l'ICANN ou avec les directives du Conseil d'administration de l'ICANN.

   Type de document d'autorisation et critères :

   • Amendement au contrat de registre (RA) : utilisé lorsque le service proposé (i) est en contradiction avec les dispositions du contrat de registre ou (ii) n'est pas envisagé dans le contrat de registre et, par conséquent, doit être ajouté à la pièce A du dit contrat et/ou comme un addenda/annexe approprié.

   • Lettre 'libre d'être utilisé': utilisée lorsque le service proposé est déjà prévu dans le contrat de registre et ne contredit pas les dispositions contractuelles.

L'organisation ICANN pourra identifier le besoin de fournir des informations supplémentaires dans la demande RSEP afin qu'elle puisse les évaluer et les inclure dans la publication de la demande. Dans ce cas, l'organisation ICANN pourra consulter l'opérateur de registre et/ou lui demander de soumettre à nouveau sa demande avec des informations supplémentaires, ce qui peut prolonger l'étape 2 : « vérification d'exhaustivité ». L'organisation ICANN travaillera de bonne foi avec l'opérateur de registre dans le cadre de ce processus.

2A - Demande de poursuite

Si les parties accordent que le critère 1 de l'étape 2 a été respecté, mais si l'opérateur de registre et l'organisation ICANN ne se sont pas mis d'accord sur le type de document et/ou sur le texte de la modification, l'opérateur de registre pourra soumettre une demande de poursuite à l'étape 3, « révision de l'ICANN », avant que le document d'autorisation ne soit finalisé. L'organisation ICANN étudiera toutes les demandes de poursuite en temps opportun et fera, de bonne foi, l'évaluation du progrès des négociations.

L'organisation ICANN pourra décider une des actions suivantes si une demande de poursuite était présentée :

• Une fois que les négociations seront presque terminées, l'organisation ICANN pourra accorder la demande de poursuite et, dans ce cas, la demande RSEP passera à l'étape 3, « révision de l'ICANN ». À ce moment-là, la demande RSEP sera publiée. Les deux parties poursuivront les négociations au cours de l'étape 3 dans le but de parvenir à un accord une fois que la révision de l'ICANN sera finie.

• Si les négociations ne sont pas proches de leur achèvement, l'organisation ICANN pourra demander des négociations supplémentaires avec la participation des dirigeants de l'organisation ICANN. Cette participation aura lieu avant le passage de la demande RSEP à l'étape 3. Si l'organisation ICANN accepte la demande de poursuite après l'escalade, elle pourra publier le document d'autorisation proposé pour consultation publique si le service de registre proposé établissait un nouveau précédent ou s'il avait des conséquences importantes sur l'ICANN, des tierces parties, ou sur le système des noms de domaine. La consultation publique aura lieu à la suite de l'étape 3, « révision de l'ICANN ».

• Si l'organisation ICANN détermine que l'opérateur de registre n'a pas négocié de bonne foi, elle pourra rejeter la demande de poursuite.

Étape 3 : révision de l'ICANN

Une fois que l'organisation ICANN aura décidé qu'une demande est complète ou aura accepté une demande de poursuite à l'étape 2, celle-ci démarrera un processus de révision de 15 jours et publiera le service de registre proposé.

Au cours de la révision de l'ICANN, on fera une détermination provisoire sur la question de savoir si des questions concernant la sécurité, la stabilité ou la concurrence ont été soulevées. L'organisation ICANN suivra les lignes directrices publiées sur la détermination préliminaire des questions relatives à la concurrence et pourra demander l'avis d'experts provenant d'entités ou de personnes assujetties aux accords de confidentialité sur les conséquences vis-à-vis de la sécurité, la stabilité, ou la concurrence du service de registre proposé. Ce groupe d'experts pourra inclure des membres du Panel d'évaluation technique des services de registre (RSTEP). Cette révision ne dépassera pas les 15 jours, tel que cela est prévu dans la Politique.

À la fin de l'étape 3, « révision de l'ICANN », l'organisation ICANN informera l'opérateur de registre ayant présenté la demande de sa détermination préliminaire sur le service de registre proposé.

Étape 4 : approbation ou renvoi

La détermination préliminaire de l'étape 3 entraînera l'un des résultats suivants :

1. Approbation de la demande RSEP,

2. Renvoi au panel d'évaluation technique des services de registre (RSTEP),

3. Renvoi à l'autorité gouvernementale compétente en matière de concurrence, ou

4. Renvoi au RSTEP et à l'autorité gouvernementale compétente en matière de concurrence.

Si la détermination préliminaire impliquait les résultats 2 à 4, l'opérateur de registre en sera notifié et devra confirmer son intention de poursuivre le processus de révision ou bien de retirer la demande RSEP. Si cela s'avérait nécessaire, l'opérateur de registre pourra consulter l'organisation ICANN sur les résultats.

Résultat	Décision	Prochaines étapes
(1) Approbation	Aucun problème considérable apparent concernant la sécurité, la stabilité, ou la concurrence	La demande sera considérée comme ayant été complétée et passera à l'étape 6, « autorisation ».
(2) Renvoi au RSTEP	Pourrait soulever d'importants problèmes en matière de stabilité ou de sécurité	Si l'opérateur de registre confirmait qu'il souhaite poursuivre le processus, le service proposé sera évalué par le RSTEP (la liste des membres du RSTEP est publiée ici). Une fois qu'une demande sera renvoyée au RSTEP, le panel aura 45 jours pour réviser le service proposé et élaborer un rapport sur les questions relatives à la sécurité ou la stabilité. Une version non expurgée du rapport final du RSTEP sera fournie à l'opérateur de registre. Étape 5 : consultation publique et commentaires de l'ICANN requis.
(3) Renvoi à l'autorité gouvernementale compétente en matière de concurrence	Pourrait soulever de graves problèmes en matière de concurrence	Si l'opérateur de registre confirme qu'il souhaite poursuivre le processus, l'organisation ICANN renverra la question à l'autorité gouvernementale compétente en matière de concurrence dans un délai de cinq jours ouvrables suivant la confirmation de l'opérateur de registre pour continuer. Étape 5 : consultation publique et commentaires de l'ICANN requis.
(4) Renvoi soit au RSTEP, soit à l'autorité gouvernementale compétente en matière de concurrence	Pourrait soulever d'importants problèmes en matière de stabilité ou de sécurité et de concurrence	Si l'opérateur de registre confirmait qu'il souhaite poursuivre le processus, l'organisation ICANN suivra les étapes des résultats 2 et 3.

Étape 5 : consultation publique et commentaires de l'ICANN (le cas échéant).

Une période de consultation publique sur un document d'autorisation proposé résultant de la demande RSEP sera nécessaire si le service de registre proposé a été renvoyé au RSTEP ou à l'autorité compétente en matière de concurrence à l'étape 4 ou dans les conditions décrites au paragraphe 2A, « demande de poursuite ».

• Renvoi au RSTEP : le service de registre proposé et le document préliminaire d'autorisation seront publiés pour consultation publique pendant que le RSTEP mène sa révision. Dès que le rapport d'évaluation du RSTEP sera fini, il sera ajouté à la période de consultation publique en cours. Une fois que la période de consultation publique sera terminée, l'opérateur de registre pourra répondre aux commentaires et le document d'autorisation préliminaire pourra être mis à jour.

• Renvoi à l'autorité compétente en matière de concurrence : Le service de registre proposé et le document d'autorisation seront publiés pour consultation publique pendant la période de renvoi de 45 jours à l'autorité gouvernementale compétente en matière de concurrence.

  • Si l'autorité concernée soulève des questions pendant la période de renvoi de 45 jours, l'opérateur de registre pourra travailler avec l'organisation ICANN pour régler les problèmes et le document d'autorisation préliminaire pourra être mis à jour.

  • Si l'autorité compétente en matière de concurrence n'a pas soulevé des questions pendant la période de renvoi de 45 jours ou si la demande est acceptée plus tôt, l'organisation ICANN en tiendra compte dans son analyse des commentaires publics. 

  • Une fois que la période de consultation publique sera terminée, l'opérateur de registre pourra répondre aux commentaires et l'autorisation préliminaire pourra être mise à jour.

Après la période de consultation publique, l'approbation de la demande RSEP sera examinée par l'organisation ICANN ou sera renvoyée au Conseil d'administration de l'ICANN.

Si elle était renvoyée au Conseil d'administration de l'ICANN, son objectif sera de parvenir à une décision dans un délai de 30 jours à compter de la finalisation du résumé des commentaires publics et du rapport d'analyse. Le Conseil d'administration de l'ICANN pourra décider 1) d'approuver la demande RSEP, 2) de refuser la demande RSEP, ou 3) de ne pas se prononcer en attendant plus d'informations.

Si le Conseil d'administration ou l'organisation ICANN approuvaient la demande RSEP, l'opérateur de registre et l'organisation ICANN passeront à l'étape 6, « autorisation ». Si le Conseil d'administration de l'ICANN refusait la demande, celle-ci ne sera pas considérée.

Étape 6 : autorisation

Comme dans le cas de la mise en œuvre préalable de la Politique par l'ICANN, une fois qu'une demande RSEP aura été approuvée et que, tant l'organisation ICANN que l'opérateur de registre auront accepté le document d'autorisation, l'organisation ICANN déclenchera le processus d'autorisation. Dans un délai maximal de 5 jours suivant la satisfaction de ces conditions, l'organisation ICANN devra :

1. Envoyer une lettre 'libre d'être utilisé' à l'opérateur de registre (comme convenu à l'étape 2), à la date à laquelle l'opérateur de registre pourra utiliser le service ou

2. Lancer le processus d'exécution du contrat de registre en utilisant la modification au RA de l'étape 2 ou de l'étape 5 si les mises à jour sont effectuées suite à la période de consultation publique. L'opérateur de registre pourra déployer le service demandé après l'exécution de la modification par, soit l'opérateur de registre, soit l'organisation ICANN.

L'organisation ICANN publiera un avis du service de registre approuvé ainsi que le document d'autorisation sur le site Web de la RSEP et le site Web du contrat de registre spécifique pour les TLD.

Si l'opérateur de registre faisait le déploiement sans un document d'autorisation, il pourra être considéré comme ne respectant pas la conformité.

Flux de travail du processus RSEP

Voir le flux de travail du processus RSEP [PDF, 50 KB] pour une représentation de haut niveau du processus RSEP contenant des références à ces informations de mise en œuvre.

Archives

Cette page Web a été mise à jour en juin 2019 dans le cadre des améliorations opérationnelles du processus RSEP (voir le blog post de l'organisation ICANN). Les notes sur la mise en œuvre sont disponibles ici.