Skip to main content
Resources

Réconciliation entre la politique de consensus et les clauses contractuelles des contrats des gTLD contenant le processus d'évaluation

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.

Disposition dans la politique de consensus

Disposition dans les contrats des gTLD

Réconciliation

Définition de service de registre :

La politique de consensus ne définit pas le « service de registre ».

Le « service de registre » est défini dans ces contrats.

Les deux documents ne sont pas incompatibles. Le Conseil de l'ICANN a demandé que la définition de service de registre incluse dans le contrat de .NET soit utilisée dans la mise en œuvre de la politique parce que c'est la seule définition disponible qui n'entre pas en conflit avec la politique de consensus.

Information suffisante et confidentialité :

L'opérateur des services de registre gTLD ou l'organisation de parrainage doivent fournir à l'ICANN suffisamment d'information sur un changement pour permettre que l'ICANN évalue 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 de parrainage 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.

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écision préliminaire » éclairée. L'information fournie par l'opérateur de registre et la mention « CONFIDENTIEL » doivent être considérés 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.

La recommandation de la GNSO et les contrats des gTLD ne sont pas incompatibles. Le fait que la mise en œuvre de la politique et les contrats des gTLD contiennent les mêmes dispositions en matière de confidentialité donne une plus grande transparence.

Avis de l'expert :

« 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écision préliminaire". Dans la mesure où l'ICANN déciderait de divulguer des informations confidentielles à ces experts, elle informera l'opérateur de registre (ou l'organisation de parrainage) l'identité de l'expert et les informations qu'elle est censé 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 à l'étape 6 ci-dessous ».

« L'ICANN peut demander l'avis d'un expert pendant la période de décision 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écision préliminaire". Dans la mesure 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é transmettre.

L'ICANN peut consulter n'importe quel membre de la communauté technique au cours de la période de décision préliminaire. Ceci permettra davantage de flexibilité et d'analyse. Les deux documents ne sont pas incompatibles.

Réexamen :

« La GNSO recommande que les parties affectées par une décision de l'ICANN utilisent les processus de réexamen existants dans les statuts constitutifs de l'ICANN ».

Les contrats de gTLD ne disent rien sur le réexamen.

Le processus de réexamen décrit dans le rapport final de la GNSO qui se trouve dans les statuts constitutifs de l'ICANN a été incorporé dans l'article 3 de la politique d'évaluation des services de registre (RSEP).

Détermination basée sur un contrat :

« Un opérateur de registre gTLD ou une organisation de parrainage détermineront si une modification à un service exigerait l'approbation fondée sur le contrat entre l'ICANN et l'opérateur de registre ».

Les contrats de gTLD ne disent rien sur cette disposition.

Si un opérateur de registre gTLD ou une organisation de parrainage d'un registre souhaitaient offrir un nouveau service de registre, l'opérateur de registre gTLD ou l'organisation de parrainage devront consulter l'ICANN pour déterminer si la modification proposée exigerait l'approbation de l'ICANN fondée sur le contrat entre l'ICANN et l'opérateur de registre. Ce n'est pas incompatible avec le rapport final de la GNSO, qui stipule que « l'ICANN évaluera si l'autorisation est requise en vertu du contrat entre l'ICANN et l'opérateur de registre ou l'organisation de parrainage ».

Concurrence :

L'étape 5 du rapport final de la GNSO établit que « l'ICANN devrait examiner si le changement diminuerait [sic] la concurrence entre les bureaux d'enregistrement fournissant des services aux titulaires de noms de domaine ou diminuerait [sic] la concurrence loyale entre les titulaires de noms de domaine pour des noms de domaine spécifiques ».

Les contrats des gTLD statuent qu'il faudrait prendre une détermination raisonnable sur la question de savoir si un nouveau service de registre soulève des questions importantes en matière de concurrence.

Les deux documents ne sont pas incompatibles et les termes des contrats des gTLD ont été adoptés.

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