Zusammenfassung

  • RFC 3060 standardisierte ein wiederverwendbares Informationsmodell für Richtlinienobjekte: Gruppen, Regeln, Bedingungen, Aktionen und ihre Verknüpfungen. Den Algorithmus, der diese Merkmale in ein Ergebnis überführt, überließ die RFC ausdrücklich den Implementierungen.
  • Das Modell konnte Prioritäten sowie zwingende oder empfohlene Aktionsreihenfolgen darstellen, war deshalb aber noch keine gemeinsame Ausführungsumgebung. RFC 3460 entwickelte es weiter und ergänzte Entscheidungsstrategien; auch das belegt nicht, dass verschiedene Geräte Richtlinien gleich auswerteten.

Eine Regel lässt sich weitergeben, ihre Bedeutung nicht unbedingt

Eine Richtliniendatei kann portabel wirken und am Rand des Netzes dennoch unterschiedliches Verhalten auslösen. Zwei Geräte erhalten vielleicht eine Bedingung und eine Aktion mit denselben Bezeichnungen, werten sie aber mit unterschiedlichen lokalen Fähigkeiten, Erweiterungen oder Routinen aus. Genau diese Unterscheidung steht im Zentrum von RFC 3060, der im Februar 2001 veröffentlichten ersten Fassung des Policy Core Information Model (PCIM).

PCIM beschrieb eine Informationsstruktur. Klassen stellten Richtlinienelemente dar; Assoziationsklassen hielten fest, wie Instanzen zusammenhingen. Eine PolicyRule verknüpfte Bedingungen mit Aktionen. PolicyGroups ordneten Regeln oder weitere Gruppen, und Regeln konnten Prioritäten tragen. Bedingungen ließen sich als ODER-Verknüpfung von UND-Ausdrücken oder als UND-Verknüpfung von ODER-Ausdrücken formulieren, auch mit negierten Aussagen. Damit erhielten Entwerfer eine gemeinsame Form, um festzuhalten, worauf eine Regel zielte und wann sie gelten sollte.

Doch das Schema war nicht zwangsläufig der Ort, an dem das Netz eine Entscheidung traf. Die RFC unterschied das Informationsmodell vom Algorithmus, der es auswertete. Ihr eigenes Beispiel macht das greifbar: Eine allgemeine Regel könnte dem Datenverkehr der Entwicklungsabteilung den Dienst Bronze zuweisen, während eine höherrangige Ausnahme für eine bestimmte Person Gold vorsieht. Das Modell konnte die Überschneidung und Priorität festhalten. Eine konkrete Implementierung musste weiterhin Bedingungen prüfen, die geltende Reihenfolge bestimmen und die ausgewählte Aktion in gerätespezifisches Verhalten übersetzen.

„Deklarativ“ – mit einer bewussten Leerstelle

RFC 3060 nennt den Ansatz deklarativ, grenzt diese Bezeichnung aber sofort ein. Das Modell definiert Entitäten und Attribute; es legt weder einen Algorithmus zur Ergebnisbildung aus diesen Attributen noch eine feste Abfolge von Verarbeitungsschritten fest. Die gewünschte Reihenfolge von Aktionen kann als zwingend oder lediglich empfohlen gekennzeichnet werden, doch das Auswertungsverfahren bleibt außerhalb des gemeinsamen Informationsmodells.

Das ist eine sorgfältig gezogene Grenze und kein Beleg für eine universelle Laufzeitumgebung. Eine Aussage wie „wenn Bedingung C zutrifft, führe Aktion A aus“ benötigt konkrete Definitionen für C und A. Ebenso braucht es Regeln für fehlende oder nicht unterstützte Attribute, widersprüchliche Richtlinien, lokale Ausnahmen und abweichende Gerätefähigkeiten. PCIM bot Erweiterungspunkte, darunter anbieterspezifische Klassen für Bedingungen und Aktionen. Das machte das Modell anpassbar, ließ aber auch unterschiedliche lokale Semantik neben einem gemeinsamen Basisschema zu.

Die Autoren beschrieben den Zielkonflikt: Richtlinien sollten sich von Menschen definieren und diagnostizieren lassen und zugleich auf sehr unterschiedlichen Geräten verarbeitbar bleiben. Ihre kollektive Erfahrung mit Richtlinienverwaltung sei noch begrenzt gewesen; vor einem vollständigen, überkomplexen Modell warnten sie ausdrücklich. Statt jeden denkbaren Fall abzudecken, bevorzugten sie einen gemeinsamen Kern für damalige Anforderungen wie VPN und QoS sowie Entwicklungsmöglichkeiten für neue Erfahrung und Bedürfnisse.

