Résumé

  • Quand startTime précède la capacité du journal, RFC 5277 fait commencer la reprise à la première notification encore disponible. replayComplete peut être vrai malgré l'intervalle perdu.
  • Le périmètre visible dépend du stockage, du stream, du filtre et du contrôle d'accès de la session. La livraison au client et la vérité opérationnelle sont des preuves ultérieures.

Un mot juste a reçu une portée fausse

Une demande porte sur A–C. Le journal ne conserve plus que B–C. Le serveur envoie B–C puis replayComplete. Rien dans cette séquence ne reconstitue A–B ; rien ne prétend qu'aucun événement ne s'y est produit.

L'erreur commence dans la couche de reporting : « fin de la partie rejouée » devient « historique complet ». Pour éviter cette promotion, le marqueur doit rester attaché à son ensemble : notifications disponibles, membres du stream, conformes au filtre et visibles pour la session.

RFC 8639 met à jour RFC 5277 et RFC 8641 transpose son schéma de gestion en YANG. Le modèle de 2008 n'est donc pas présenté comme l'unique cadre actuel ; il reste une preuve précise de la différence entre fin de traitement et couverture historique.

Le journal a un âge et une génération

La reprise est facultative et dépend d'un service de journalisation. Le nombre d'éléments conservés et les règles de rétention relèvent de l'implémentation.

replayLogCreationTime peut être antérieur à la plus vieille notification disponible. L'objet journal a une date de naissance, tandis que son contenu vieillit. Confondre les deux revient à déduire une conservation continue de la simple existence du contenant.

Le client doit enregistrer le début demandé, le début effectif, replayLogAgedTime, la création et toute remise à zéro. Si B est postérieur à A, l'écart doit apparaître comme résultat. Une reprise techniquement réussie peut être insuffisante pour l'enquête.

Le stream ne représente pas tout le système

Un event stream regroupe des notifications selon des critères de forwarding. Le stream NETCONF par défaut rassemble toutes les notifications XML NETCONF prises en charge par le serveur. Il ne promet pas que chaque mutation interne devienne une notification.

Les sources supplémentaires et leur configuration restent hors périmètre. Il faut donc versionner la définition du stream et le contrat entre événements internes et notifications. L'absence dans le stream n'est une preuve d'absence du fait que si ce contrat de couverture existe séparément.

Un événement peut appartenir à plusieurs streams. Le choix d'un stream est déjà une projection éditoriale et opérationnelle de la réalité.

Deux sessions reçoivent deux histoires valides

Le filtre fourni à create-subscription sélectionne les éléments transmis. Ensuite le serveur applique le contrôle d'accès à chaque notification générée. Si la session n'est pas autorisée, l'élément est supprimé pour elle.

Deux clients peuvent donc recevoir des reprises différentes sur la même période. Leur replayComplete ferme deux ensembles différents. Ce n'est pas nécessairement une incohérence ; c'est l'effet attendu de leurs filtres et droits.

L'audit doit conserver le filtre exact, l'identité authentifiée, la génération de la politique et, si possible, les compteurs avant et après chaque réduction. Sinon une modification de droits transforme une seconde reprise en apparente contradiction.

L'abonnement accepté ne confirme pas chaque message

La réponse positive à create-subscription atteste que le serveur a accepté l'opération. Les notifications suivantes sont unidirectionnelles et n'ont pas d'accusé individuel défini par RFC 5277.

Le serveur peut donc terminer correctement l'émission tandis qu'une file, un transport, un décodeur ou le stockage du client perd une partie du flux. Une exigence de complétude de bout en bout demande un checkpoint côté récepteur.

notificationComplete a encore un autre sens : il signale la fin d'un abonnement muni de stopTime. replayComplete ferme la portion historique ; notificationComplete ferme l'abonnement. Aucun ne certifie la production exhaustive des événements du système.

Le passage au direct mérite son propre reçu

Sans stop time, le serveur termine le replay, envoie les notifications produites depuis la création de l'abonnement, puis poursuit avec les événements en direct. Le marqueur situe ce passage mais ne prouve pas l'absence de doublon, de trou ou de réordonnancement en aval.

eventTime indique quand la source a généré l'événement. Ce n'est ni l'heure de réception du serveur, ni celle du client, ni une preuve de synchronisation. Une chronologie triée peut être pratique tout en restant causalement incertaine.

Un reçu défendable relie serveur et session, capability, stream et version, temps demandés, horizon effectif, génération du journal, filtre, politique d'accès, acceptation RPC, deux marqueurs, transition live, identifiants d'événement, temps source/émission/réception, persistance client et comparaison avec l'état faisant autorité.

Sources