Skip to main content
Resources

Politique d’évaluation des services 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.

Page Web du processus RSEP

(Publiée le 25 juillet 2006, date d'entrée en vigueur, 15 août 2006)

1. Définitions

1.1 Les services de registre sont définis comme suit :

  1. les services qui sont à la fois : (i) les opérations de registre essentielles pour les tâches suivantes : la réception de données provenant des bureaux d'enregistrement concernant l'enregistrement de noms de domaine et les serveurs de noms ; la fourniture aux bureaux d'enregistrement du statut des informations liées aux serveurs de zone pour les TLD ; la diffusion des fichiers de zone TLD ; la gestion des serveurs de zone de registre et la diffusion des informations de contact et d'autres informations liées aux enregistrements de serveurs de noms de domaines dans le TLD comme établi dans le contrat de registre ; et (ii) fournies par l'opérateur de registre à partir de la date d'entrée en vigueur du contrat de registre, selon le cas ;
  2. d'autres produits ou services que doit fournir l'opérateur de registre du fait de l'établissement d'une politique de consensus (tel que défini ci-dessus ;
  3. tout autre produit ou service que seul un opérateur de registre est habilité à fournir, du fait de son statut d'opérateur de registre ; et
  4. les changements matériels à n'importe quel service de registre dans le cadre de (A), (B) ou (C) ci-dessus. (La définition provient du contrat de .NET, tel que spécifié par le Conseil d'administration de l'ICANN le 8 novembre 2005,http://www.icann.org/minutes/resolutions-08nov05.htm).

1.2 Sécurité - Un impact du service de registre proposé sur la sécurité signifie (A) la divulgation, l'altération, l'insertion ou la destruction non autorisées des données du registre, ou (B) l'accès non autorisé à des informations ou à des ressources ou leur divulgation non autorisée sur Internet par des systèmes fonctionnant conformément à toutes les normes applicables. (La définition provient de la recommandation de la GNSO disponible à l'adresse :   http://gnso.icann.org/issues/registry-services/final-rpt-registry-approval-10july05.htm#5).

1.3 Stabilité - Un impact sur la stabilité signifie que le service de registre proposé (A) n'est pas conforme aux normes correspondantes applicables faisant autorité et publiées par une entité officielle de normalisation reconnue et bien établie, telles que les documents RFC sur les meilleures pratiques actuelles ou sur le processus de standardisation de l'Internet parrainés par l'IETF, ou (B) crée une condition qui influence défavorablement le débit, le temps de réponse, la régularité ou la cohérence des réponses aux serveurs Internet ou aux étapes initiale ou finale du processus (end systems), fonctionnant selon les normes correspondantes applicables faisant autorité et publiées par une entité officielle de normalisation reconnue et bien établie, telles que les documents RFC sur les meilleures pratiques actuelles ou sur le processus de standardisation de l'Internet, et dépendant des services d'approvisionnement ou d'informations de délégation de l'opérateur de registre. (La définition provient de la recommandation de la GNSO, disponible à l'adresse :http://gnso.icann.org/issues/registry-services/final-rpt-registry-approval-10july05.htm#5).

1.4 Panel d'évaluation technique des services de registre - Le Panel d'évaluation technique des services de registre se compose d'un total de 20 experts en matière de conception, gestion et mise en œuvre des systèmes complexes et des normes-protocoles utilisés dans l'infrastructure de l'Internet et du DNS (le « Panel d'évaluation technique des services de registre »). Les membres du Panel d'évaluation technique des services de registre seront sélectionnés par leur président. Le président du Panel d'évaluation technique des services de registre sera une personne acceptée aussi bien par l'ICANN que par l'unité constitutive des opérateurs de registre des organisations de soutien qui sera responsable des politiques de registre des domaines génériques de premier niveau. Tous les membres du Panel d'évaluation technique des services de registre et le président concluront un accord établissant que le panel sera neutre et agira conformément aux définitions spécifiées en matière de sécurité et de stabilité. Pour chaque question soumise au Panel d'évaluation technique des services de registre, le président doit choisir un maximum de cinq membres du Panel d'évaluation technique des services de registre afin d'évaluer la question reçue ; aucun de ces membres n'aura des conflits d'intérêts concurrentiels, financiers ou juridiques, et tiendra dûment compte des questions techniques particulières soulevées par le renvoi. (La définition provient de la recommandation de la GNSO disponible à l'adresse :   http://gnso.icann.org/issues/registry-services/final-rpt-registry-approval-10july05.htm#5).

2. Processus d'examen des services de registre proposés

2.1 L'opérateur de registre ou l'organisation parraine examinent le nouveau service de registre

Un opérateur de registre ou organisation parraine pourront, à tout moment, décider de changer l'architecture ou l'exploitation d'un service de registre TLD existant ou d'introduire un nouveau service de registre TLD (voir l'introduction des notes de mise en œuvre de la RSEP).

2.2 Déterminer si les modifications exigent une révision de l'ICANN

Un opérateur de registre gTLD ou une organisation parraine en consultation avec l'ICANN comme décrit à l'article 2.4 déterminera si une modification à un service exigerait l'approbation fondée sur le contrat entre l'ICANN et l'opérateur de registre (voir l'introduction des notes de mise en œuvre de la RSEP).

2.3 Donner les informations sur le changement proposé à l'ICANN

La Politique encourage les promoteurs d'un nouveau service de registre à collaborer avec l'ICANN avant la présentation d'une demande de nouveaux services de registre. L'objectif de la Politique d'évaluation des services de registre et du processus d'approbation est de créer avec l'ICANN un environnement qui encourage les opérateurs de registre gTLD à discuter tout changement pouvant affecter des tiers avant que ces changements soient effectués.

L'opérateur de registre gTLD ou l'organisation parraine doivent fournir à l'ICANN suffisamment d'information sur un changement pour lui permettre d'évaluer si ce changement doit faire l'objet d'un processus d'approbation. L'information devrait inclure une description technique du changement tel qu'il serait perçu par les utilisateurs externes ainsi qu'une évaluation de l'impact sur les utilisateurs externes. Si l'opérateur de registre ou l'organisation parraine avaient demandé des commentaires aux parties externes et à la communauté, les détails du processus et les résultats de cette évaluation devraient être inclus. À ce stade du processus l'information devrait être considérée comme confidentielle par le personnel de l'ICANN (voir les étapes 1 et 2 des notes de mise en œuvre de la RSEP).

2.4 Période de détermination préliminaire

À la suite de la notification écrite de l'opérateur de registre à l'ICANN, cet opérateur de registre peut faire un changement au service de registre dans le cadre du paragraphe précédent :

  1. l'ICANN aura 15 jours calendaires pour rendre sa « détermination préliminaire » si un service de registre exigeait l'analyse de l'ICANN au cas où il serait raisonnablement déterminé que ce service de registre : (i) pourrait soulever des questions importantes en matière de sécurité ou à de stabilité ou (ii) pourrait soulever des questions importantes en matière de concurrence.
  2. Au moment de la notification, l'opérateur de registre doit fournir à l'ICANN suffisamment d'informations pour permettre la mise en œuvre du service de registre proposé ce qui habiliterait l'ICANN à prendre une « détermination préliminaire » éclairée. L'information fournie par l'opérateur de registre et la mention « CONFIDENTIEL » doivent être considérées comme confidentiels par l'ICANN. L'opérateur de registre ne désignera pas comme « CONFIDENTIELLE » toute information nécessaire pour décrire l'objectif du service de registre proposé et l'effet sur les utilisateurs du DNS.
  3. L'ICANN peut demander l'avis d'un expert pendant la période de détermination préliminaire (des entités ou personnes soumises à des engagements de confidentialité) sur l'implication du service de registre sur la concurrence, la sécurité ou la stabilité afin de rendre sa « détermination préliminaire ». Au cas où l'ICANN déciderait de divulguer des informations confidentielles à ces experts, elle informera à l'opérateur de registre l'identité de l'expert et les informations qu'elle est censée transmettre. Pour répondre à des questions impliquant la sécurité ou la stabilité, l'ICANN peut se servir d'un expert appartenant au panel permanent d'experts décrit au point 2.4(F) ci-dessous.
  4. Si pendant la période de 15 jours calendaires de la « détermination préliminaire » l'ICANN évaluait que le service de registre proposé n'a pas soulevé de questions relatives à la sécurité ou la stabilité (tel que défini dans les articles 1.3 et 1.4), ou à la concurrence, l'opérateur de registre sera libre de le déployer sur une telle décision.

Si la mise en œuvre du nouveau service de registre proposé exige un changement important à un contrat de registre, la détermination préliminaire sera renvoyée au Conseil d'administration pour examen (voir l'étape 5 des notes de mise en œuvre de la RSEP).

2.5 Questions relatives à la concurrence

Au cas où l'ICANN déterminerait raisonnablement pendant la période de 15 jours calendaires pour la « détermination préliminaire » que le service de registre pourrait soulever des questions importantes en matière de concurrence, l'ICANN devra renvoyer le dossier à l'autorité compétente ou aux autorités avec juridiction en la matière dans les cinq jours ouvrables suivant sa décision, ou dans les deux jours ouvrables suivant l'expiration de cette période de 15 jours, le délai plus court étant retenu, moyennant une notification à l'opérateur de registre.

Une telle communication de renvoi sera publiée sur le site Web de l'ICANN à la date d'envoi de la notification.

À la suite de ce renvoi, l'ICANN n'aura aucune autre responsabilité, et l'opérateur de registre n'aura aucune obligation supplémentaire envers l'ICANN en ce concernant les questions de concurrence liées au service de registre. Au cas où ce renvoi aurait lieu, l'opérateur de registre ne déploiera pas le service de registre jusqu'à 45 jours calendaires après le renvoi, à moins qu'il soit autorisé au préalable par l'autorité gouvernementale compétente (voir les étapes 4 à 6 des notes de mise en œuvre de la RSEP).

2.6 Questions relatives à la sécurité et la stabilité

Au cas où l'ICANN déterminerait raisonnablement pendant la période de 15 jours calendaires pour la « détermination préliminaire » que le service de registre pourrait soulever des questions importantes en matière de stabilité et de sécurité (tel que défini dans les articles 1.3 et 1.4), l'ICANN devra renvoyer la proposition au Panel d'évaluation technique des services de registre (tel que défini dans l'article 1.5) dans les cinq jours ouvrables suivant sa décision, ou dans les deux jours ouvrables suivant l'expiration de cette période de 15 jours, le délai le plus court étant retenu, et simultanément inviter à une période de consultation publique sur la proposition.

