Skip to main content
Resources

Services pour les opérateurs de registre

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.

Le contrat de registre définit les droits, obligations et dispositions des opérateurs de registre quant à la gestion de leurs domaines de premier niveau (TLD). Si l'opérateur de registre doit informer ou demander le consentement ou l'approbation de l'organisation ICANN, des services ont été développés pour faciliter ces processus.

Vous trouverez ci-dessous des liens vers les services couramment demandés pour les opérateurs de registre :

  • Cession d'un contrat de registre ou changement de contrôle de l'opérateur de registre - Pour les opérateurs de registre soumis au contrat de registre de base des nouveaux gTLD (« Contrat de registre »), toute proposition de cession du contrat de registre ou de changement de contrôle direct ou indirect de l'opérateur de registre doit suivre le processus énoncé à l'article 7.5 du contrat de registre.
  • Demandes de changement d'un gTLD communautaire - La procédure de demande de changement d'un gTLD communautaire permet à l'opérateur de registre des gTLD communautaires de demander des modifications à la Spécification 12 sans supprimer les politiques d'enregistrement communautaires, é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.
  • Services de l'instrument assurant la continuité des opérations (COI) - Le COI garantit que des ressources financières suffisantes sont en place pour pour soutenir le fonctionnement continu des fonctions de registre critiques liées aux TLD. En vertu de la Spécification 8 du contrat de registre de base, les opérateurs de registre doivent avoir un COI qui prévoie des ressources financières suffisantes pour couvrir les cinq fonctions de registre essentielles de l'article 6 de la Spécification 10 pour une période donnée conformément à l'article 1 de la Spécification 8.
  • Tables d'IDN : Mise à jour et publication - Elles fournissent un mécanisme permettant de mettre à jour les tables d'IDN déjà approuvées et de refléter ces tables dans le référentiel de l'IANA, conformément à l'article 4 de la Spécification 6 du contrat de registre.
  • Changement du contrat de sous-traitance partiel de fonctions critiques (MSA) - Un changement du MSA fait référence à un changement de n'importe quel opérateur de registre back-end (appelé également fournisseur de services back-end ou fournisseur de services de registre), défini par le processus de transition entre opérateurs de registre comme une organisation contractée par un opérateur de registre pour gérer une ou plusieurs fonctions critiques d'un registre gTLD et qui inclut des fournisseurs de services tels que les fournisseurs du système des noms de domaine (DNS).
  • Renouvellement du RA pour les nouveaux gTLD - Les nouveaux gTLD de la série 2012 du programme des nouveaux gTLD sont régis par le contrat de registre (RA) de base, en vigueur pour une durée initiale de dix (10) ans. Ce contrat devrait être reconduit, pour une durée équivalente, à moins que l'une des exceptions énoncées à l'article 4.2 du RA de base ne s'applique.
  • Service de résiliation de contrat de registre - En vertu du nouveau contrat de registre gTLD, chaque partie peut résilier le contrat conformément à certaines conditions du contrat de registre, incluant, mais sans s'y limiter :

    • Article 4.3 et ses sous-articles – Résiliation décidée par l'organisation ICANN
    • Article 4.4 et ses sous-articles - Résiliation décidée par l'opérateur de registre
  • Changement de nom de l'opérateur de registre — Si un opérateur de registre modifie le nom de son organisation, et que ce n'est pas le résultat d'un changement de contrôle, l'opérateur de registre devra informer l'organisation ICANN de la modification par le biais du Service de changement de nom de l'opérateur de registre.
  • Processus d'évaluation des services de registre (RSEP) - Le RSEP est le processus d'évaluation de l'organisation ICANN destiné à évaluer les services de registre gTLD ou des modifications contractuelles proposées, pour des questions de sécurité, de stabilité ou de concurrence.
  • Processus de transition entre opérateurs de registre (RTP) - Une modification dans la partie contractante d'un contrat de registre gTLD avec l'organisation ICANN. Exemples de circonstances menant à une transition du registre : changement de nom de l'organisation gérant le gTLD, vente ou transfert du registre, cas où le registre actuel ne respecte pas le contrat de registre, etc.
  • Suppression des restrictions en matière de propriété hybride - Dans le but de lever les restrictions en matière de propriété hybride, les opérateurs de registre gTLD existants peuvent demander un amendement au contrat de registre existant pour supprimer les restrictions ou demander la transition vers une nouvelle forme de contrat de registre pour les nouveaux gTLD.
  • Page d'accueil des noms réservés

    • Noms réservés : Étiquettes à deux caractères ASCII - L'article 2 de la Spécification 5 du contrat de registre de base des nouveaux gTLD exige que des étiquettes à deux caractères ASCII soient réservées au second niveau. Pendant deux ans, les membres de la communauté Internet, l'organisation ICANN, le Comité consultatif gouvernemental (GAC) et les gouvernements, les registres gTLD et d'autres, ont travaillé ensemble pour établir un cadre permettant l'utilisation de ces étiquettes. Ces deux ans d'efforts ont finalement entraîné de multiples autorisations, de la publication à la réservation, des étiquettes à deux caractères.
    • Noms réservés : Noms de pays et territoires - L'article 4 de la Spécification 5 du contrat de registre des nouveaux gTLD exige que les opérateurs de registre réservent certains noms de pays et de territoires au second niveau. Le contrat de registre fournit également deux méthodes par lesquelles les opérateurs de registre peuvent utiliser des noms de pays et de territoires au second niveau, décrites en détail dans les directives de l'organisation ICANN pour l'utilisation de noms de pays et de territoires.
  • Mécanismes de protection des droits (RPM) et Procédures de règlement de litiges (DRP) - Les RMP sont des sauvegardes qui aident à protéger les droits de propriété intellectuelle des propriétaires de marques déposées. Les RPM incluent : le Centre d'échange d'information sur les marques, la politique de règlement uniforme de litiges relatifs aux noms de domaine (UDRP), le système uniforme de suspension rapide (URS) et les procédures de règlement de litiges après délégation relatifs à des marques déposées. Les DRP sont des processus par lesquels les litiges liés aux noms de domaine sont réglés (sans litiges) grâce à des procédures de règlement de litiges élaborées par la communauté de l'ICANN.
  • Procédure de modification du contrat entre opérateurs de registre et bureaux d'enregistrement (RAA) - La procédure de modification du RAA est un processus qui prend en considération les amendements proposés aux RAA des gTLD par lesquels l'opérateur de registre doit obtenir l'approbation de l'ICANN pour de telles modifications. Ce processus est conçu pour permettre à l'organisation ICANN d'obtenir des retours d'information des bureaux d'enregistrement (et du public, le cas échéant) avant toute approbation des modifications d'un RAA.
  • Processus de demande de dérogation pour incident de sécurité (SRW) pour les opérateurs de registre - Les SRW ont été développées afin de permettre aux opérateurs de registres TLD ayant signalé à l'organisation ICANN tout incident de sécurité présent ou imminent (ci-après « incident ») dans leurs TLD, et/ou le DNS de demander une clause dérogatoire pour toute action qu'ils pourraient prendre ou avoir prise dans le but d'atténuer ou d'éliminer l'incident.
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."