Résumé

  • draft-ietf-netmod-yang-versioning-reqs-14 expose cinq familles d’exigences et précise qu’il n’étudie ni ne recommande aucune solution particulière.
  • Un statut de WG Document, la mention I-D Exists ou une correspondance entre clause et mécanisme établissent un objectif documentaire, pas un résultat d’implémentation.

Imaginez une revue où cinq cases sont cochées parce que cinq numéros de section figurent dans une présentation. La première case concerne l’évolution non rétrocompatible sans renommage en chaîne. La deuxième, l’identification BC/NBC. La troisième, les anciens clients. La quatrième, les nœuds deprecated ou obsolete. La cinquième, la migration depuis YANG 1.0/1.1 et l’interprétation des données d’instance. La feuille paraît complète; aucune cible n’a pourtant été testée.

La révision 14, datée du 20 juillet 2026, porte « Intended status: Informational ». Datatracker la classe parmi les Internet-Drafts actifs de NETMOD, avec les états WG Document et I-D Exists. Son résumé fixe la limite décisive: elle décrit des problèmes et les exigences imposées à une éventuelle solution; elle n’en examine et n’en cautionne aucune.

Cinq obligations, cinq preuves distinctes

Le premier groupe veut autoriser une mise à jour NBC sans obliger tous les modules importateurs à changer simultanément de nom, tout en épargnant les clients qui n’utilisent que des nœuds inchangés ou modifiés de façon compatible. Une contrainte d’import intermédiaire et un signalement des changements incompatibles sont aussi requis. Pour accepter une solution, il faut donc conserver les artefacts exacts, la fermeture des imports et includes, le schéma effectif résolu et les clients réellement exercés. Une compilation réussie ne prouve pas l’ensemble.

Le deuxième groupe demande que lecteurs et outils distinguent BC et NBC, jusque dans les différences entre nœuds. Mais le texte rappelle qu’un comportement sémantique peut changer sans modification détectable des instructions YANG. L’étiquette doit être attribuable; sa justesse exige les deux versions, la politique de comparaison, les features, deviations, exceptions humaines et avertissements.

Le troisième groupe protège les clients existants, y compris ceux qui attendent une ancienne version après une rupture. Cette promesse se vérifie dans les deux sens: ancien client avec nouveau serveur, nouveau client avec ancien serveur. Il faut exercer lectures, écritures, RPC, notifications, erreurs et droits d’accès avec les binaires et ensembles de modules exacts.

Le quatrième groupe veut rendre visible l’implémentation des nœuds deprecated, documenter les alternatives et prévenir avant le passage à obsolete, tant que la définition reste utilisable. Une annonce de serveur n’est qu’une déclaration. Le schéma effectif, les deviations, les opérations réelles et la stabilité après redémarrage constituent des preuves séparées.

Enfin, le cinquième groupe exige des instructions de transition et une explication des effets sur les données d’instance. RFC 9195 permet d’identifier le content-schema, mais avertit que la réutilisation sous un autre schéma dépend des révisions, features, deviations et du périmètre. Une migration doit comptabiliser valeurs renommées, supprimées, produites, mises par défaut ou rejetées, puis tester les invariants de sens et le retour arrière.

Les travaux voisins — historique de révisions, Semver, packages, comparaison de schémas, nommage de fichiers ou YANG 2.0 — peuvent répondre à certaines cellules. Leur proximité institutionnelle ne prouve ni la couverture complète ni le fonctionnement d’un serveur. La force de ce texte est précisément de garder la recette ouverte.

Sources primaires

Le dossier officiel gelé réunit la révision 14, sa fiche Datatracker et son historique, les documents NETMOD, ainsi que RFC 2119, RFC 6020, RFC 7950, RFC 8049, RFC 8299, RFC 8525 et RFC 9195.