Le Panel d'évaluation technique des services de registre aura 45 jours à partir du renvoi pour préparer un rapport écrit sur l'effet du service de registre proposé sur la sécurité ou la stabilité (tel que défini dans les articles 1.2 et 1.3). Le rapport (accompagné d'un résumé des commentaires publics) sera transmis au Conseil d'administration de l'ICANN. Le rapport inclura les opinions du Panel d'évaluation technique des services de registre y compris, mais sans s'y limiter, un état détaillé de l'analyse, des motifs et des informations sur lesquelles le panel s'est basé pour arriver à ses conclusions ainsi que la réponse à des questions spécifiques ayant été incluses dans le renvoi du personnel de l'ICANN. Sur le renvoi de l'ICANN au Panel d'évaluation technique des services de registre, l'opérateur de registre peut présenter des informations ou des analyses supplémentaires au sujet de l'effet probable du service de registre sur la sécurité ou la stabilité.

Lors de son évaluation du service de registre proposé, le Panel d'évaluation technique des services de registre inclura un rapport sur la probabilité et l'importance relative des effets du service de registre proposé sur la sécurité ou la stabilité, notamment si le service de registre proposé crée un risque raisonnable d'avoir un effet négatif significatif sur la sécurité ou la stabilité (voir les étapes 4 à 6 des des notes de mise en œuvre de la RSEP).

2.7 Décision du Conseil d'administration de l'ICANN

Après avoir reçu le rapport du Panel d'évaluation technique des services de registre qui sera publié (avec les suppressions de confidentialité appropriées après consultation avec l'opérateur de registre) et soumis à la consultation publique, le Conseil d'administration de l'ICANN aura 30 jours calendaires pour prendre une décision. Au cas où le Conseil d'administration de l'ICANN déterminerait raisonnablement que le service de registre proposé crée un risque raisonnable d'un effet défavorable significatif sur la stabilité ou la sécurité, l'opérateur de registre n'offrira pas le service de registre proposé.

Une version non expurgée du rapport du Panel d'évaluation technique des services de registre sera fournie par l'opérateur dès la publication du rapport. L'opérateur de registre peut répondre au rapport du Panel d'évaluation technique des services de registre ou autrement présenter au Conseil d'administration de l'ICANN des informations supplémentaires ou des analyses au sujet de l'effet probable du service de registre sur la sécurité ou la stabilité (voir l'étape 5 des notes de mise en œuvre de la RSEP).

3. Réexamen

Les opérateurs de registre gTLD ou les organisations parraines affectées par une décision de l'ICANN sur un nouveau service de registre peuvent utiliser le processus de réexamen inclus dans les statuts constitutifs de l'ICANN.

La source d'informations sur le processus de réexamen faisant autorité se trouve dans les statuts constitutifs l'ICANN (voir chapitre IV : article 2 http://www.icann.org/general/bylaws.htm#IV). Le réexamen s'applique aux actions du personnel qui contredisent une politique de l'ICANN, ou à une décision du Conseil d'administration de l'ICANN ayant été prise sans tenir compte de l'information fournie. Pour plus d'information sur le processus de réexamen veuillez consulter le site suivant :http://www.icann.org/committees/reconsideration.

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