Summary

  • La révision draft-ietf-ianabis-rfc8126bis-04, datée du 26 octobre 2026, demanderait à l'IANA d'ajouter un champ « Change Controller » aux nouveaux registres dont les inscriptions n'exigent pas un RFC issu du flux IETF. Les procédures First Come First Served, Expert Review, Specification Required et RFC Required sont expressément citées. Les registres existants dépourvus de ce champ recevraient plus tard une colonne vide.
  • Le RFC 8126 recommandait déjà de préciser qui contrôle les changements. Le projet passe d'un conseil de rédaction à une instruction adressée à l'IANA. Dans le registre JSONPath actuel, l'expert nommé est Glyn Normington, tandis que l'IETF est inscrit comme responsable des changements des cinq fonctions répertoriées.

La deuxième décision arrive après l'attribution

L'attribution initiale d'un identifiant retient l'attention : un numéro libre devient un élément que des logiciels peuvent échanger. La vie de la notice commence ensuite. Sa référence vieillit, le contact part, une définition réclame une précision. Modifier cette ligne exige une autorisation que le simple fait de posséder l'adresse électronique de l'auteur ne fournit pas.

Le RFC 8126 en vigueur pose déjà le problème. Pour les registres et inscriptions issus de RFC du flux IETF, l'IETF exerce par défaut le contrôle des modifications par l'intermédiaire de l'IESG. Le texte recommande de préciser ce contrôle quand les inscriptions peuvent venir d'ailleurs. Il conseille aussi un champ consacré au responsable dans les nouveaux registres « premier arrivé, premier servi » ou soumis à l'examen d'un expert. Ce vocabulaire organise la bonne pratique, sans ordonner à l'IANA de poser la même colonne partout.

La version -04 du projet IANABIS durcit ce point précis. Son §11.2 prévoit un champ pour tout nouveau registre utilisant First Come First Served, Expert Review, Specification Required ou RFC Required, ainsi que pour toute autre procédure permettant une inscription sans RFC du flux IETF. La formulation élargit le terrain : elle vise la manière dont un registre accepte des valeurs, puis exige un emplacement où inscrire l'autorité compétente pour les retoucher. Un examinateur juge une demande; il n'acquiert pas pour autant le pouvoir de modifier toutes les inscriptions qu'il a examinées.

Le §2.5 tranche même une subtilité institutionnelle. Une inscription née d'un RFC du flux IETF devrait normalement porter « IETF » comme responsable, alors que l'IESG agit au nom de cette organisation. Des textes fondateurs imposent explicitement « IESG » pour certains registres, notamment les ports. Le projet conserve ces exceptions. L'étiquette publique doit suivre le titre de compétence réel, pas seulement le nom du bureau qui traite le courrier.

Une case vide vaut mieux qu'un faux titulaire

Pour les anciens registres privés du champ, le projet annonce l'ajout futur de cases vides. Il ne donne ni le nombre de tableaux concernés ni un calendrier de remplissage des inscriptions historiques. Voilà la frontière honnête de la réforme proposée. Créer la colonne peut être une opération de format; déterminer qui contrôle une ligne relève du document qui a créé le registre, de la procédure applicable et parfois d'une chaîne de décisions plus ancienne. Écrire un nom au hasard pour donner l'impression d'avoir terminé serait la pire migration possible.

L'IANA montre déjà un cas rempli avec JSONPath. Le registre des extensions de fonctions suit la procédure Expert Review et affiche Glyn Normington comme expert. Dans la table, length, count, match, search et value portent chacune « IETF » dans la colonne « Change Controller ». Deux fonctions de gouvernement tiennent ainsi sur la même page : appréciation technique des inscriptions et autorité sur leur modification. Cet exemple précède le projet; il n'atteste aucune mise en œuvre de la version -04.

Le projet précise encore que, sauf règle contraire, la procédure d'inscription sert aussi à modifier une valeur. Pour une inscription qui n'a pas été créée par RFC, l'IANA pourrait confirmer et approuver les changements de coordonnées ou de responsable, en sollicitant au besoin des experts ou des directeurs de domaine. Cette voie de réparation compte quand les personnes ont changé. Elle exige surtout que le contenu de la case et la procédure suivie pour le modifier racontent la même histoire.

Le document reste un Internet-Draft de groupe de travail. Son état IESG est « I-D Exists »; le RFC 8126 demeure le texte en vigueur. Il manque une version approuvée et un relevé d'implémentation IANA pour dire combien de champs seront réellement créés puis remplis. Ce sont les faits qui permettraient de mesurer la portée de cette proposition.