Résumé

  • draft-ietf-netmod-yang-schema-comparison-09 compare à la fois les instructions analysées et l’arbre de données compilé, puis classe chaque changement en éditorial, rétrocompatible ou non rétrocompatible.
  • Ce résultat éclaire la revue d’une révision, son étiquette sémantique et la préparation d’une conversion. Il ne démontre ni l’identité du contexte de compilation, ni l’absence de perte, ni l’interopérabilité, la stabilité de NACM ou la convergence opérationnelle.

Un résultat de comparaison a la forme rassurante d’une conclusion. Quelques lignes remplacent des milliers de lignes YANG ; une absence de changement incompatible semble pouvoir fermer le dossier. C’est précisément là que la discipline se perd. Le diff décrit une expérience délimitée. La mise à niveau, elle, traverse des convertisseurs, des clients, des serveurs, des règles d’accès, un ordre de déploiement et enfin un système vivant.

La révision 09 a été publiée le 3 juillet 2026. Le Datatracker de l’IETF la présente comme un Internet-Draft actif du groupe NETMOD, et non comme un RFC. Le résumé de validation visible indique zéro erreur et zéro avertissement. Il s’agit d’éléments sur le document et ses outils de contrôle, pas d’une mesure d’adoption, d’interopérabilité ou de production.

Deux représentations pour une même révision

Le projet distingue le schéma analysé du schéma compilé. Le premier reste proche de l’arbre des instructions chargées : les références et transformations n’y sont pas toutes résolues. Le second construit le modèle effectif. Il incorpore les imports et sous-modules, résout uses et typedef, applique augment, deviation et refine, puis tient compte des expressions if-feature activées.

La distinction évite deux angles morts. Une modification minuscule d’un typedef peut se propager à de nombreuses feuilles. Un augment placé dans un autre module peut modifier l’arbre de données examiné. Une deviation propre à un équipement peut lever une contrainte alors que le fichier cible n’a pas bougé. Le texte source seul ne révèle pas tout l’arbre effectif ; l’arbre seul ne restitue pas toutes les modifications d’instructions utiles aux auteurs et aux modules importateurs.

La révision 09 produit donc d’abord les changements des nœuds compilés, puis examine les autres instructions analysées sans dupliquer les nœuds déjà signalés. L’identité de compilation contient le nom et la révision des modules ancien et nouveau, les sous-modules inclus, les features activées et les imports récursifs.

Une comparaison vide ne vaut que pour cet ensemble précis. Changer une feature, une révision importée, une deviation fournisseur ou un sous-module change l’expérience. Le reçu initial doit conserver le hash des sources et cette identité de compilation complète, faute de quoi le verdict n’est pas portable.

Les trois classes restent des affirmations de schéma

Chaque différence devient ED, BC ou NBC. Une modification éditoriale ne doit ni toucher l’espace des valeurs valides ni invalider un module importateur. Une modification rétrocompatible peut agrandir cet espace sans casser les importateurs. Toute réduction de l’espace valide, ou tout risque d’invalidation d’un importateur, relève de NBC.

La règle ne suit pas toujours l’intuition. Passer de uint32 à uint64 étend la plage mathématique. Pourtant, l’encodage JSON de RFC 7951 passe d’un nombre à une chaîne. Pour un client, la représentation change de nature ; la modification peut donc être NBC.

Les changements de pattern, when et must sont NBC par défaut. description, reference et presence sont éditoriaux par défaut ; une instance d’extension est BC par défaut. L’auteur peut surcharger ces choix au moyen de marqueurs persistants ed-change-at, bc-change-at ou nbc-change-at, associés à une version sémantique.

Cette possibilité n’est pas une faiblesse si elle est traitée comme une décision traçable. Le dossier doit distinguer la règle déterministe, la classe par défaut et la surcharge humaine, puis conserver sa justification. L’étiquette de version devient ainsi un engagement révisable, non une observation du terrain.

Rétrocompatible ne signifie pas immobile

L’ajout d’une feuille optionnelle peut être BC tout en modifiant les comportements : un serveur commence à la remplir, un client la sérialise, un moteur de politique la lit, une interface l’affiche. Un défaut différent peut changer le comportement effectif sans toucher à la configuration stockée. when, must, features et deviations déplacent eux aussi la surface réellement exécutée.

La comparaison ne lance aucun RPC, ne rejoue pas l’ensemble des configurations, ne compare pas les datastores après application des valeurs par défaut. RFC 8525 permet d’identifier le jeu de modules, les features et les deviations déclarés par un serveur. Son content-id identifie la bibliothèque YANG ; il n’atteste pas que le code exécute fidèlement chaque règle.

L’autorisation est un autre plan. NACM, défini par RFC 8341, peut changer les nœuds accessibles à un rôle sans aucune modification de schéma. À l’inverse, une branche NBC peut rester hors de portée d’un rôle donné. Une conclusion de production exige donc une matrice NACM testée avec les identités réelles, pas une déduction depuis le diff.

Une conversion doit comptabiliser les pertes

Le projet indique que la sortie peut aider à convertir des données d’instance anciennes pour la nouvelle révision. Mais le convertisseur choisit encore ce qu’il supprime, renomme, normalise, complète par défaut, synthétise ou refuse. La conformité du résultat au nouveau schéma ne dit pas si l’intention initiale a survécu.

Le modèle de provenance et d’identité de contenu de RFC 9195 est utile ici. Un reçu de conversion devrait lier le hash de l’instance source, son identité de schéma, la version du convertisseur et ses règles. Il doit compter les nœuds supprimés, ajoutés, normalisés et rejetés, hasher la sortie, la valider contre le schéma compilé cible et documenter les invariants sémantiques ou les essais aller-retour.

Lorsque deux états anciens deviennent un même état nouveau, l’information perdue ne revient pas parce que la validation est verte. L’acceptation de cette perte appartient au propriétaire des données.

Les preuves suivantes viennent du code en marche

Après le diff viennent les essais d’implémentation : analyseurs ou serveurs indépendants lorsque l’interopérabilité compte, configurations et RPC représentatifs, erreurs, valeurs par défaut, encodages canoniques, négociation de features et rôles NACM concernés. Binaire, modules, options et vecteurs doivent être conservés pour reproduire le résultat.

Il faut ensuite éprouver l’ordre de déploiement. Une migration progressive crée des périodes mixtes : ancien client avec nouveau serveur, nouveau client avec ancien serveur, voisins chargés avec des features ou deviations différents. Le diff ne décide pas qui doit changer en premier, ne garantit pas la continuité de la télémétrie et ne prouve pas qu’un retour arrière saura lire les données écrites par la nouvelle version.

Enfin, RFC 8342 rappelle pourquoi running, intended et operational sont séparés. La configuration, l’intention appliquée et l’état observé peuvent diverger. Seule l’observation du déploiement peut établir la convergence, le silence des alarmes, la performance et l’effet extérieur.

La force de la révision 09 est d’offrir un reçu précis au contrôle de schéma. Elle reste intacte lorsque le reçu demeure la première étape d’une chaîne de preuves, au lieu d’en devenir la conclusion prématurée.

Sources

Sources primaires : YANG Schema Comparison, révision 09 ; fiche Datatracker ; YANG 1.1, RFC 7950 ; YANG Library, RFC 8525 ; NMDA, RFC 8342 ; NACM, RFC 8341 ; YANG Instance Data, RFC 9195 ; YANG Semantic Versioning, révision 28 ; YANG Module Versioning, révision 16. Chronologie : historique Datatracker.