Summary

  • Ein individueller Internet-Draft aus dem ONSEN-Problemfeld trennt YANG-Syntax von operativer Service-Semantik: Lebenszyklusverhalten, Gültigkeit, Dauer und Rückmeldung. Revision -01 lief am 19. August 2026 ab und ist weder WG-Adoption noch IETF-Konsens.
  • Auftragsannahme, Intended Configuration, angewendete Konfiguration, beobachtete Gesundheit und kaufmännischer Abschluss sind verschiedene Aussagen. Ein grünes Ergebnis einer Schicht definiert nicht „aktiv“, „abgelaufen“, „zurückgerollt“ oder „geschlossen“ für alle anderen.
  • Daniel Kade schlägt einen Service-Semantik-Beleg vor, der exakten Intent, Zustandsvokabular, Zeitbasis, Zerlegung, Transformation, Ausführungsevidenz, Entscheidungsbefugnis und Abschlussnachweis verbindet. Das ist redaktionelle Governance, keine ONSEN-Anforderung.

Mehrere richtige Zustände ergeben noch keinen gemeinsamen Zustand

Der Fall braucht weder Angreifer noch fehlerhaften Parser. Ein Kunde bestellt hohe Kapazität zwischen zwei Standorten für ein bestimmtes Intervall. Das BSS hält den Auftrag. Ein Service-Orchestrator zerlegt das Ziel in Netzdienste, Controller übersetzen diese in Segmente und Gerätekonfiguration. Telemetrie und Assurance beobachten die Wirkung.

Am Endzeitpunkt kann „abgeschlossen“ nur das Ende der Abrechnung meinen. „Abgelaufen“ kann eine Verlängerung sperren. „Abbau läuft“ kann lediglich belegen, dass eine Löschanforderung abgesandt wurde. „Aktiv“ kann eine weiterhin angewendete Konfiguration beschreiben. Ein Health Score bleibt möglicherweise grün, weil seine Messung vor dem letzten Intent-Wechsel liegt.

Jeder Satz kann im eigenen Zuständigkeitsbereich stimmen. Der Policy Mirror entsteht am Übergang: Ein Dashboard verdichtet die Aussagen auf eine Farbe und verleiht damit der sichtbarsten Schicht unbemerkt Deutungshoheit über den gesamten Dienst.

YANG kann Knoten, Typen, Constraints, Operationen und Notifications präzisieren. Es bestimmt nicht automatisch, wann ein Übergang wirksam wird, welche Uhr gilt, was als Teilfehler zählt und wer Rollback oder Abschluss erklären darf. Zwei Produkte können dasselbe Schema annehmen und unterschiedliche Lebenszyklen ausführen.

Was der ONSEN-Entwurf tatsächlich festhält

draft-xie-onsen-problem-statement-01 definiert Service-Semantik als operative Bedeutung von Lebenszyklus, Gültigkeit, Dauer und Feedback, nicht als YANG-Syntax. APIs aus ähnlichen Modellen könnten sich zwischen Systemen, Anbietern und Deployments unterscheiden und maßgeschneiderte Integration in OSS/BSS erzwingen.

Das DTS-I-Beispiel behandelt einen zeitlich begrenzten Massendatentransfer mit hoher Bandbreite, planbarer Dauer und Koordination über heterogene, womöglich betreiberübergreifende Domains. Der Beispielauftrag enthält Start, Ende und Bandbreite. Die Umsetzung reicht durch BSS, Orchestrator, Controller, Zugangssegment, VPN und Rechenzentrumsausgang. Ein Intent wird so zu mehreren Objekten mit verschiedenen Uhren.

Der Entwurf nennt fragmentierte Abläufe für Instanziierung, Überwachung, Fehlersuche, Änderung und Stilllegung. Abstraktionen enthielten oft keine nativen Angaben zu Aktivierungszeit, Dauer, Ablauf oder Rollback. Ähnliche Kennzahlen könnten Definition, Einheit, Scope oder Aktualisierungsrate unterschiedlich fassen. Konfigurationsorientierte APIs lieferten nur begrenzte Evidenz, ob gewünschtes Verhalten angewendet wurde und gültig bleibt.

Der institutionelle Status begrenzt die Aussage. Revision -01 erschien am 15. Februar 2026 und nennt den 19. August als Ablaufdatum. Der bei dieser Recherche aufgerufene Datatracker bezeichnet sie weiterhin als aktiven individuellen Draft; formalen Rang im IETF-Standardisierungsprozess hat sie nicht. Operational und Security Considerations sind noch nicht ausgearbeitet, und der Text schlägt ausdrücklich keine konkrete Lösung vor.

