Résumé

  • La révision 18 permet au serveur YANG-Push de sélectionner une période de publication à partir de conditions XPath mutuellement exclusives.
  • eval-interval détermine la fréquence d’évaluation ; en son absence, le serveur choisit une valeur minimale dépendante de son implémentation et de ses ressources.
  • adaptive-period-update ne peut être ni supprimée ni filtrée pour les destinataires concernés, mais elle ne peut pas être conservée dans un tampon de rejeu.
  • Un flux rejoué peut donc contenir les mesures postérieures sans la transition de contrôle qui explique leur rythme. Ce n’est pas une preuve de perte : c’est une limite de reconstruction.
  • Le texte vise une publication expérimentale et se trouve dans la file RFC Editor sans numéro RFC. Le prototype déclaré par un contributeur n’est pas une validation indépendante.

Ce que voit le collecteur qui revient

Imaginons un collecteur déconnecté pendant trente secondes. Avant la coupure, il recevait une mise à jour toutes les dix secondes. À son retour, les messages arrivent chaque seconde. Le contenu est valide, l’abonnement existe toujours et le serveur connaît la période active. Pourtant, la transition qui a justifié ce changement ne figure pas dans le rejeu du contenu ordinaire.

La révision 18 ne cache pas cette propriété. Elle classe adaptive-period-update parmi les notifications de changement d’état de l’abonnement. Le serveur doit la livrer aux destinataires concernés ; elle ne peut être abandonnée ni éliminée par un filtre. En même temps, elle ne peut pas être stockée dans les tampons de rejeu.

La règle protège une conversation de contrôle vivante. Elle ne promet pas qu’un nouveau consommateur pourra reconstruire l’histoire de cette conversation. Le présent est observable ; la cause passée peut dépendre d’un journal extérieur.

Une condition et deux cadences

L’abonnement contient au moins deux rythmes. eval-interval fixe la fréquence à laquelle l’expression XPath est examinée. period fixe la fréquence à laquelle le contenu sélectionné est publié lorsque la condition correspondante est vraie.

Si eval-interval n’est pas fourni, le serveur utilise l’intervalle minimal qu’il peut prendre en charge. Le projet précise que cette valeur est propre à l’implémentation et peut varier avec la mémoire ou le processeur disponibles. Ainsi, la politique déclarée par le client ne suffit pas à déduire toutes les occasions réelles d’évaluation.

Le calendrier de publication possède encore sa propre géométrie. anchor-time et period placent les mises à jour sur des limites déterminées. La valeur peut franchir un seuil, être lue lors de l’évaluation suivante, provoquer un changement de période puis n’apparaître dans un enregistrement qu’à la prochaine limite. Une date de basculement n’est donc pas une observation continue.

XPath choisit un rythme, pas un fait complet

eval-expression vise un nœud de données précis et doit devenir vrai ou faux selon les règles XPath 1.0. Une cible supprimée vaut faux. Un résultat non booléen est converti par la fonction booléenne. Plusieurs critères doivent être mutuellement exclusifs, sinon le serveur peut répondre multi-xpath-criteria-conflict.

La condition ne modifie pas le filtre qui détermine les données publiées. Elle ne fabrique pas non plus directement un événement. Elle choisit une période parmi celles qui ont été configurées.

La précision numérique compte. XPath 1.0 emploie des nombres à double précision IEEE 754 ; certaines valeurs int64, uint64 ou decimal64 n’y ont pas de représentation exacte. Le texte recommande donc un ensemble minimal de nœuds, des types comparables et des seuils constants. Une politique acceptée est syntaxiquement exploitable par ce serveur ; elle n’est pas automatiquement fidèle à l’intention de l’opérateur.

La notification explique, mais ne certifie pas

Le message de changement peut transporter l’identifiant d’abonnement, la nouvelle période, period-update-time, les données qui ont satisfait le critère et le filtre de sélection. C’est un reçu utile pour le destinataire en ligne.

Il reste borné. Les données satisfaisantes sont facultatives et utilisent anydata. Elles montrent ce que le serveur a présenté au moment du basculement, pas toutes les valeurs qui ont existé entre deux évaluations. La notification ne certifie ni la continuité du transport, ni l’absence de mesures manquées, ni l’absorption du surcroît par le client.

Un journal durable devrait relier la génération de politique, le contexte de noms XPath, la cadence d’évaluation effectivement appliquée, la valeur retenue, l’ancienne et la nouvelle période, le destinataire et le premier enregistrement reçu après la transition. Ce journal est une recommandation d’exploitation de BTW, pas une nouvelle exigence normative attribuée au projet.

Le débit supplémentaire est aussi une charge

Le but est raisonnable : réduire les données lorsque le réseau est calme et accroître la finesse d’observation lorsqu’un état le justifie. Mais une période plus courte augmente les messages, les écritures, les files et le travail d’analyse.

Le document expérimental demande précisément des résultats sur la stabilité, l’échelle, les ressources du serveur, les tampons du client, la charge de traitement, les rafales et les économies de transmission. Il identifie une forte densité de notifications de changement comme signe d’oscillation ou d’expression instable.

Cette densité est un indicateur, pas une cause. Un seuil mal choisi, une donnée bruitée, une cadence d’évaluation variable ou un système réellement instable peuvent produire une forme similaire. Une automatisation qui réagit à chaque accélération sans conserver le contexte peut transformer un problème d’observation en problème de contrôle.

Une étape éditoriale, pas un résultat terrain

Le Datatracker classe le document dans la file du RFC Editor et le destine à l’Experimental. Le texte archivé reste un Internet-Draft. Il ne faut ni inventer un numéro RFC ni confondre la progression éditoriale avec un résultat d’interopérabilité.

La section d’état mentionne un prototype fourni par un contributeur pour la télémétrie Wi-Fi. Elle avertit que l’IETF ne l’a pas vérifié et ne l’endosse pas. Le prototype rend l’expérience plausible ; il ne répond pas encore à la question de la récupération après coupure ni à celle du comportement à grande échelle.