Zusammenfassung

  • draft-ietf-nmop-network-incident-yang-14 trennt den Netzlebenszyklus raised, updated, cleared vom Betreiberablauf acknowledged, diagnosed, resolved und erlaubt mehrere Vorfälle in einer Resolve-RPC.
  • Der Erfolg folgt asynchron in einer eigenen Benachrichtigung. Die YANG-Doctors-Prüfung vom 31. August stellte fest, dass diese Meldung keinem konkreten RPC-Aufruf zugeordnet werden kann.
  • Ein Befehls-bis-Cleared-Beleg sollte Anfrage, Befugnis, Ziele, Handlung, Meldung, Ticketabbildung und Dienstprüfung verbinden. Er ist ein redaktioneller Vorschlag, keine IETF-Vorgabe.

Der Vorfall hat eine Nummer, der Aufruf nicht dieselbe Art Identität

Der NMOP-Entwurf will Alarme, Messwerte und Anomalien aus mehreren Schichten zu handhabbaren Netzvorfällen zusammenführen. Client und Server können diese Vorfälle bestätigen, diagnostizieren und bearbeiten, ohne jedes Rohsignal zum eigenen Ticket zu machen.

Für die Bearbeitung nimmt incident-resolve eine Liste von incident-no entgegen. Meldet der Server eine erfolgreiche Lösung, folgt eine separate Benachrichtigung und der Vorfall erhält cleared. Wie der Server das Problem konkret löst, bleibt außerhalb des Dokuments.

Die Vorfallnummer sagt, welcher Datensatz geändert wurde. Sie ist kein eindeutiger Bezeichner für einen einzelnen Aufruf. Zwei Controller können denselben Vorfall adressieren; ein Client kann nach einem Timeout wiederholen; der Server kann selbst heilen; eine Bedingung kann unabhängig verschwinden. In allen Fällen kann die Benachrichtigung echt sein, ohne den verursachenden Weg zu beweisen.

Zwei Lebenszyklen schützen vor einer falschen Gleichsetzung

Der Entwurf führt für die Netzinstanz raised, updated und cleared. Der Betreiber bestätigt, diagnostiziert und löst. Ein Messsignal kann verschwinden, während die Untersuchung offen bleibt. Eine Umleitung kann den Dienst wiederherstellen, obwohl die wahrscheinliche Ursache besteht. Umgekehrt kann menschliche Arbeit abgeschlossen sein, während der Server weiterhin Auswirkungen beobachtet.

Für das OSS-Ticketsystem kommt ein dritter Zustandspfad hinzu. Eine deterministische Übersetzung zwischen YANG-Zuständen und Open, Assigned, In-Progress oder Resolved soll eine gespaltene Sicht verhindern: Netz geschlossen, Ticket offen oder umgekehrt.

Deterministische Übersetzung bedeutet jedoch nur, dass dieselbe Eingabe gleich behandelt wird. Sie beweist nicht, warum die Eingabe entstand. Eine Regel kann cleared zuverlässig in Resolved umwandeln und damit eine ungeklärte Ursache als administrative Gewissheit weiterreichen.

Die Fachprüfung benennt genau die fehlende Kante

Die frühe YANG-Doctors-Prüfung bewertete das Dokument als Almost Ready. Zugleich hielt sie fest, dass RPC-Ergebnisse durch Benachrichtigungen gemeldet werden, aber kein Weg besteht, eine Benachrichtigung dem auslösenden RPC zuzuordnen. Für Diagnoseaufrufe stellte sie dieselbe Frage.

Weitere Punkte betrafen Zustandsmaschinen, Vorfallbezeichner, leere Zielmengen, Fehlerstrukturen sowie Quelle und Ziel einer Meldung. Die Prüfung vermerkt auch, dass eine nächste, damals unveröffentlichte Fassung erneut geprüft werden sollte.

Das ist ein überprüfbarer Befund zur begutachteten Schnittstelle. Es ist kein Beleg für einen realen Ausfall, keine Aussage über eine Betreiberimplementierung und keine Vorwegnahme späterer Änderungen.

Schon das NMOP-Protokoll der IETF 126 dokumentierte Fragen zum Verhältnis von Listenschlüssel, Vorfallnummer und Vorfall-ID. Es zeigt laufende Designarbeit, nicht deren endgültiges Ergebnis.

Zugriffskontrolle entscheidet über den Eintritt, nicht über die spätere Ursache

Der Entwurf sieht NETCONF oder RESTCONF mit sicherem Transport und gegenseitiger Authentisierung vor. NACM kann Benutzer auf bestimmte Operationen und Inhalte begrenzen. Für fehlgeschlagene Lösungen gibt es Gründe wie ungelöste wahrscheinliche Ursache, verweigerte Berechtigung, Timeout und fehlende Ressource.

