Skip to main content

Le point sur les progrès : assurer la sécurité, la stabilité et la résilience de la maintenance de la zone racine

Le 10 mars 2016, un plan visant à transférer la supervision de l'IANA du gouvernement américain à la communauté multipartite mondiale a été soumis à l'examen de la NTIA. Les efforts extraordinaires que déployait la communauté multipartite pour élaborer ces propositions nous ont empreints à la fois d'admiration et d'humilité.

Alors que la communauté travaillait d'arrache-pied à finaliser les propositions figurant dans le plan, mon équipe et moi-même préparions diligemment la phase de mise en œuvre de la transition de la supervision de l'IANA si anticipée. Au nombre des tâches à accomplir, l'ICANN et Verisign devraient conclure l'accord régissant le responsable de la maintenance de la zone racine (« RZMA »). D'autre part, il faudra prolonger le contrat du registre .com afin que sa durée corresponde à celle du RZMA ; l'ICANN et Verisign sont convaincus que cette démarche renforcera la sécurité, la stabilité et la résilience de l'infrastructure de la zone racine. Je profite de l'occasion qui m'est donnée aujourd'hui pour vous fournir des renseignements d'ordre général au sujet du RZMA et vous faire le point sur nos progrès.

Comme l'indique la proposition du groupe de coordination pour la transition du rôle de supervision des fonctions IANA (« ICG »), une transition complète et finalisée nécessite une révision de la relation entre l'opérateur actuel des fonctions IANA (« ICANN »), le responsable actuel de la maintenance de la zone racine (« Verisign ») et le gestionnaire actuel de la zone racine (« NTIA »). Le rôle de la NTIA sera expressément éliminé, et à ce moment-là, l'ICANN et Verisign devraient avoir conclu un accord écrit établissant le rôle de chacune des parties.

Le 4 mars 2015, la NTIA a officiellement demandé à l'ICANN et à VeriSign de collaborer pour élaborer une proposition sur la meilleure façon de procéder quant à la transition du rôle administratif de la NTIA associé à la gestion de la zone racine. Il est crucial d'accomplir cette transition de manière à maintenir la sécurité, la stabilité et la résilience du processus de gestion de la zone racine. L'ICANN et VeriSign ont presque finalisé les conditions générales permettant de réaliser cet objectif essentiel, tout en définissant clairement les rôles et responsabilités respectifs de chacune des parties.

De manière générale, nous avons déjà validé le fait que VeriSign sera rémunéré pour son exécution des fonctions de responsable et qu'il sera tenu de respecter certaines obligations relatives à des Conventions de service (« SLA ») que les parties pourraient ajuster pour donner suite à des recommandations du Comité permanent de clients, conformément au processus de contrôle de modifications prévu aux termes de l'accord. Ce processus de modification est en cours de définition pour permettre à la communauté d'introduire elle aussi, à travers l'ICANN, des améliorations au système de gestion de la zone racine. Bien que la durée du RZMA est censée promouvoir la sécurité, la stabilité et la résilience des opérations de maintenance de la zone racine en maintenant le rôle de Verisign, l'accord fournit à la communauté, dans le cadre d'un processus communautaire et consensuel, la capacité d'imposer à l'ICANN le transfert de ces fonctions à un prestataire de service différent après un nombre préétabli d'années.

Certaines questions demeurent en suspens et doivent être résolues avant de finaliser la version préliminaire de l'accord. Il serait difficile de les énumérer parce que leur statut change fréquemment étant donné que les discussions se poursuivent. Cela dit, les progrès vont bon train, et nous pensons disposer d'ici peu d'une version préliminaire complète.

Une fois que l'ICANN et Verisign auraient achevé une version préliminaire de l'accord, celle-ci sera publiée pour une période de commentaire public de 30 jours. Cette démarche est conforme à la politique de transparence de l'ICANN et va dans le sens de la proposition de l'ICG qui recommande la mise à disposition de la version préliminaire pour examen public avant son exécution.

Il reste du travail sur la planche, mais nous progressons de manière satisfaisante. Je vous encourage à explorer les pages web ci-dessous pour obtenir de plus amples informations et pour rester au courant des derniers développements.

Comments

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