Résumé

  • Le Datatracker a approuvé la version de groupe draft-ietf-intarea-legacy-registries-00 le 11 septembre 2026. INTAREA prend ainsi le projet en charge, sans en faire une RFC.
  • Le texte demande de fermer un registre, d’attribuer l’approbation de l’IESG à un autre, d’appliquer le premier arrivé, premier servi à deux listes de noms et de retirer — ou réécrire — le registre TTL.
  • Les pages de l’IANA n’ont pas encore changé. Un reçu par action permettrait de relier la décision documentaire à l’état réellement publié sans confondre fermeture, suppression et changement de procédure.

Ce que le 11 septembre a vraiment changé

La fiche Datatracker du projet le classe désormais parmi les documents actifs d’INTAREA. Son historique consigne, le 11 septembre, l’approbation de la version -00 par le groupe et son remplacement du projet individuel antérieur.

Ce changement de préfixe n’est pas une formalité vide. Il signifie que le groupe de travail accepte de porter le problème, de discuter le texte et d’en répondre dans la suite du processus. Il ne signifie pas que l’IETF a approuvé une norme proposée. Encore moins que l’IANA a reçu puis exécuté les instructions.

L’historique de la série individuelle sépare bien ces étapes. Le 27 août, les présidents ont constaté un consensus pour l’adoption. Ils ont aussi signalé une objection, estimé qu’elle avait été entendue et discutée, puis précisé que le projet traitait de maintenance des registres et non de l’avenir d’IPv4. Le groupe a donc accepté de travailler sur un objet, sans prétendre que chaque justification était définitivement tranchée.

Le passage de la révision individuelle 03 à la révision INTAREA 00 n’a pas modifié les opérations demandées. La comparaison révèle une correction grammaticale dans les considérations de sécurité et l’ajout d’un remerciement. Le contenu de la commande future reste le même ; seul son propriétaire institutionnel a changé.

Cinq surfaces, pas une seule opération

Le mot « nettoyage » est commode pour le titre du chantier. Il devient trompeur s’il efface les traitements particuliers.

Le registre NetWare/IP Option Type 63 Sub-Option Codes doit, selon le projet, être fermé parce que NetWare n’est plus étendu. Fermer interdit de nouvelles inscriptions, mais ne rend pas les anciennes valeurs fausses. La règle générale de la RFC 8126 est explicite : les informations d’un registre fermé restent valides et ses inscriptions peuvent encore être mises à jour.

Pour IP Option Numbers, le projet ne demande pas la fermeture. Il propose la procédure IESG Approval. Cette voie autorise l’IESG à approuver une nouvelle attribution sans exiger systématiquement une RFC, tout en lui laissant la faculté de demander des pièces ou de consulter la communauté. La RFC 8126 la présente comme exceptionnelle, rarement employée et non comme un chemin ordinaire.

Les registres Machine Names et Terminal Type Names recevraient au contraire une procédure légère : First Come First Served. Dans la terminologie de la RFC 8126, cela signifie une documentation minimale sans examen de fond. Le projet évoque le risque d’inscriptions absurdes et le filtrage de bon sens exercé par l’IANA. Donner une porte d’entrée définie à deux listes dormantes n’est pas les condamner.

Enfin, le projet préfère supprimer le registre IP Time to Live Parameter, car le TTL IPv4 est choisi par le système ou l’application et n’a pas besoin d’un registre. Il prévoit une solution de repli : si le retrait complet n’est pas possible, remplacer la note. Une page retirée et une page conservée avec un avertissement ne produisent pas la même trace documentaire.

L’état public n’a pas suivi le nouveau préfixe

La page DHCP et BOOTP de l’IANA affiche encore les codes NetWare et une procédure Not defined. Elle n’indique pas que le registre est fermé.

La page des paramètres IPv4 conserve Not defined pour IP Option Numbers. Elle contient toujours le registre TTL avec la recommandation d’une valeur par défaut de 64. Les valeurs expérimentales d’options restent visibles, mais aucune ligne n’affiche encore la procédure IESG Approval demandée.

Le registre Machine Names porte toujours la mention Not defined. Celui des Terminal Type Names conserve même Not defined?. La procédure premier arrivé, premier servi n’apparaît sur aucun des deux.

Ce décalage ne prouve ni inertie ni retard. Le document n’est qu’un Internet-Draft. La RFC 8126 rappelle que l’IANA intervient normalement après l’approbation d’un document pour publication. La liste des documents INTAREA décrit l’avancement du texte ; les pages de l’IANA décrivent l’état opérationnel des registres. Il faut consulter les deux.

L’adoption n’efface pas la discussion

Le compte rendu d’INTAREA à l’IETF 126 conserve deux tensions utiles. Un intervenant craignait qu’une fermeture de fait des numéros d’options IPv4 empêche des usages futurs dans des domaines limités. Un autre insistait sur la conservation de l’information lorsque des mécanismes deviennent anciens. L’auteur a répondu que des valeurs expérimentales existaient et que les entrées seraient préservées.

Dans le fil d’adoption, les réserves portent aussi sur la manière de qualifier la fiabilité des options IPv4 et sur le risque qu’une justification soit citée plus largement que son objet. D’autres participants soutiennent l’adoption. Cette pluralité n’invalide pas la décision des présidents ; elle interdit seulement de présenter l’adoption comme une unanimité sur chaque phrase.

La formulation exacte de l’acte compte : le groupe accepte de développer ce document. Il n’a pas encore produit une RFC, et l’IANA n’a pas encore publié les effets demandés.

Un reçu distinct pour chaque instruction

Il manque une liaison publique entre l’instruction future et son résultat. Un reçu d’action de registre pourrait être attaché à chaque opération. Il s’agit d’une proposition éditoriale, pas d’une exigence annoncée par l’IETF ou l’IANA.

Ce reçu comporterait le nom et l’URL exacts du registre, une empreinte datée avant changement, la révision et l’empreinte du projet, le verbe demandé, les décisions successives du groupe et de l’IESG, la confirmation d’exécution par l’IANA, la référence devenue applicable, une empreinte après changement et le sort des anciennes valeurs.

Deux registres soumis à la même procédure garderaient deux reçus. Une fermeture ne serait jamais libellée suppression. Pour le TTL, le reçu indiquerait si la page a disparu ou si la note de repli a été utilisée. Si une révision ultérieure modifie la procédure des options IP, l’ancienne demande resterait dans l’historique.

La modestie du chantier rend cette discipline possible. Le nom draft-ietf prouve un transfert de responsabilité. Une RFC future prouverait un autre état. Seule la page IANA modifiée prouvera l’exécution. En attendant, l’honnêteté consiste à dire précisément où s’arrête la preuve.

Sources

  1. IETF Datatracker — document INTAREA
  2. Historique du document de groupe
  3. Révision INTAREA 00
  4. Historique du projet individuel remplacé
  5. Révision individuelle 03
  6. Compte rendu INTAREA de l’IETF 126
  7. Discussion sur l’adoption
  8. IANA — paramètres DHCP et BOOTP
  9. IANA — paramètres IPv4
  10. IANA — Machine Names
  11. IANA — Terminal Type Names
  12. RFC 8126 — procédures d’enregistrement IANA
  13. Documents INTAREA