Summary

  • La révision 14 de draft-ietf-netconf-yang-notifications-versioning permet de contraindre un abonnement YANG-Push par révision ou version sémantique et enrichit les avis de début et de modification avec le contexte des modules.
  • La révision, la version éventuelle et le yang-library-content-id décrivent le contexte publié. Ils ne certifient ni le décodeur chargé par le récepteur, ni l’ordre des éléments en file, ni la continuité des projections et décisions en aval.
  • Daniel Kade propose un dossier de relais de schéma télémétrique : empreintes exactes avant/après, dernier et premier enregistrements décodés, traitement des files et reprises, tests, suspensions en aval, responsable et clôture. Cette proposition n’est pas une exigence de l’IETF.

L’heure de maintenance ne suffit pas

Une équipe réseau fixe une fenêtre à deux heures. Le serveur redémarre à 02:04, le nouvel ensemble de modules est actif à 02:06, l’avis de modification porte un eventTime à 02:06:12 et le collecteur le reçoit à 02:06:15. Son nouveau décodeur n’entre pourtant en service qu’à 02:06:21. Entre-temps, des messages attendent dans deux files distinctes. À 02:07, le tableau d’exploitation repasse au vert.

Quel instant désigne le vert ?

La fenêtre planifiée est une intention. Le changement côté éditeur est un état local. L’heure de l’avis décrit l’événement déclaré. L’arrivée au récepteur prouve une réception. L’activation du décodeur décrit un autre composant. L’écriture durable et la reprise d’une décision automatique surviennent encore plus tard.

Une gouvernance précise refuse de choisir arbitrairement l’une de ces heures pour parler d’un « relais achevé ». Elle conserve le lien entre elles et nomme les écarts.

Le progrès réel de la révision 14

Le projet répond à une difficulté concrète. Sans l’extension proposée, le récepteur d’un flux YANG-Push doit interroger ietf-yang-library après un avis de changement d’état afin de savoir si la sémantique des modules concernés a évolué. Cette requête supplémentaire peut retarder l’interprétation et observer un état déjà différent de celui qui motivait l’avis.

Le module ietf-yang-push-revision introduit d’abord une politique d’abonnement. Le client peut nommer un module et demander une révision déterminée ou une version sémantique compatible. Si le serveur ne la prend pas en charge, il renvoie une erreur RPC. Si la contrainte d’un abonnement configuré ne correspond plus à sa bibliothèque YANG, l’éditeur ne doit plus transmettre de notifications.

Le projet enrichit ensuite subscription-started et subscription-modified. L’avis peut porter le nom de chaque module concerné, sa révision, sa version sémantique lorsqu’elle existe, ainsi que l’identifiant de contenu de la bibliothèque. Le récepteur n’est plus obligé de partir d’un identifiant d’abonnement inchangé pour deviner un contexte sémantique peut-être différent.

Cette visibilité compte. Elle permet de refuser un contexte non accepté et de repérer une mutation pendant la vie d’un abonnement configuré. Elle ne constitue pas une transaction distribuée entre l’éditeur, le transport, le collecteur, le stockage et les usages analytiques.

L’identifiant de contenu a un périmètre propre

Le yang-library-content-id représente les informations courantes de la bibliothèque YANG d’un serveur. Il est propre à l’implémentation. Une nouvelle valeur indique qu’un ou plusieurs modules ont changé sur ce serveur ; elle ne dit pas nécessairement que le chemin sélectionné par l’abonnement a changé.

Il ne faut donc pas le rebaptiser « empreinte du schéma du flux ». Une empreinte calculée par l’opérateur sur les octets exacts des modules, leurs imports, fonctionnalités et déviations répond à une question différente. Les deux valeurs sont utiles si leur origine et leur portée restent séparées.

La liste des modules dans l’avis rapproche le contexte du flux. Mais elle ne prouve pas que le collecteur possède les mêmes octets, que les dépendances ont été résolues de la même façon ou que la base de données a migré sa représentation. Elle ne teste pas non plus les règles qui calculent un seuil, une capacité ou une alerte à partir de ces données.

Une identité de schéma est une référence. Un résultat de décodage est une preuve d’exécution.

Un avis n’est pas une barrière de file

Prenons quatre éléments : A et B sont produits sous l’ancien schéma, C annonce la nouvelle révision, D est produit sous le nouveau. L’ordre logique A-B-C-D n’oblige pas chaque composant à les traiter ainsi. Des canaux ou ouvriers différents peuvent donner A-C-B-D. Une reprise peut livrer B après D. Le contrôle peut recevoir C alors que les données antérieures restent comprimées dans un tampon.

