Skip to main content
Resources

Procédure d'amendement au contrat entre opérateurs de registre et bureaux d'enregistrement (RRA)

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.

Mise à jour 2 juillet 2018

Pour les amendements des contrats entre opérateurs de registre et bureaux d'enregistrement visant à inclure la spécification temporaire relative aux données d'enregistrement des gTLD approuvée, veuillez consulter cettepage.

Page d'accueil de l'amendement du RRA

Propositions publiées et notes de présentation

Procédure de l'ICANN pour la prise en compte d'amendements proposés au contrat entre opérateurs de registre et bureaux d'enregistrement

L'ICANN a mis au point le processus suivant visant à prendre en considération les amendements proposés aux contrats de registre-bureaux d'enregistrement (RRA) des gTLD où l'opérateur de registre doit obtenir l'approbation de ces amendements de la part de l'ICANN. Ce processus est conçu pour garantir les contributions du bureau d'enregistrement (et les contributions du public, le cas échéant) avant que l'ICANN approuve les changements dans un RRA.

Procédure d'analyse des amendements proposés au RRA :

  1. Le registre demandant la modification de son RRA doit remettre à l'ICANN une copie du RRA proposé en surlignant toutes les modifications et accompagnée d'une note de présentation. La note de présentation du registre devrait décrire l'objectif des modifications proposées. Même s'il n'est pas obligatoire, un entretien consultatif avec l'ICANN avant de soumettre les modifications proposées au RRA, est recommandé.
  2. L'ICANN transmettra la version modifiée du RRA proposée et la note de présentation au groupe des représentants des bureaux d'enregistrement pour son analyse alors que l'ICANN s'engage à une révision interne des changements proposés. La durée de la période de révision des bureaux d'enregistrement peut varier selon la complexité des modifications proposées ou d'autres circonstances, mais normalement elle ne devra pas dépasser les 21 jours. L'ICANN publiera usuellement la proposition et la note de présentation sur son site Internet.
  3. À l'issue de la période de révision du bureau d'enregistrement, au cas où il y aurait des inquiétudes, l'ICANN consultera le groupe des représentants des bureaux d'enregistrement pour tenter de résoudre ces préoccupations.
  4. Si les consultations entraînent des modifications à la proposition, l'ICANN présentera la version révisée du document au groupe des représentants des bureaux d'enregistrement et ouvrira une période de révision supplémentaire qui normalement ne doit pas dépasser les quinze (15) jours. À l'issue d'une deuxième période de révision, l'ICANN tentera de résoudre les éventuels problèmes restants par le biais de consultations avec les bureaux d'enregistrement et le registre.
  5. Suite aux processus de révision et de consultation ci-dessus, l'ICANN va approuver ou rejeter les modifications proposées. Certains changements peuvent exiger l'approbation du Conseil d'administration de l'ICANN par exemple, au cas où il pourrait y avoir un effet substantiel sur des tiers ou sur la sécurité et la stabilité du DNS.

Organigramme du processus d'approbation de l'amendement du RRA

RRA Amendment Approval Process Flowchart
Untitled Document

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."