Skip to main content
Retour

Avenant 2016 à l’Accord de coopération avec le Groupe de travail de génie Internet (IETF)

Cette page est disponible en:

État de situation de l’accord supplémentaire de 2016

1er octobre 2016 : L’accord supplémentaire 2016 avec le Groupe de travail de génie Internet (IETF) est maintenant en vigueur.  

 

Aperçu

Depuis l’an 2000, l’ICANN et l’IETF ont signé un protocole d’accord (MoU). En vertu du MoU, l’ICANN exécute un ensemble de fonctions impliquant l’attribution des paramètres de protocole utilisés dans les normes de l’IETF. Chaque année, les parties conviennent d’annexer au protocole un accord supplémentaire qui définit les niveaux de service applicables à l’exécution de la fonction des registres des paramètres de protocole. Une série d’avenants au protocole d’accord ont été conclus entre 2007 et 2014.

Dans la proposition de l’ICG, la communauté de l’IETF a exprimé sa satisfaction avec les arrangements actuels avec l’ICANN et a proposé de maintenir le MoU existant. En particulier, la communauté de l’IETF a proposé que les mises à jour des registres de paramètres de protocole de l’IANA continuent de fonctionner au quotidien de la même manière qu’au cours de la dernière décennie, voire plus, et que les fonctions IANA relatives aux paramètres de protocole continuent d’être fournies s’appuyant sur le système de contrats, politiques et mécanismes de contrôle en vigueur entre l’IETF, l’ICANN et le Conseil d’architecture de l’Internet (IAB).

Dans la proposition de l’ICG, la communauté de l’IETF a demandé la conclusion d’un accord supplémentaire entre l’ICANN et la communauté de l’IETF. Plus précisément, les dirigeants de l’IETF ont demandé que le nouvel accord supplémentaire comprenne :

>> la reconnaissance de l’ICANN que les paramètres de protocole sont du domaine public.

>> l’engagement de l’ICANN de réaliser une transition en douceur aux opérateurs ultérieurs, le cas échéant.

Pour mettre en œuvre cette tâche, l’ICANN et les dirigeants de l’IETF se sont engagés dans des négociations pour un accord supplémentaire de 2016. En plus d’inclure la convention de service (SLA) applicable à la fonction des registres des paramètres de protocole, l’accord supplémentaire de 2016 énonce explicitement que : « L’ICANN ne prétend aucun droit sur le contenu des registres des paramètres de protocole car ces derniers sont du domaine public ». Il contient également une disposition disant que l’ICANN fera les meilleurs efforts raisonnables et coopérera afin d’assurer un transfert ordonné et efficace à son successeur, le cas échéant, sans que cela n’implique aucun coût pour l’IETF.

Le 27 mai 2016, le Conseil de l’ICANN a publié une résolution approuvant pour conclusion l’accord supplémentaire de 2016 au MoU signé avec de l’IETF. Le 24 juin 2016, l’ICANN et les représentants de l’IETF ont conclu l’accord supplémentaire de 2016

 

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