Résumé

  • La révision 14 du projet OPSAWG associe aux données de télémétrie le contexte de la plateforme, de l’abonnement et de la période réellement employée. Elle reste un Internet-Draft actif, non un RFC ni une preuve de déploiement.
  • Le texte reconnaît une limite décisive : le manifeste est collecté avec la même fiabilité que les données, puisqu’il est lui-même une donnée. Il rend un point reçu interprétable, mais ne certifie pas tout ce qui aurait dû être reçu.
  • Pour une décision importante, l’opérateur devrait conserver hors de ce domaine de panne unique un reçu de continuité : intention d’abonnement, cadence, séquence, arrivée au collecteur, versions du manifeste, coupures de session, origine d’une reconstruction, traitement de la lacune et responsable nommé.

La scène paraît banale. Une série de compteurs s’interrompt, puis reprend. Les points de 11 h 03 et de 11 h 05 portent le même identifiant de plateforme et le même identifiant d’abonnement. La dernière version disponible du manifeste indique le même logiciel. Pourtant, le point de 11 h 04 n’existe pas dans la base.

L’écran n’affiche pas une cause. Il affiche une absence. La plateforme a peut-être allongé la période de collecte. Un paquet a pu se perdre. Le collecteur a pu redémarrer. Une fin d’abonnement, un changement de filtre ou une mise à jour du manifeste ont pu disparaître en même temps. Avec une collecte « on-change », rien n’a peut-être changé. Ces hypothèses n’ont pas la même conséquence, mais elles produisent le même espace blanc.

Le projet de manifeste améliore fortement le sens des observations présentes. La gouvernance commence là où l’on voudrait faire parler l’observation absente.

Le progrès réel : ne plus confondre une valeur et son contexte

Une donnée de télémétrie n’est pas autonome. Un compteur ne dit pas quelle plateforme l’a produit, avec quelle version, selon quel filtre, à quel rythme ni sous quelle capacité de collecte. Une série peut rester techniquement lisible tout en devenant analytiquement trompeuse.

draft-ietf-opsawg-collected-data-manifest-14 organise ce contexte. Le Platform Manifest normatif caractérise la plateforme émettrice. Le Data Collection Manifest décrit la manière et le moment de la mesure ; il demeure un exemple non normatif, notamment parce que le montage de schéma nécessaire à la conception n’est pas disponible. Cette asymétrie compte : la forme la plus proche de l’identité de plateforme est standardisée, tandis que le détail de la collecte reste plus difficile à généraliser.

Le projet ajoute aussi current-period à YANG-Push. La feuille, en lecture seule, expose la période effectivement utilisée. Une plateforme surchargée peut augmenter l’intervalle au lieu de rejeter la collecte demandée. Pour l’analyste, savoir que la mesure est passée de dix à soixante secondes évite d’attribuer trop vite l’espacement à une perte ou à un défaut.

Le manifeste doit accompagner les données, les suivre vers le stockage et être actualisé lorsque la plateforme ou l’abonnement change. Il devient une série temporelle. C’est plus rigoureux qu’une fiche d’inventaire actuelle appliquée rétrospectivement à des mois de mesures.

La période actuelle n’est pas le journal complet des périodes passées

La feuille current-period répond à une question précise : quel intervalle la plateforme déclare-t-elle employer dans son état courant ? Elle ne prétend pas être une chronologie indépendante et exhaustive de toutes les transitions.

Si le changement de période arrive avant les mesures espacées, l’interprétation est solide. S’il arrive après la lacune, on ignore le moment exact du basculement. S’il disparaît avec les données, la version ultérieure ne peut pas prouver qu’aucun état intermédiaire n’a existé. Le mécanisme devient historique seulement si la collecte et le stockage de ses changements sont complets.

Or le projet énonce franchement que la fiabilité de collecte du manifeste est celle de la collecte des données. Cette proximité est économique : l’opérateur réutilise le même système, les mêmes abonnements et le même stockage. Elle est aussi une dépendance commune. Quand le canal d’observation tombe, l’explication de ce canal peut tomber avec lui.

Il faut donc séparer le sens et la continuité. Le manifeste répond : « Que signifie cette valeur reçue ? » Un contrôle distinct répond : « Pourquoi attendions-nous une valeur ici, et quelle preuve montre ce qui s’est passé lorsqu’elle n’est pas arrivée ? »

Le raccord temporel fonctionne sur ce que la base connaît

Pour retrouver le bon contexte, le projet utilise trois coordonnées : l’heure d’envoi, l’identifiant de la plateforme et celui de l’abonnement. La base sélectionne le Platform Manifest le plus récent avant l’horodatage, puis le Data Collection Manifest le plus récent correspondant à la plateforme et à l’abonnement.

Ce raccord est clair et praticable. Il ne certifie pas l’absence d’une version perdue. Si M1 est conservé à 11 h 00 et M3 à 11 h 10, la recherche pour 11 h 07 retourne logiquement M1. Une version M2 émise à 11 h 05 mais jamais stockée resterait invisible. Elle aurait pourtant pu modifier le filtre, la cadence ou l’état de l’abonnement.

L’identifiant lui-même a une frontière. Le projet note que le nom d’hôte décrit souvent un rôle plutôt qu’un matériel particulier. Il signale aussi qu’une exigence de conformité — prendre en charge au moins une des fonctions yang-catalog ou ietf-system — ne peut pas être imposée par le schéma. Un module peut donc valider sans fournir beaucoup plus que son identifiant.

