Résumé

  • draft-ietf-netmod-yang-module-versioning-17 autorise explicitement des historiques non linéaires. Une date de révision identifie une définition ; elle n’établit ni filiation, ni ordre sémantique, ni compatibilité.
  • Le marqueur NBC, la date minimale recommandée et les deux indicateurs de YANG Library sont des déclarations circonscrites. Le schéma effectif, le comportement du serveur, le client, les données persistantes et l’ordre de déploiement doivent conserver leurs propres preuves.

Un résolveur reçoit deux révisions d’un même module. L’une date d’avril, l’autre de mai ; l’import recommande avril comme minimum. Mai paraît donc admissible. Pourtant cette révision vient d’une autre branche et n’a jamais reçu le grouping ajouté en avril. Le prédicat chronologique réussit, la dépendance échoue.

C’est le déplacement décisif d’Updated YANG Module Revision Handling, révision 17. Publié le 29 juin 2026, le texte reste un Internet-Draft et non un RFC. Il admet que deux révisions indépendantes d’un module ou sous-module puissent dériver du même parent. Les dates demeurent uniques, mais elles n’impliquent plus un ordre de descendance ni une compatibilité.

L’historique ne montre qu’un chemin

Dans un développement ramifié, chaque fichier décrit la lignée dont il provient, pas toutes les branches possibles. La filiation entre deux révisions ne peut donc pas être déduite en comparant dates ou étiquettes de version. Il faut consulter l’historique de la révision concernée.

Cet historique peut lui-même être élagué. Le projet permet de supprimer d’anciennes entrées lorsque les marqueurs NBC restant décrivent encore correctement la relation entre les entrées conservées. La révision la plus récente ne peut pas disparaître. La règle évite une fausse continuité, mais elle ne recrée pas les commits absents. Un dossier exploitable doit préserver les octets, le dépôt ou l’archive d’origine, la filiation des commits et la trace des suppressions.

Les sous-modules aggravent le risque d’ambiguïté. Le module parent devrait les inclure avec une revision-date exacte. Sans cette contrainte, son propre identifiant ne suffit pas à reconstruire le contenu réellement compilé.

NBC est une alerte attribuée

Le projet autorise des changements non rétrocompatibles tout en les déconseillant. Une correction, le retrait progressif d’un nœud ou la refonte d’un modèle encore instable peuvent les rendre nécessaires. Si une révision contient, par rapport à la précédente de son historique, une modification contraire aux règles BC, elle doit porter rev:non-backwards-compatible. En l’absence du marqueur, les changements doivent être BC.

Cette obligation rend le risque visible, mais ne produit pas la classification à la place de l’auteur. Celui-ci peut aussi marquer prudemment une extension formellement compatible dont l’impact sur les clients paraît sérieux. Et l’absence de marqueur ne vaut que par la qualité de la revue et de l’historique conservé. Il faut donc joindre les deux contenus, l’inventaire des changements, la règle appliquée et l’identité du réviseur. L’algorithme détaillé de comparaison de schémas relève d’un autre projet et n’est pas repris ici.

Une date plancher n’est pas une contrainte de branche

RFC 7950 permet de fixer une révision exacte dans un import ; sans cette précision, la révision choisie n’est pas définie par le langage. Pour éviter des épingles trop rigides, la révision 17 propose rev:recommended-min-date, indication lisible par machine de la première date censée satisfaire la dépendance.

Le mécanisme peut déclencher un avertissement. Il ne modifie ni la sémantique de l’import ni la conformité YANG. Surtout, le projet reconnaît qu’une révision datée après le seuil peut appartenir à une autre branche et ne pas contenir la définition attendue. Cette recommandation sert principalement les historiques linéaires.

Une preuve de résolution doit identifier la révision choisie, établir son ascendance ou la présence effective des définitions requises, résoudre les symboles avec les vraies features et deviations, puis fixer l’empreinte du schéma résultant. date choisie ≥ date minimale n’est qu’un signal d’admission à cet examen.

Deux booléens réduisent l’ambiguïté annoncée

Le module ietf-yang-library-status ajoute deux feuilles à YANG Library. Avec deprecated-nodes-implemented=true, le serveur affirme implémenter les nœuds dépréciés comme des nœuds courants, sauf deviation explicite. Avec obsolete-nodes-absent=true, il affirme n’implémenter aucun nœud obsolète. La valeur par défaut false laisse le comportement indéterminé.

Les deux valeurs true rendent le schéma annoncé plus précis. Si le premier indicateur n’est pas true, le client ne doit pas fonder son jugement sur les marqueurs NBC seulement. Mais ces booléens restent des affirmations du serveur. Ils n’exécutent aucune lecture, écriture, RPC ou notification ; ils ne prouvent pas le chargement des deviations ni la stabilité après redémarrage. Des sondes doivent confronter le catalogue déclaré au comportement réellement observé.

Client, données et réseau conservent leur veto

Le texte avertit qu’un serveur révisé peut renvoyer une valeur valide pour son schéma mais hors des contraintes connues d’un ancien client. Il recommande une gestion défensive, la surveillance des historiques et l’analyse de chaque NBC avant migration. Les clients devraient quitter les nœuds dépréciés et doivent cesser d’utiliser les nœuds obsolètes.

Il faut pourtant tester les deux sens : ancien client contre nouveau serveur, puis nouveau client contre ancien serveur. Les encodages, valeurs par défaut, RPC, notifications, erreurs et rôles NACM font partie de l’épreuve. Les binaires, modules, features et deviations doivent être attachés au résultat.

Les données persistantes ont une frontière distincte. RFC 9195 peut associer un jeu d’instances à son content-schema, mais une validation réussie après conversion ne prouve pas la conservation du sens. Le reçu de migration doit compter suppressions, renommages, valeurs synthétisées et rejets, vérifier des invariants, puis montrer que l’ancienne version peut relire l’état après retour arrière.

Enfin, RFC 8342 sépare running, intended et operational précisément parce que configuration, intention appliquée et état observé peuvent diverger. Une compilation propre ne démontre ni la convergence de l’équipement, ni l’interopérabilité pendant une montée de version progressive, ni le résultat du service.

La révision 17 rend l’évolution YANG plus honnête. Pour préserver cette précision, chaque métadonnée doit rester à sa place : la date identifie, l’historique décrit une lignée, NBC alerte, la date minimale conseille et YANG Library rapporte. Le client exécuté, les données migrées et le réseau observé doivent répondre au reste.

Sources principales

Le corpus officiel figé comprend la révision 17, sa fiche Datatracker et son historique, RFC 7950, RFC 8525, RFC 9907, RFC 8342, RFC 8341, RFC 9195 et les exigences de versionnage, révision 13.