Zusammenfassung

  • RFC 3737 übertrug die Zuständigkeit für künftige RMON-MIB-Modulwurzeln von der Arbeitsgruppe an IANA, ließ aber bereits vergebene OIDs unverändert.
  • Die Grenze blieb eng: IANA vergibt die MODULE-IDENTITY-Wurzel unter rmon; Modulautoren und -redakteure vergeben die gewöhnlichen Objekt-IDs innerhalb des Moduls.

Eine Liste, die funktionierte – bis zu den späten Korrekturen

Remote-Monitoring-MIBs hatten sich unter dem Knoten rmon im MIB-II-Baum angesammelt, bei 1.3.6.1.2.1.16. Die RMONMIB-Arbeitsgruppe führte eine eigene Liste neuer Modulzuweisungen. RFC 3737 bezeichnet dieses Verfahren nicht als gescheitert: Es habe recht gut funktioniert. Allerdings mussten Fehler mitunter erst spät korrigiert werden, und einige Zuweisungen waren hinfällig geworden. Außerdem wich das Verfahren vom üblichen Weg ab, bei dem ein Standards-Track-MIB-Modul seine Wurzel bei der Veröffentlichung des RFC erhält.

Die Tabelle des RFC macht sichtbar, was sich in dieser Struktur vermischt hatte: Frühe Einträge benennen Objektgruppen für Statistiken, Verlauf, Alarme und Erfassung; spätere Zahlen stehen für MODULE-IDENTITY-Wurzeln, verfügbaren Raum, reservierte Werte und eine hinfällige Zuweisung. RFC 3737 sagt ausdrücklich, dass manche historischen Entscheidungen unlogisch sind und nicht geändert werden können. Die Antwort war ein Zuständigkeitswechsel für künftige Entscheidungen, keine Umnummerierung.

IANA erhielt die Wurzel, nicht das ganze Modul

RFC 3737 überführte das Zuweisungsverzeichnis in das SMI-Numbers-Register und beauftragte IANA mit seiner Pflege. Künftig sollte IANA nur MODULE-IDENTITY-Wurzeln unter rmon vergeben. Die gewöhnlichen OIDs innerhalb eines Moduls wiesen dessen Autoren oder Redakteure weiterhin nach den normalen MIB-Verfahren zu. Für eine neue Wurzel verlangte RFC 2434, der damals geltende Leitfaden, eine Standards Action; IANA vergab die Nummer bei der RFC-Veröffentlichung.

Diese Grenze trennt den gemeinsamen Namensraum-Punkt, an dem zwei Wurzeln kollidieren könnten, von der internen Gliederung eines Moduls. Die Wurzel zentral zu registrieren hieß nicht, die technische Ausgestaltung jedes Objekts zu zentralisieren. Die Arbeitsgruppe war nicht länger alleinige Hüterin der nächsten Wurzel, wurde aber auch nicht zur Gestalterin sämtlicher innerer Modulzweige.

Die heutige IANA-Seite führt den rmon-Baum weiterhin auf, mit späteren Referenzen, verfügbarem Raum, einem hinfälligen Eintrag und reservierten Werten. Das ist ein zeitgebundener Registerstand, kein Beleg für die Implementierung oder den Einsatz eines Moduls. Eine eingetragene Wurzel, eine implementierte MIB und eine tatsächlich erhobene Monitoring-Beobachtung sind verschiedene Nachweise. RFC 3737 änderte, wer die nächste Wurzel registriert; ein Registereintrag wurde dadurch nicht zum Beweis laufenden Codes.

Quellen