Zusammenfassung

  • SAMP-Revision 04 führt record_revision für die Ergebnisse von CONFIG und EXEC ein. Ändert sich der maßgebliche Befund, steigt die Nummer; frühere Zustände bleiben in einer nur erweiterbaren Prüfhistorie. In Revision 03 fehlte dieses Feld.
  • Ein verspätetes „erfolgreich“ braucht einen Beleg für die Wirkung genau dieses Befehls. Die identische Anfrage liest den neuesten Befund, ohne den Befehl erneut auszuführen. Kann der Endpunkt die zuletzt verbindlich gespeicherte Revision nicht ermitteln, antwortet er mit back_pressure ohne Ergebnis.

Eine spätere Wahrheit braucht ihre eigene Zeile

Bei einer Übergabe ist die Versuchung groß: Auf dem Bildschirm steht zunächst „unbestimmt“, danach erscheint der gewünschte Konfigurationswert. Also trägt der Nachtdienst „erledigt“ ein. Doch vielleicht hat ein anderer Administrator den Wert geändert. Die Anzeige belegt den Zustand, nicht den Urheber des Eingriffs. Wer diese beiden Dinge verwechselt, baut eine hübsche, aber falsche Betriebsgeschichte.

Der neue Entwurf fixiert die Kennung der ursprünglichen Operation und ihre authentifizierte Anfrage. Der erste verbindliche Befund trägt Revision 1. Nachträglich geprüfte Wirkungsbelege können daraus Revision 2 machen. Der ungewisse Anfang, die damalige Zulassung, der Beleg und der Zeitpunkt der Aufklärung bleiben erhalten. Ein bytegleich wiederholter Aufruf fragt den letzten Stand ab. Er löst keinen zweiten Eingriff aus.

Der Beleg muss mehr leisten als ein grünes Gesundheitslämpchen. Eine gültige Richtlinienentscheidung, ein späterer Sollzustand oder eine allgemeine Statusmeldung beweisen die Wirkung dieses Befehls nicht. Das Prüfprofil muss die Wirkung der konkreten Operation zuordnen. Ein Widerspruch zu einem bereits bestätigten Endergebnis wandert in die Prüfhistorie zur Klärung; er darf das alte Ergebnis nicht heimlich überschreiben.

Auch Ausführung und dauerhafte Belegsicherung sind getrennte Tatsachen. Ein Eingriff kann erfolgreich sein, obwohl die Auditspeicherung scheitert. Der Endpunkt meldet beides, sofern er eine neue gültige Revision verbindlich speichern kann. Nach einem Neustart oder Wechsel auf eine Replik darf er einen alten Kontrollpunkt nicht als aktuellen Befund verkaufen, wenn die letzte Revision ungewiss ist. Die Managementseite merkt sich die höchste akzeptierte Nummer. Eine niedrigere Nummer ist ein Rücksprung, dieselbe Nummer mit anderem Inhalt ein Konflikt. Netzwerkpakete wählen keine Wahrheit durch ihre Ankunftszeit.

Laut IETF-Dokumentenseite handelt es sich um einen individuellen Entwurf mit angestrebtem Status Experimental. Ein authentifizierter Ablauf von unklarer Antwort über verspäteten Wirkungsbeleg bis zur Wiederherstellung nach Neustart würde zeigen, ob eine konkrete Implementierung die Versionskette hält.

Quellen: Revision 04; Revision 03; IETF-Status.