Zusammenfassung

  • RFC 9968 hält die Ergebnisse des NEMOPS-Workshops zu Werkzeugen, Dienstmodellen, Verifikation und Automatisierung fest. Der Text ist ein Informational-Bericht des IAB, keine Standards-Track-Vorschrift und keine Vollmacht für einen Controller.
  • Gewünschte Konfiguration, angewandte Konfiguration, beobachteter Betriebszustand und gemeldete Änderung sind verschiedene Aussagen. Keine davon beweist allein Vollständigkeit, Kundenfreigabe, Verursachung oder die Berechtigung, ein Risiko auszulösen.
  • Nachvollziehbare Automation bewahrt vier getrennte Aufzeichnungen: Dienstzusage, begrenzte Beobachtung, konkreten Änderungsvorschlag und widerrufbare lokale Autorisierung. Wer sie zu einer einzigen Wahrheit verschmilzt, macht aus Sichtbarkeit eine scheinbare Herrschaft.

Eine gemeinsame Sprache ist keine gemeinsame Entscheidungsgewalt

RFC 9968 ist der Bericht des IAB-Workshops zur nächsten Ära des Netzmanagements. Er knüpft an den Workshop-Bericht RFC 3535 an, ohne ihn zu ersetzen. Seine Diagnose ist nüchtern: Managementprotokolle, Datenmodelle und Werkzeuge bleiben schwer nutzbar und zersplittert; SNMP und CLI werden weiterhin verwendet; NETCONF und YANG decken auf vielen Geräten nicht alle Funktionen ab; Mehrhersteller-Umgebungen müssen mehrere Modelle gleichzeitig tragen. Gefragt sind bessere Verifikation, Beobachtbarkeit, Dienstmodellierung, offene Werkzeuge und praktikable Übergänge.

Das ist kein Argument gegen Standardisierung. Es ist ein Grund, ihre Aufgabe klein und präzise zu halten. Ein Modell kann eine gemeinsame Schnittstelle schaffen. Es kann einer externen Übersetzung helfen, eine Dienstabsicht auf verschiedene Geräte abzubilden. Es kann die Vergleichbarkeit einer Konfiguration verbessern. Aber ein Modell legt nicht fest, welcher Kunde eine Beeinträchtigung tragen darf, ob ein Wartungsfenster angemessen ist oder wer für einen falschen automatischen Eingriff haftet.

Der Bericht setzt seine eigene Grenze. RFC 9968 ist Informational und kein Internet-Standards-Track-Dokument. Er hält Präsentationen und Diskussionsnotizen ohne Interpretation oder Validierung fest; sofern nicht ausdrücklich gesagt, bildet er keinen Konsens ab, und Äußerungen der Teilnehmenden sind nicht notwendig IAB-Positionen. Diese Einschränkung macht den Bericht nicht schwach. Sie beschreibt seine Beweiskraft: Er zeigt Probleme, Erfahrungen und Vorschläge. Er autorisiert keine Veränderung am Netz eines anderen Betreibers.

RFC 3535 hatte die betriebliche Trennung schon deutlich gemacht. Betreiber verlangten eine Unterscheidung von Konfigurationsdaten, Betriebszustand und Statistiken, möglichst geringe Auswirkungen beim Übergang von Konfiguration A nach B, geringste Privilegien sowie die Trennung von Verteilung und Aktivierung einer Konfiguration. Ein ausgeliefertes Artefakt ist deshalb noch kein freigegebener Eingriff. Technische Bereitstellung und Entscheidung über die Folgen sind verschiedene Handlungen.

Vier Akten statt einer vermeintlichen Wahrheit

Die erste Akte ist die Dienstzusage: Erreichbarkeit, Latenzrahmen, Kundenübergabe, geschützter Verkehr, Wartungsgrenze oder Wiederherstellungsziel. Sie benennt auch den Eigentümer der Zusage. Gerätekonfiguration ist meist nur eine mögliche Umsetzung.

Die zweite Akte ist die Beobachtung: Telemetrie, Probes, Logs, Zähler, Routing-Sichten und Alarme. Jede Beobachtung braucht Quelle, Zeit, Umfang, Verlustverhalten und bekannte blinde Flecken. Ein sauberer Strom kann genau das melden, was sein Herausgeber sieht, und dennoch einen entscheidenden Zustand auslassen. Stille kann Gesundheit, aber ebenso eine unterbrochene Subscription, einen defekten Sammler, Filterung oder fehlende Modellierung bedeuten.

