Zusammenfassung

  • Revision 16 hielt das Incident-Modell ausdrücklich von Konfidenz unabhängig; Revision 17 führt eine strukturierte Probable Root Cause ohne Score, Erzeugeridentität, Modellversion oder Kalibrierungsnachweis fort.
  • Die benachbarten NMOP-Anomalieentwürfe bewahren Konfidenz, Concern und Annotator-Provenienz. Das Risiko entsteht, wenn diese vorgelagerte Evidenzhülle verloren geht, während ihre ausgewählte Ursache bestehen bleibt.
  • Eine typisierte Ursache ist eine begrenzte Hypothese, keine Handlungsvollmacht. Der belastbare Nachweis muss Analyseversion, Incident-Revision, Entscheidungsschwelle, autorisierte Maßnahme und beobachtetes Ergebnis verbinden.

Die formale Ursache überlebt ihre Begründung

Ein NOC verdichtet tausende Messwerte zu einem Incident. Die Korrelation findet einen Lichtsignalverlust an einem Port, bewertet einen Hardwarefehler als wahrscheinlichste Ursache und verwirft eine beinahe gleich starke Konfigurationshypothese. Im Schichtbericht stehen noch Zweifel und fehlende Telemetrie. Im normalisierten Incident stehen Knoten, Ressource, Ereignisreferenzen, kritische Priorität und interface-hardware-failure.

Der zweite Datensatz ist leichter weiterzugeben. Gerade deshalb kann er autoritativer wirken als die Analyse, aus der er entstand. Die formale Präzision der Klassifikation verdeckt, dass die Auswahl knapp, modellabhängig oder vorläufig war.

Die Versionsgeschichte von draft-ietf-nmop-network-incident-yang zeigt eine gewollte Modellgrenze. Revision 15 erläuterte noch, dass verwandte Anomalieerkennung Ergebnisse mit Konfidenz und Concern bewertet. Revision 16 entfernte diesen Satz und vermerkte im Änderungsprotokoll, das Incident-Modell bleibe von Konfidenz unabhängig. Revision 17 vom 24. September 2026 hält daran fest.

Das ist kein Plädoyer für ein universelles Prozentfeld. Es ist eine Aufforderung, die Übersetzung von reicher Evidenz in einen schmalen Betriebsgegenstand wie eine kontrollierte Datenverarbeitung zu behandeln.

Was der gemeinsame Kern zusichern kann

Ein Incident kann entstehen, bevor seine Quelle feststeht. Die Quellenliste darf leer beginnen und später durch Diagnose ergänzt werden. probable-causes kann Netzwerk und Knoten, optional eine Ressource, eine cause-name-Identität und erläuternde Details tragen. probable-events verweist auf zugehörige Ereignisse. Domäne, Priorität und Kategorie sind im Incident-Gruppentyp verpflichtend.

Diese Festlegungen lösen reale Interoperabilitätsprobleme. Systeme tauschen eine gemeinsame Ursachenklasse statt uneinheitlicher Freitextdiagnosen. Knoten- und Ressourcenreferenzen lokalisieren die Behauptung. Ereignisverweise erhalten einen Weg zu Beobachtungen. Neue Quellen können hinzukommen, ohne den Incident als Betriebsobjekt neu zu erfinden.

Doch die Felder beantworten andere Fragen als Konfidenz. Priorität bezeichnet Dringlichkeit, nicht die Wahrscheinlichkeit der Diagnose. Kategorie klassifiziert den Vorfall, nicht die Güte des Detektors. Ein verwandtes Ereignis belegt Zusammenhang, aber keine hinreichende Kausalität. Ein normiertes identityref macht die Bezeichnung austauschbar, nicht wahr.

Die Definition der Probable Root Cause ist anspruchsvoll: Die vollständige Beseitigung dieser Fehlerbedingung beendet den Incident und verhindert sein Wiederauftreten; ein beitragender Faktor genügt nicht. Das Ursachenobjekt enthält jedoch keinen standardisierten Beseitigungstest, kein Rezidivfenster, keinen kontrafaktischen Versuch und keine konkurrierenden Erklärungen. Die Semantik setzt den Maßstab. Eine befüllte Instanz beweist nicht automatisch, dass der Maßstab erreicht wurde.

Die fehlenden Größen liegen in den Anomaliemodellen

draft-ietf-nmop-network-anomaly-lifecycle-07 definiert eine Konfidenz von 0 bis 100 für eine Anomalie oder Erkennungsstrategie und separat einen Concern-Wert von 0 bis 100 für die erforderliche betriebliche Aufmerksamkeit. Das Modell kann Version und Phase der Anomalie, Identität und Namen des Annotators, seinen menschlichen oder algorithmischen Typ sowie seine Version festhalten. Detection, Validation und Refinement bilden einen Kreislauf.

draft-ietf-nmop-network-anomaly-semantics-06 überführt Konfidenz, Concern, Strategie, Annotator-Typ und -Version in ein serialisierbares Vokabular. In den Beispielen darf Konfidenz null sein. Eine Evidenzhülle muss also keine Gewissheit vortäuschen; sie kann auch ausdrücken, dass eine Bewertung fehlt.

