Zusammenfassung

  • RFC 3159 verlangte, dass PIB-INDEX genau eine InstanceId bezeichnete. Dieser Wert hatte ausdrücklich keine Semantik außer der Identifikation der PRC-Instanz. Eine präzise Adresse war noch keine Policy-Erklärung.
  • Bedeutung entstand aus PIB-Modul, PRC und Textual Conventions, Subject Category, Zugriffsart, Eindeutigkeits- und Referenzregeln, Konformität sowie den unterschiedlichen Lebenszyklen von AUGMENTS und EXTENDS.
  • Annahme und Wirkung brauchten spätere Belege: COPS-PR-Austausch, Transaktionsergebnis, PEP-Zustand, tatsächlich erzwungenes Verhalten und Anwendungsergebnis. Historic-Status und begrenzte Verbreitung ändern diese Trennung nicht.

Zwei Nummern waren noch keine zwei Absichten

Ein PDP sendet zwei Provisioning Instances an einen Router. Klassifikator, Aktion, Schwelle und referenzierte Warteschlange stimmen überein. Nur die InstanceId ist verschieden.

Eine Oberfläche kann zwei Zeilen anzeigen, aber daraus folgen nicht automatisch zwei Policies. Das Modul kann gleiche Inhalte erlauben. Eine Eindeutigkeitsklausel kann sie verbieten. Eine Zeile kann eine sparse Erweiterung ohne vorhandene Basis sein. Beide können in verschiedenen virtuellen Informationsspeichern liegen. Und auch nach erfolgreicher Schemavalidierung kann das PEP die Installation ablehnen.

SPPI begrenzte die Aussage des Identifikators. PIB-INDEX enthielt einen Deskriptor mit der Syntax InstanceId. Der auf Unsigned32 beruhende Wert besaß keine andere Bedeutung, als eine Instanz zu identifizieren. An die OID der Zeilendefinition angehängt, bildete er die PRID.

Die PRID war eine Adresse, keine komprimierte Geschäftsaussage. Würde ein Produkt Mandant, Priorität oder Region heimlich in die Nummer codieren, entstünde ein zweites, unsichtbares Schema. Eine spätere Umnummerierung könnte diese Bedeutung zerstören, ohne das formale Modell zu verletzen.

SPPI übernahm SMI-Werkzeuge, aber nicht unbesehen deren Sprache

Die im August 2001 veröffentlichte Structure of Policy Provisioning Information passte die SNMP-SMI an Policy Information Bases an. ASN.1-Formen, Erfahrung und Werkzeuge konnten wiederverwendet werden.

COPS verwendete jedoch bereits den Begriff object für Protokollelemente. SPPI nannte Tabellen- und Zeilendefinition deshalb Provisioning Class, kurz PRC. Eine instanziierte Zeile war eine Provisioning Instance, PRI, eine Spalte ein Attribut. Ein Gegenstück zu skalaren SMI-Objekten gab es nicht.

MODULE-IDENTITY vermittelte die Modulsemantik. OBJECT-TYPE beschrieb Syntax und Semantik von PRCs und Attributen. Textual Conventions gaben wiederverwendeten Grundtypen eine bestimmte Bedeutung. Objektgruppen und Konformitätserklärungen setzten Mindestgrenzen für Implementierungen.

Das war ein Datenmodell, keine Ausführung. Eine PRI konnte korrekt codiert, vollständig und typgültig sein, ohne vom PEP angenommen zu werden. Annahme bewies weder die lokale Installation noch die Änderung des Paketverhaltens.

PIB-INDEX adressierte, INDEX diente der Konvertierung

Eine Basiszeile benötigte PIB-INDEX, sofern sie ihre Identität nicht über AUGMENTS oder EXTENDS erbte. Der eine Deskriptor verwies auf ein InstanceId-Attribut, meist, aber nicht zwingend, derselben PRC.

Daneben konnte ein gewöhnlicher INDEX stehen. Er hatte nur eine Rolle bei der algorithmischen Umwandlung einer PIB in eine MIB. Beide Klauseln gleichzusetzen hieße, die Identität einer Provisioning-Instanz mit der Indizierung ihrer abgeleiteten Managementdarstellung zu verwechseln.

Ein Auditarchiv braucht daher mehr als die PRID. Es muss Modul und Revision, PRC-Definition, Textual Conventions und Kontext erhalten. Ohne Wörterbuch bleibt selbst eine eindeutige OID verwaist.

