Processus de transition d'un registre

Définitions

Dans le cadre du présent document, les termes ci-dessous sont définis comme suit :

Opérateur de registre de secours : organisation engagée par un registre pour exécuter une ou plusieurs des fonctions critiques d'un registre gTLD.

Fonctions critiques :fonctions critiques au fonctionnement d'un registre gTLD :

1. Résolution de DNS
2. Zone DNSSEC correctement signée (si les DNSSEC sont offertes par le registre)
3. Système de registre partagé (SRS), en général via le protocole d'approvisionnement extensible (EPP)
4. Service d'annuaire de données d'enregistrement (RDDS), par exemple le service WHOIS fourni via le port 43 et un service basé sur le Web.
5. Dépôt de données d'enregistrement

Transition d'un registre : modification de la partie contractante d'un contrat de registre de gTLD avec l'ICANN. Parmi les circonstances qui mènent à la transition d'un registre, figurent : la modification du nom de l'organisation qui exécute le gTLD, une vente ou un transfert du registre, la violation du contrat de registre par le registre actuel, etc.

Registre successeur : nouvelle partie contractante d'un contrat de registre de gTLD avec l'ICANN après une transition du registre.

Processus de transition d'un registre

Selon la section 9.2 de l'affirmation d'engagements, l'un des engagements de l'ICANN consiste à :

Préserver la sécurité, la stabilité et la résilience [du DNS].¹

Les statuts constitutifs de l'ICANN identifient les valeurs fondamentales de l'organisation. La 1ère valeur fondamentale est la suivante :

Préserver et améliorer la stabilité opérationnelle, la fiabilité, la sécurité et l'interopérabilité mondiale de l'Internet.²

Le plan opérationnel de l'ICANN 2006-2007 (section 1.1.2) prévoit que l'ICANN :

Établira un plan complet à suivre en cas d'échec financier, technique ou commercial d'un opérateur de registre, y compris la pleine conformité aux exigences de dépôt de données et aux tests de reprise.³

Ce processus a été créé durant l'exercice fiscal 06-07 et a été continuellement mis à jour ; on parle dorénavant de Cadre de continuité des registres.⁴ Le processus de gestion des incidents et des événements décrit dans le Cadre de continuité des registres souligne la nécessité de trouver une solution lorsqu'il est porté préjudice aux fonctions de registre critiques.

Afin de respecter sa 1ère valeur fondamentale et suite à la définition du Cadre de continuité des registres, l'ICANN a souligné la nécessité de définir des processus de transition d'un gTLD de manière sécurisée, stable et fiable, tout en minimisant l'impact sur les titulaires de nom de domaine et les utilisateurs de gTLD, et en garantissant aux parties impliquées dans la transition la transparence.

Les trois processus suivants ont été développés et sont décrits dans le présent document :

1. Processus de transition d'un registre avec proposition de successeur
2. Processus de transition avec appel à propositions (RFP)
3. Processus de transition temporaire d'un opérateur de registre de secours

 

