Skip to main content
Resources

Politique provisoire relative aux données d'enregistrement des gTLD

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.

Cette politique provisoire relative aux données d'enregistrement des gTLD (politique provisoire) est une politique de consensus qui met en œuvre les recommandations de politiques de  l'Organisation de soutien aux extensions génériques (GNSO) adoptées par le Conseil d'administration de l'ICANN le 15 mai 2019, concernant la protection des données applicables aux domaines génériques de premier niveau (gTLD). Cette politique provisoire met en œuvre une des recommandations (sur un total de 29) de l'équipe responsable du processus accéléré d'élaboration de politiques (EPDP), comme cela est décrit dans la rubrique « Contexte » ci-dessous. Une future politique relative aux données d'enregistrement des gTLD (politique de données d'enregistrement) mettra en œuvre les recommandations approuvées par le Conseil d'administration, et, après la fin de l'étape 2, remplacera la politique provisoire.

Cette politique provisoire est entrée en vigueur le 20 mai 2019. Cette politique provisoire, en vigueur à compter du 20 mai 2019, exige que les opérateurs de registre gTLD et que les bureaux d'enregistrement accrédités par l'ICANN (collectivement, les « parties contractantes ») continuent à mettre en place, provisoirement, des mesures qui soient compatibles avec la spécification temporaire relative aux données d'enregistrement des gTLD en attendant la mise en œuvre de la politique de données d'enregistrement.

  1. Première étape
  2. À compter du 20 mai 2019, les parties contractantes doivent continuer à mettre en œuvre des mesures compatibles avec la spécification temporaire relative aux données d'enregistrement des gTLD(spécification temporaire), adoptée par le Conseil d'administration de l'ICANN le 17 mai 2018.

  3. Deuxième étape
  4. Une fois que l'organisation ICANN (a) aura achevé le document de politique de données d'enregistrement, en consultation avec l'équipe de révision de la mise en œuvre, (b) aura publié le document de politique de données d'enregistrement, et (c) aura informé officiellement les parties contractantes sur la publication de la politique de données d'enregistrement, les parties contractantes devront, soit continuer à mettre en place des mesures cohérentes avec la  spécification temporaire, soit mettre en œuvre des mesures cohérentes avec le document de politique de données d'enregistrement.

    Au cours de cette étape, les parties contractantes peuvent appliquer soit la politique temporaire soit la politique de données d'enregistrement dans sa totalité, ou bien utiliser des éléments des deux, alors qu'elles se préparent pour la date d'entrée en vigueur du document de politique de données d'enregistrement.

  5. Troisième étape
  6. À compter de la date effective d'entrée en vigueur de la politique de données d'enregistrement (dont la date recommandée par l'équipe responsable de l'EPDP est le 20 février 2020), les parties contractantes doivent se conformer à la politique de données d'enregistrement.

Notes sur la mise en œuvre

Le département en charge de la conformité contractuelle de l'ICANN fera respecter les obligations des parties contractantes pour se conformer à cette politique provisoire comme suit :

Étape 1 : le département en charge de la conformité contractuelle de l'ICANN fera respecter les obligations des parties contractantes de continuer à mettre en œuvre des mesures qui soient compatibles avec la spécification temporaire.

Étape 2 : le département en charge de la conformité contractuelle de l'ICANN fera respecter les obligations des parties contractantes de (a) continuer à mettre en place des mesures cohérentes avec la spécification temporaire (b) mettre en œuvre des mesures cohérentes avec le document de politique de données d'enregistrement. En réponse à une enquête de conformité, une partie contractante serait tenue de démontrer comment ses activités satisfont à cette obligation. Le rythme de la transition de la spécification temporaire à la politique de données d'enregistrement est à la discrétion de la partie contractante.

Étape 3 : le département en charge de la conformité contractuelle de l'ICANN fera respecter les obligations des parties contractantes pour se conformer à la politique de données d'enregistrement. À ce stade, la politique de données d'enregistrement deviendra opérationnelle et la politique provisoire ne sera plus en vigueur.

Les parties contractantes doivent continuer à se conformer aux parties inchangées du contrat de registre et du contrat d'accréditation de bureau d'enregistrement au cours des trois étapes.

Contexte