La révision 14 n’a pas besoin de transformer l’avis en mécanisme universel de vidage de files. Son champ normatif peut rester étroit. C’est l’exploitant qui doit éviter de confondre l’annonce et la clôture du passage.

La confusion est tentante, car l’avis est net et structuré. Il porte un identifiant d’abonnement, un filtre, des modules et une heure. Un système d’audit peut facilement prendre cette ligne comme coupure. Pourtant, si le collecteur ne sait pas attribuer B à l’ancien décodeur, la netteté de C ne répare pas l’ambiguïté.

La compatibilité se vérifie chez le consommateur

Le modèle classique de révisions YANG attend des changements compatibles. Le travail NETMOD sur les versions sémantiques sait aussi signaler les changements non rétrocompatibles. Cette discipline réduit l’incertitude, mais elle ne remplace pas l’essai d’un consommateur particulier.

Un ajout compatible peut révéler un défaut de parseur. Une fonctionnalité activée peut modifier l’ensemble réellement offert. Une déviation peut retirer ce qu’un modèle aval supposait présent. Une unité ou une condition de présence interprétée de travers peut laisser la validation syntaxique au vert tout en faussant un calcul.

Il faut donc distinguer la qualification du changement par son auteur, l’acceptation par la politique d’abonnement et l’observation d’un bon résultat chez le récepteur. Trois propositions, trois sources de preuve.

Quand l’absence de messages devient ambiguë

La règle d’arrêt en cas de non-correspondance de version protège le souscripteur. Un éditeur ne doit pas continuer comme si la contrainte n’existait pas. Mais le silence obtenu ressemble à d’autres silences : aucune variation sur un abonnement « on-change », panne de transport, collecteur indisponible, changement d’autorisation ou filtre devenu vide.

Un tableau qui transforme le silence en « état stable » neutralise la protection. Un centre d’exploitation qui transforme tout silence en incompatibilité produit de faux incidents. La preuve utile doit établir la dernière attente valide, la cause observée de l’arrêt, l’acteur qui l’a constatée et les conditions de reprise.

Le dossier de relais à conserver

Le dossier proposé ne recopie pas le flux. Il assemble un petit nombre de références contrôlées par des acteurs différents :

  • identité de l’éditeur, identifiant d’abonnement, filtre exact et contrainte de version ou de révision ;
  • identifiant de contenu côté serveur et, séparément, empreintes locales des ensembles exacts de modules avant/après ;
  • empreinte de l’avis authentifié, heure de l’événement, heure de réception et heure de traitement ;
  • dernier élément correctement décodé sous l’ancien ensemble et premier sous le nouveau ;
  • éléments de séquence, de reprise et de resynchronisation, ainsi que les intervalles mis en quarantaine, perdus ou retraités ;
  • versions du décodeur et du mappeur de stockage, jeux d’essai et résultats ;
  • alertes, automatismes et modèles suspendus, recalculés ou acceptés avec exception ;
  • propriétaire de la décision, incertitude restante, cible de retour arrière et preuve de clôture.

« Dernier » et « premier » doivent rester honnêtes : il s’agit des éléments que le collecteur peut attribuer et décoder, pas nécessairement des limites exactes de production chez l’éditeur. Si les preuves de transport ne réduisent pas l’écart, le dossier conserve cet écart.

La sécurité n’absorbe pas la sémantique

Le projet demande des transports sûrs, une authentification mutuelle et des contrôles NACM adaptés, car les nœuds permettant de modifier la politique de version sont sensibles. Un changement non autorisé peut interrompre le flux ou imposer un contexte inattendu.

Ces protections établissent qui peut agir et préservent l’intégrité de l’échange. Elles ne prouvent pas le vidage d’une file, le chargement d’un décodeur ou la validité d’une règle métier. Ajouter ces conclusions à une preuve d’authentification reviendrait à donner au protocole la responsabilité d’un système qu’il n’observe pas.

Le bon usage d’un avis de schéma est de déclencher une pause proportionnée : identifier les octets exacts, tester le décodeur, réconcilier les files, comparer les projections et libérer séparément les usages qui ont satisfait leur seuil de preuve. Un changement sans effet sur le filtre peut être clos vite. Une rupture de sémantique alimentant une commande automatique mérite une barre plus haute.

L’avis rend le changement visible. Le dossier de relais rend la reprise défendable.

Sources