Résumé

  • draft-ietf-netconf-yang-notifications-versioning-16 permet de contraindre un module nommé par date de révision exacte ou par version sémantique compatible, puis d’enregistrer ses coordonnées lors des changements d’état de la souscription.
  • Le content-id de YANG Library couvre un périmètre plus large : il peut signaler la modification d’une dépendance importée sans désigner cette dépendance ni démontrer une incompatibilité.
  • Une reprise sûre exige donc de relier la notification, le nouvel inventaire YANG, la fermeture des dépendances et la validation du décodeur ; la stabilité du seul module direct ne suffit pas.

La stabilité d’une interface est souvent déduite d’un nombre qui n’a pas changé. Dans un flux de télémétrie piloté par YANG, ce raccourci peut devenir une erreur d’interprétation : le module directement souscrit conserve sa révision, tandis qu’un type importé évolue sous lui.

La révision 16 de YANG-Push Notification Versioning traite ce cas. YANG-Push sait déjà établir une souscription et pousser les mises à jour, mais son mécanisme historique ne transporte pas la révision du module souscrit. Après une mise à niveau du nœud, le Receiver peut donc appliquer un ancien modèle à un nouveau flux sans recevoir l’avertissement attendu.

Le module proposé, ietf-yang-push-revision, ajoute une contrainte à la demande. Le client peut exiger une date de révision YANG précise ou la version la plus récente compatible avec une version sémantique donnée. Si le Publisher ne peut pas la satisfaire, il renvoie invalid-value accompagné de revision-unsupported, version-unsupported ou incompatible-revision-and-version. Le refus devient ainsi explicable, plutôt qu’un simple échec de souscription.

La preuve de départ est attachée à l’état. subscription-started et subscription-modified sont enrichis avec le module concerné, sa révision, sa version éventuelle et le yang-library-content-id. Une modification de révision ou de version d’un module suivi constitue un changement de politique de souscription et doit provoquer subscription-modified. Après redémarrage, si la bibliothèque du Publisher ne satisfait plus les exigences d’une souscription configurée, celui-ci doit envoyer subscription-terminated.

Cette précision ne supprime pourtant pas la profondeur du graphe YANG. L’exemple central du texte souscrit à /ietf-interfaces:interfaces. La notification décrit la coordonnée d’ietf-interfaces. Si ce module change, sa coordonnée et le content ID peuvent bouger ensemble. Mais si seule la dépendance importée ietf-yang-types change, la révision directement visible reste identique. Le Receiver ne sait qu’un état de schéma a changé qu’en observant le content ID global.

Ce second signal vient de YANG Library. Il représente, selon l’implémentation, les informations actuelles de la bibliothèque sur un serveur donné. Ce n’est ni une empreinte portable entre équipements, ni un résumé sémantique. Sa modification ne dit pas quel module a changé, si le changement atteint le chemin souscrit, ni si le décodeur existant produira une erreur.

Elle peut même résulter d’un ajout sans rapport avec la souscription. Arrêter le traitement à chaque variation reviendrait à donner à toute évolution de la bibliothèque un pouvoir sur la disponibilité. Ignorer la variation parce que la révision directe est stable expose au risque inverse : faire passer des données issues d’un graphe différent dans un ancien interpréteur.

Les deux preuves ne sont donc pas redondantes. La coordonnée du module décrit une lignée sélectionnée et pertinente pour le chemin. Le content ID constate que le reçu plus large de la bibliothèque n’est plus le même. Aucun des deux ne certifie qu’une requête stockée, un modèle de base de données ou une automatisation métier demeure correct.

Une chaîne exploitable commence par l’identité du Publisher et l’annonce de sa capacité. Elle conserve l’identifiant local de souscription, le filtre ou le chemin, les contraintes acceptées, les coordonnées initiales et le content ID initial. Lors d’un changement d’état, le Receiver compare les deux périmètres. Si le content ID a bougé, il récupère la nouvelle YANG Library, reconstitue les imports et inclusions pertinents, sélectionne ou teste un décodeur, puis seulement autorise la suite du traitement.

Les messages déjà mis en mémoire tampon doivent rester liés au reçu sous lequel ils ont été produits. Une bibliothèque plus récente ne doit pas réinterpréter silencieusement des octets antérieurs. La validation du décodeur, la compatibilité du stockage, l’acquittement des consommateurs et l’autorisation de l’automatisation sont autant de preuves supplémentaires.

Le droit de modifier les contraintes mérite la même rigueur. Ces données peuvent être créées, modifiées ou supprimées ; le projet exige un contrôle d’accès approprié, dont NACM fournit le modèle standard. Relâcher une contrainte revient à changer l’état de schéma que l’organisation accepte de consommer.

Datée du 17 septembre 2026, la révision 16 apparaît dans son historique Datatracker en IETF Last Call jusqu’au 29 septembre, sans date de téléconférence dans l’enregistrement figé. La validation YANG du 27 septembre affiche zéro erreur et zéro avertissement. Elle valide le module soumis avec les outils indiqués, pas son comportement en production. Le texte intégral reste un Internet-Draft modifiable.

RFC 8639 définit les notifications souscrites, RFC 8641 leur extension YANG-Push et RFC 7950 les règles de révision et d’import. Les projets YANG Module Versioning et YANG Semantic Versioning sont eux-mêmes encore en chantier ; RFC 9196 apporte un autre cadre de sélection. Une mention « compatible » reste une relation déclarée, pas la preuve qu’un consommateur particulier a survécu au changement.

Sources