Résumé

  • L’ancienne formulation du RFC 6020 exigeait l’unicité de tous les noms de modules et sous-modules ainsi que de tous les espaces de noms XML. Le RFC 9890 limite à juste titre cette unicité à la version initiale et impose aux révisions de conserver l’identité d’origine.
  • Cette identité commune établit une filiation éditoriale. Elle ne révèle ni la révision exacte, ni les octets du fichier, ni les fonctions et déviations actives, ni la configuration appliquée par un équipement.

Sur l’écran de validation d’un changement, deux lignes paraissent rassurantes. Avant la mise à niveau : même nom de module. Après : même nom. L’espace de noms XML n’a pas bougé non plus. Si ces deux champs deviennent la preuve que le schéma est identique, le contrôle a déjà confondu l’étiquette durable avec son contenu. Entre les deux captures, une nouvelle révision a pu ajouter des nœuds, modifier des contraintes ou être chargée avec un autre ensemble de fonctions.

Le RFC 9890, publié sur la voie normative en octobre 2025, traite précisément de cette confusion. Son objet est modeste : corriger les consignes IANA relatives au registre des noms de modules YANG. Il ne change pas le protocole sur le réseau, n’ajoute aucune opération de gestion et ne prouve aucun déploiement. Il rend la règle écrite cohérente avec la pratique suivie pour enregistrer un module et ses révisions.

Le texte hérité du RFC 6020 déclarait que tous les noms présents dans le registre devaient être uniques, tout comme tous les espaces de noms XML. Pris ligne par ligne, ce principe semblait interdire qu’une révision ultérieure porte le nom de la première. Or une révision n’est pas un nouvel objet sans lien : elle continue la même lignée. Le RFC 9890 précise donc que les noms des versions initiales sont uniques, que l’espace de noms du module initial est unique, puis que les révisions gardent ce nom et cet espace de noms.

Une identité ne constitue pas une empreinte

YANG a besoin des deux idées à la fois : continuité et différence. La continuité permet aux outils et aux auteurs de reconnaître le module. La différence permet de choisir les définitions voulues. Dans YANG 1.1, RFC 7950, les déclarations revision forment l’historique éditorial du module. Une instruction d’import peut employer revision-date pour viser une version précise. Sans cette date, la révision dont proviennent les définitions reste indéterminée.

YANG 1.1 autorise même l’import de plusieurs révisions du même module si des préfixes distincts séparent les références. Ce détail détruit l’idée selon laquelle le nom suffirait à identifier le contenu. Le nom répond à « de quelle lignée s’agit-il ? » ; la date répond à « quelle étape de cette lignée ? » ; le fichier et son empreinte répondent à « quels octets avons-nous effectivement examinés ? ».

Le registre IANA des paramètres YANG matérialise cette logique. ietf-yang-types y apparaît avec des fichiers datés de 2010, 2013 et 2025. Ce ne sont pas trois attributions concurrentes du même nom. Ce sont trois traces d’une même histoire publiée. Le registre coordonne cette histoire publique, mais il n’observe ni l’image logicielle d’un constructeur ni le cache d’un contrôleur.

Les recommandations du RFC 9907 empêchent l’abus inverse. Un nom déjà publié ne peut pas être repris pour un autre module, même si le RFC d’origine devient historique. Changer le nom revient à créer un nouveau module. Quand le contenu publié change, une nouvelle date de révision s’ajoute et les anciennes déclarations publiées sont conservées. L’identité ne doit donc être ni jetable à chaque mise à jour, ni réutilisable pour un sujet étranger.

Cette discipline a une valeur institutionnelle. Un espace de noms n’est pas un numéro de version déguisé. Le recréer à chaque édition multiplierait les identités, les mappages et les risques de divergence. Mais sa stabilité ne doit pas non plus devenir un raccourci dans une feuille de contrôle. La lignée est stable précisément pour que ses changements restent comparables.

Après IANA commence la preuve locale

Pour savoir ce qu’un serveur de gestion utilise, il faut passer au RFC 8525. La bibliothèque YANG décrit les ensembles de modules, les modules implantés ou seulement importés, leurs révisions et espaces de noms, les fonctions activées, les modules de déviation, les schémas et les magasins de données d’un serveur déterminé.