ONSEN selbst ist eine aktive Working Group mit genehmigter Charter. Ihr Auftrag umfasst Abstraktionsmodelle und die Schnittstelle zwischen YANG-Service-APIs und OSS/BSS. Eine Charter erteilt einen Arbeitsauftrag; sie adoptiert nicht rückwirkend einen individuellen Draft.

Ein Schema ist kein Staatsvertrag zwischen Zuständen

RFC 8969 trennt Service-, Netz- und Gerätemodelle und beschreibt, wie Intent nach unten und Betriebsinformation nach oben fließt. Das Informational RFC repräsentiert IETF-Konsens, verspricht aber keine gemeinsame State Machine aller Implementierungen.

RFC 8342 unterscheidet Intended Configuration, Applied Configuration und System State. Transformationen, fehlende Ressourcen, Verzögerungen und Protokollinteraktion können Werte und Lebensdauern auseinanderziehen. Ein erfolgreicher Commit beweist daher keine erfüllte Servicezusage.

RFC 9417 stellt klar, dass angewendete Konfiguration keinen erwartungsgemäß laufenden Dienst garantiert. Sein Assurance Graph verbindet Service-Instanz, Subservices, Health und Symptome; RFC 9418 modelliert die Schnittstellen. Das kann Abweichungen zeigen, rekonstruiert aber ohne weitere Verbindung weder die gekaufte Dauer noch die Abschlussbefugnis.

RFC 8299 beschreibt das kundenseitige L3VPN-Servicemodell, RFC 9182 das betreiberseitige Netzmodell. Feld-Mapping ist notwendig, doch es beweist nicht, welcher untere Übergang eine obere Verpflichtung erfüllt. RFC 9834 hält Administrative und Operational Status ausdrücklich getrennt.

Sechs grüne Lichter, sechs verschiedene Behauptungen

Acceptance belegt eine an dieser Grenze zulässige Anfrage. Validation prüft bekannte Constraints. Commit belegt eine Transaktion. Intended beschreibt das angestrebte, Applied das tatsächlich verwendete Ergebnis. Observed Health beruht auf Messung, Regel, Scope und Zeitpunkt.

Commercial Closure kann Abrechnung oder Kundenpflichten beenden. Resource Closure muss Tunnel, Adressen, Credentials und Monitoring-Abonnements freigeben. Ein geschlossenes Auftragsobjekt vollzieht diese Wirkungen nicht von selbst.

Der Service-Semantik-Beleg

Daniel Kade schlägt für jeden wesentlichen Übergang einen Service-Semantik-Beleg vor. Er erzwingt kein globales Zustandsvokabular, sondern dokumentiert Übersetzungen an Grenzen.

Zunächst bindet er Digest von Auftrag und Intent, Modell- und Modulrevisionen, Features, Deviations, Extensions und den vorausgesetzten Vorzustand. Danach folgen Aktivierungsziel, Dauer, Ablauf, Zeitzone, Uhrquelle, Kulanz und die Trennung von Ereignis- und Beobachtungszeit.

Die Zerlegung verknüpft Kundendienst, Netzinstanzen und Geräte mit stabilen IDs. Adapter und Transformationen werden versioniert. Wird „Transfer bis 18 Uhr beenden“ zu „Kapazität bis 18 Uhr reservieren“, ist der Bedeutungsverlust eine sichtbare Policy-Entscheidung.

Die Evidenz hält Acceptance, Validation, Commit, Intended, Applied und Observed samt Zeitstempeln, Admin- und Operational State, Einheiten, Scope, Freshness und Symptomen fest. Widerspruch bleibt sichtbar. Die Autorität benennt pro Schicht, wer aktivieren, ändern, kündigen, wiederholen, kompensieren, zurückrollen und schließen darf. Das kann eine verifizierbare Rolle oder begrenzte Automation sein.

Der Abschluss verzeichnet freigegebene Ressourcen, verbliebene Konfiguration, gestoppte Abrechnung, verspätete Evidenz und Ungewissheit. Auch der Beleg läuft ab; gestrige Übereinstimmung zertifiziert keinen heute geänderten Dienst.

RFC 9968 hält den IAB-NEMOPS-Workshop fest und behandelt Fragmentierung, Service-Level-Modellierung, Observability, Mapping und verifizierbare Konfiguration. Als Informational Workshop Report warnt er, Teilnehmermeinungen seien nicht notwendig IAB-Positionen und der Bericht behaupte nicht überall Konsens. Er belegt die Debatte, nicht das Mandat für diesen Vorschlag.

