Résumé

  • draft-ietf-regext-epp-same-entity-01 laisse au registre la définition de l’équivalence et des options, ainsi que la méthode d’accord avec les bureaux d’enregistrement, tout en donnant à cette politique extérieure des effets dans le protocole.
  • Le transfert d’un membre alloué peut emporter tout l’ensemble ; supprimer le domaine primaire doit supprimer tous les membres alloués ou n’en supprimer aucun. Un dépôt central partagé peut étendre cette portée à plusieurs registres.
  • Un « reçu de politique d’équivalence » devrait relier chaque opération à la version de politique et de LGR, aux parties, au domaine primaire, à la preuve d’appartenance, aux exceptions, à la portée et au résultat atomique.

Le problème n’est pas de savoir si le serveur sait traiter une liste. L’ensemble existe avant la liste. Le projet décrit des noms associés à une même entité dans un dépôt central ; le premier nom enregistré devient le domaine primaire. Les suivants ne peuvent être attribués qu’au même bureau d’enregistrement, qui doit conserver le même titulaire.

L’appartenance procède d’une règle. Dans un cas réaliste présenté par le texte, l’univers peut atteindre 10^15 noms. Le serveur ne saurait les énumérer tous : il peut rendre les membres déjà alloués, non matérialiser toutes les possibilités. Un audit qui sauvegarde seulement cette sortie oublie donc la fonction qui a produit le périmètre.

Cette fonction est décisive. Le registre fixe les caractéristiques d’équivalence et les options. La politique est communiquée aux bureaux d’enregistrement, mais la politique comme le procédé d’accord sont expressément hors spécification. Prescribed, Settable et Linked illustrent des comportements possibles ; ce ne sont ni des catégories obligatoires ni une liste close.

L’atomicité ne certifie pas la bonne classification

La suppression du domaine primaire doit englober tous les membres alloués. Si l’un d’eux ne peut être supprimé, l’opération entière échoue et l’état initial demeure. Cette garantie évite une famille cassée, où quelques variantes disparaîtraient tandis que d’autres resteraient contrôlées.

Elle ne prouve toutefois pas que le contour était juste. Un dépôt peut exécuter impeccablement une politique périmée, une LGR mal identifiée ou une exception mal représentée. La cohérence transactionnelle protège contre l’état partiel ; elle ne remplace ni l’autorité de la règle ni sa traçabilité.

Le transfert amplifie cette distinction. Toute demande concernant un membre alloué s’applique à l’ensemble. Si plusieurs registres partagent la politique et le dépôt central, elle peut toucher leurs ensembles correspondants. L’avantage est évident : le lien d’identité ne se fracture pas à chaque changement de prestataire. Le risque l’est aussi : une erreur d’autorisation ou d’appartenance franchit la frontière du nom explicitement demandé.

Les trois principes du projet — compatibilité descendante, gestion de la même entité et gestion de l’ensemble — doivent toujours tenir. Un client ignorant l’extension reçoit donc un refus prudent quand sa commande violerait la logique collective. Ce refus est plus sûr qu’un succès partiel, mais il peut rester incompréhensible sans accès à la politique qui a motivé la décision.

Les exceptions révèlent l’histoire réelle

Les états ont une portée précise. Allocated signifie actif dans le registre, sans garantir une délégation DNS. Allocatable réserve un nom à la même entité. Blocked le rend indisponible à tous. Exempted désigne notamment un héritage antérieur dont le titulaire ou le bureau peut différer jusqu’à certaines conditions de convergence.

L’exception n’est pas une anomalie à masquer. Elle enregistre le contact entre une règle nouvelle et des droits existants. C’est souvent elle qui fait échouer un transfert ou une suppression de l’ensemble. La gouvernance sérieuse doit conserver sa base juridique, sa durée et son mécanisme de sortie.

Le document lui-même demeure provisoire. Son annexe laisse ouverts les numéros de codes d’erreur, une partie de l’analyse de sécurité, le traitement des enregistrements DS et les effets d’une mise à jour Unicode. La section IANA est vide dans la version rendue. Le Datatracker n’affiche pas de statut RFC visé alors que l’en-tête dit Standards Track. Rien de cela ne permet d’annoncer un RFC achevé ou un déploiement effectif.

Un reçu rend la frontière attribuable

Le reçu proposé ici n’ajoute pas toute la politique à chaque message. Il en fixe l’identité : version de politique, version de LGR, date d’effet, registre, bureau et opérateur du dépôt. Il nomme le domaine primaire et explique pourquoi le nom demandé appartenait à l’ensemble à l’instant de l’évaluation.

Il consigne ensuite la portée : commande, membres alloués visés, registres couverts, états allocatable ou blocked pertinents et exemptions. Enfin, il relie le résultat aux identifiants de transaction et à la preuve de retour à l’état initial en cas d’échec atomique. Un condensat vérifiable vaut mieux qu’une mention vague de « lot de variantes ».

Ce dispositif ne déplace pas les responsabilités. Le registre répond de la définition ; le bureau, de l’identité du titulaire ; le dépôt, de la symétrie et de l’exécution. Il relie simplement une décision invisible sur le fil à ses conséquences visibles.

Sources