Résumé

  • Le GAC demandait un webinaire avant ICANN86 puis un dialogue avec le Board et le Conseil de la GNSO ; le créneau prévu a finalement accueilli une séance d’information, en présence de plusieurs membres du Board comme simples observateurs.
  • La présidente du Board a ensuite indiqué que toute obligation nouvelle ou modifiée visant les registrars au titre de la RDDS Accuracy Program Specification devait passer soit par une négociation contractuelle, soit par l’élaboration d’une politique gTLD. Aucune des deux voies n’est publiquement sélectionnée.
  • Une fiche publique et versionnée de choix de voie permettrait de distinguer information, observation, priorité, négociation et élaboration normative.

Le rendez-vous a changé de nature

Le 11 mai 2026, Nicolas Caballero, président du GAC, a demandé aux présidentes du Board de l’ICANN et du Conseil de la GNSO de réunir à nouveau un format trilatéral pendant ICANN86. Le sujet était le délai entre l’enregistrement d’un nom et le moment où un registrar peut valider les coordonnées du titulaire. Le GAC souhaitait auparavant un webinaire afin d’arriver à Séville avec une base commune et de discuter d’étapes concrètes.

La séquence envisagée était donc : information avant la réunion, dialogue trilatéral à ICANN86, puis examen d’une suite. Le 26 mai, Susan Payne a répondu au nom du Conseil de la GNSO qu’un webinaire correctement préparé ne pouvait pas être organisé à temps. Elle a proposé d’utiliser le créneau du dialogue pour un briefing. Le créneau entrait aussi en conflit avec la réunion du Registrar Stakeholder Group, alors même que les registrars portent l’obligation existante. La GNSO se disait disponible pour un dialogue ultérieur.

La page officielle d’ICANN86 qualifie la séance du 9 juin de « séance d’information sur l’exactitude des données d’enregistrement ». Elle devait exposer l’origine du délai, son éventuelle exploitation à des fins d’abus, les conséquences opérationnelles d’un changement et les voies de mise en œuvre possibles. Le dialogue trilatéral est présenté comme une étape ultérieure, après le forum de Séville.

Ce changement de forme est une information de gouvernance. Un briefing transmet des connaissances. Un dialogue rapproche des positions. Ni l’un ni l’autre ne modifie un contrat.

Observer n’est pas approuver

La réponse de Tripti Sinha, datée du 25 août et publiée le 14 septembre, précise que plusieurs membres du Board ont assisté à la séance « en tant qu’observateurs ». Elle ne mentionne ni vote, ni approbation de la préférence du GAC, ni choix d’un mécanisme.

Le Board partage l’objectif général de réduction des abus du DNS et demande que plusieurs sources de données soient comparées. Cela justifie l’examen du dossier. Cela ne transforme pas la présence de ses membres en décision du Board. La participation donne accès à l’information ; elle ne confère pas automatiquement un mandat.

L’obligation actuelle n’est pas le résultat demandé

La RDDS Accuracy Program Specification intégrée au Registrar Accreditation Agreement de 2013 contient déjà une obligation. Pour certaines opérations — enregistrement, transfert ou changement de titulaire — le registrar doit valider les champs requis et vérifier le canal de contact dans un délai de 15 jours. Sans réponse affirmative du titulaire, il doit procéder à une vérification manuelle ou suspendre l’enregistrement jusqu’à vérification.

La préférence exprimée par le GAC déplace le moment de l’obligation : les coordonnées devraient être vérifiées avant que le nouveau nom puisse être accessible dans le DNS. La question de compétence dépend donc d’une classification simple mais essentielle. S’agit-il d’expliquer une obligation existante, ou d’en modifier le déclencheur, le délai ou la conséquence ?

La lettre du Board apporte une limite précise. Si le but est de créer ou modifier des obligations de registrar relatives à cette spécification, deux mécanismes seulement peuvent les produire : les négociations contractuelles et l’élaboration de politiques gTLD. Cette affirmation concerne cet objet contractuel. Elle ne couvre pas indistinctement toutes les mesures contre les abus du DNS et ne prouve pas que l’une des deux voies est ouverte.

Le rapport final n’est pas une décision de voie

Le Board renvoie au Final Issue Report on DNS Abuse, en indiquant qu’il peut faciliter de futurs travaux de politique. Le rapport traite effectivement du manque de vérification proactive ou rapide. Il relève que la fenêtre postérieure à l’enregistrement peut être exploitée et consigne plusieurs options avancées dans le débat : modification contractuelle immédiate, travail politique ultérieur, autres travaux de la GNSO ou réponses plus ciblées de conformité et d’expertise technique.

Mais les deux premières priorités recommandées pour un PDP sont les contrôles de domaines associés et les garanties entourant l’accès API des nouveaux clients. La vérification proactive demeure parmi les lacunes susceptibles d’être examinées plus tard, en fonction des ressources, de la capacité de travail de la communauté et des priorités du Conseil.

Un thème peut donc figurer dans l’inventaire sans être entré dans le premier paquet de travail autorisé. Citer le rapport ne revient pas à lancer un PDP sur les 15 jours.

Le chiffre de 70 % éclaire, il n’autorise pas

La lettre du GAC reprend un résultat d’INFERMAL : dans le modèle et les données de l’étude, la validation du téléphone ou du courriel pendant la création du compte ou avant l’achat est associée à environ 70 % d’enregistrements malveillants en moins.

Le mot « associée » doit être conservé. Ce résultat ne démontre pas qu’une modification contractuelle produirait partout le même effet. Il ne tranche ni les coûts, ni les erreurs, ni les droits des titulaires, ni l’organisation des revendeurs, ni la comparaison avec d’autres mesures. Une donnée peut orienter le choix ; elle ne choisit pas l’autorité compétente.

Publier une fiche de choix de voie

Après tout dialogue interinstitutionnel, l’ICANN devrait publier une fiche courte et versionnée. Elle énoncerait le résultat recherché en termes opérationnels, préciserait s’il s’agit d’interpréter l’existant ou de créer ou modifier une obligation, et nommerait la voie retenue — ou indiquerait qu’aucune ne l’est.

La fiche devrait aussi identifier le décideur ou les parties compétentes, le seuil de priorité et de ressources, la prochaine décision autorisée, les points explicitement non décidés et la date d’état. Tout changement de voie laisserait l’historique visible.

Dans le cas présent, la fiche dirait : le résultat demandé est une vérification avant résolution ; le changement porterait sur le calendrier d’une obligation existante ; deux voies formelles ont été identifiées ; aucune sélection n’apparaît dans les sources publiques examinées ; les contraintes de priorité et de ressources de la GNSO subsistent ; le briefing et la présence d’observateurs n’ont ni modifié le RAA, ni lancé un PDP, ni approuvé la demande du GAC.

Ce document ne favoriserait aucun camp. Il empêcherait seulement qu’une salle, une invitation ou un échange d’informations soient pris pour l’exercice d’un pouvoir qu’ils ne possèdent pas.

Sources