Zusammenfassung

  • RFC 3318 erlaubte * in einer Policy-Rollenkombination. Eine Regel konnte damit Interfaces erfassen, die vorgeschriebene Rollen und beliebig viele zusätzliche Rollen trugen.
  • Die Wildcard schuf keinen Vorrang. Der PDP musste Unvereinbarkeiten lösen; erreichte der Konflikt den PEP, musste dieser ablehnen, statt lokal eine neue Policy zu erfinden.

Doppelte Konfiguration ist leicht zu zählen. Überlappung ist schwerer zu sehen, bis zwei Regeln dasselbe Interface beanspruchen. Der Framework PIB verband beide Probleme mit Rollen: Sie lösten die zentrale Policy von gerätespezifischen Portnamen, während das Sternchen den Geltungsbereich einer Regel verbreiterte.

Im COPS-PR-Modell wählte der Policy Decision Point die bereitzustellenden Informationen. Der Policy Enforcement Point stand für das Gerät, das sie annehmen sollte. SPPI beschrieb Provisioning Classes und ihre Instanzen. RFC 3318 lieferte gemeinsame Begriffe für Rollen, Capability-Sets, Zustandsinkarnationen, Grenzen und Fehler.

Eine Rolle war eine Zeichenfolge für eine Interface-Funktion, etwa finance, manager, Backbone oder Firewall. Ein Interface konnte mehrere Rollen besitzen. Die Policy trug eine RoleCombination; deren Vergleich mit dem Rollensatz entschied über die Anwendbarkeit. So musste der zentrale Server lokale Interface-Kennungen nicht kennen und konnte dieselbe Policy einmal für mehrere gleichartige Ports liefern.

Die Darstellung war kanonisch. Groß- und Kleinschreibung zählten, die Rollen mussten nach ASCII lexikografisch sortiert sein. a+b war gültig; b+a bezeichnete keine andere Kombination, sondern war eine ungültige Schreibweise desselben Satzes. Interfaces ohne Rollen nutzten null.

Das Sternchen machte die Wiederverwendung breiter. In install- oder install-notify-Klassen bedeutete *+a+b: Das Interface enthält a und b sowie null oder mehr weitere Rollen. * durfte nicht als echte Interface-Rolle gemeldet werden und war kein Platzhalter innerhalb eines Namens. Das Beispiel im RFC ließ *+b+e+g auf a+b+c+e+f+g passen.

Drei Interfaces mit den gemeinsamen Rollen A und B, aber den zusätzlichen Rollen R1, R2 und R3, konnten eine einzige Policy *+A+B teilen. Der PDP sparte Kopien, und die Absicht „alles mit A und B“ wurde direkt sichtbar.

Doch Mengeninklusion ist keine Priorität. Mehrere Wildcard-Kombinationen konnten auf dasselbe Interface passen. Manche Policies waren gleichzeitig erfüllbar, andere gaben demselben Mechanismus widersprüchliche Werte. Das Matching bewies nur Anwendbarkeit und enthielt keine Rangordnung.

RFC 3318 gab die Lösung dem PDP. Er sollte Konflikte vor dem Versand beseitigen. Gelangten unvereinbare Policies wegen eines PDP-Fehlers oder einer gerätespezifischen Einschränkung dennoch zum PEP, musste der PEP die Installation ablehnen und einen Fehler melden. Damit blieb Ausführung von Entscheidung getrennt.

Das Beispiel finance und manager machte die Grenze anschaulich. Zunächst konnten zwei Interfaces finance und ein weiteres manager tragen. Nach einer Beförderung meldete ein Interface finance+manager. Der PDP durfte Manager-Policy bevorzugen oder eine dritte Policy erzeugen, etwa DSCP 7 für Finanzmanager. Selbst wenn das Ergebnis einer vorhandenen Policy entsprach, musste der PDP es für die neue Kombination bestimmen.

Der PEP durfte die Antwort nicht aus zwei alten Policies zusammensetzen. Sonst könnten Geräte verschiedener Hersteller dieselben Eingaben verschieden mischen, während der zentrale Controller die Autorisierung des Ergebnisses nicht mehr erklären könnte. Eine Ablehnung ist ein prüfbarer Beleg; eine stille Synthese sieht lediglich erfolgreich aus.

Auch eine Rollenänderung war eine Abfolge. Der PEP meldete Zuordnungen im vollständigen Request-Zustand. Der PDP konnte sie durch eine unaufgeforderte Entscheidung ändern. Nach erfolgreicher Verarbeitung meldete der PEP zuerst Erfolg und sandte danach aktualisierte Vollzustände für offene Kontexte. Bei einem Fehler durfte er nur den Fehlerbericht senden. Vor dem Erfolg sollte der PDP den neuen Zustand nicht voraussetzen.

In diesem Übergang konnten Entscheidungen noch auf alten Rollen beruhen. Eine neue Rolle bewies also nicht, dass jede abhängige Policy bereits neu berechnet war. RFC 3084 definierte Request, Decision und Report; RFC 3159 das PIB-Modell. Rollenabsicht, Annahme, erneuerter Zustand, Installationsbeleg und Paketwirkung blieben getrennte Tatsachen.

Transportschutz löste keine semantische Kollision. RFC 3318 warnte vor schwerwiegender Fehlkonfiguration. Authentisierung konnte den Absender belegen, Verschlüsselung den Inhalt schützen. Keine davon entschied, ob finance oder manager gewinnen sollte.

2016 stufte die IESG RFC 3318, COPS-PR und SPPI als Historic ein. Genannt wurden begrenzte Verbreitung und die Verlagerung auf NETCONF und YANG. Das verbietet Erzählungen über breite Praxis, nicht aber die allgemeine Lehre: Eine Wildcard spart Regeln, nicht die Pflicht zur benannten Konfliktentscheidung.

Quellen: RFC 3318, RFC 3084, RFC 3159 und die IESG-Statusänderung von 2016.