Résumé

  • Le projet individuel draft-brown-epp-deleg-03, daté du 29 septembre, ajoute <deleg:all/> sous <deleg:rem> : la demande de retrait peut porter sur tous les DELEG d'un domaine, sans les énumérer. La version 02 ne comportait pas cette possibilité.
  • Il s'agit d'une proposition Internet-Draft, pas d'une norme approuvée ni de la preuve qu'un registre l'exécute. Les NS traditionnels et l'objet domaine ne sont pas la cible de cette commande.

Une opération d'administration peut paraître plus simple lorsque le client n'a plus à connaître chaque élément présent. Pourtant, cette simplicité déplace un choix. Avec une liste explicite, l'approbateur peut comparer les enregistrements visés avec la demande. Avec « tous », la portée concrète dépend de l'état trouvé par le serveur au moment de la mise à jour. C'est précisément la différence introduite par la nouvelle rédaction du projet EPP DELEG.

La section 5.2.2 offre désormais deux formes de retrait dans une mise à jour du domaine : des éléments deleg:deleg désignés individuellement, ou un élément vide <deleg:all/> qui signifie le retrait de tous les enregistrements DELEG du domaine. Un exemple montre le second cas sans ajout simultané. Cette syntaxe ne raconte aucun incident. Elle formalise une capacité éventuelle que les exploitants devront délimiter si elle se retrouve un jour dans des services réels.

Le mot « tous » ne doit pas être détaché de son objet. Il ne supprime pas l'enregistrement du domaine lui-même, les objets hôtes EPP ni l'ensemble des données DNS. La section 6 prévoit la coexistence des DELEG avec les NS habituels. Un résultat positif au niveau du provisionnement ne prouverait pas non plus que les serveurs faisant autorité ont déjà publié le même état, ni que les résolveurs ont cessé d'utiliser une réponse mise en cache. Il faut distinguer ces observations, même si la commande est unique.

Cette troisième version change également le format des paramètres : les anciens attributs de deleg:params cèdent la place à des éléments deleg:param, et l'espace de noms proposé passe de deleg-0.01 à deleg-0.02. Les champs priority et target visibles dans l'ancien schéma ont disparu. BTW avait signalé que ces champs persistaient dans la version 02 alors que le projet RDAP correspondant les avait retirés. Le nouveau texte réduit cet écart documentaire précis ; il ne démontre ni conversion complète entre EPP, DNS et RDAP, ni migration en production. Notre sujet ici est l'autorité sur le retrait intégral, pas la reprise de l'ancien constat.

La section consacrée à la sécurité propose le refus des noms de paramètres inconnus et des valeurs invalides. Elle évoque une mise à jour périodique des listes de clés enregistrées par clients et serveurs. Cela définit la recevabilité de données dans un modèle futur ; cela ne répond pas à la question de savoir qui a le droit de vider un jeu entier. La version 11 du projet DELEG principal demande encore la création d'un registre IANA pour ces informations. Une référence à ce registre dans les projets n'est pas la preuve qu'il fonctionne déjà.

Le Datatracker classe le texte EPP parmi les Internet-Drafts individuels actifs, sans flux RFC ni directeur de secteur responsable, au stade « I-D Exists ». L'annonce du 29 septembre atteste la diffusion du texte, non un consensus, un déploiement ou un dommage. La conséquence institutionnelle reste conditionnelle : si une implémentation adopte cette option, un droit de modifier un DELEG à la fois ne devrait pas automatiquement devenir un droit d'effacer la collection entière.

Sources