Damit lassen sich Gegenstelle, Aufrufrecht und synchrones Scheitern erfassen. Eine spätere Meldung benötigt dennoch eine eigene Herkunftsbeziehung. Selbst derselbe autorisierte Principal kann zwei Aufrufe senden; die Authentisierung entscheidet nicht, welchem von beiden das Ergebnis gehört.

Identität, Erlaubnis, Annahme, Ausführung, Zustandsbeobachtung und Dienstwiederherstellung sind getrennte Behauptungen. Wer sie unter „automatisch gelöst“ zusammenzieht, macht eine Zugriffsregel versehentlich zum Kausalitätsnachweis.

Die Daten brauchen Schutz. Lesbare Vorfälle können den beschädigten Zustand eines Netzes offenlegen; fehlerhafte oder bösartige Clients können mit vielen Diagnose- oder Resolve-Aufrufen Ressourcen verbrauchen. Ein vollständiger Beleg gehört deshalb in einen geschützten Nachweisraum. Öffentlich genügen Aktionsklasse, Zeitpunkt, Autorisierungsstatus, Zuordnungsqualität und Dienstresultat.

Bei Sammelaufrufen wird Unschärfe zur Zuteilungsfrage

Ein Aufruf nennt die Vorfälle 101, 102 und 103. Nummer 101 verschwindet nach der geplanten Aktion. Nummer 102 wird durch lokalen Schutz umgeleitet. Nummer 103 wird nach aktualisierter Topologie neu gruppiert. Später stehen alle drei nicht mehr auf Rot. Nur bei einem ist die Wirkung des Befehls belegt.

Eine pauschale Erfolgsquote schreibt dem Controller fremde Wirkung gut. Sie kann auch eine verantwortungsvolle Nichtentscheidung auslöschen. Der Entwurf sagt ausdrücklich, dass eine Lösung laufende Dienste beeinflussen kann und der Client bei nicht trivialem Risiko auf die Operation verzichten darf. Ablehnung und Alternative gehören daher zum Ergebnis.

Veraltete Topologiedaten verschlechtern laut Entwurf außerdem Ursachen- und Auswirkungsanalyse. Ein Statuswechsel kann auf neuem Wissen beruhen, ohne dass sich das Netz durch einen Befehl geändert hat.

Null Validierungsfehler haben eine klare, begrenzte Aussage

Die Datatracker-Seite führt Revision 14 als aktiven NMOP-Entwurf mit Ziel Standards Track. Der WG Last Call endete am 3. September. Im eingefrorenen Stand vom 9. September blieb der Status In WG Last Call; ein verantwortlicher AD und ein IESG-Telechat-Termin fehlten.

Am 7. September meldete die YANG-Prüfung null Fehler und null Warnungen. Das ist relevante Evidenz für die Form des Modells. Es ist weder RFC-Status noch Konsens, Einsatz oder Ende-zu-Ende-Nachweis. Ein aussagekräftiger Lauf müsste parallele Aufrufe mit überlappenden Zielen, Selbstheilung, verzögerte Meldungen und Teilerfolg auseinanderhalten.

Ein Beleg darf das Ergebnis „unbekannt“ haben

Der Befehls-bis-Cleared-Beleg beginnt mit einer eindeutigen Aufruf-ID. Er friert Zielvorfälle und Revisionen, Principal und Rolle, NACM- und Änderungsrichtlinie, erwartete Wirkung, Genehmigung und eine risikoärmere Alternative ein.

Danach hält er Annahme oder Fehler je Vorfall, Server- und Modellversion, Wiederholungen, Teilungen und Fallback fest. Jede Benachrichtigung wird dem Aufruf zugeordnet, als unabhängige Änderung gekennzeichnet oder ehrlich mit unbekannter Korrelation versehen.

Zum Abschluss folgen OSS-Abbildungsregel, Ticketzustand, handelnde Person und Zeit, Dienstprüfung, Restursache oder Umgehung, Rollback-Verantwortung und Korrekturhistorie. Dafür muss das Protokoll nicht erweitert werden.

The Policy Mirror trennt die Schreiborte der Macht: NACM erlaubt, der RPC verlangt, der Datenspeicher beobachtet, das Ticket schließt organisatorisch, der Diensttest prüft die Wirklichkeit. Running-Code Primacy verlangt, dass ihre Ausführungsspuren zusammentreffen. Reality, Not Advocacy begrenzt die Aussage: Der Entwurf liefert eine nützliche Sprache. cleared allein beweist nicht seine eigene Ursache.

Quellen