Résumé

  • YANG 2.0 est conçu pour cohabiter avec YANG 1 et 1.1. Les règles restent asymétriques : la version 2.0 peut importer une ancienne version par révision, pas l'inverse.
  • L'exception concernant un import sans révision empêche qu'une mise à jour de B oblige tout le graphe à migrer. Elle ne démontre ni le choix du client, ni un schéma effectif commun, ni l'interopérabilité en production.

Prenons un changement banal. B vient d'être réécrit en YANG 2.0. A reste en YANG 1.1 et importait B sans préciser de révision. Le serveur redémarre, A et B figurent dans l'inventaire et le contrôle de changement passe au vert. Ce résultat peut être conforme au projet. Il ne permet pourtant pas d'affirmer que deux clients ont téléchargé les mêmes octets, retenu la même révision de B et construit le même contrat.

Le texte revision 00, daté du 6 juillet 2026, indique que YANG 2.0 ne rend obsolètes ni RFC 6020 ni RFC 7950 et qu'un modèle complet peut associer plusieurs versions du langage. Le Datatracker de l'IETF le classe comme Internet-Draft actif du groupe NETMOD. La page de garde vise la filière Standards Track ; ce n'est encore ni un RFC, ni une preuve d'implémentation.

Une asymétrie faite pour migrer

La section 12 interdit à un module YANG 2.0 d'inclure autre chose que des sous-modules 2.0. Un module 1 ou 1.1 ne peut pas inclure un sous-module 2.0. De même, un module ancien ne peut pas importer un module 2.0 en nommant sa révision. En revanche, un module 2.0 peut importer par révision un module 1 ou 1.1.

Il ne s'agit donc pas d'une compatibilité symétrique. Le nouveau langage peut s'appuyer explicitement sur l'ancien ; l'ancien ne peut pas créer une dépendance explicite vers une révision du nouveau.

Reste le cas de A. Lorsque A, écrit en 1/1.1, importe B sans révision et que B évolue vers 2.0, le serveur peut implémenter A et B simultanément. Il doit annoncer les modules selon les règles d'implémentation et devrait aussi annoncer A avec la dernière révision de B encore exprimée en YANG 1 ou 1.1. Le motif est opérationnel : éviter que le passage de B à 2.0 n'entraîne la réécriture de A, puis de tous ses dépendants.

Cette retenue préserve le choix local. Elle rejoint l'idée de spécification initiale minimale et d'adoption volontaire formulée par Lu Heng : une évolution devient réelle pour ceux qui peuvent la valider et l'exécuter, pas parce qu'un graphe entier est sommé de basculer. Mais une adoption distribuée exige une preuve distribuée.

Une annonce n'est pas un schéma compilé

La section 5.6.4 précise qu'un serveur ne doit pas implémenter plusieurs révisions du même module. Elle distingue toutefois les modules implémentés de ceux utilisés uniquement pour l'import. RFC 8525 formalise cette description avec les module sets, les rôles implemented/import-only, les features, les deviations et un identifiant de changement.

Cet inventaire prouve ce que le serveur déclare à un instant donné. Il peut documenter la présence de A, les révisions de B répertoriées et leur rôle. Il ne prouve pas le fichier effectivement lu par un client, la décision prise pour un import sans révision, la version du parseur, ni l'identité du schéma effectif produit.

Les travaux voisins ne comblent pas automatiquement ce vide. Le module versioning améliore l'identité des révisions ; Semver exprime des contraintes ; les packages décrivent un ensemble ; la comparaison de schémas qualifie les changements ; le nom de fichier aide à repérer un artefact. Aucun de ces éléments ne remplace la trace de résolution et le résultat compilé.

Une chaîne de preuves non compressible

Une validation sérieuse doit conserver, dans l'ordre :

  1. les octets exacts de chaque module et sous-module, leur provenance, namespace, version du langage, révision et hash ;
  2. la fermeture complète des import/include et chaque choix effectué lorsqu'aucune révision n'était indiquée ;
  3. l'instantané YANG Library, les rôles de conformité, features, deviations et l'identité du module set ;
  4. le parseur ou compilateur, ses diagnostics et l'empreinte normalisée du schéma effectif ;
  5. des instances valides et volontairement invalides exécutées contre ce schéma gelé ;
  6. les traces de résolution de plusieurs clients indépendants ;
  7. les tests de lecture, édition, RPC, action, notification, panne et retour arrière ;
  8. le comportement en exploitation, en distinguant configuration intended et état operational comme le fait RFC 8342.

Chaque niveau apporte une information nouvelle. La déclaration, l'artefact résolu, la validation et l'exploitation appartiennent à des couches de réalité liées mais non substituables.

Le mérite du projet YANG 2.0 est ici précis : rendre possible une transition sans conversion générale. Sa portée s'arrête avant la preuve qu'un client donné applique le même contrat qu'un autre.

Sources