Zusammenfassung

  • RFC 1239 verschob fünf MIB-Wurzeln von experimentellen Bögen unter 1.3.6.1.3 in die Standardzweige mib-2 und transmission.
  • Der Grund war betrieblicher Natur: Späte Umnummerierung erzwang Herstelleränderungen ohne wesentliche technische Neudefinition, konnte Feldprobleme auslösen und frühe Implementierung hemmen.
  • Die Zuordnungstabelle belegt den Standardisierungsbeschluss. Sie belegt nicht, wann ein konkreter Agent, Manager oder Datenbestand umgestellt wurde.

Der OID war längst Bestandteil des Produkts

RFC 1239 beschreibt eine frühere Praxis. Eine MIB erhielt während ihrer Entwicklung einen experimentellen Bogen. Erst als Full Standard bekam sie einen Standardbogen. Dadurch mussten Hersteller ihre Implementierungen beim Statuswechsel überarbeiten, obwohl die Definitionen wahrscheinlich keine wesentliche technische Änderung erfahren hatten.

Die SMI aus RFC 1155 erklärt die Wirkung. Ein Object Identifier ist der administrativ vergebene Name eines Objekttyps. Der Manager fragt diese Zahl ab, der Agent ordnet sie zu, der Sammler speichert sie, die Oberfläche legt einen Text darüber. Wechselt die Wurzel, wechseln die Adressen sämtlicher Nachfahren.

Späte Stabilität setzte außerdem den falschen Anreiz. Wer eine spätere Umnummerierung erwartete, konnte die Implementierung bis Full Standard verschieben. Dann fehlte gerade jene frühe Erfahrung, die einen Standard verbessern sollte. RFC 1239 bevorzugte deshalb frühe Zuweisung im Standardnamensraum und die Bewahrung des Bogens während der weiteren Entwicklung.

Der RFC Editor und der Datatracker führen das Dokument heute als Historic und Legacy. Das klassifiziert den Text, nicht den Softwarestand eines Geräts.

Die Tabelle verschob Wurzeln, nicht nachweislich Geräte

Die Generic Interface Extensions aus RFC 1229 lagen unter 1.3.6.1.3.6. RFC 1239 gab ihnen 1.3.6.1.2.1.12: aus experimental 6 wurde mib-2 12.

Vier weitere Wurzeln wechselten zu transmission. IEEE 802.4 aus RFC 1230 ging von 7 auf 8. IEEE 802.5 aus RFC 1231 ging von 4 auf 9. DS1 aus RFC 1232 wechselte von 2 auf 18, DS3 aus RFC 1233 von 15 auf 30. Die neuen Medienwurzeln lagen unter 1.3.6.1.2.1.10.

Die Genauigkeit der Zahlen ist keine Migrationsanleitung. Der RFC nennt keinen Stichtag, Alias, Parallelbetrieb, Aushandlungsmechanismus, Sammlerkonverter oder Umgang mit historischen Reihen. Er legt die neue Standardadresse fest. Versionen, Konfiguration und Rollout der vorhandenen Systeme bleiben unbeobachtet.

Registerautorität und Geräteantwort sind verschiedene Belege

Das heutige IANA-SMI-Register enthält GenericIF 12 sowie die Transmission-Werte 8, 9, 18 und 30. Einige Einträge verweisen inzwischen auf spätere RFCs. Der aktuelle Registerstand beantwortet die heutige Zuweisung; RFC 1239 dokumentiert den damaligen Wechsel. Keiner der beiden Datensätze ist eine Antwortspur eines bestimmten Agenten.

Scheitert eine Abfrage unter der neuen OID, kann alte Software, fehlende Unterstützung, Zugriffsschutz, Nichterreichbarkeit oder ein Abfragefehler dahinterstehen. Antwortet die alte OID, ist nur diese Antwort an diesem Beobachtungspunkt belegt. Daraus folgt weder die allgemeine Abwesenheit noch die allgemeine Anwesenheit der Standard-OID.

Auch Zeitreihen brauchen einen Herkunftsnachweis. Ein Sammler kann bei gleichem Anzeigenamen den numerischen Schlüssel wechseln und eine Reihe teilen. Automatisches Zusammenführen kann einen gleichzeitigen Versions- oder Bedeutungswechsel verstecken. RFC 1239 meldet kein solches Ereignis. Er zeigt, warum genaue OID, Agent- und Manager-Version, Zeit, Antwort, Zugriffskontext, Speicherschlüssel und Zusammenführungsregel erhalten bleiben müssen.

Stabile Nummern fixieren zudem keine Semantik. Spätere Spezifikationen können Status, Zugriff oder Bedeutung unter derselben Wurzel ändern. RFC 1239 schützte vor unnötigem Adresswechsel; Identitätskontinuität und Bedeutungskontinuität blieben getrennte Aussagen.

Quellen