Zusammenfassung

  • Liegt der angeforderte startTime vor dem noch verfügbaren Logbestand, darf eine RFC-5277-Wiederholung beim ältesten verbliebenen Ereignis beginnen. replayComplete kann korrekt sein, obwohl der Anfang des Untersuchungszeitraums fehlt.
  • Vollständigkeit gilt nur für die Schnittmenge aus Aufbewahrung, Stream-Mitgliedschaft, Filter und Sitzungsberechtigung. Annahme, Zustellung, Zeitqualität, dauerhafte Ablage und Anwendungsergebnis bleiben eigenständige Beweisgrenzen.

Das Adjektiv „vollständig“ braucht ein Objekt

RFC 5277 versieht replayComplete mit einem engen Bezugsrahmen: Alle für dieses Abonnement anwendbaren Replay-Benachrichtigungen wurden gesendet. Das Signal urteilt nicht darüber, ob davor Daten alterten, ob der Stream die gesamte Wirklichkeit abbildete oder ob der Empfänger alles dauerhaft speicherte.

Fordert ein Client den Beginn A an und reicht das Log nur bis B zurück, startet die Wiederholung bei B. Der Server rekonstruiert A bis B nicht. Er behauptet auch nicht, dort seien keine Ereignisse aufgetreten. Nach dem letzten verfügbaren, anwendbaren Element ist der Marker trotzdem regelkonform.

Ein belastbarer Bericht muss deshalb angeforderten und effektiven Beginn nebeneinander ausweisen. Ihre Differenz ist eine bekannte Evidenzlücke. Wer nur den Erfolgsstatus speichert, verwandelt eine korrekte Protokollaussage in eine unzulässige historische Behauptung.

RFC 8639 aktualisiert den Rahmen für abonnierte Benachrichtigungen; RFC 8641 überführt das Managementschema aus RFC 5277 nach YANG. Die Analyse hier betrifft die Grenzen von RFC 5277 und erhebt das Modell von 2008 nicht zur einzigen heutigen Architektur.

Ein altes Log kann einen jungen Inhalt haben

Replay ist optional und setzt ein Benachrichtigungslog voraus. Umfang und Aufbewahrung werden der Implementierung überlassen. Ein System kann replayLogCreationTime und replayLogAgedTime anzeigen, ohne seit der Logerzeugung lückenlose Inhalte vorzuhalten.

Gerade replayLogCreationTime lädt zu einer Fehlinterpretation ein. Der Erstellungszeitpunkt kann vor der ältesten noch verfügbaren Benachrichtigung liegen. Der Behälter bleibt bestehen, während ältere Einträge herausaltern. Das Alter des Behälters misst daher nicht die Tiefe seiner Erinnerung.

Für eine Prüfung gehören Loggeneration oder Reset-Identität, Aufbewahrungsrichtlinie, Alterungsgrenze und die tatsächlich beobachteten Randereignisse zusammen. Verschiebt sich der effektive Beginn nach vorn, ist das eine Verringerung der Untersuchungsreichweite und muss als solche sichtbar bleiben.

Der Stream ist bereits eine Auswahl

Ein Event-Stream ist eine Menge von Benachrichtigungen, die Weiterleitungskriterien erfüllt. Der voreingestellte NETCONF-Stream enthält die vom Server unterstützten NETCONF-XML-Ereignisbenachrichtigungen. Er enthält nicht zwangsläufig jede Zustandsänderung des verwalteten Systems.

Wie nicht standardmäßige Quellen konfiguriert sind und welche internen Vorgänge überhaupt zu Benachrichtigungen werden, liegt außerhalb des RFC-Umfangs. Aus „nicht im Stream“ darf ohne einen separaten Erzeugungsvertrag nicht „nicht geschehen“ werden.

Auch die Stream-Definition braucht eine Version. Softwarestände oder Konfigurationen können ihre Mitgliedschaft verändern, während der Name gleich bleibt. Langzeitvergleiche ohne Versionsbezug stellen dann unterschiedliche Beobachtungsflächen als identische Quelle dar.

Filter und Zugriffsrecht teilen die Vergangenheit auf

Bei create-subscription kann der Client einen Filter angeben. Nach Erzeugung eines Benachrichtigungselements wird die Zugriffskontrolle angewandt; fehlt der Sitzung die Berechtigung, wird das Element für sie verworfen.