Mit dem Schema lässt sich erklären, was eine Zeile bedeuten darf. Ob sie installiert wurde, bleibt eine eigene Beweisfrage.

Bedeutung entstand aus mehreren verbundenen Verträgen

Die PRC definierte Attribute und Beschreibungen. Textual Conventions verliehen einfachen Zahlen oder Zeichenfolgen eine spezifische Semantik. SUBJECT-CATEGORIES verband ein Modul mit benannten COPS Client Types oder mit allen Kategorien. Dasselbe Modul konnte in mehreren virtuellen Speichern vorkommen.

PIB-ACCESS legte den Informationsfluss fest. install erlaubte dem PDP, Instanzen im PEP einzurichten. notify verlangte, dass das PEP dem PDP alle Instanzen und Werte mitteilte. install-notify kombinierte beides. report-only war weder regulär installierbar noch auf diese Weise meldepflichtig, konnte aber in PEP-Berichten erscheinen.

Der PRID war diese Rolle nicht anzusehen. Eine installierbare Zeile und eine reine Berichtszeile konnten gleich stabile Nummern besitzen. Wer sie erzeugte und welche Operation zulässig war, ergab sich erst aus der Definition.

Eine Konformitätserklärung beschrieb wiederum minimale Fähigkeit, nicht die Existenz einer bestimmten aktiven PRI.

Eindeutigkeit war nicht dasselbe wie Protokollidentität

UNIQUENESS listete Attribute auf, deren Wertkombination sich zwischen PRC-Instanzen nicht wiederholen durfte. Das PIB-INDEX-Attribut durfte nicht Teil dieser Liste sein.

Damit trennte SPPI die referenzierbare Zeilenidentität von einer inhaltlichen Eindeutigkeit. Bei einer leeren Klausel durften zwei Instanzen in allen Attributen außer der Instanznummer identisch sein.

Unterschiedliche IDs beweisen folglich keine unterschiedlichen Policies. Gleicher Inhalt erlaubt umgekehrt keine automatische Zusammenführung: Referenzen, Speicher oder Lebenszyklen können verschieden sein.

RFC 3159 empfahl UNIQUENESS, wo sie nützliche Information lieferte, verlangte sie aber nicht überall. Fehlt die Deklaration, darf ein Werkzeug nicht willkürlich Felder zur natürlichen Schlüsseldefinition machen.

Ein Referenzwert brauchte einen deklarierten Zieltyp

Ein ReferenceId-Attribut erforderte PIB-REFERENCES; die Klausel nannte die PRC der Zielinstanz. TagReferenceId erforderte PIB-TAG, das ein Attribut zur Bildung einer markierten Instanzmenge benannte.

Die erste Beziehung zeigte auf eine Instanz eines erklärten Typs. Die zweite wählte eine Gruppe mit demselben Tag. Die Integerbytes allein verrieten weder Beziehungsart noch Ziel.

Instanz 12 in einer Queue-PRC war nicht automatisch Instanz 12 in einer Threshold-PRC. Tag 7 wurde außerhalb seines Moduls und Attributs nicht zu einer universellen Gruppe. Wer nur die Zahl speicherte, bewahrte den Anschein eines Links und verlor dessen Richtung.

Wiederherstellbarer Nachweis umfasst Quellattribut, Textual Convention, Ziel-PRC, Identitätsregeln der Zielseite und Modulrevision.

Basis, Augmentation und sparse Erweiterung hatten verschiedene Lebenszyklen

Jede Zeilendefinition wählte genau eine Form: eigener PIB-INDEX, AUGMENTS oder EXTENDS.

Eine AUGMENTS-PRC stand eins zu eins zu ihrer Basis, verwendete deren Index und teilte deren Existenz. Installation oder Entfernung der Basis installierte beziehungsweise entfernte auch alle zugehörigen Augmentationen.

EXTENDS beschrieb eine null-oder-eins-Beziehung. Die sparse Instanz konnte ohne Basis nicht existieren; die Basis konnte jedoch ohne sie bestehen. Die Erweiterung musste ausdrücklich installiert werden, konnte vorher separat entfernt werden und verschwand implizit mit der Basis. Bei gemeinsamer Installation mussten beide in einer COPS-Nachricht stehen.

Dieselbe Instanznummer konnte somit in drei Zeitregimen vorkommen. Eine Wiederherstellung bloßer Zeilen ohne Beziehungen konnte einen adressierbaren, aber unzulässigen Waisen erzeugen.

