Zusammenfassung

  • RFC 6020 verlangte Eindeutigkeit für alle YANG-Modul- und Submodulnamen sowie für alle XML-Namensräume im Register. Die IANA führte Revisionen dagegen unter demselben Namen und Namensraum fort.
  • RFC 9890, verfasst von Andy Bierman, Mohamed Boucadair und Qin Wu, beschränkt die Eindeutigkeit auf die erste Version. Revisionen müssen deren Namen und bei Modulen auch deren XML-Namensraum behalten.
  • Eine stabile Identität macht Revisionen nicht inhaltlich gleich. Revisionsdatum, Dateibytes, Importauswahl, Validierung und Produktionsbeobachtung bleiben eigenständige Nachweise.

Am 1. September 2026 enthielt das YANG-Register der IANA drei Zeilen mit dem Namen ietf-yang-types. Die Dateien trugen die Daten 2010-09-24, 2013-07-15 und 2025-12-22. RFC-Verweise und Dateiinhalte änderten sich; Modulname und XML-Namensraum blieben gleich.

Nach dem alten Wortlaut von RFC 6020 sah das wie ein Regelbruch aus. Abschnitt 14 verlangte, dass alle Namen im Register eindeutig sein mussten. Die drei Zeilen waren jedoch keine konkurrierenden Erstzuweisungen. Sie dokumentierten die Entwicklung derselben Modulidentität.

RFC 9890 stellte im Oktober 2025 die Begriffe richtig. Das Standards-Track-Dokument führte keinen neuen Betriebsprozess ein. Es ließ die Norm die Praxis beschreiben, mit der Module und ihre Revisionen bereits verwaltet wurden.

Eine Zeichenkette kennt ihren Vorgang nicht

Ein reiner Duplikatvergleich sieht zweimal denselben Wert. Ein Register muss zusätzlich wissen, ob der Vorgang eine Erstzuweisung oder eine Revision ist. Im ersten Fall droht eine Kollision, im zweiten ist die Wiederholung beabsichtigt.

Die neue Regel trennt vier Pflichten. Namen erster Modul- und Submodulversionen müssen eindeutig sein. XML-Namensräume erster Modulversionen ebenfalls. Jede Revision behält den ursprünglichen Modul- oder Submodulnamen. Eine Modulrevision behält außerdem den ursprünglichen XML-Namensraum.

Damit schützt das Register sowohl Exklusivität als auch Kontinuität. Eine fremde Linie kann keine bestehende öffentliche Identität übernehmen. Die legitime Linie muss aber nicht nach jeder redaktionellen Änderung unter einem neuen Namen weiterleben.

Ein Alarm „duplicate“ ist deshalb erst mit Ereignistyp, Datum, Quelldokument, Name und Namensraum aussagekräftig. Fehlen diese Felder, kann eine Bereinigung gültige Historie löschen oder eine echte Zweitzuweisung fälschlich als Revision akzeptieren.

Derselbe Name enthält nicht denselben Inhalt

Die Korrektur darf nicht zur gegenteiligen Abkürzung führen. Gleich benannte Revisionen sind nicht automatisch austauschbar. RFC 7950 hält ihre Unterschiede ausdrücklich fest.

YANG 1.1 beschreibt revision-Anweisungen als redaktionelle Historie eines Moduls. Ihr Argument ist ein Datum. Jede veröffentlichte Änderung soll einen neuen Eintrag an den Anfang der umgekehrt chronologischen Folge setzen. Der empfohlene Dateiname verbindet den stabilen Namen mit einem optionalen @Revisionsdatum.

Der Name beantwortet die Frage nach der Linie. Das Datum bezeichnet ihren redaktionellen Zustand. Identitätskontinuität und Inhaltsgleichheit sind verschiedene Behauptungen.

Beim Import wird daraus eine wirksame Auswahl. Mit revision-date werden die Definitionen der angegebenen Revision verwendet; fehlt diese Revision, ist das ein Fehler. Ohne Datum bleibt laut RFC 7950 undefiniert, welche Revision importiert wird. Mehrere Revisionen desselben Moduls können mit unterschiedlichen Präfixen sogar nebeneinander importiert werden.

Der gemeinsame Namensraum ist daher keine Freigabe für ein Upgrade. Er sagt weder, welche Datei ein Hersteller ausgeliefert hat, noch ob ein Betreiber ihre Folgen geprüft hat. Er stabilisiert nur die Adresse, unter der diese Fragen gestellt werden.

Datum, Hash und Paket beantworten verschiedene Fragen

Bei ietf-yang-types verweist die Fassung von 2010 auf RFC 6021, die Fassung von 2013 auf RFC 6991 und die Fassung von 2025 auf RFC 9911. Das Register hält die Identität fest und lässt die dokumentarische Autorität wechseln.

Ein Inventar, das nur den Modulnamen speichert, macht aus drei Zuständen einen. Ein Inventar, das eigene Namen wie v1, v2 und v3 erfindet, verlässt die registrierte Identität. Richtig ist eine zweidimensionale Aufzeichnung aus kanonischem Namen und genauem Revisionsdatum.

Für Produktion reichen diese beiden Felder nicht. Hinzu kommen Dateihash, URL, Quell-RFC, Paket- oder Firmwareversion, Parser, Importgraph, Validierung, Rollout und Beobachtung. Das Datum bezeichnet die vorgesehene Revision. Der Hash fixiert die Bytes. Das Manifest zeigt, was ausgeliefert wurde. Der Test zeigt, was die Implementierung akzeptierte. Telemetrie zeigt, was im Betrieb geschah.

