Zusammenfassung

  • Command Code 314, Application-Id 16777243 und das OMA-Policy-Data-AVP klassifizieren die in RFC 5224 registrierte Anfrage und Antwort. Sie verleihen den transportierten Daten weder Vollständigkeit noch Entscheidungsbefugnis.
  • Die OMA-Architektur erlaubt reine Auswertung. Eine Entscheidung kann an die anfragende Ressource zurückgehen, die selbst über ihre Umsetzung verfügt; alternativ kann PEEM vollstrecken. Eine Antwort lässt den gewählten Pfad nicht automatisch erkennen.
  • Belastbare Automation trennt Entscheidung, Empfang am Enforcement Point, Installation, Aktivierung, spätere Ablösung und beobachtete Wirkung und verbindet sie über unverwechselbare Belege.

Zwischen Antwort und Zustand liegt ein Aktuator

Eine Policy-Plattform kann in einer Sekunde antworten und trotzdem nie Einfluss auf das Zielsystem gewinnen. Das ist kein Widerspruch, sondern eine Folge verteilter Kontrolle.

In einem konstruierten Prüffall sendet ein Dienst eine PDR. Die PDA trifft mit passender Korrelation und Erfolgsstatus ein. Das Dashboard meldet „durchgesetzt“. Der Adapter zum Ziel ist jedoch im Wartungsmodus. Als er zurückkehrt, gilt bereits eine neuere lokale Entscheidung. Der Diameter-Austausch war erfolgreich. Der behauptete Zielzustand trat nicht ein.

RFC 5224 ist Informational und bewusst knapp. Er weist PDR/PDA den Code 314 zu, verwendet Policy-Data Code 1 im OMA-Herstellerraum und registriert 16777243 für die Anwendung. Für den normativen Diameter-Einsatz verweist er auf OMA PEM-1. Damit dokumentiert er den Träger, nicht den gesamten Lebenslauf einer Policy.

Wer aus der Antwort bereits den Endzustand ableitet, lässt das Protokoll für Komponenten sprechen, die es weder steuert noch beobachtet.

Registrierte Zahlen ordnen Semantik, keine Zuständigkeit

Die IANA-AAA-Registry führt die Zuweisungen weiterhin. OMA verwendet Vendor-Id 30079 und kündigt die Anwendung im Capabilities Exchange an. Diese Mechanik ist unverzichtbar: Ohne sie könnten Peers Nachrichten nicht kollisionsfrei interpretieren.

Doch ein Application-Id beantwortet nicht, ob dieser Peer für dieses Konto, diese Sitzung oder diesen Dienst entscheiden darf. Ein Realm routet. Ein Host benennt. Eine Capability behauptet Unterstützung. Nichts davon ist allein eine aktuelle Delegation.

RFC 5224 übernimmt die Sicherheitsbetrachtung aus RFC 3588; RFC 6733 ersetzte das Basisprotokoll später. Geschützte Peer-Kommunikation authentisiert den Gegenüber und schützt Nachrichten. Sie bescheinigt nicht, dass externe Kontextdaten aktuell sind oder der authentisierte Knoten geschäftliche Hoheit über die Ressource besitzt.

Das Vertrauensmodell braucht deshalb drei Datensätze: kryptografischer Peer, Berechtigung zur Anwendung und Mandat für die konkrete Policy. Eine lokale Architektur darf sie koppeln, muss die Kopplung aber versionieren und prüfbar machen.

Ein Template ist ein Decodervertrag

Die PEM-1-Spezifikation kapselt variable Ein- und Ausgaben in BLOBs und Standard- oder Custom-Templates. Dadurch kann dieselbe Schnittstelle sehr unterschiedliche Policies bedienen.

Template-ID und Version sagen, wie Daten strukturiert sind. Sie sagen nicht, ob die Felder aus den richtigen Quellen stammen, noch gültig oder zwischen zwei Betreibern gleich verstanden sind. Ein korrekt dekodierter Standort kann zum falschen Subjekt gehören; ein Kontostand kann im Moment der Entscheidung überholt sein.

OMA zieht die Grenze ausdrücklich: Das Bekanntmachen unterstützter Optionen liegt außerhalb des Scopes. Ebenso wenig definiert PEM-1, wie eine Implementierung Inputs verarbeitet oder eine anfragende Ressource Outputs verwendet. Die Schnittstelle schafft keinen unsichtbaren Konsens über lokale Verarbeitung.

Der Request-Beleg sollte Rohdaten, Template-Version, Subjekt, Ressource, Policy-Version, Herkunft und Beobachtungszeit jedes Kontextwerts sowie delegierte Unteraufrufe binden. Ohne diese Provenienz ist die Entscheidung als Nachricht reproduzierbar, als Urteil aber nicht erklärbar.

Verarbeitung kann Auswertung oder Auswertung plus Vollstreckung heißen

PEM-1 verwendet Policy Processing für beide Varianten. Die PEEM-Architektur trennt sie deutlich.

PEEM kann eine Entscheidung an die anfragende Ressource zurückgeben. Dann kontrolliert diese Ressource den weiteren Umgang. PEEM kann auch selbst vollstrecken und möglicherweise keinen Wert zurückliefern. Ein eigenes Modell zeigt Auswertung ohne Policy-Aktion oder Enforcement durch PEEM.

