Résumé

  • Un projet actif du groupe NETCONF ajoute aux abonnements YANG-Push une contrainte de révision exacte ou de version sémantique compatible, puis expose la version du module et l’identifiant de contenu de la bibliothèque YANG dans les notifications de cycle de vie.
  • Ces reçus rendent une dérive de schéma visible, mais ne démontrent ni que les dépendances importées sont restées compatibles, ni que le collecteur a chargé le bon modèle, ni que la chaîne de décision a conservé son sens et son autorité.

Le piège d’une télémétrie moderne n’est pas toujours le silence. Le silence déclenche une alarme, ouvre un incident et mobilise rapidement un propriétaire. Le flux qui continue, lui, rassure. Il permet à une modification du contrat de passer pour une simple continuité d’exploitation.

Dans YANG-Push, un abonnement persistant décrit les données à publier et la manière de les publier. Leur interprétation dépend toutefois d’un autre ensemble vivant : modules YANG, révisions, imports, identités, types et déviations effectivement exposés par l’équipement. Une mise à niveau peut préserver l’abonnement tout en remplaçant une partie de cet ensemble. Le transport reste alors fidèle à sa mission tandis que le consommateur raisonne avec une carte devenue ancienne.

Le document draft-ietf-netconf-yang-notifications-versioning-16, daté du 17 septembre 2026, traite précisément ce décalage. Le Datatracker le présente comme un Internet-Draft actif du groupe NETCONF, soumis à l’IESG en vue d’un Proposed Standard, avec une Last Call se terminant le 29 septembre. Ce statut doit rester visible : il ne s’agit ni d’un RFC définitif, ni d’un certificat de conformité, ni d’une preuve de déploiement.

La proposition apporte néanmoins un mécanisme opérationnel important. Elle permet de demander une révision déterminée ou une version sémantique compatible d’un module, puis d’inscrire l’état de version dans les événements qui démarrent, modifient ou terminent l’abonnement. Une hypothèse tacite devient ainsi un élément observable.

Deux façons d’encadrer l’évolution

La première contrainte désigne une date de revision. Elle répond à un besoin de reproduction : ce module précis, dans cette révision précise, doit soutenir l’abonnement. Si le diffuseur ne peut pas la fournir, la bonne réponse n’est pas une adaptation silencieuse, mais un refus revision-unsupported.

La seconde contrainte désigne une version sémantique et demande la version compatible la plus récente. Elle accepte qu’un module évolue à l’intérieur d’une frontière déclarée. Si aucune version acceptable n’existe, le diffuseur renvoie version-unsupported. Si les contraintes de révision et de version se contredisent, incompatible-revision-and-version rend le conflit explicite. Ces erreurs appartiennent à la classe applicative invalid-value.

Le choix entre révision fixe et compatibilité déclarée n’est pas un classement entre prudence et modernité. Une révision exacte facilite l’audit, mais peut arrêter un service lors d’une mise à niveau planifiée. Une plage compatible réduit les coordinations, mais exige de croire que la compatibilité a été correctement déclarée et qu’elle couvre l’usage particulier du consommateur. La décision doit être prise pour chaque classe d’automatisation.

Les abonnements configurés ajoutent une difficulté temporelle. Ils survivent au redémarrage. Après celui-ci, le diffuseur doit vérifier la contrainte enregistrée contre sa bibliothèque YANG actuelle. Si elle ne correspond plus, le projet impose une notification subscription-terminated. La persistance de la configuration n’accorde donc pas un droit à la persistance du sens.

Les notifications positives deviennent elles aussi probantes. subscription-started et subscription-modified peuvent porter le nom du module, sa révision, sa version éventuelle et le content-id de la bibliothèque YANG. Une modification de révision ou de version compte comme un changement de politique d’abonnement et doit produire subscription-modified. Le consommateur reçoit enfin un repère avant que l’erreur n’apparaisse sous la forme d’une valeur mal décodée.

La révision annoncée ne charge aucun fichier

Une révision correcte au niveau du protocole n’installe pas le bon schéma dans le collecteur. Elle ne remplace pas une liaison générée, ne redémarre pas un worker, ne purge pas un cache et ne rejoue pas les messages déjà en attente. Elle atteste seulement ce que le diffuseur associe au module contraint.

Cette limite paraît évidente, mais les chaînes industrielles l’effacent. Le registre de schémas peut contenir le bon fichier alors que le processus actif conserve une ancienne représentation. Un parseur peut accepter une nouvelle identité tandis qu’une colonne de base de données la transforme en valeur inconnue. Une transformation peut produire un champ renommé que le moteur d’alerte ne lit jamais. Tous les composants restent verts ; le sens, lui, s’est divisé.

