Zusammenfassung

  • RFC 9890 aktualisiert RFC 6020 und die IANA-Leitlinien für die Eindeutigkeit von YANG-Modul- und Submodulnamen, weil der Wortlaut von RFC 6020 die Praxis bei Revisionen nicht zutreffend beschrieb.
  • RFC 6020 formulierte, alle Modul- und Submodulnamen sowie alle XML-Namensräume im Register müssten eindeutig sein. Die neue Regel macht die Erstversion eindeutig; spätere Revisionen behalten den Namen der Erstversion.
  • Der XML-Namensraum der Erstversion bleibt eindeutig, und jede Revision behält denselben XML-Namensraum. Das identifiziert den Registereintrag, aber nicht die konkrete Revision oder deren Semantik.

Der normative Wechsel

RFC 9890 ist ein Standards-Track-Update zu RFC 6020. Die Änderung betrifft die IANA-Anleitung für die Vergabe von Namen. Nach der aktualisierten Regel sind Namen von Erstversionen eindeutig. Eine Revision erhält dagegen weiterhin den Namen der Erstversion. Entsprechend bleibt der XML-Namensraum der Erstversion eindeutig, während alle Revisionen denselben Namensraum verwenden.

Das ist keine Aufhebung von Identität, sondern eine präzisere Trennung: Der stabile Name und der stabile Namensraum zeigen, zu welcher registrierten Modulidentität eine Revision gehört. Sie sagen nicht, welche Revision ein Gerät, ein Inventarsystem oder eine Validierung tatsächlich verwendet.

Abschnitt 3.1 von RFC 9890 führt den RFC als zusätzliche Referenz im IANA-Register auf. Das Verfahren des RFC ist damit maßgeblich für die Vergabe von Namen im YANG Module Names Registry. Die eingefrorene IANA-Aufnahme bleibt jedoch eine Beobachtung des Registerzustands; sie ist kein Nachweis für Implementierungsqualität, Verbreitung oder die Korrektheit einer bestimmten Modulrevision.

Was die Quellen nicht behaupten

RFC 9890 bringt die Regelung mit der bestehenden Registerpraxis in Einklang. Nach Abschnitt 4 entstehen keine neuen Operationen und keine zusätzlichen Manageability-Anforderungen. Abschnitt 5 nennt keine neuen oder erhöhten Sicherheitsrisiken, die eigens behandelt werden müssten. Daraus folgt weder, dass Werkzeuge immer revisionsbewusst arbeiten, noch dass aufeinanderfolgende Revisionen semantisch kompatibel sind.

Die folgende Einordnung ist Analyse von Theo March und keine RFC-Anforderung: Wenn Automatisierung einen stabilen Namen mit unveränderter Bedeutung gleichsetzt, kann zwischen Registeridentität und eingesetzter Semantik eine Kontrolllücke entstehen. Dann können Inventar, Validierung und Rollback auseinanderlaufen. Die Quellen belegen aber weder, wie viele Werkzeuge globale Eindeutigkeit über alle Revisionen angenommen haben, noch einen Betreiberzwischenfall, Interoperabilitätsfehler oder Migrationsaufwand. Auch eine Herstellerunterstützung oder Einsatzverbreitung ist nicht belegt.

Konkrete Prüf-Fixtures

Eine minimale Prüf-Fixture führt vier getrennte Werte: name, namespace, revision und den geprüften Schemaartefakt-Nachweis. Für die Erstversion kann sie etwa name=example, namespace=urn:example, revision=2024-01-01 enthalten; eine spätere Fixture lautet name=example, namespace=urn:example, revision=2025-06-01. Das Namens- und Namespace-Matching muss bestehen. Daraus darf die Prüfung aber nicht automatisch «semantisch kompatibel» ableiten.

Ein Deployment, das revision=2024-01-01 verlangt, muss nachweisen können, dass genau diese Revision validiert und für den Rollback aufbewahrt wurde. Fehlt dieser Nachweis, sollte der Prozess stoppen, statt stillschweigend die jüngste Revision unter demselben Namen zu verwenden. Das ist eine operative Kontrollentscheidung und keine neue Pflicht aus RFC 9890.

Der Entscheidungsweg für Betreiber lautet: erst Name und Namensraum auflösen, dann die Revision aus der Quelle bestimmen, anschließend gegen das validierte Schemaartefakt abgleichen, lokale Kompatibilitätsregeln prüfen, den vollständigen Nachweis samt Rollback-Version speichern und bei einer fehlenden Grenze anhalten.

Quellen