Zusammenfassung

  • BCP 139 warnt davor, einen veröffentlichten MIB-RFC als Vorlage zu kopieren: Das Dokument bleibt unverändert, während Boilerplate und andere Anforderungen weiterziehen.
  • Bei der aktuellen Erhebung endeten die historischen URLs für XML, kommentierten Text und Klartext auf derselben generischen Vorlagenseite. Der erfolgreiche Abruf beweist den Webpfad, nicht die Identität des benannten Artefakts.

Der Prüfer bekam drei grüne Haken und keine Versionsnummer

Die Linkprüfung meldete Erfolg. Die XML-Vorlage war erreichbar, ebenso die Textfassung mit Hinweisen und die Fassung ohne Hinweise. Erst die gespeicherten Endadressen zeigten, dass alle drei Anfragen an derselben Stelle ankamen.

Diese Stelle gehört zur IETF und bietet aktuelle Autorenressourcen. Dennoch bezeichnete sich die Antwort nicht als eine der drei MIB-spezifischen Dateien. Ein grüner Haken hatte eine Transportfrage beantwortet: Kam die Anfrage irgendwo an? Die Prüffrage lautete aber: Welches konkrete Artefakt hat die Entscheidungen des Autors geprägt?

Beide Fragen sind legitim. Nur ihre Antworten dürfen nicht zusammengelegt werden.

Der feste Standard delegiert an einen veränderlichen Eingang

RFC 5249 erschien 2008 als BCP 139. Sein Ausgangspunkt war die damals verbreitete Praxis, einen vorhandenen MIB-RFC als Muster zu verwenden. Das spart Arbeit und sieht konservativ aus, übernimmt jedoch den historischen Stand von Pflichttexten, Copyright, IANA-Hinweisen und Prüfgewohnheiten.

Die MIB Doctors stellten deshalb drei Varianten bereit. XML2RFC-Quelltext enthält erläuternde Kommentare. Eine Textfassung behält Ratschläge, eine andere nur die saubere Struktur. Der RFC erklärt, dass zahlreiche MUSTs in den Hinweisen auf IESG-Anforderungen zurückgehen und bei der Prüfung auffallen werden. Die Vorlagen sollen gelegentlich aktualisiert werden.

Damit entsteht ein bewusst zusammengesetzter Kontrollpfad. Der RFC definiert das Prinzip, die externe Vorlage konkretisiert den jeweils aktuellen Startpunkt. Weitere Richtlinien, Werkzeuge und Fachurteile ergänzen ihn. Der Satz „nach RFC 5249 erstellt“ identifiziert nur das Prinzip, nicht die verwendete Revision.

Weiterleitung ist keine signierte Nachfolge

Die OPS-Seite nennt weiterhin drei MIB-Vorlagen und verweist auf Aktualisierungen vom Juni 2013. Ihre früheren tools.ietf.org-Adressen leiten auf authors.ietf.org/templates-and-schemas um. Dort stehen allgemeine RFCXML-, Markdown- und Asciidoc-Ressourcen. Die Seite warnt zutreffend davor, einen bereits aufbereiteten XML-RFC als Internet-Draft-Vorlage zu verwenden.

In der aufgezeichneten Antwort fehlten jedoch die MIB-spezifischen Namen. Daraus folgt weder, dass die Dateien endgültig verschwunden sind, noch dass die IETF sie absichtlich zurückgezogen hat. Vielleicht existiert ein anderer autoritativer Ort. Sicher ist nur: Die HTTP-Kette selbst belegt die semantische Nachfolge nicht.

Ein belastbarer Abrufnachweis umfasst Startadresse, Redirects, Endadresse, Zeitpunkt, Inhaltstyp, Größe und Hash. Ein Autoritätsnachweis ergänzt, welche zuständige Quelle den Endinhalt zum Nachfolger erklärt. Ohne diesen zweiten Teil lautet der Status „erreichbar, Identität offen“.

Vier Nachweise statt eines Konformitätslabels

RFC 5249 trennt die Dokumentvorlage vom MIB-Modul. Das Modul soll außerhalb des Begleittexts entwickelt und für Prüfwerkzeuge isoliert werden, bevor es in das Dokument eingeht.

Folglich braucht eine Prüfung vier Ergebnisse: aktuelle Richtlinie, genaue Dokumentvorlage, Werkzeugnachweis für das getrennte Modul und menschliches Urteil über Bedeutung und Sicherheit. Keine Ebene kann die nächste ersetzen.

Eine korrekte Gliederung garantiert keinen gültigen SMIv2-Code. Ein erfolgreicher Compiler garantiert keine verständlichen DESCRIPTION-Klauseln. Eine vorhandene Sicherheitssektion garantiert nicht, dass gefährliche schreibbare oder sensible lesbare Objekte benannt wurden.

RFC 4181 verlangt aktuelle genehmigte Textbausteine, warnt aber vor blindem Kopieren. Eine nicht erwähnte Objektklasse darf nicht als risikofrei gelten. Syntaxprüfung ist wichtig; ebenso wichtig ist die Frage eines möglichen Implementierers, ob der Text zu interoperablem Verhalten führt.

Wiedererkennbarkeit ist gerade das Risiko

RFC 7367 würdigt Harringtons Vorlage, RFC 9349 dokumentiert spätere MIB-Arbeit. Das belegt eine Traditionslinie, nicht die Bytes einer beliebigen Revision. RFC 8407 gehört zu YANG-Dokumenten; technische Nähe macht es nicht ohne ausdrücklichen Übergang zum Ersatz für MIB-Anleitungen.

Teams speichern gern lokale Kopien, weil sie reproduzierbar wirken. Ohne Versionsvergleich wird dieselbe Stärke zum Problem: Die Kopie bleibt gleich, während Anforderungen wechseln. Am Ende entsteht wieder das veraltete Vorbild, gegen das RFC 5249 gerichtet war.

Behandelt man die Vorlage als Build-Abhängigkeit, wird der Umgang klarer. Für eine Prüfung wird sie fixiert. Bei Änderungen wird ein Diff erzeugt. Nur betroffene Entscheidungen werden geöffnet. Die menschenlesbare Adresse darf auf „aktuell“ zeigen; der Prüfdatensatz muss unveränderliche Inhalte referenzieren.

Ein Manifest enthält Richtlinien, Vorlagenname und -revision, Herausgeber, Abrufdaten und Hash, Redirectkette, Modulhash, Prüfwerkzeug und Version, Ausgabe und Ausnahmen, sicherheitsrelevante Objekte sowie Prüfer und Ergebnis. Es schafft keine Wahrheit, begrenzt aber die Kosten der nächsten Änderung.

Heng Lus Reality-Layer-Disziplin setzt die richtige Grenze: Ein institutionelles Etikett ist noch kein Ergebnis. Die Vorlage koordiniert Text, der Validator beobachtet formale Eigenschaften, der Mensch beurteilt Bedeutung, die Implementierung erzeugt Verhalten. Jede Ebene darf nur für ihren eigenen Nachweis sprechen.

Quellen