Zwei berechtigte Clients können dadurch für denselben Zeitraum unterschiedliche, jeweils gültige Verläufe sehen. Jeder Verlauf ist eine Projektion aus Stream, Filter und geltender Autorisierung. replayComplete beendet nur diese sitzungsspezifische Sicht.

Für die Nachvollziehbarkeit sollten Filtertext, authentisierte Identität, Generation der Zugriffsrichtlinie und verfügbare Zähler vor und nach den Sichtbarkeitsgrenzen erhalten bleiben. Ändert sich eine Richtlinie während einer Untersuchung, kann ein neuer Replay-Lauf anders aussehen, ohne dass das Quelllog manipuliert wurde.

Die Annahme des Abonnements ist keine Einzelquittung

Eine positive RPC-Antwort auf create-subscription belegt, dass der Server die Anfrage angenommen hat. Spätere Benachrichtigungen sind Einwegnachrichten; RFC 5277 definiert keine Antwort pro Benachrichtigung. Ebenso beweist die Capability-Anzeige nur Unterstützung des Verfahrens, nicht die Zustellung eines bestimmten Ereignisses.

Sitzungsabbruch, Queue-Verlust, Decoder-Ablehnung und fehlgeschlagene Client-Persistenz liegen hinter dieser Annahmegrenze. Der Server kann Replay und Marker ordnungsgemäß senden, während beim Empfänger ein Abschnitt verloren geht. Ende-zu-Ende-Vollständigkeit verlangt daher Empfänger-Checkpoints, Identitäten oder Sequenzen und einen dauerhaften Speicherbeleg.

replayComplete darf zudem nicht mit notificationComplete verschmolzen werden. Der erste Marker trennt den historischen Replay-Teil ab, der zweite beendet ein Abonnement mit Stoppzeit. Eine Oberfläche, die beide nur „fertig“ nennt, beseitigt die Semantik, die sie unterscheiden soll.

Der Übergang zum Live-Strom ist eine prüfbare Naht

Bei einem Replay-Abonnement ohne Stoppzeit folgen auf den Marker zunächst die seit der Abonnementerstellung erzeugten Benachrichtigungen und danach neue Live-Ereignisse. Diese Folge verbindet historische Speicherung und laufende Veröffentlichung.

Der Marker lokalisiert die Naht, garantiert aber nicht allein Verlustfreiheit, Deduplizierung oder Reihenfolge. Systeme mit Kontinuitätsanspruch benötigen Produzentengeneration, Ereignis-IDs oder Sequenzinformation sowie Sende-, Empfangs- und Persistenzzeiten.

eventTime bezeichnet den Erzeugungszeitpunkt an der Ereignisquelle. Es ist weder Ankunftszeit noch Nachweis einer synchronisierten Uhr. Eine nach diesem Feld sortierte Chronologie kann hilfreich sein, beweist aber keine Kausalordnung.

Eine Quittung mit den richtigen Grenzen

Für folgenreiche historische Aussagen sollte die Evidenz enthalten:

  • authentisierten Server, NETCONF-Sitzung und Client-Identität;
  • Capability- und Stream-Discovery-Antwort;
  • Streamname, Definitionsversion und Replay-Unterstützung;
  • angeforderte Start- und Stoppzeit sowie effektiven Beginn;
  • Logerzeugung, Alterungsgrenze, Generation oder Reset;
  • erste und letzte tatsächlich beobachtete Benachrichtigung;
  • exakten Filter und Generation der Autorisierungsrichtlinie;
  • RPC-Ergebnis und serverseitige Abonnementkennung;
  • beide Abschlussmarker samt Empfangszeit;
  • Replay-zu-Live-Übergang, erkennbare Lücken und Duplikate;
  • eventTime, Sende-, Empfangs-, Dekodier- und Speicherergebnis;
  • autoritativen Zustand oder Anwendungsausgang zur Gegenprüfung.

Die belastbare Aussage lautet: „Die Wiederholung ist für aufbewahrte, anwendbare und autorisierte Ereignisse zwischen B und C abgeschlossen.“ Wer die Einschränkungen streicht, formuliert nicht kürzer, sondern behauptet etwas anderes.

Sources