La preuve exploitable relie donc plusieurs artefacts : identité et build du diffuseur, identité et build du récepteur, identifiant de l’abonnement, contrainte demandée, révision effective, instantané de la bibliothèque YANG, empreinte du module chargé, version du décodeur, version des transformations et résultat d’un corpus rejoué. La révision du protocole est une pièce de cette chaîne, pas son substitut.

Cette discipline reprend la primauté du code en fonctionnement défendue par Lu Heng. La norme coordonne ; seul le système observé montre ce qui a réellement tourné. Le Datatracker indiquait le 28 septembre zéro erreur et zéro avertissement lors de la validation YANG du module ietf-yang-push-revision. C’est une preuve utile sur l’artefact du modèle. Elle ne valide ni un routeur, ni un collecteur, ni une décision réseau.

« Compatible » reste une hypothèse à éprouver

La version sémantique offre un langage pour distinguer évolution rétrocompatible et rupture. Les travaux YANG sur la gestion de versions et SemVer définissent comment publier cette histoire. Ils ne peuvent connaître chaque dépendance locale d’un consommateur.

Un ajout réputé compatible peut révéler un défaut dans un générateur de code. Une nouvelle valeur d’énumération peut traverser le parseur et échouer dans une règle métier. Un nœud facultatif peut modifier la manière dont un système calcule une absence. Une application peut dépendre d’un comportement jamais inscrit dans le modèle. La compatibilité du module autorise un essai ; elle n’enregistre pas le succès de l’essai.

Le test pertinent suit les chemins réellement consommés. Il identifie les types importés, les identités utilisées, les déviations propres au diffuseur et les champs qui déclenchent une action. Il rejoue des valeurs normales et des frontières contre le build effectivement déployé. Une version compatible qui échoue ce corpus doit rester en quarantaine, même si son étiquette est impeccable.

À l’inverse, toute évolution ne justifie pas un arrêt général. Une modification sans effet sur les chemins sélectionnés peut être acceptée après un diff de dépendances et un rejeu concluant. Le protocole fournit le signal commun minimal ; la politique locale décide, de manière visible, si ce signal entraîne poursuite, pause, examen ou terminaison.

Le changement peut venir d’un module importé

Le module directement cité n’est pas seul à définir les valeurs. YANG permet d’importer des typedefs, groupings et identités. Une dépendance peut changer sans que la révision du module sélectionné bouge. Le reçu direct reste stable tandis que l’arbre de signification se transforme sous lui.

L’identifiant content-id de la bibliothèque YANG élargit le champ d’observation. RFC 8525 le définit comme un identifiant propre à l’implémentation pour le contenu actuel de la bibliothèque. S’il change, le récepteur sait que l’inventaire de schémas du dispositif a changé et peut rechercher une dépendance indirecte.

Ce signal est volontairement grossier. Il peut changer à cause d’un module sans rapport avec l’abonnement. Il n’indique pas lequel a bougé. Deux dispositifs ne doivent pas nécessairement calculer le même identifiant pour un contenu comparable. Sa variation est une alarme ; elle n’est ni un diagnostic, ni une déclaration d’incompatibilité.

Le bon enchaînement consiste à conserver l’ancien instantané, récupérer le nouveau, calculer un diff tenant compte des imports, isoler les nœuds touchés puis exécuter les tests du consommateur. Fermer automatiquement tous les abonnements au moindre changement créerait une fragilité globale. Ignorer le signal recréerait le défaut initial. La gouvernance se trouve entre ces deux automatismes.

Situer la frontière pendant la transition

Recevoir subscription-modified ne migre pas les travailleurs. La notification peut croiser des données encore en file d’attente sous l’ancien schéma. Des consommateurs parallèles peuvent l’observer à des instants différents. Une base peut enregistrer le nouvel identifiant après avoir écrit plusieurs valeurs avec l’ancien décodeur.

Il faut donc matérialiser une frontière : dernière notification traitée sous l’ancien artefact, événement de cycle de vie, premier élément accepté sous le nouveau. Chaque enregistrement à enjeu devrait pouvoir être relié à l’empreinte de schéma et au build qui l’a interprété. Lorsque l’ordre ne peut pas être établi, la chaîne d’action doit se mettre en pause ou isoler les éléments ambigus.

subscription-terminated possède une autre portée. Il prouve que le diffuseur a refusé de reprendre un abonnement devenu incompatible après redémarrage. Il ne prouve pas que les anciennes files ont été vidées, que les tâches dérivées ont été annulées ou que les actions basées sur des données en cache se sont arrêtées. Ces conséquences doivent avoir leurs propres reçus.

La capacité yang-push-module-revision-supported est elle aussi une annonce, non une démonstration. Elle permet au client de savoir que le diffuseur prétend exporter la révision ou la version dans les événements. Seuls des essais de mise à niveau, de redémarrage et de défaut montrent que cette promesse tient sur le flux réel.