Identität verbindet Datensätze. Der Lebenszyklus entscheidet, ob die Verbindung über die Zeit gültig war. Ein Snapshot ersetzt keine Installationshistorie.

Eine gültige Zeile konnte bei der Installation scheitern

INSTALL-ERRORS konnte PRC-spezifische Gründe für die Ablehnung einer Installation oder Entfernung aufzählen. Jeder Grund erhielt einen COPS-Untercode. Fehlte die Klausel, konnte die Operation dennoch scheitern; es stand lediglich kein PRC-spezifischer Fehler zur Verfügung.

Schemavalidierung war also keine PEP-Annahme. Annahme war kein Transaktionsabschluss. Abschluss war kein verifizierter Gerätezustand. Konfiguration war keine nachgewiesene Paketwirkung. Paketwirkung war kein Anwendungserfolg.

COPS-PR stellte Entscheidungen, Fehler, Abschluss oder Abbruch, Cache-Zustand und Wiederverbindung bereit. SPPI beschrieb die transportierten Daten. Die Belege ergänzten einander, ohne austauschbar zu sein.

Ein grüner Status muss benennen, welche Stufe er bestätigt. Sonst verschluckt der früheste Syntaxerfolg alle späteren Ungewissheiten.

Konformität war eine Fähigkeit, keine einzelne Ausführung

Objektgruppen sammelten zusammengehörige Attribute. MODULE-COMPLIANCE definierte verpflichtende Gruppen und Mindestzugriff. Eine konforme Implementierung musste die betreffenden Attribute und PRCs umsetzen.

Sie musste aber keine konkrete Instanz installiert haben. Eine gespeicherte PRI konnte inaktiv sein. Eine aktive Regel konnte nie auf Daten treffen. Fähigkeit, Konfiguration und Ergebnis waren eigenständige Zustände.

Auch die Security-Aussage der RFC war eng: Die Sprache zur Definition von Provisioning-Information habe selbst keine Sicherheitswirkung auf das Internet. Das war keine Zertifizierung von COPS-Sitzungen, PDP-Berechtigung, Policy-Inhalt oder PEP-Implementierung.

Nachweise dürfen nicht stillschweigend über ihre Schicht hinaus wachsen.

Historic bedeutete Richtungswechsel, nicht Nichtexistenz

RFC 6632 hielt später fest, dass COPS-PR nicht weit verbreitet war. Betreiber fanden die binäre Codierung für einfache Aufgaben in üblichen textbasierten Skriptsprachen unhandlich. Kein PIB-Modul wurde als Proposed Standard zugelassen; COPS-PR wurde nicht mehr empfohlen. RFC 3159 ist heute Historic.

Diese Entwicklung gehört zur Geschichte. SPPI ist keine gegenwärtig dominierende Konfigurationsmethode. „Nicht weit verbreitet“ bedeutet jedoch nicht „niemals implementiert“, und Historic beweist nichts über ein bestimmtes Gerät.

Der aufgegebene Weg bewahrt eine klare Grenze: Adresse, Bedeutung, Zugriff, Existenzbeziehung, Transaktion und Wirkung sind nicht synonym. Moderne APIs wiederholen denselben Fehler, wenn sie eine Ressourcen-URI oder HTTP 200 als Ausführungsbeleg darstellen.

Verbreitung erklärt, welche Technik gewann. Sie entscheidet nicht allein, welche Entwurfsdisziplin fortlebt.

Das dauerhafte Artefakt war die Nachweiskette

Ein prüfbarer Datensatz beginnt mit PIB-Modul, Revision, Subject Category und virtuellem Speicher. Er erhält PRC, Textual Conventions, Basis- oder Erweiterungsbeziehung, InstanceId, PRID, Eindeutigkeit, Referenzen, Tags, Zugriff und Konformitätsprofil.

Danach folgen COPS-PR-Anfrage und Entscheidung, Transaktionskennung und Ergebnis, Fehler, Cache- und Wiederverbindungskontext sowie PEP-Zustand vorher und nachher. Beobachteter Verkehr belegt die Durchsetzung. Die Anwendung bewertet schließlich das Ergebnis.

Das Modul erklärt Felder. Der PRID bezeichnet die Instanz. Das Protokoll belegt den Austausch. Das Gerät belegt die Installation. Verkehr belegt die Anwendung, und die Anwendung belegt den Nutzen.

Der Index aus RFC 3159 war gerade deshalb belastbar, weil er nicht vorgab, diese gesamte Kette zu sein. Er benannte die Zeile; er erzeugte nicht das Ergebnis.

Quellen