Zusammenfassung

  • RFC 1442 verlangte pro Informationsmodul genau eine MODULE-IDENTITY mit OID, verantwortlicher Organisation, Kontakt, letzter Bearbeitung und beschriebenen Revisionen.
  • Die Makroerweiterung findet laut RFC begrifflich während der Implementierung statt, nicht zur Laufzeit. Sie dokumentiert die Herkunft eines Moduls, aber weder den Objektumfang noch die Zugriffsrechte oder das Verhalten eines konkreten Geräts.
  • RFC 1902 und RFC 2578 bewahrten diese Trennung. Kompatible Änderungen bleiben unter demselben Modulnamen; inkompatible Bedeutung braucht einen neuen Deskriptor und eine neue OID; obsolete Definitionen und ihre OIDs werden nicht wiederverwendet.

Der Compiler hatte den neueren Stand

In einem NOC wird die MIB-Bibliothek aktualisiert. Ohne Firmwarewechsel erscheinen daraufhin verständlichere Bezeichnungen und eine jüngere Revisionsangabe neben denselben Messwerten. Die Oberfläche lässt den Eindruck entstehen, auch das entfernte Gerät sei neuer geworden.

Geändert hat sich zunächst nur der Interpret. Der Agent lieferte OIDs und codierte Werte; der Collector entschied, mit welchem Schema er sie las. Eine aktuelle Definition kann alte Antworten korrekt deuten. Ein Hersteller kann aus einem jüngeren Modul nur einen Teil instrumentieren. Eine Access View kann vorhandene Objekte verbergen, ein Proxy kann für einen anderen Agenten antworten.

RFC 1442 machte die Herkunft der Compiler- und Werkzeugseite besser überprüfbar. Es machte sie nicht zur Selbstauskunft des Geräts. Gerade diese Begrenzung bewahrt den Wert des Datums.

Das Modul bekam eine eigene Herkunft

SMIv2 unterschied drei Definitionsarten: MODULE-IDENTITY für das Informationsmodul, OBJECT-TYPE für verwaltete Objekte und NOTIFICATION-TYPE für Meldungen. Das Modul war damit nicht länger nur die anonyme Hülle einer OID-Sammlung, sondern ein benanntes und verantwortetes Artefakt.

Nach möglichen imports oder exports sollte genau eine MODULE-IDENTITY stehen. Sie nannte die zuständige Organisation, einen Kontakt, den letzten Bearbeitungszeitpunkt sowie Revisionen mit Beschreibung. Wer ein Modul erhielt, konnte dessen Namensraum und redaktionelle Linie aus dem Dokument selbst nachvollziehen.

Das stabilisierte auch Abhängigkeiten. Andere Module importierten Deskriptoren aus einem benannten Modul. Würde jede kompatible Korrektur einen neuen Modulnamen erzwingen, zerfiele eine zusammengehörige Linie und Werkzeuge müssten unnötige Brüche verwalten.

Das Makro war jedoch kein abfragbares Managementobjekt. RFC 1442 erklärte ausdrücklich, seine Expansion erfolge konzeptionell zur Implementierungszeit und nicht zur Laufzeit. Die enthaltenen Zeitangaben und die OID sehen wie Betriebsdaten aus, sind aber Deklarationen des Schemas. Ein Agent musste daraus kein Live-Register seiner Baugeschichte machen.

LAST-UPDATED datierte einen Text

Ohne Subjekt wirkt LAST-UPDATED umfassend. Es könnte nach letzter Firmwareinstallation, letztem Neustart oder letzter Konfigurationsänderung klingen. In der SMI bezeichnete es allein den Zeitpunkt, an dem das Informationsmodul zuletzt bearbeitet wurde.

Auch die REVISION-Klauseln waren kein Deployment-Log. Sie verbanden Zeit und Beschreibung einer Moduländerung und standen in umgekehrter zeitlicher Reihenfolge. In RFC 1442 waren sie noch optional. Eine fehlende Liste bewies also keine unveränderte Implementierung; eine vollständige Liste bewies keine Adoption.

Ein belastbarer Bestand führt mehrere Uhren. Für das Schema werden Quelle, Hash und Erwerbszeit festgehalten. Für Software werden Paket- oder Herstellerprovenienz dokumentiert. Für die Beobachtung zählen Endpoint, Identität, Kontext, Anfrage und Antwort. Für die Wirkung braucht es eine unabhängige Kontrolle. Erst die Verknüpfung dieser Uhren ermöglicht eine Aussage; ihre Verschmelzung zu „Version“ vernichtet Herkunft.

Ein stabiler Name war ein Kompatibilitätsversprechen