Die Trennung kann sauber funktionieren. Der Incident bleibt als gemeinsames Austauschobjekt klein, während ein versionierter Anomaliedatensatz die Urteilsbildung dokumentiert. Entscheidend ist der Join. Ist seine Kennung dauerhaft, unveränderlich und zugriffsgeschützt, kann ein Prüfer Ursache und Evidenz wieder zusammenführen. Lebt der Join nur in einem Dashboard, wird Aggregation zu stiller Löschung.

Dann bleibt der Ursachenname in Tickets, Automatisierung und Berichten erhalten, während Modellversion, Beobachtungsfenster, verworfene Hypothesen und Kalibrierung überschrieben werden. Das ist ein Kompressionsrisiko: Die Auswahl dessen, was eine Verdichtung überlebt, ist selbst eine Kontrollentscheidung.

Drei Größen dürfen nicht zu einer Ampel werden

Konfidenz fragt, wie stark ein Detektor eine Beobachtung oder Strategie stützt. Concern fragt, wie viel Aufmerksamkeit oder Abhilfe die Lage angesichts möglicher Folgen verdient. Incident-Priorität bestimmt die Dringlichkeit der Behandlung des aggregierten Objekts.

Eine erwartete Verkehrsverschiebung kann mit hoher Konfidenz anomal und dennoch wenig besorgniserregend sein. Ein schwaches optisches Signal kann nur eine unsichere Diagnose tragen, bei einem kritischen Dienst aber hohen Concern erzeugen. Ein Incident kann wegen des Schadenspotenzials höchste Priorität erhalten, obwohl die führende Ursache noch umstritten ist.

Ein einziger Rot-Gelb-Grün-Indikator zerstört diese Unterschiede. Scores hängen vom Erzeuger, Referenzkollektiv, Beobachtungsfenster, Regelwerk oder Training und von der Kalibrierungsmethode ab. Eine 90 aus zwei verschiedenen Detektoren muss nicht dasselbe bedeuten. Die Unabhängigkeit des Incident-Kerns verhindert zu Recht eine Scheingenauigkeit; sie entbindet das Entscheidungssystem nicht davon, die lokalen Bedeutungen zu erhalten.

Autorisierung ist kein Qualitätsurteil über die Diagnose

Revision 17 erwartet sichere Transporte und gegenseitige Authentisierung und verweist für Operationen und Inhalte auf NACM. Das ist notwendig, weil Incident-Daten identifizierbare Dienste und die beschädigte Netzstruktur offenlegen können. Diagnose- und Auflösungsoperationen können Ressourcen beanspruchen oder laufende Dienste verändern.

Authentisierung belegt den Kommunikationspartner. Autorisierung entscheidet, welcher Principal eine Ursache lesen oder eine Operation aufrufen darf. Beides sagt nichts über die Kalibrierung der Ursache. Ein ordnungsgemäß autorisierter Principal kann auf einer schlecht gestützten Hypothese handeln; hohe Konfidenz verleiht einem Modell umgekehrt keine Änderungsbefugnis.

Der Entscheidungsbeleg muss daher epistemische Unterstützung und institutionelle Vollmacht getrennt festhalten.

Implementierungsstatus ist ein Hinweis, kein Abschlussbeweis

Der Entwurf nennt Huawei iMaster NCE als Implementierung des Incident-Modells mit Intent Management, KI-Werkzeugen, RESTCONF, Lebenszyklusverwaltung, Benachrichtigungen und Listenabfrage. Das ist relevante Running-Code-Evidenz.

Dieselbe Passage sagt, dass die Angaben von Mitwirkenden stammen, vom IETF nicht verifiziert wurden, keine Billigung darstellen und kein vollständiger Implementierungskatalog sind. Der eingefrorene Stand enthält keinen Interoperabilitätstrace zur Erhaltung von Konfidenz und Annotator-Version, keine Kalibrierungs- oder Genauigkeitsmessung und keinen Produktionsnachweis über Incident-Ergebnisse.

Die belastbare Aussage bleibt deshalb begrenzt: Eine Implementierung ist gemeldet; wie sie die Evidenzhülle erhält, muss praktisch geprüft werden.

Der frühere Text untersucht einen späteren Übergang

BTW hat bereits A Cleared Incident Does Not Prove Which Command Cleared It veröffentlicht. Dort geht es um die asynchrone Lücke in Revision 14 zwischen einem incident-resolve-Aufruf und einer späteren cleared-Benachrichtigung: Welcher Befehl bewirkte den Zustandswechsel?

Dieser Bericht setzt vorher an. Er fragt, welche Evidenz die Ursache stützte, bevor jemand einen Befehl auswählte. Eine perfekte Request-ID stellt eine verlorene Konfidenz nicht wieder her. Eine gut kalibrierte Ursache benötigt weiterhin Autorisierung und Ergebnisnachweis. Erkenntnis und Ausführung brechen an verschiedenen Joins; die Analysen duplizieren einander nicht.

Quellen