Die dritte Akte ist der Änderungsvorschlag: exakter Delta, Geräte, Dienste, Kunden, Abhängigkeiten, Zeitfenster, erwartete Wirkung und Rückweg. Übersetzt ein Adapter ein Dienstmodell in herstellerspezifische Konfiguration, müssen Eingabe, Ausgabe und Adapterversion erhalten bleiben. Sonst lässt sich nach einem Fehler nicht mehr unterscheiden, ob Absicht, Übersetzung oder Ausführung versagt hat.

Die vierte Akte ist die Autorisierung: Wer genehmigt welchen Umfang, auf welcher Evidenz, bis wann, und wer darf anhalten oder zurücknehmen? Das verlangt keinen zeremoniellen Klick vor jedem Befehl. Es verlangt, dass auch eine automatische Regel einen lokalen Eigentümer, Grenzen, Ablauf und Widerruf besitzt. Schnelligkeit ersetzt keine Zuständigkeit.

RFC 8342 trennt in der NMDA beabsichtigte, angewandte und operative Konfiguration. Das ist eine technische Architektur, keine Verfassung für Geschäftsrisiken. Sie entscheidet weder über Kundenerfolg noch über Änderungsrechte. Sie lehrt jedoch die richtige Reihenfolge: Erst fragen, welche Art von Datensatz vorliegt; dann fragen, welche Schlussfolgerung er tragen kann.

RFC 6241 beschreibt NETCONF und unter anderem Candidate-, Running- und Confirmed-Commit-Flächen; RFC 8040 definiert RESTCONF. Diese Mechanismen können eine Operation innerhalb ihres technischen Rahmens strukturieren, authentisieren und rückgängig machen. Sie kennen weder die Vertragspflicht eines Transitkunden noch die Person, die eine Störung wirtschaftlich tragen muss. Schreibzugriff ist keine Entscheidungsvollmacht.

Mehr Telemetrie ist keine vollständige Welt

RFC 8639, RFC 8641 und RFC 9196 schaffen Begriffe für Subscriptions, Datastore-Änderungen und Fähigkeiten. Sie liefern strukturierte Signale. Sie sichern nicht zu, dass jeder relevante Zustand modelliert ist, eine Übersetzung verlustfrei bleibt, ein Strom lückenlos war oder eine Korrelation Ursache beweist.

Der unzulässige Schluss lautet: Das Modell erlaubt die Änderung; also entscheidet das Modell; also ist die Änderung autorisiert. Der erste Satz kann getestet werden. Der zweite benötigt eine andere Quelle: lokale Delegation, Vertrag, anwendbare Pflichten und die Person, die Folgen und Verlust trägt. Ein Datenbaum kann diese Quelle nicht erzeugen.

Heng Lus Überlegungen zu laufendem Code, minimaler Anfangsspezifikation und lokaler Zukunftsentscheidung sowie Realitätsschichten geben dafür einen redaktionellen Test: Gemeinsame Spezifikation soll Interoperabilität ermöglichen, nicht spätere Entscheidungen einziehen. Das laufende Dienstresultat prüft die Behauptung. Ein symbolischer Datensatz ersetzt keine operative Realität.

Den Übergang von Evidenz zu Handlung stören

Eine Übung muss mehr prüfen als einen erfolgreichen Commit. Sie verbindet Dienstzusage, Modellversion, Gerätefähigkeiten, Alter und Lücken der Signale, Vorschlagsdelta, Genehmigung und unabhängige Sonde. Danach erzeugt sie Gegenfälle: eine fehlende Telemetriequelle bei gesundem Dienst, verspätete Benachrichtigung, abgelehntes Modellblatt, nicht unterstützte Herstellerfunktion, Out-of-Band-CLI-Änderung, Neustart zwischen Verteilung und Aktivierung oder eine nachträgliche Bereichserweiterung. Jeder Fall zeigt eine andere Stelle, an der Beobachtung für unbeaufsichtigtes Handeln nicht mehr reicht.

Sources