So lassen sich Abweichungen zuordnen. Gleiche Daten mit unterschiedlichen Hashes deuten auf Liefer- oder Paketierungsprobleme. Unterschiedliche Parsergebnisse für dieselbe Revision gehören zur Implementierung. Eine bestandene Laborprüfung ohne Rollout ist kein Produktionsnachweis.

Das Register ist am stärksten, wenn seine Aussage klein bleibt

RFC 9890 wurde zu einer maßgeblichen Referenz für die Namensvergabe im Register. Zugleich erklärt das Dokument, dass es keine neuen Betriebs- oder Manageability-Anforderungen und keine neuen oder erhöhten Sicherheitsrisiken einführt.

Diese Begrenzung ist keine Schwäche. Die IANA kann eine Kollision bei der Erstzuweisung verhindern und eine datierte Revision derselben Linie zuordnen. Sie kann nicht die Qualität eines Modells, die Korrektheit eines Parsers, die Kompatibilität zweier Fassungen oder die Sicherheit eines Rollouts zertifizieren.

Heng Lus Prinzip der minimalen Anfangsspezifikation liefert hier eine klare Trennlinie. Name und Namensraum brauchen eine gemeinsame Antwort, weil konkurrierende Erstzuweisungen Referenzen zerstören würden. Versionswahl, Paketierung, Wartungsfenster und lokales Risiko brauchen keine zentrale Entscheidung.

Eine registrierte Revision ist verfügbar, nicht verpflichtend. Hersteller, Werkzeuge und Betreiber dürfen sie zu unterschiedlichen Zeitpunkten annehmen. Die gemeinsame Identität überlebt diese lokalen Zukunftsentscheidungen, ohne sie zu ersetzen.

Qin Wus Autorenangabe ist Herkunft, keine Betriebsvollmacht

RFC 9890 führt Qin Wu von Huawei zusammen mit Andy Bierman und Mohamed Boucadair im Autorenteam. Das offizielle IETF-Datatracker-Profil verbindet zahlreiche RFCs mit derselben öffentlichen Identität. Das belegt einen langfristigen Standardisierungskontext.

Es macht Qin Wu weder zum alleinigen Urheber noch zum Eigentümer der Regel. Das IETF-Verfahren trägt den Konsens, die IANA führt das Register, Spezifikationsteams schreiben Revisionen, Anbieter implementieren sie und Betreiber entscheiden über Produktion.

Diese Rollen verhindern falsche Verantwortungszuweisung. Ein Registerfehler gehört zum Registerprozess. Ein Parserfehler gehört zur Software. Ein mangelhaft geprüfter Rollout gehört zur Freigabekette. Eine Autorenangabe weist die Quelle des Textes nach; sie überträgt keine Verantwortung für fremde Systeme.

Der konkrete Beitrag bleibt wichtig: Eine normative Grenze wurde so korrigiert, dass das Register Kontinuität wahrheitsgemäß abbilden kann, ohne nachgelagerte Entscheidungen an sich zu ziehen.

Praxis darf Text nur korrigieren, wenn sie dessen Zweck erhält

Running-Code-Primat bedeutet nicht, dass jede verbreitete Implementierung richtig ist. Schlechte Praxis kann ebenfalls laufen. Entscheidend ist, ob die Praxis die gemeinsame Eigenschaft schützt, für die die Regel geschaffen wurde.

Gleichbleibende Namen und Namensräume bei Revisionen schwächen die Eindeutigkeit erster Zuweisungen nicht. Sie verhindern künstliche Identitätsbrüche und halten Verweise für Werkzeuge und Dokumentation stabil. Genau deshalb durfte die Praxis den zu weit formulierten Satz korrigieren.

Auch das Änderungsverfahren ist prüfbar. RFC 9890 druckt die alte Regel ab, benennt die Abweichung, veröffentlicht den neuen Text und verweist auf das betroffene Register. Es versteckt die Korrektur nicht als unauffällige Redaktion.

Eine Norm gewinnt technische Glaubwürdigkeit, wenn sie eine falsche Abstraktion offen repariert. Die laufende Infrastruktur nur zur Rettung eines alten Satzes umzubenennen, hätte Papier über Funktion gestellt.

Ein Revisionsnachweis für das nächste Update

Der erste Block enthält Name, Namensraum, zuweisendes Dokument, Datum und die Markierung „initial“. Nur hier wird Eindeutigkeit gegenüber anderen Erstzuweisungen geprüft.

Jede Revision übernimmt diese Identitätsfelder und ergänzt Revisionsdatum, exakte URL, Hash, Quell-RFC und Vorgänger. Außerdem wird festgehalten, ob revision-date ausdrücklich gewählt oder die Auswahl offengelassen wurde.

Der Softwareblock enthält Parser und Version, Importgraph, Features, Deviations, Paket, Validierung und gelieferte Bytes. Der Betriebsblock verbindet Freigabe, Test, Rollout-Umfang, Fehler, Beobachtung und Rücknahme.

Auch die Verben bleiben getrennt: Die IANA registriert. Eine RFC spezifiziert. Ein Paket enthält. Ein Parser akzeptiert. Ein Anbieter unterstützt. Ein Betreiber deployt. Ein Dienst läuft oder scheitert. Kein grüner Status darf für den nächsten sprechen.

Quellen