Le 17 mai 2018, le Conseil d'administration de l'ICANN a adopté la spécification temporaire pour les données d'enregistrement des gTLD. La spécification temporaire a modifié les exigences existantes dans les contrats de registre et de bureau d'enregistrement pour se conformer au Règlement général sur la protection des données (RGPD) de l'Union Européenne. Conformément aux statuts constitutifs de l'ICANN, aux politiques de consensus et aux spécifications de politique temporaire du contrat de registre (RA) et du contrat d'accréditation de bureau d'enregistrement (RAA), la spécification temporaire expirera le 20 mai 2019.

Le 19 juin 2018, le conseil de la GNSO a initié un EPDP et a approuvé la charte de l'équipe responsable de l'EPDP sur la spécification temporaire relative aux données d'enregistrement des gTLD. Tous les groupes de parties prenantes de la GNSO, les unités constitutives et les comités consultatifs de l'ICANN ayant signalé leur intérêt à participer, sont représentés à l'équipe responsable de l'EPDP, bien que la charte limite le nombre de membres par groupe.

La charte établit que l'équipe EPDP déterminera si la spécification temporaire relative aux données d'enregistrement des gTLD doit rester telle quelle ou subir des modifications pour devenir une politique de consensus. En outre, la charte prescrit que le résultat doit se conformer au RGPD et prendre en compte d'autres lois relatives à la protection des données et de la vie privée. La charte de l'équipe responsable de l'EPDP demande également de discuter un modèle d'accès normalisé aux données d'enregistrement non publiques, à la suite de l'achèvement des recommandations de politique et du débat sur des questions préliminaires.

Le 21 novembre 2018, l'équipe responsable de l'EPDP a publié son rapport initial pour consultation publique. Le rapport initial contenait les recommandations préliminaires de l'équipe responsable de l'EPDP ainsi qu'une série de questions pour commentaire public. L'équipe responsable de l'EPDP a analysé et a fait des recommandations sur : (I) la validité, la légitimité et la base juridique des objectifs décrits dans la spécification temporaire, (ii) la légitimité, la nécessité et la portée de (x) la collecte de données d'enregistrement de la part du bureau d'enregistrement et (y) le transfert de données des bureaux d'enregistrement aux opérateurs de registre comme cela est décrit dans la spécification temporaire, et (iii) la publication des données d'enregistrement par les bureaux d'enregistrement et les opérateurs de registre tel que décrit dans la spécification temporaire.

Le rapport initial contenait également des recommandations préliminaires et des questions que le public est invité à considérer : (I) le transfert de données des bureaux d'enregistrement et des opérateurs de registre aux agents d'entiercement de données et à l'ICANN, (ii) le transfert de données des opérateurs de registre aux opérateurs de registre de secours (EBERO), (iii) la définition et le cadre d'un accès raisonnable aux données d'enregistrement, (iv) les rôles et responsabilités en vertu du RGPD, c.-à-d., les parties responsables, (v) les mises à jour applicables aux politiques de consensus de l'ICANN, et (vi) le travail futur de la GNSO afin d'assurer que les politiques de consensus soient réévaluées pour se conformer à la loi applicable.

L'équipe responsable de l'EPDP a documenté chacune des étapes de traitement des données ainsi que l'objectif et la base juridique de chacune d'elles. Ce travail fondamental a été nécessaire pour élaborer les solutions conformes aux normes établies dans le RGPD. Il est disponible dans l'annexe du rapport.

Après la publication du rapport initial, l'équipe responsable de l'EPDP : (i) a demandé des conseils sur les questions juridiques, (ii) a examiné attentivement les commentaires reçus du public en réponse à la publication du rapport initial, (iii) a examiné les travaux en cours avec les groupes communautaires représentés par les membres de l'équipe, et (iv) a délibéré pour élaborer son rapport final. Les appels au consensus sur les recommandations contenues dans ce rapport final, tel que cela est requis par les directives de la GNSO pour les groupes de travail, ont été effectués par le président de l'équipe responsable de l'EPDP, comme décrit ici : https://mm.icann.org/pipermail/gnso-epdp-team/2019-February/001436.html.

Le conseil de la GNSO a adopté le rapport final le 4 mars 2019. L'organisation ICANN a commencé une période de commentaires publics sur le rapport final le 4 mars 2019. Le rapport d'analyse et de synthèse a été publié le 23 avril 2019 pour consultation publique. Le Conseil d'administration a résolu d'adopter les recommandations, à quelques exceptions près, le 15 mai 2019.

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