Auch die Komponenten sind getrennt: PV wertet aus und liefert ein Ergebnis; PF führt als Folge dieses Ergebnisses eine Aktion aus und kann weitere Ressourcen einschalten. Dass beide Funktionen in derselben Software laufen können, macht ihre Belege nicht identisch.

RFC 2753 verortet Entscheidungen am PDP und tatsächliche Durchsetzung am PEP. RFC 3198 definiert Enforcement als Ausführung einer Policy-Entscheidung. Die Pflicht des PEP ist eine Sollensnorm. Der Nachweis, dass es im Einzelfall handelte, ist ein Ist-Befund.

Erfolg ist kein einheitlicher Datentyp

Diameter liefert Protokollergebnisse über Result-Code oder Experimental-Result. „Experimental“ bedeutet hier herstellerspezifischer Ergebniscontainer, nicht beobachtetes Experiment.

PEM-1 besitzt zusätzlich ein Output-Status-Template mit obligatorischem statusCode für den Verarbeitungsabschluss oder einen Fehler. Schließlich enthält die Policy-Ausgabe die fachliche Entscheidung oder Daten für den Requestor.

Alle drei Ebenen können erfolgreich sein, bevor ein Zielsystem verändert wurde. Nachricht angenommen, Verarbeitung abgeschlossen, Entscheidung zurückgegeben – danach kann der Vollstrecker ablehnen, nur teilweise installieren oder von einem neueren Zustand überholt werden. Umgekehrt kann PEEM intern vollstrecken und nur knappen Status melden.

Ein brauchbares Zustandsmodell sagt: transportiert, protokollarisch akzeptiert, ausgewertet, Entscheidung zurückgegeben, vom Vollstrecker empfangen, installiert, aktiv, Wirkung beobachtet, abgelöst, zurückgerollt. Ein UI darf gruppieren; die darunterliegenden Fakten dürfen nicht verschmelzen.

NO_STATE_MAINTAINED ist keine Policy-Historie

Die OMA-Bindung setzt Auth-Session-State auf NO_STATE_MAINTAINED. Der Server hält keinen Diameter-Sessionzustand, der Client sendet keine Terminierung. Das macht den Aufruf leichtgewichtig, liefert aber keinen dauerhaften Verlauf über Installation oder Ablösung.

Diese Abgrenzung verhindert auch Wiederholung bestehender Arbeiten. RFC 3539 behandelt Watchdogs, Failover, wartende Requests und Duplikate. Transportzuverlässigkeit kann Empfang erklären, nicht Durchsetzung. RFC 2989 beschreibt AAA-Fähigkeiten; eine vorhandene Fähigkeit ist kein Transaktionsbeleg. RFC 7683 und RFC 4006 zeigen ebenfalls, dass Lastzustand, Anwendungszustand und Dienstwirkung je eigene Semantik tragen.

Der Beleg gehört an den Kontrollwechsel

Eine belastbare Kette speichert Request und Route, sicheren Peer, Subjekt und Ressource, Policy- und Template-Version, Inputquellen, Auswertungsabhängigkeiten, Protokollergebnis, PEEM-Status und Fachausgabe getrennt. Danach folgen designierter Vollstrecker, Empfang, Installationsziel, Vorzustand, Konfliktprüfung, Readback, Aktivierung, Teilfehler, Rollback, spätere Entscheidungen und eine Wirkungsmessung, die auf den ursprünglichen Request zurückverweist.

Fakten werden ergänzt, nicht rückwirkend umbenannt. Eine später abgelöste Entscheidung wurde trotzdem zurückgegeben. Eine gescheiterte Installation macht die Antwort nicht nachträglich falsch; sie dokumentiert den Bruch im nächsten Glied. So bleiben Ursache und Kompensation präzise.

Lu Hengs Unterscheidung von Realitätsschichten setzt dafür den richtigen Maßstab. Eine Nummer klassifiziert, eine Antwort protokolliert, eine Entscheidung weist an. Operative Realität entsteht erst, wenn laufende Systeme akzeptieren, installieren, handeln und beobachtbaren Zustand offenlegen. Jede Evidenz sollte nur die Autorität des Ereignisses tragen, das sie tatsächlich gesehen hat.

Quellen

  1. RFC 5224
  2. RFC 5224 als Text
  3. RFC 5224 im IETF Datatracker
  4. Status von RFC 5224
  5. Historie von RFC 5224
  6. Errata zu RFC 5224
  7. RFC 3588
  8. RFC 6733
  9. RFC 3539
  10. RFC 2989
  11. RFC 2753
  12. RFC 2748
  13. RFC 3198
  14. RFC 3084
  15. RFC 2903
  16. RFC 2904
  17. RFC 4006
  18. RFC 7683
  19. RFC 5234
  20. IANA AAA Parameters
  21. OMA PEM-1 Technical Specification
  22. OMA PEEM Architecture
  23. OMA PEEM Requirements
  24. OMA Registry for Private AVP Codes
  25. Lu Heng — Reality Layers and Symbolic Power
  26. Lu Heng — Running-Code Primacy
  27. Lu Heng — The Agency Problem