1. Processus de transition d'un registre avec proposition de successeur

   Ce processus sera utilisé lorsqu'un registre demandera à l'ICANN d'affecter son contrat de registre à un successeur potentiel (par exemple le registre est en cours d'acquisition, un changement de nom intervient dans l'organisation, une transition vers le fournisseur de continuité de services de registre s'opère). Ce processus sera également utilisé si, à la fin du terme du contrat de registre, ou suite au jugement d'une autorité légale compétente, le gouvernement ou l'autorité publique concerné retire son soutien à l'opérateur de registre d'un gTLD représentant un nom géographique et propose un registre successeur. Un organigramme de ce processus figure à l'Annexe 2.

   Un examen adéquat sera constamment exercé lors de l'évaluation du successeur proposé. Par exemple, dans le cas d'un changement de nom, l'évaluation veillera à ce que la garantie contre toute utilisation frauduleuse du TLD soit légitime.

   Lors de la réception de la requête du registre actuel ou du gouvernement ou de l'autorité publique concerné (dans le cas de gTLD géographiques), l'ICANN évaluera la situation à partir des faits recueillis, des conversations avec le registre actuel et, éventuellement, le gouvernement ou l'autorité publique, ainsi que d'une analyse du contrat de registre. L'évaluation portera sur les questions suivantes :

   • Une entité fournissant l'une quelconque des fonctions de registre de secours a-t-elle été modifiée ?
   • Le TLD possède-t-il une communauté intéressée devant être consultée ?
   • Le gTLD correspond-t-il à un nom géographique d'après la définition du guide de candidature ? (Ou le soutien du gouvernement était-il requis au moment de la candidature ?)
   • Existe-t-il des restrictions dans le contrat de registre pouvant affecter une transition ?

   L'ICANN procédera également à une évaluation des risques du gTLD, du registre actuel et de l'opérateur de registre de secours (en cas de modification à cet égard). L'évaluation portera sur les particularités de ces trois éléments pris ensemble et individuellement. Par exemple, il sera déterminé si le gTLD est très utilisé par des institutions financières ou pour le commerce électronique, ce qui pourrait conduire à l'adoption de mesures plus strictes concernant la sécurité de la transition.

   Une fois ces évaluations terminées, le registre successeur proposé sera vérifié pour s'assurer qu'il dispose du soutien externe requis, si cela est exigé. Si le gTLD est un nom géographique, comme défini dans le guide de candidature aux nouveaux gTLD, l'ICANN invitera le successeur proposé à demander au gouvernement ou à l'autorité publique concerné d'apporter son soutien au successeur potentiel et à fournir des documents attestant de ce soutien/cette non-objection. Si le contrat de registre prévoit qu'une communauté précise doit être consultée au moment de la transition, l'ICANN la consultera à ce stade. Dans ces cas, la communauté en question doit apporter son soutien au successeur proposé afin que le processus poursuive la transition.

   Si le successeur proposé dispose du soutien requis ou si aucun soutien n'est requis, l'ICANN procédera alors à l'évaluation du candidat à l'aide des processus définis dans le guide de candidature aux nouveaux gTLD. En fonction des critères énoncés dans la Matrice d'évaluation de registre prospectif décrite à l'Annexe 1, l'ICANN déterminera les évaluations nécessaires, recueillera les informations et percevra les frais. Ces frais couvriront le coût des évaluations menées par des fournisseurs externes.

   Le candidat ne prendra pas en charge les coûts liés aux évaluations internes menées par l'ICANN.

   La portée des évaluations variera pour chaque cas en fonction du niveau d'examen requis et approprié. Les trois niveaux d'examen sont présentés à l'Annexe 1. La portée du niveau le plus élevé (Complet) sera identique à celle de l'examen des candidats aux nouveaux gTLD. L'évaluation sera menée par l'une des entreprises engagées pour évaluer les candidatures aux nouveaux gTLD. La portée du niveau suivant (Limité) est plus restreinte. Par exemple, l'évaluation technique et des opérations peut consister à s'assurer que la nouvelle organisation dispose d'accords similaires avec l'opérateur de registre de secours existant. La portée du troisième niveau (Minimal) est très limitée ; cet examen sera effectué en interne par l'ICANN.

   Le fournisseur d'évaluation procédera ensuite aux évaluations requises et fournira un rapport au candidat et à l'ICANN. Si le candidat ne satisfait pas aux critères d'évaluation, il pourra, dans un délai de trois semaines à compter de l'échec de l'évaluation, corriger les lacunes (évaluation étendue). Si le candidat échoue encore lors de la seconde évaluation, le processus prendra fin sans transition et le candidat bénéficiera du remboursement des frais perçus moins les coûts d'évaluation réels.

   Si le successeur potentiel réussit l'évaluation, l'ICANN cherchera à obtenir les approbations requises et, en cas d'approbation, conclura un contrat de registre avec le successeur. Si le successeur potentiel n'est pas retenu, le processus se termine sans transition.

   Une fois le successeur approuvé, ce résultat sera communiqué de manière interne et externe, si nécessaire et de façon appropriée. Si la transition n'implique pas de changement au niveau de l'opérateur de registre de secours, le successeur doit alors demander la modification de l'organisation de parrainage auprès de l'IANA.

   En cas de modification de l'entité fournissant des services d'opérateur de registre de secours, le successeur devra réussir les tests de pré-délégation tels que définis dans le guide de candidature aux nouveaux gTLD, que le fournisseur de secours soit l'opérateur de registre ou un prestataire de l'opérateur de registre. Une fois le test correctement exécuté, le nouvel opérateur de registre doit procéder à la modification de l'organisation de parrainage auprès de l'IANA dans la base de données de zone racine de l'IANA. Une fois l'étape de l'IANA achevée, l'opérateur de registre successeur effectuera la migration des données et des services, puis demandera à l'IANA de modifier les enregistrements du DNS et du RDDS (WHOIS).

   Les étapes finales du processus de transition consisteront à communiquer de manière interne et externe, si nécessaire et de façon appropriée, afin que l'ICANN mette à jour ses informations publiques et internes relatives au registre gTLD.