Un flux vivant ne dispose d’aucun pouvoir emprunté

Le suivi traditionnel mesure le débit, le retard, les reconnexions et l’état de l’abonnement. Ces mesures répondent à une question légitime : le mécanisme de livraison fonctionne-t-il ? Elles ne répondent pas aux questions suivantes.

Le diffuseur expose-t-il le jeu de modules attendu ? La contrainte a-t-elle été acceptée contre ce jeu ? Le récepteur a-t-il chargé les artefacts correspondants ? Les valeurs ont-elles été décodées et transformées sans perte de sens ? La politique locale autorise-t-elle cette information à déclencher une décision ? L’identité qui agit possède-t-elle le droit nécessaire ? L’opération a-t-elle été exécutée ? Son effet sur le réseau a-t-il été observé ?

Chaque question appartient à une couche de réalité distincte. La livraison ne prouve pas l’interprétation. L’interprétation ne donne pas l’autorité. L’autorisation ne prouve pas l’exécution. Une configuration acceptée ne prouve pas l’effet final. Les relier par un identifiant de transaction est utile ; fusionner leurs conclusions serait une erreur.

Cette séparation améliore aussi le diagnostic. Un content-id modifié suivi d’un rejeu identique peut conclure à un changement sans effet. Une révision inchangée accompagnée de décisions divergentes oriente l’enquête vers le consommateur. Une action techniquement correcte mais non autorisée relève de la gouvernance, pas du versionnement YANG.

La contrainte de version est une configuration sensible

Modifier la révision ou la plage compatible influence les données que l’automatisation acceptera. Un acteur peut épingler un modèle ancien, provoquer une terminaison au prochain redémarrage ou élargir une plage au-delà des tests réalisés. Ce champ n’est pas une préférence d’affichage.

NETCONF et RESTCONF doivent continuer d’utiliser un transport sûr et une authentification mutuelle adaptée. NACM apporte un contrôle d’accès sur les données de configuration et d’état. Il convient d’enregistrer l’identité, la méthode, l’ancienne et la nouvelle contrainte, l’abonnement concerné et l’approbation associée. L’automate qui constate l’échec ne devrait jamais pouvoir assouplir seul la contrainte afin de rétablir un indicateur vert.

Le droit de souscrire n’est pas non plus le droit d’agir. Une mesure peut conduire à une modification de routage ou de capacité. Cette décision doit disposer d’une politique et d’une autorisation séparées, même lorsque le flux et son schéma sont parfaitement valides.

Les implémentations annoncées doivent encore se rencontrer

Le projet mentionne des travaux déclarés par les auteurs pour Huawei VRP, 6WIND VSR et Cisco IOS XR, sur des sous-ensembles différents. Ces informations montrent un intérêt et alimentent le travail du groupe. Elles ne constituent pas un test indépendant d’interopérabilité.

Une qualification sérieuse vérifie les trois erreurs définies, la sélection de la version compatible, la terminaison après redémarrage, la modification en service, la préservation du nom et de la version du module, ainsi que le comportement lorsque seul un import change. Elle injecte aussi perte, duplication et réordonnancement des notifications de cycle de vie. Elle capture le trafic et l’état durable du récepteur.

L’essai doit utiliser les builds appelés à entrer en production. Deux lignes dans une annexe ne prouvent pas que deux composants indépendants s’accordent sur la même frontière de transition. L’interopérabilité commence lorsque le diffuseur, le récepteur et la chaîne de décision produisent des reçus compatibles sur le même événement.

Préparer une mise à niveau réversible

Avant le changement, archiver la bibliothèque YANG, les modules, les liaisons générées et le corpus de rejeu. Calculer le diff du jeu candidat en suivant les imports. Tester révision exacte, révision absente, version incompatible, première rupture sémantique, changement direct, changement indirect et variation sans rapport du content-id.

Pendant la bascule, enregistrer l’événement de cycle de vie et sa position dans le flux. Ne pas déduire le détail d’un nouveau content-id : récupérer l’inventaire. Suspendre les actions à fort impact jusqu’à ce que le récepteur ait chargé et testé les nouveaux artefacts. Une incompatibilité doit échouer de manière visible, jamais par substitution silencieuse.

Après la bascule, comparer les objets décodés, les transformations, les décisions et les effets. Vérifier les files anciennes et la capacité de retour arrière des deux côtés. Le critère n’est pas la survie de l’abonnement, mais la continuité démontrée du contrat pertinent.

Le projet de versionnement rend observable une fissure qui existait déjà. Il ne promet pas de la réparer à la place de l’opérateur. Sa bonne utilisation consiste à recevoir le signal, à produire la preuve d’exécution et à refuser qu’un flux continu se fasse passer pour un sens continu.

Sources