Die RFC ordnete PCIM außerdem in die gemeinsame Arbeit der IETF Policy Framework Working Group und des DMTF-Projekts Common Information Model ein. Spätere Dokumente sollten das abstrakte Informationsmodell auf konkrete Implementierungen abbilden; als Beispiel nennt die RFC ein LDAPv3-gestütztes Verzeichnis. Das ist wichtig: Das Modell war ein möglicher Ausgangspunkt für einen Implementierungspfad, aber kein Nachweis, dass ein bestimmtes Verzeichnis, ein Richtlinienserver oder ein Router es übernommen hatte.

Die umgebende Architektur hatte andere Aufgaben

Das frühere richtlinienbasierte Zulassungsmodell in RFC 2753 trennte den Policy Decision Point (PDP), an dem Entscheidungen getroffen wurden, vom Policy Enforcement Point (PEP), an dem sie ein Netzelement beeinflussten. RFC 2748 definierte anschließend COPS als Protokoll für den Austausch von Anfragen und Entscheidungen zwischen diesen Rollen. RFC 3084 beschrieb eine COPS-Verwendung zur Bereitstellung von Policy Information Bases. Das sind benachbarte Schichten, aber nicht dasselbe wie PCIM: Transportprotokoll, Bereitstellungsmodell und Informationsschema beantworten unterschiedliche Fragen.

Diese Trennung legt auch ein Messproblem offen. Ein Verzeichnis kann eine Regel enthalten; ein PDP kann sie auswerten; ein PEP kann eine Entscheidung erhalten; und ein Router kann eine Konfiguration installieren. Das sind jeweils eigene Ereignisse. Ein PCIM-ähnliches Objekt im Speicher zeigt weder, welche Richtlinienversion ein Gerät verwendet hat, noch ob der Entscheidungspunkt eine Erweiterung verstand, der Durchsetzungspunkt die Entscheidung akzeptierte oder Pakete die vorgesehene Behandlung erhielten.

Die Nachfolge-RFC änderte das Modell, nicht die Beweisanforderung

RFC 3460 aktualisierte PCIM im Januar 2003. Sie ergänzte Elemente, erklärte andere für überholt und ersetzte sie, änderte die Darstellung von Prioritäten und führte administrativ festlegbare Entscheidungsstrategien ein. Das war eine tatsächliche Weiterentwicklung des Informationsmodells. Zugleich zeigt es, dass das frühere Vokabular nicht unveränderlich war: Spätere Arbeit konnte überarbeiten, wie Regelgruppen und Auswertungsoptionen ausgedrückt wurden.

Die Nachfolge-RFC belegt für sich genommen keine einheitliche Ausführung. Ein Feld für eine Entscheidungsstrategie zeigt, welche Wahl ein Modell darstellen kann; es beweist nicht, dass zwei Implementierungen sie gleich auswerten, dieselben Erweiterungen unterstützen oder dasselbe Weiterleitungsverhalten installieren. RFC 3198 unterschied später zwischen abstrakten Geschäftszielen und gerätespezifischen Parametern und wies darauf hin, dass ihre Übersetzung zusätzliche Angaben zu Fähigkeiten und Konfiguration erfordern kann. Eine gemeinsame Darstellung kann Mehrdeutigkeit verringern, beseitigt aber nicht die Übersetzungsarbeit.

Die historische Aussage muss deshalb eng gefasst bleiben. RFC 3060 dokumentiert den Versuch, Richtlinieninformationen in einer vielfältigen Verwaltungsumgebung wiederverwendbar zu machen. Ebenso dokumentiert sie die Grenze dieses Ansatzes: Gemeinsame Objekte bedeuteten keinen universellen Algorithmus. Die Standards belegen das Modell und seine spätere Überarbeitung – nicht, welche Anbieter es implementierten, wie viele Netze es nutzten oder ob ihre Entscheidungen im Produktivbetrieb interoperabel waren.

Die bleibende Lehre lautet, die ganze Kette zu prüfen. Welches Schema und welche Erweiterungen waren vorhanden? Welche Richtlinienversion wertete der Entscheidungspunkt aus? Welcher Algorithmus löste Überschneidungen und Prioritäten auf? Was installierte der Durchsetzungspunkt? Was tat das Netz tatsächlich? Eine interoperable Richtlinienbeschreibung kann wertvoll sein. Sie ist noch kein Beleg für interoperable Ergebnisse.

Quellen