2. Processus de transition d'un registre avec RFP

   Ce processus sera principalement utilisé en cas de violation par un registre gTLD de son contrat de registre (menant à sa résiliation) et si aucun registre successeur n'a été identifié. Ce processus sera également utilisé si, à la fin du terme du contrat de registre, ou suite au jugement d'une autorité légale compétente, le gouvernement ou l'autorité publique concerné retire son soutien au registre d'un gTLD géographique et ne propose pas de registre successeur. Un organigramme de ce processus figure à l'Annexe 3.

   Ce processus est similaire au Processus de transition d'un registre avec proposition de successeur décrit ci-dessus, sauf qu'il inclut un sous-processus d'appel à propositions (RFP). L'objectif de l'appel à propositions est d'identifier et de solliciter des candidatures auprès de registres successeurs potentiels.

   Le processus d'appel à propositions sera lancé après l'évaluation des risques du gTLD, cette évaluation pouvant dégager d'importantes conclusions devant figurer dans l'appel à propositions. L'appel à propositions décrira les services nécessaires que le registre successeur devra fournir. En outre, les coûts prévus pour les services d'évaluation seront inclus dans l'appel à propositions et serviront de proposition économique minimum acceptable d'un candidat.

   Si le registre exploite un gTLD qui correspond à un nom géographique, comme défini dans le guide de candidature, l'ICANN consultera le gouvernement ou l'autorité publique concerné afin d'inclure leurs commentaires dans l'appel à propositions. Ensuite, si le contrat de registre contient une disposition exigeant que l'ICANN consulte une communauté spécifique concernant un successeur potentiel avant la transition, cette consultation sera effectuée à ce stade du processus.

   Une fois l'appel à propositions approuvé, il sera publié pendant 45 jours et les candidats auront jusqu'à la fin de la période de publication pour donner une réponse.

   Le candidat qui propose le paiement le plus élevé au registre d'origine sera ensuite contrôlé afin de s'assurer qu''il dispose du soutien requis et évalué comme décrit dans le Processus de transition d'un registre avec proposition de successeur. Ce mécanisme de sélection fournit le retour maximum pour le registre d'origine et réduit les dépenses inutiles pour les candidats non retenus, tout en veillant à ce que le candidat retenu soit qualifié.

   Si le candidat dispose du soutien requis (ou si aucun soutien n'est requis) et qu'il réussit l'évaluation, le processus se poursuivra comme décrit dans le processus susmentionné. Si le candidat ne dispose pas du soutien requis ou échoue lors de l'évaluation, le candidat suivant avec la proposition la plus élevée sera examiné, etc. jusqu'à trouver un candidat disposant du soutien requis et ayant réussi l'évaluation ou jusqu'à ce qu'il n'y ait plus de propositions.

   Si aucune proposition n'est reçue au cours du processus d'appel à propositions ou si aucun des candidats n'est qualifié, en raison du manque de soutien approprié ou de son échec à l'évaluation, le processus d'abrogation de TLD sera invoqué afin de clôturer le gTLD. Si un candidat viable est identifié après la clôture d'un processus d'appel à propositions qui n'a pas permis d'identifier un successeur, cette candidature pourra être examinée en fonction des circonstances présentes et l'on évaluera également si une telle décision sert ou non l'intérêt public.

   Si un registre successeur qualifié est identifié via ce processus, tous les fonds versés par ce candidat moins les coûts d'évaluation et les dépenses impayées seront remis à l'opérateur de registre en charge du gTLD.

3. Processus de transition temporaire d'un opérateur de registre de secours

   Ce processus sera utilisé pour les nouveaux gTLD, principalement sous deux conditions : (1) le registre n'a pas respecté son contrat de registre et (2) une fonction critique est exécutée sous le seuil d'urgence, tel que défini dans le contrat de registre, entraînant une situation de risque inacceptable comme définie ci-dessous. Dans un tel cas, des opérations peuvent être transférées à un fournisseur d'urgence de services de secours jusqu'à ce que l'opérateur de registre puisse restaurer les opérations normales. Cette transition temporaire peut également être initiée à la demande de l'opérateur de registre si une impossibilité de fournir les fonctions critiques de manière adéquate est détectée ou anticipée.

   Les mesures permettant de détecter le seuil d'urgence pour les fonctions critiques (à l'exception du dépôt de données) seront tirées du système de suivi de la convention de service du registre utilisé par l'ICANN, comme décrit dans le contrat de registre.

   Il convient également de noter que ce processus de transition est censé être une mesure temporaire visant à protéger les titulaires de nom de domaine et les utilisateurs du gTLD. La transition temporaire des fonctions critiques demeurera effective jusqu'à la résolution des problèmes sous-jacents ou la transition du gTLD vers un autre opérateur utilisant les processus de transition de registre précédemment décrits. Afin d'autoriser cette transition temporaire, le contrat de registre des nouveaux gTLD prévoit une pré-autorisation de la part de l'opérateur de registre afin d'effectuer des changements dans la base de données de l'IANA des enregistrements du DNS et du RDDS (WHOIS), en cas d'urgence.

   Une fois que l'opérateur de registre est prêt à reprendre les opérations et qu'il a remédié à tous les problèmes à l'origine du non-respect de ses obligations, il peut lancer un Processus de transition d'un registre avec proposition de successeur afin de reprendre le contrôle des opérations du gTLD. L'opérateur de registre pourra profiter de cette option jusqu'à l'expiration de la période de remédiation à la violation. L'opérateur de registre s'identifiera lui-même en tant que successeur proposé dans ce processus.

   L'ICANN conservera au moins deux opérateurs de registre de secours présélectionnés (opérateurs d'urgence) sous contrat. Un processus d'appel à propositions d'opérateur d'urgence sera lancé tous les cinq ans afin de renouveler les contrats et/ou d'identifier et de sélectionner de nouveaux opérateurs d'urgence. Les opérateurs d'urgence qui sont sélectionnés proviendront de diverses régions géographiques afin d'accroître la fiabilité des opérateurs d'urgence dans leur ensemble ; en cas de catastrophe dans une région affectant le fonctionnement de l'un des opérateurs d'urgence, l'autre opérateur sera toujours prêt à le suppléer. Les conditions de base d'éligibilité des opérateurs d'urgence sont les suivantes : au moins trois ans d'expérience dans le fonctionnement d'un DNS et un an d'expérience dans le fonctionnement du RDSS (par exemple WHOIS) et des services EPP.

   L'ICANN sélectionnera les opérateurs d'urgence sur le fondement de leur valeur, à savoir la meilleure combinaison entre service et prix. Les fonds affectés au recours aux services de l'opérateur d'urgence pour chaque cas proviendront des différents instruments assurant la continuité des opérations pour les opérateurs de registre des nouveaux gTLD tel que prévu par la spécification 8 du contrat de registre.

   Les candidats au poste d'opérateur d'urgence seront évalués à l'aide de processus similaires à ceux des nouveaux gTLD, y compris des tests de pré-délégation sur l'infrastructure à utiliser en cas d'urgence. L'infrastructure doit être prête à fonctionner pendant l'évaluation. L'ICANN peut, de temps en temps, imposer un test des capacités et de la disponibilité de l'opérateur d'urgence afin d'accepter et de procéder à une transition d'urgence.

   Dès que l'ICANN sélectionne les opérateurs d'urgence, ceux-ci fourniront un contrat de registre-bureau d'enregistrement « léger » à tous les bureaux d'enregistrement qui permettra aux opérateurs d'urgence d'exécuter des fonctions SRS lors d'un processus de transition temporaire. Les bureaux d'enregistrement seront encouragés à engager les opérateurs d'urgence avant toute situation d'urgence afin qu'ils soient prêts à opérer (par exemple un contrat doit être établi, des identifiants pour accéder au SRS doivent déjà être diffusés, un test opérationnel des opérateurs d'urgence doit être effectué, etc.) en cas de lancement d'une transition d'urgence pour un gTLD donné.

   Lors d'une urgence qui nécessite les services d'opérateur d'urgence, l'ICANN tâchera d'abord d'engager l'un des opérateurs d'urgence. Si le fournisseur sélectionné n'est pas en mesure de se charger de l'opération ou s'il existe un conflit d'intérêts, l'ICANN engagera alors un autre fournisseur. Un opérateur d'urgence actif pourra demander à devenir le registre successeur définitif ou l'opérateur de secours du gTLD en cas de transition de registre, conformément aux règles habituelles de l'appel à propositions. Afin de mener un processus d'appel d'offres équitable, un opérateur d'urgence actif fournira à l'ICANN les informations opérationnelles devant être incluses dans un RFP pour le fonctionnement du gTLD.

   L'opérateur de registre de secours actuel pourrait occuper la fonction d'opérateur d'urgence. Un tel cas de figure se présenterait si :

   • l'opérateur de registre demandait à l'ICANN de lancer la transition d'urgence pour l'opérateur de registre de secours en tant qu'opérateur d'urgence ;
   • l'opérateur de registre de secours actuel assurait les fonctions critiques dans le respect des niveaux de service définis dans le contrat de registre ;
   • la société de l'opérateur de registre de secours n'était pas liée ou associée à l'opérateur de registre ; et
   • l'opérateur de registre de secours acceptait d'exploiter le gTLD en vertu de conditions équivalentes ou plus avantageuses que celles convenues par les opérateurs d'urgence.

   L'ICANN pourra alors, à son entière discrétion, proposer à l'opérateur de registre de secours d'assurer les fonctions de registre pour le gTLD. Dans ce cas, l'opérateur de registre de secours faisant office d'opérateur d'urgence sera payé par prélèvement sur les produits de l'instrument assurant la continuité des opérations.

   Les opérateurs d'urgence auront des exigences de niveau de service pour l'activation de chacune des fonctions critiques, comme suit.

   Fonction critique	Exigence de niveau de service
   DNS/DNSSEC	4 heures à compter de la demande de l'ICANN
   RDDS	24 heures à compter de la réception de données
   SRS (EPP)*	72 heures à compter de la réception de données
   Dépôt de données	24 heures à compter du début de l'opération du SRS

   *Serveurs SRS prêts à accepter des demandes de bureaux d'enregistrement.

   Les opérateurs d'urgence conserveront un dossier contenant au moins les fichiers de zone quotidiens pour tous les gTLD afin de permettre à l'opérateur d'urgence sélectionné de redémarrer rapidement le service DNS en cas d'urgence. Pour les autres fonctions critiques, les données seront obtenues à partir du registre actuel et/ou des remises du dépôt de données.

   Les dépositaires légaux des nouveaux gTLD devront convenir d'une exigence pour la publication des données du gTLD dans un délai de 24 heures à compter de la demande, en cas d'urgence.

   En cas d'opération d'urgence de fonctions critiques pour un gTLD, un opérateur d'urgence ne facturera pas les opérations du SRS des bureaux d'enregistrement.

   En règle générale, l'opérateur d'urgence n'acceptera pas de nouveaux domaines, de renouvellements de domaines, de transferts de domaines ou de suppressions de noms de domaine de la part des bureaux d'enregistrement. Toutefois, dans certaines cas exceptionnels, les opérations susmentionnées seront acceptées, par exemple en cas de demande accélérée de sécurité du registre ⁵, d'UDRP ou de toute autre procédure de règlement de litiges en matière de noms de domaine de l'ICANN. Les transferts groupés de domaines peuvent être approuvés par l'ICANN pour des domaines parrainés par des bureaux d'enregistrement ne pouvant plus assurer leur mise en service (par exemple un bureau d'enregistrement qui a perdu son accréditation). L'opérateur de registre ne pourra faire expirer des enregistrements ou les renouveler automatiquement et inclura dans les résultats du RDDS (par exemple le WHOIS) une brève explication (approuvée par l'ICANN)  au-dessus de la clause de non-responsabilité (le cas échéant), tel que décrit dans la section 1.1 de la spécification 4 du contrat de registre, des raisons pour lesquelles la date d'expiration est dans le passé. Le reste du nom de domaine standard, des contacts et des opérations du SRS de l'hôte (RFC 5730-34, 5910) seront autorisés. L'opérateur d'urgence collaborera avec tous les bureaux d'enregistrement accrédités possédant des domaines parrainés dans le gTLD.

   Un registre successeur sera autorisé à facturer le renouvellement ou les renouvellements fractionnés à compter de la date de début de ses opérations. Le registre successeur devra prendre en charge les frais du registre ayant échoué et devra suivre le processus défini dans le contrat de registre afin de les modifier.

   Un organigramme du processus à suivre en cas d'urgence figure à l'Annexe 4.

   Lors de la transition d'un opérateur d'urgence vers l'opérateur de registre précédent ou vers un nouvel opérateur de registre, l'opérateur de registre collaborera et coopérera avec le nouvel opérateur afin d'assurer une transition en bonne et due forme ayant le moins d'incidences possible sur les titulaires de nom de domaine et les utilisateurs gTLD.

   Le cas échéant, l'ICANN suivra et documentera les processus de transition d'urgence. Des indicateurs seront développés, notamment des indicateurs des performances des opérateurs de registre et des EBERO eu égard aux cinq fonctions critiques. L'ICANN prendra note de ce qui a bien fonctionné et de ce qui pourrait être amélioré afin de proposer des modifications du processus.

---

• Appendix 1 | Prospective Registry Evaluation Matrix
• Appendix 2-1 | Registry Transition Process with Proposed Successor
• Appendix 2-2 | Registry Transition Process with Proposed Successor - Check Support
• Appendix 2-3 | Registry Transition Process with Proposed Successor - Evaluate
• Appendix 2-4 | Registry Transition Process with Proposed Successor - Communicate
• Appendix 3-1 | Registry Transition Process with Request for Proposals
• Appendix 3-2 | Registry Transition Process with Request for Proposals - Check Support
• Appendix 3-3 | Registry Transition Process with Request for Proposals - Evaluate
• Appendix 3-4 | Registry Transition Process with Request for Proposals - RFP
• Appendix 3-5 | Registry Transition Process with Request for Proposals - Communicate
• Appendix 4-1 | Emergency Back-End Registry Operator Temporary Transition Process
• Appendix 4-2 | Emergency Back-End Registry Operator Transition Process - DNS
• Appendix 4-3 | Emergency Back-End Registry Operator Transition Process - RDDS
• Appendix 4-4 | Emergency Back-End Registry Operator Transition Process - SRS
• Appendix 4-5 | Emergency Back-End Registry Operator Transition Process - Data Escrow
• Appendix 4-6 | Emergency Back-End Registry Operator Transition Process - Communicate

---

¹ ICANN. (2009, September 30). Affirmation of Commitments. Retrieved from http://www.icann.org/en/documents/affirmation-of-commitments-30sep09-en.htm

² ICANN. (2009, September 30). ICANN bylaws. Retrieved from http://www.icann.org/en/general/bylaws.htm#I

³ ICANN. (2006, June 22). 2006-2007 ICANN Operating Plan. Retrieved from http://www.icann.org/announcements/operating-plan-22jun06.htm

⁴ ICANN. (2009). gTLD Registry Continuity. Retrieved from http://www.icann.org/en/registries/continuity/

⁵ http://icann.org/en/registries/ersr/