Cette observation est plus proche de l’exécution, mais elle a une portée locale. Deux serveurs peuvent publier des bibliothèques différentes. Un redémarrage ou une modification à chaud peut changer l’information. Le content-id doit changer quand la bibliothèque de ce serveur change ; il n’est pourtant pas tenu d’être une empreinte du contenu ni de rester identique sur deux serveurs qui exposent les mêmes données. Il sert à savoir si un cache local doit être rafraîchi.

Une preuve exploitable conserve donc l’identité du serveur, le point d’accès authentifié et l’heure de capture avec le content-id. Elle enregistre l’ensemble de modules, le schéma du magasin, le statut implanté ou importé, la révision, les fonctions, les déviations et l’emplacement de la source. Pour une construction reproductible, elle ajoute le fichier exact et son empreinte cryptographique.

Ces champs n’ont rien d’une bureaucratie ornementale. Ils permettent de comprendre pourquoi deux routeurs portant les mêmes noms de modules rejettent des configurations différentes. Ils permettent aussi de distinguer une transition de flotte planifiée d’une dérive silencieuse. Une liste d’inventaire limitée aux noms supprimerait précisément les dimensions qui expliquent l’écart.

Du module au résultat, plusieurs seuils subsistent

Le RFC 8342 définit le schéma d’un magasin comme l’ensemble des nœuds fourni par les modules, compte tenu des fonctions activées et des déviations. La présence du bon nom et même de la bonne révision ne garantit donc pas que deux appareils offrent le même schéma effectif.

Le chemin continue. <running> peut contenir une configuration qui doit encore subir des transformations. <intended> représente ce que le système tente d’appliquer après ces transformations. <operational> combine la configuration appliquée et l’état produit par le système. Des valeurs peuvent diverger à cause du matériel, d’un protocole, d’un autre appareil ou du délai de propagation.

On peut alors formuler une échelle de preuve sans raccourci :

  1. IANA atteste l’identité publique et les références de publication.
  2. Le fichier d’une révision atteste des définitions précises.
  3. La bibliothèque d’un serveur déclare la révision, les fonctions et les déviations qu’il utilise.
  4. Le schéma effectif établit quels nœuds sont disponibles dans un magasin.
  5. Une configuration autorisée exprime un état désiré.
  6. <intended> montre ce que l’appareil tente d’appliquer.
  7. <operational> montre l’état actuellement utilisé et observé.
  8. La mesure du réseau établit, ou non, le résultat attendu.

Aucun échelon ne certifie automatiquement le suivant. Cette séparation ne diminue pas la valeur du registre ; elle lui rend sa véritable autorité.

Le minimum commun protège les décisions futures

La stabilité du nom réduit le coût de coordination mondiale. Elle évite de fabriquer une nouvelle identité pour chaque édition et laisse les utilisateurs choisir localement le moment où ils adoptent une révision. C’est proche de la logique décrite par Heng Lu dans Minimum Initial Specification and Localized Future Decision : fixer au centre ce qui doit être commun, conserver à la périphérie les décisions dont les conséquences sont locales.

Cette liberté locale exige cependant une responsabilité locale. L’auteur de l’import choisit de fixer ou non la révision. Le mainteneur du paquet décide quelle source distribuer. L’exploitant choisit le calendrier de flotte. Le responsable de l’automatisation décide quel changement déclenche une alerte ou bloque un déploiement. La coordination ne prend pas ces décisions à leur place.

Dans Running Code as Primary Evidence, la priorité donnée au système observable rappelle qu’une norme corrigée ne peut témoigner du code chargé. La norme fixe une relation symbolique légitime ; la bibliothèque, le fichier, le schéma et l’état opérationnel prouvent des propositions différentes.

Enfin, Reality Layers and Symbolic Power aide à comprendre pourquoi les tableaux de bord résistent à cette pluralité. Un voyant vert paraît plus clair qu’une série de jointures incomplètes. Pourtant, la clarté qui efface le domaine d’autorité de chaque preuve produit une certitude factice. Le RFC 9890 nous apprend à garder le symbole durable sans lui attribuer le pouvoir de figer la réalité.

Sources