Validation du schéma, utilité du contexte et complétude historique ne sont pas des synonymes. Une institution responsable publie le verdict exact qu’elle possède, pas celui qu'un outil de validation semble suggérer.

Redémarrage, terminaison et nouvelle époque

Le manifeste de plateforme devrait rester relativement stable durant une session. Après un redémarrage, la notification subscription-terminated peut marquer la rupture ; lorsque l’abonnement est rétabli, le collecteur doit récupérer une éventuelle mise à jour du manifeste. La succession terminaison–rétablissement–rafraîchissement crée une nouvelle époque compréhensible.

Mais cette explication exige que les trois éléments soient observés. Si seule la reconnexion subsiste, elle ne prouve pas à elle seule la cause de la rupture. La notification a pu être perdue, le transport interrompu avant sa livraison ou le collecteur indisponible. La première donnée reçue après la reprise décrit le nouvel état, non tout le chemin qui y mène.

RFC 8641 propose un indice pour les notifications « on-change » : lorsque patch-id sert de compteur croissant, un saut ou un désordre devient détectable. Le compteur est réinitialisé lors d’une resynchronisation ou d’un bouclage. C’est un bon détecteur conditionnel. Ce n’est ni une obligation universellement observée ni une preuve de complétude pour chaque série périodique. Détecter une rupture ne signifie pas encore l’attribuer.

Une signature prouve l’objet signé, pas l’objet attendu

Le projet renvoie l’intégrité et la provenance au travail OPSAWG sur les signatures COSE appliquées aux données YANG. Une signature peut lier un manifeste à son auteur, révéler une modification et soutenir la traçabilité d’un objet conservé. Des contresignatures peuvent documenter plusieurs étapes de garde.

La force cryptographique ne doit pas élargir la phrase probatoire. Un M1 signé prouve l’origine et l’intégrité de M1 selon les clés et règles retenues. Il ne prouve pas que M2 n’a jamais été émis. Un point signé prouve quelque chose sur ce point ; il ne certifie pas que tous ses voisins attendus existent. L’authenticité d’un objet présent ne devient pas la complétude d’une série.

La même discipline vaut lorsque le collecteur assemble le manifeste à partir de modules standard ou propres à un fournisseur, option admise pour les équipements dépourvus de prise en charge native. Un manifeste reconstruit peut être exact. Son origine doit simplement rester visible : observations utilisées, heure d’assemblage, champs inconnus et responsable de la composition. « Produit par la plateforme » et « assemblé par le collecteur » sont des états de provenance, pas des jugements de valeur.

Un reçu de continuité placé à côté du flux

Le contrôle proportionné n’est pas une seconde copie de la télémétrie. C’est un petit registre qui conserve, pour une fenêtre analytique ou une action automatisée importante, les preuves permettant d’interpréter la présence comme l’absence :

  • abonnement demandé, filtre et cadence configurée, avec acceptation ou rejet ;
  • période courante déclarée par la plateforme et fenêtre durant laquelle elle a été observée ;
  • compteur de séquence, délai d’arrivée attendu ou autre indice de cadence, avec sa portée exacte ;
  • identifiant ou empreinte de chaque version de manifeste reçue, et origine plateforme ou collecteur ;
  • terminaison, redémarrage, resynchronisation et rétablissement qui ouvrent ou ferment une époque ;
  • frontières d’émission, de transport, d’ingestion et de stockage, pour ne pas appeler chacune « la collecte » ;
  • lacune détectée, causes encore compatibles, état d’enquête et disposition finale ;
  • responsable, voie de contestation, correction publiée et décision annulée faute de preuve suffisante.

Ce reçu ne transforme pas le silence en faute. Dans une souscription « on-change », l’absence peut signifier qu’aucune valeur n’a changé. Dans une collecte périodique, une période prolongée peut être légitime. Après une terminaison connue, aucune arrivée n’est attendue. Le reçu doit conserver l’attente applicable avant d'étiqueter son absence.

Il doit aussi rester protégé. Les versions, logiciels et caractéristiques de plateforme peuvent aider un attaquant ; le projet exige à juste titre des contrôles d’accès. Le reçu peut employer des identifiants pseudonymisés, des empreintes et des fenêtres plutôt que reproduire les données sensibles. L’accès opérationnel et l’accès d’audit n’ont pas besoin d’être identiques.

Ne pas demander au projet de devenir tout le système de preuve

La lignée des transformations analytiques est expressément hors périmètre. Cette limite protège l’implémentabilité. Le projet n’a pas à devenir simultanément inventaire, journal de transport, preuve de stockage, registre de modèles et mécanisme d’autorisation.

Il accomplit déjà un travail utile : période réelle, contexte temporel, coordonnées de raccord, rafraîchissement après rupture, précautions d’accès et voie de provenance cryptographique. Surtout, il reconnaît le domaine de panne partagé. Le reçu de continuité est donc une responsabilité locale de l’opérateur, non une modification normative attribuée à l’IETF.

Au 7 septembre 2026, la révision 14 reste un Internet-Draft actif visant le statut Proposed Standard. La page courante la situe en évaluation par l’AD avec suivi et sans date de téléconférence. L’historique des revues montre un travail encore ouvert ; il ne prouve ni rejet, ni approbation, ni usage sur un réseau nommé.

Le manifeste rend les points présents honnêtes. Le reçu de continuité empêche le blanc de devenir, par commodité, une conclusion.

Sources