Ein genauer Zeitstempel kann eine ungenaue Regel tragen

Zwei Systeme können denselben Timestamp korrekt lesen und gegensätzlich handeln. Für das eine ist das Ende der letzte erlaubte Nutzungszeitpunkt, für das andere der erste Zeitpunkt des Abbaus. Eines lässt bestehende Flows in einer Kulanz auslaufen, das andere trennt an der Grenze. Der Wert stimmt überein, die Zeitregel nicht.

Der Beleg ergänzt Start und Ende daher um Grenzinklusion, Zeitzone, Uhrquelle, Toleranz, Verlängerungsbedingung und Behandlung verspäteter Aktivierung. Ereigniszeit, Beobachtungszeit und Verarbeitungszeit bleiben getrennt. Eine verspätete Nachricht ändert die Empfangsreihenfolge, nicht das historische Ereignis.

Auch ein Retry verlangt eine Regel. Erbt er das alte Fenster, startet ein Dienst womöglich fast abgelaufen. Beginnt er ohne neue Genehmigung eine volle Dauer, erweitert er die Verpflichtung. Policy und Autorität müssen feststehen.

Ein zusammengesetzter Dienst braucht Komponentenstatus

Bei DTS-I können Zugriff, VPN und Rechenzentrumsausgang zu verschiedenen Zeiten wechseln. Ein aggregiertes active sagt nicht, ob alle Segmente angewendet sind, ein Mindestpfad genügt oder Redundanz fehlt. failed sagt nicht, welche Arbeit abgeschlossen und welche Kompensation nötig ist.

Der Beleg bewahrt Komponentenstatus und Aggregationsregel: Erfolg aller oder einer Mindestmenge, kritische Teile, Wirkung von Degradation und Remnants, die Closure verhindern. Auch die Regel wird versioniert, weil ihre Änderung die Aussage derselben Telemetrie verändert.

Über Betreibergrenzen muss der Nachweis keine interne Topologie oder vertrauliche Verträge offenlegen. Begrenztes Commitment, Epoche, Ergebnis und verantwortliche Schnittstelle können genügen; Details bleiben geschützt referenziert. Vertraulichkeit begrenzt Offenlegung, nicht die Ehrlichkeit des Status.

Rollback ist kein Commit rückwärts

Das Entfernen neuer Konfiguration stellt den alten Dienst nicht zwingend wieder her. Kapazität kann neu vergeben, ein Credential widerrufen, Daten können übertragen und externe Systeme durch eine Erfolgsmeldung ausgelöst worden sein. Ein Controller kehrt zurück, ohne BSS, Assurance und Nachbardomain in dieselbe Epoche zu bringen.

Der Beleg trennt technische Wiederherstellung, kommerzielle Kompensation und Evidenzkorrektur. Die erste benennt rückholbare Zustände, die zweite die Verantwortung für irreversible Wirkung, die dritte erhält die alte Entscheidung und ergänzt die Korrektur. Erst dann hat „Rollback abgeschlossen“ einen prüfbaren Scope.

Die Quellen beweisen keinen Vorfall eines benannten Operators, keinen universellen Timeout und keine Pflichtarchitektur. Die belastbare Aussage ist enger: Kompatible Strukturen können unterschiedliche institutionelle Bedeutungen tragen. Beherrschbare Automation bewahrt lokale Wahrheit und macht ihre Übergänge nachweisbar.

Quellen

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://datatracker.ietf.org/doc/html/draft-xie-onsen-problem-statement-01
  5. https://datatracker.ietf.org/doc/draft-xie-onsen-problem-statement/
  6. https://datatracker.ietf.org/doc/draft-xie-onsen-problem-statement/history/
  7. https://datatracker.ietf.org/group/onsen/about/
  8. https://www.rfc-editor.org/info/rfc9968/
  9. https://www.rfc-editor.org/rfc/rfc8969.html
  10. https://www.rfc-editor.org/rfc/rfc8342.html
  11. https://www.rfc-editor.org/rfc/rfc9417.html
  12. https://www.rfc-editor.org/rfc/rfc9418.html
  13. https://www.rfc-editor.org/rfc/rfc8299.html
  14. https://www.rfc-editor.org/rfc/rfc9182.html
  15. https://www.rfc-editor.org/rfc/rfc9834.html