Résumé

  • draft-ietf-intarea-legacy-registries-00 ne propose pas une retraite uniforme : il ferme un registre, impose l’approbation de l’IESG à un autre, donne une règle légère à deux registres oubliés et demande la suppression d’un registre fondé sur une mauvaise catégorie.
  • L’état IANA atteste une décision de coordination. Il ne prouve ni la présence du code dans un produit, ni le passage d’un paquet, ni l’autorisation d’un opérateur, ni l’issue d’un service.

La fermeture agit sur l’avenir, pas rétroactivement sur les octets

Le cas NetWare est le point de départ le plus net. Le projet demande de fermer le registre des sous-options de type 63, puisque NetWare n’est plus étendu. Il précise pourtant que les valeurs existantes restent valides et que leurs fiches peuvent encore être mises à jour conformément à RFC 8126. La porte administrative se ferme aux nouveaux entrants ; les occupants historiques ne sont ni effacés ni soudainement rendus illégaux.

Cette nuance protège la vérité. Une ancienne valeur peut subsister dans un équipement industriel, un parseur de secours ou une passerelle de compatibilité. Elle peut aussi ne plus avoir aucun utilisateur réel. Le registre ne permet pas de trancher entre ces situations. Il décrit l’attribution ; l’inventaire logiciel, les journaux, les captures de chemin et les résultats de service décrivent l’usage.

Une migration mal gouvernée transforme trop vite « fermé » en « impossible ». Elle retire un décodeur, supprime un compteur ou bloque tout paquet avant d’avoir trouvé le dernier dépendant. Une migration sérieuse procède autrement : elle arrête les nouvelles dépendances, observe les anciennes, définit une exception bornée, puis ne retire le dernier mécanisme qu’après une preuve de sortie.

Quatre verbes, quatre pouvoirs

Le projet montre que le ménage d’un registre ne se résume pas à supprimer une page.

Pour les numéros d’options IPv4, la procédure proposée est IESG Approval. L’entrée future exigerait donc une décision explicite de l’IESG. Mais le même texte rappelle que les options IPv4 fonctionnent mal sur l’Internet public et qu’une solution fondée sur une nouvelle option risque de manquer de fiabilité. Une attribution approuvée ne devient pas un reçu de traversée des routeurs, pare-feu ou chemins rapides.

Pour Machine Names et Terminal Type Names, la solution proposée est First Come First Served. Aucun processus n’était défini et aucune inscription nouvelle n’a été observée depuis deux décennies. FCFS fournit une discipline d’unicité et d’ordre. Il ne demande pas à IANA de garantir l’utilité, la sécurité, l’implémentation ou l’adoption du nom.

Pour IP Time to Live Parameter, le projet demande la suppression du registre, ou au minimum une note rectifiée. Le TTL est choisi librement par le système source ou l’application. Une valeur par défaut recommandée de 64 peut guider les implémentations ; elle n’est pas pour autant une ressource centrale à attribuer. Supprimer le registre revient donc à corriger le modèle, non à interdire une valeur particulière.

Fermer signifie arrêter les nouvelles inscriptions. Exiger l’IESG signifie soumettre les nouvelles inscriptions à une autorité explicite. FCFS signifie coordonner sans évaluation substantielle. Supprimer signifie reconnaître que le champ ne relevait pas de cette forme d’attribution. Confondre ces verbes produit de mauvaises décisions techniques.

De l’ouvrage imprimé à la base vivante

RFC 1700 rassemblait les numéros attribués dans un document. RFC 3232 a ensuite placé l’autorité courante dans les bases en ligne d’IANA. Ce déplacement permet de maintenir les registres sans republier constamment un RFC. Il n’a jamais signifié que toute vérité opérationnelle résidait désormais dans une cellule de la base.

La spécification définit le sens sur le fil. Le logiciel choisit ce qu’il émet ou accepte. L’opérateur fixe une politique. Le réseau laisse passer, modifie ou bloque. Le service révèle enfin si l’objectif a été atteint. Il faut donc cinq reçus séparés : état du document, état du registre, comportement d’une version nommée, résultat sur un chemin défini et résultat du service.

Présenter deux fois le reçu IANA ne compense pas l’absence d’un test de service. Inversement, le succès d’un ancien flux ne prouve pas que le registre doit continuer à accepter de nouvelles extensions. Chaque affirmation doit être soutenue par la surface qui la contrôle.

Le texte reste un projet

La limite temporelle interdit tout triomphalisme. Le Datatracker présente la révision 00 comme un document actif du groupe intarea, à l’état I-D Exists. Elle date du 11 septembre 2026 et expire le 15 mars 2027. Ce n’est ni un RFC, ni une approbation finale, ni la preuve que les opérations IANA demandées ont été exécutées.

Les pages IANA actuelles restent donc la source du présent. Le projet est une proposition de changement et une occasion d’examiner l’autorité appropriée. Une révision ultérieure peut modifier les registres visés, les politiques ou la justification. Cette incertitude ne diminue pas l’enseignement principal : un acte sur le registre et un acte sur les systèmes déployés sont deux transitions différentes.

Sources