Zusammenfassung

  • RFC 1065 erklärt einen Objekttyp über Name, Syntax, Kodierung und Zugriffskategorie; diese Erklärung ist kein aktueller Messwert einer bestimmten Maschine.
  • Sein Identifikatorbaum delegiert dauerhafte Namen, sein Typsystem diszipliniert die Darstellung; MIB und Protokoll müssen weiterhin sagen, was existiert, wie eine Instanz referenziert wird und was eine Antwort bedeutet.

Ein Katalog war kein Bedienpult

Das frühe TCP/IP-Management musste sich zunächst über Wörter verständigen. Ohne gemeinsame Struktur konnte der Schnittstellenfehler einer Implementierung in einer anderen nur eine private Zahl sein, anders dargestellt und anders übertragen. Doch ein gemeinsames Vokabular erzeugte eine weitere Versuchung: den Katalog mit dem gegenwärtigen Zustand des Netzes zu verwechseln.

Der im August 1988 veröffentlichte RFC 1065 trennte diese Aufgaben. Mit ASN.1 lieferte er gemeinsame Strukturen und ein Identifikationsschema für Managementinformation in TCP/IP-basierten Internets. Seine Structure of Management Information war ein Fundament, kein Betriebslexikon. Der Text sagt ausdrücklich, dass sie weder die tatsächlich von einem bestimmten System verwalteten Objekte noch den protokollspezifischen Mechanismus zur Referenzierung einer Objektinstanz definiert. Die MIB behält die erste Aufgabe, das Managementprotokoll die zweite.

Die Grenze zeigt sich am object type. Ein Typ erklärt, wie eine Klasse von Managementinformation heißt, welche Syntax ihre Werte haben, wie sie kodiert werden und welche Zugriffskategorie gilt. Das ist eine deklarative Beschreibung. Eine object instance ist dagegen ein Typ, der zu einem Zeitpunkt an einen Wert gebunden ist. Der Typ bereitet das Lesen einer möglichen Antwort vor; er liefert weder die Antwort noch den antwortenden Rechner, weder den Zeitpunkt der Messung noch den Beleg, dass der Wert das laufende System weiterhin beschreibt.

Der Baum benannte Verantwortung vor dem Wert

OBJECT IDENTIFIER war das sichtbare Rückgrat dieser Disziplin. RFC 1065 nutzte eine Hierarchie von Bögen und ordnete Internetmanagement unter iso.org.dod.internet ein. Der numerische Pfad erlaubte unabhängig verwalteten Teilbäumen, ohne eine weltweite flache Liste aller denkbaren Variablen nebeneinander zu bestehen.

Es wäre eine Überdehnung, diesen Pfad als Seriennummer eines Geräts, als Primärschlüssel jeder Erscheinung oder als Zusage zu lesen, dass eine Implementierung das Objekt anbietet. Ein Objektidentifikator ist ein strukturierter Name, dessen Verwaltung delegiert werden kann. Er bezeichnet die Definition eines Typs. Wie eine Referenz im Protokoll mit Instanzinformation ergänzt wird und ob ein Agent diese Instanz tatsächlich besitzt, bleibt Sache weiterer Regeln.

Diese Bescheidenheit zählt. Ein stabiler Name ermöglicht Vergleich, löscht aber nicht dessen Umstände. Zwei Agenten können mit demselben Typ antworten; derselbe Agent kann zu verschiedenen Zeiten anders antworten; eine ausbleibende Antwort kann weit mehr bedeuten als das Fehlen eines Typs. RFC 1065 schuf die Grammatik, um diese Fragen zu stellen, statt sie stillschweigend zu beantworten.

Syntax machte einen Wert lesbar, nicht zwingend wahr

Der RFC ergänzte das ASN.1-Grundvokabular um anwendungsweite Typen wie Counter, Gauge, TimeTicks und Opaque. Das war keine Verzierung. Wer Syntax und Kodierung kennt, kann die Bytes lesen, ohne zu raten, ob ein Integer, ein Objektidentifikator oder eine Oktettfolge eingetroffen ist.

Darstellung ist jedoch keine Herkunft. Ein wohlgeformter Counter verrät nicht, wo die Zählung begann; ein TimeTicks-Wert rekonstruiert nicht die größere Geschichte einer Uhr; Opaque wird nicht verständlich, nur weil das umschließende Feld korrekt transportiert wurde. Spätere MIBs und Protokolle konnten einzelnen Typen präzisere betriebliche Bedeutung geben. Der Beitrag von RFC 1065 war enger und dauerhaft: Nicht jeder Managementaustausch sollte seine Grundnotation neu erfinden.

Dasselbe Limit gilt für Zugriff. read-only, read-write, write-only und not-accessible ordnen die erwartete Managementoberfläche eines Typs ein. Sie sind weder Anmeldedaten noch das Ergebnis einer Authentisierung, keine Richtlinienentscheidung für einen bestimmten Betreiber und kein Beweis dafür, dass eine verlangte Änderung gelang. read-write autorisiert nicht jeden Manager; es zeigt nur, dass Lesen und Schreiben zur Deklaration gehören, vorbehaltlich des Systems, das eine Anfrage tatsächlich verarbeitet.

Die Grenze verhinderte, dass ein Protokoll sich als Datenbank ausgab

Mit wachsenden Tabellen, Zählern und Konfigurationssteuerungen wurde die Zurückhaltung der SMI wertvoller. Die MIB definiert Objekte; das Protokoll bildet eine Instanzreferenz, transportiert Anfrage und Antwort; der Agent wendet lokalen Zustand und lokale Politik an; der Manager entscheidet über das Vertrauen in das Ergebnis. RFC 1065 ließ keinen dieser Akteure hinter einem gefälligen Namen verschwinden.

RFC 1155 machte RFC 1065 später obsolet und erklärte zugleich, dessen technischen Inhalt unverändert neu herauszugeben, abgesehen von Status und kleinen typografischen Korrekturen. RFC 1212 bietet spätere Konventionen für knappe MIB-Definitionen, RFC 2578 hält die weiterentwickelte SMIv2-Form fest. Diese Linie erlaubt nicht, spätere Mechanismen in den Text von 1988 zurückzulesen.

Quellen und Grenzen

RFC 1065 belegt Umfang der frühen SMI, Typdeklaration, Identifikatorhierarchie, Wertsytax und Zugriffskategorien. RFC 1155 belegt die technisch unveränderte Neuauflage. RFC 1212 und RFC 2578 sind spätere Vergleiche. Die Texte belegen weder heutige Verbreitung noch den MIB-Inhalt eines Herstellers, die Identität eines antwortenden Agenten, die Autorisierung einer konkreten Sitzung, Datenplaneffekte oder Wahrheit und Frische eines einzelnen Werts. Die Lesart, dass eine dauerhafte Deklaration absichtlich schmaler ist als eine lebendige Beobachtung, ist eine Interpretation dieser dokumentierten Trennung.