Der Modulname sollte bei zulässigen Revisionen bestehen bleiben. Beschreibungen ließen sich präzisieren, Referenzen korrigieren und bestimmte Eigenschaften in kompatibler Richtung verändern. Das schützte ältere Implementierungen und die Module, die Definitionen importierten.

Die Beständigkeit war aber keine Erlaubnis zum Bedeutungswechsel. Lag eine Änderung außerhalb der erlaubten Kategorien, musste die neue Definition einen anderen Deskriptor und eine neue OID erhalten. Eine alte Adresse durfte nicht unbemerkt einen neuen Vertrag tragen.

Der Name bezeichnete somit eine kontrollierte Abstammungslinie, keine identische Binärdatei. Mehrere Ausgaben konnten denselben Modulnamen tragen. Ein Gerät konnte nur einen Ausschnitt implementieren, und die sichtbare Menge konnte zusätzlich von Berechtigungen abhängen.

Zwei Nachfolger bestätigten die Grenze

RFC 1902 löste RFC 1442 im Jahr 1996 ab. Die drei Definitionsarten, die einmalige Modulidentität und die Unterscheidung zwischen Implementierungs- und Laufzeit blieben erhalten. Ein obsolet gewordener Text hinterließ also eine weiter geltende architektonische Entscheidung.

1999 wurde RFC 1902 durch RFC 2578 ersetzt, den Internet Standard für SMIv2. Dort wurde die Revisionsdisziplin deutlicher: Verschiedene Versionen dürfen denselben Modulnamen behalten; Änderungen sollen keine Interoperabilitätsprobleme über die Leitung erzeugen; jede Änderung muss in der Revisionsinformation erscheinen; Definitionen sollen nicht willkürlich in andere Module wandern.

Besonders folgenreich ist der Umgang mit obsolete. Solche Definitionen werden nicht entfernt, und ihre OIDs dürfen nie neu vergeben werden. Der alte Bedeutungsraum bleibt reserviert, damit spätere Software einem bekannten numerischen Ort nicht einen anderen Vertrag unterschiebt.

current, deprecated und obsolete sind deshalb Statusangaben über die normative Verwendung einer Definition. Sie sind keine Messergebnisse. Ein obsoletes Objekt kann noch antworten, ein aktuelles kann fehlen, ein deprecated Objekt kann aus Kompatibilitätsgründen weiterlaufen oder nur unter bestimmten Views sichtbar sein.

Welche Aussage braucht welchen Beleg?

MODULE-IDENTITY kann mit Quelle und Hash eindeutig belegen, welches Schema ein Werkzeug verwendet hat. Es verankert OID, Verantwortung und redaktionelle Geschichte. Dadurch lässt sich nachvollziehen, warum ein Rohwert mit einem bestimmten Typ, einer Einheit oder einem Anzeigenamen interpretiert wurde.

Allein belegt es nicht, dass ein Agent das Modul enthält, alle Objekte instrumentiert, dem anfragenden Principal Zugriff gewährt, die beschriebene Semantik einhält oder eine Schreiboperation eine dauerhafte Außenwirkung hatte. Das sind fünf Behauptungen über andere Kontrollflächen.

Objektsonden und erhaltene Fehlermeldungen unterscheiden Abwesenheit von Verweigerung. Conformance Groups geben einen Prüfrahmen. Security Identity, Context und View begrenzen Sichtbarkeit. Kontrollierte Versuche und externe Zustandsbeobachtung prüfen Verhalten. Eine spätere Messung nach einem Lebenszyklusereignis prüft Persistenz.

Statt „Gerät D führt Revision R aus“ sollte der Nachweis daher lauten: Collector C lud das Schema mit Hash H, fragte Endpoint E zum Zeitpunkt T unter Identität P ab, erhielt für Objekt O die Antwort A und verglich deren Wirkung mit Beobachtung B. Jeder Übergang bleibt sichtbar und korrigierbar.

Die Stärke einer bescheidenen Registrierung

RFC 1442 löste ein dauerhaftes Problem: Definitionen mussten sich ändern können, ohne ihre Verantwortung und ihre Adresse zu verlieren. Der feste Modulname und die Revisionsspur machten diese Entwicklung prüfbar. Die Nachfolger übernahmen das Modell, weil es im Ökosystem funktionierte.

Eine Registrierung wird nicht dadurch schwach, dass sie ihre Reichweite begrenzt. Schwach wird sie, wenn man ihr Aussagen zuschreibt, die nie erhoben wurden. Schema, Build, Netzantwort und Gerätewirkung sind verbundene, aber eigenständige Wirklichkeiten.

Der Modulname durfte bleiben. Ob die Maschine hinter der Glasscheibe die neueste Bedeutung ausführte, musste jedes Mal neu bewiesen werden.

Quellen