Skip to main content
Resources

Modifications au contrat de sous-traitance partiel de fonctions critiques (MSA)

Cette page est disponible en:

Veuillez noter que seule la version anglaise des contenus et des documents traduits a un caractère officiel. Les traductions dans d'autres langues sont fournies uniquement à titre informatif.

Aperçu

Cette page Web oriente les opérateurs de registre sur la procédure de demande d'approbation d'une modification au contrat de sous-traitance partiel de fonctions critiques (MSA) à l'organisation ICANN.

Tout arrangement de sous-traitance lié à une fonction critique telle que définie dans la section 6 de la spécification 10 du Contrat de registre est considéré comme un contrat de sous-traitance partiel de fonctions critiques (MSA). Les sous-traitants qui exploitent une ou plusieurs fonctions critiques sont appelés « opérateur de registre back-end » ou « fournisseur de services de registre » (RSP).

Les fonctions critiques soumises au processus de modification du MSA sont les suivantes :

  • Résolution du DNS
  • Zone DNSSEC correctement signée (si les DNSSEC sont offertes par l'opérateur de registre)
  • Système de registre partagé (SRS), en général via le protocole d'avitaillement extensible (EPP)
  • Service d'annuaire de données d'enregistrement (RDDS), par exemple le Protocole d'accès aux données d'enregistrement des noms de domaine (RDAP) et le service WHOIS fourni via le port 43 et à travers un service basé sur le Web.

Par le biais du processus de modification du MSA, l'ICANN teste et évalue un RSP pour s'assurer qu'il a la capacité d'exploiter un domaine de premier niveau (TLD) de manière stable et sécurisée. L'organisation ICANN exige également que les opérateurs de registre soumettent un plan de transition pour démontrer comment une transition de services d'un RSP à un autre sera coordonnée et complétée de manière stable et sécurisée.

Ci-dessous, vous trouverez le calendrier du processus MSA. Cliquez ici pour voir le flux de travail du processus de manière plus détaillée.

Modifications au contrat de sous-traitance partiel de fonctions critiques (MSA)

Avant votre soumission : Considérations et préparatifs

Les étapes ci-dessous montrent les principaux éléments à en tenir compte et les préparatifs que les opérateurs de registre devraient effectuer avant de soumettre une demande de modification du MSA dans le portail des services de nommage (NSp).

Étape 1 : Prendre en compte les transactions connexes Le changement de votre RSP pourrait entraîner d'autres changements associés. Considérez par exemple :

  • Des modifications seront-elles apportées aux services de registre de l'annexe A du Contrat de registre (RA) à la suite de votre changement de RSP ?
  • Attribuerez-vous le TLD à une autre entité en plus de cette modification du MSA ?

Modifications aux services de registre : Si votre RSP proposé offre des services de registre différents de ceux de votre RSP actuel (par exemple, verrouillage du registre, langages/scripts IDN), vous devrez mettre à jour le texte de l'annexe A en soumettant une demande de politique d'évaluation des services de registre (RSEP) avant la soumission de la demande de modification du MSA. Nous vous encourageons à demander un appel de consultation pour discuter des étapes appropriées.

Attribution du TLD : Si vous prévoyez d'attribuer le RA de votre TLD à une autre entité en plus de votre changement de MSA, vous devrez compléter une transaction avant d'engager l'autre. Nous vous recommandons fortement de demander un appel de consultation pour discuter des options disponibles, ce qui vous aidera à mieux comprendre les implications des transactions. Consultez la page d'attributions pour plus d'informations sur l'attribution d'un TLD.

Étape 2 : Comprendre votre calendrier. Accordez-vous au moins 7 à 12 semaines pour compléter la demande de modification du MSA avec l'organisation ICANN. Dans votre calendrier, tenez compte des exigences de l'organisation ICANN pour traiter la modification du MSA, y compris les tests, en fonction des besoins et des exigences de votre entreprise. Par exemple, considérez :

  • Votre contrat avec votre RSP actuel vient-il à échéance prochainement ?
  • Combien de temps faudra-t-il pour passer de votre RSP actuel au nouveau RSP ?

Étape 3 : Organiser un appel de consultation avec votre responsable des comptes pour vous assurer que vous comprenez le processus. Votre responsable des comptes peut vous fournir un aperçu général de ce que le processus implique, vous informer de la documentation et des tests requis et vous aider à comprendre ce qui est nécessaire pour engager une demande de modification du MSA. Cela rendra le processus plus efficace une fois que vous serez prêt à soumettre votre demande.

Étape 4 : Examiner et préparer la documentation requise. Planifiez à l'avance en examinant les ressources fournies et en préparant la documentation que vous devrez inclure dans votre soumission, en prenant note des éléments suivants :

Ressources

Aperçu des exigences (par type de modification du MSA)

Exigence RSP connu RSP inconnu*

Soumission informelle

✔

✔

Évaluation technique

(Coût d'évaluation estimé de 14 300 USD)

✔

Approbation du plan de transition

✔

✔

Tests du système de registre

✔

✔

Exercice de simulation

✔

Soumission formelle/examen de l'ICANN

✔

✔

Détermination de l'ICANN

✔

✔

Transition du RSP

✔

✔

*Ne supporte pas actuellement les nouveaux gTLD

A note about our terms of service:

We have updated our electronic terms of service to provide greater transparency and align with laws applicable to us. Learn more.

This site uses cookies to deliver an efficient user experience and to help us see how the site is used. Learn more.OK

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."