Zusammenfassung

  • RFC 9890 verlangt Eindeutigkeit für den ersten Namen eines YANG-Moduls oder -Submoduls; spätere Revisionen behalten diesen Namen, Modulrevisionen zusätzlich den ersten XML-Namensraum.
  • Das stabile Paar belegt eine Veröffentlichungsfamilie, nicht identische Bytes, die Serverrevision, Features, Deviations, angewandte Konfiguration oder Betriebswirkung.

Im Freigabeprotokoll standen zwei Treffer. Der Modulname war gleich, der Namespace ebenfalls. Das System erklärte die Wartung deshalb zur Fortsetzung ohne Schemaveränderung.

Fortsetzung traf zu, Gleichheit nicht. Eine neue Revision kann andere Definitionen enthalten. Ein Server kann sie implementieren, ein anderer die vorherige Version, ein dritter mehrere Revisionen nur für Imports bereithalten. Der konstante Name beantwortet diese Fragen nicht.

RFC 9890 korrigiert die Registeranweisung aus RFC 6020. Die alte Formulierung verlangte eindeutige Namen für alle Module und Submodule im IANA-Register sowie eindeutige XML-Namensräume. Auf jede Revisionszeile angewendet, widerspräche das normaler Pflege: Dasselbe Modul müsste sich für neuen Inhalt umbenennen.

Die neue Grenze lautet: Namen der Erstversionen sind eindeutig, ebenso der XML-Namensraum des ersten Moduls. Alle späteren Modul- und Submodulrevisionen behalten den ersten Namen; Modulrevisionen behalten auch dessen Namespace.

Das erlaubt keinem fremden Projekt eine Namensübernahme. Die erste Registrierung reserviert einen dauerhaften Schlüssel. Revisionen verwenden ihn wieder, weil sie zu dieser Linie gehören.

Im IANA-Register YANG Module Names erscheint etwa ietf-yang-types mit mehreren datierten Dateien. Das sind keine fehlerhaften Duplikate, sondern getrennt abrufbare Revisionen unter einer stabilen Koordinationskennung.

Der Familienname ist kein Inhaltsdigest

Modulname, XML-Namensraum, Revisionsdatum und Quelldatei tragen verschiedene Behauptungen. Der Name wählt die Modulfamilie. Der Namespace qualifiziert XML-Knoten. Das Datum bezeichnet eine Revision. Die Bytes zeigen die geprüften Definitionen.

Wer alles zu einem Schlüssel verdichtet, kann eine legitime Revision als Duplikat ablehnen oder eine echte Änderung übersehen. RFC 9890 beseitigt den ersten Fehler im Register. Den zweiten müssen Bestands- und Prüfsysteme verhindern.

RFC 7950 zeigt die Auswahlgrenze. Ein import kann mit revision-date eine Fassung festlegen. Ohne diese Angabe ist undefiniert, aus welcher Revision die Definitionen stammen. Mit verschiedenen prefixes dürfen sogar mehrere Revisionen desselben Moduls importiert werden. Eine reine Namensliste reproduziert keinen Build.

Ein belastbarer Beleg speichert revision statement, Abruf-URL, Byte-Hash, importierendes Modul und Versionsbindung. Löst ein Werkzeug eine ungebundene Abhängigkeit, gehören Werkzeugversion, verfügbares Set und ausgewählte Datei dazu.

IANA beobachtet keinen Server

RFC 9890 ändert ein IANA-Verfahren und führt ausdrücklich keine neue Operation oder Manageability-Anforderung ein. Das Register belegt Zuteilung und Revisionszugehörigkeit, nicht die Implementierung eines Routers oder Controllers.

Dafür gibt es YANG Library nach RFC 8525. Ein bestimmter Server meldet module sets, schemas und datastores sowie revision, Features, Deviation-Module und implemented oder import-only. Ein gemeinsamer Name verbindet Quellen, ersetzt aber keinen Serverbeleg.

Die content-id repräsentiert die aktuellen Bibliotheksinformationen dieses Servers und muss sich bei einer Änderung ändern. Sie ist kein globaler Hash; gleiche Inhalte müssen nicht denselben Wert liefern. Ihr Wert liegt in der Bindung einer Aufnahme an einen Serverzustand.

Ein implementiertes Modul nutzt serverweit eine Revision, während mehrere Revisionen für Imports vorhanden sein können. „Vorhanden“ kann deshalb Implementierung, Abhängigkeit oder öffentliche Registrierung bedeuten.

Nach dem Schema folgt der Betrieb

RFC 8342 bestimmt ein Datastore-Schema aus unterstützten Modulen unter Berücksichtigung von Features und Deviations. Zwei Geräte mit derselben Revision können unterschiedliche wirksame Schemas zeigen.

Danach kann <running> transformiert werden, bevor <intended> entsteht. Intended ist die Konfiguration, die das System anzuwenden versucht. Operational verbindet angewandte Konfiguration mit Systemzustand. Hardware, Protokolle, andere Geräte und Laufzeiten können Abweichungen erzeugen.

Die Beweiskette bleibt geschichtet. IANA belegt die Publikationslinie. Revision und Hash belegen die Quelle. YANG Library belegt die Serverauswahl bei einer content-id. Datastores belegen Absicht und Anwendung. Dienstmessung belegt Wirkung.

Ein gültiger Registereintrag ist kein Konformitätszertifikat. Eine aktuelle Bibliothek ist kein Anwendungsbeleg. Passender Betriebszustand beweist nicht automatisch das Geschäftsziel.

Der erste Name bindet langfristig

RFC 9907 verbietet die Wiederverwendung eines veröffentlichten Modulnamens selbst dann, wenn der RFC Historic wird. Eine Namensänderung schafft ein neues Modul. Inhaltliche Änderungen erhalten ein neues eindeutiges Revisionsdatum; frühere veröffentlichte revision statements bleiben erhalten.

Diese Stabilität erleichtert Imports, Werkzeuge und Dokumentation. Sie macht einen unklaren ersten Namen oder Namespace zugleich schwer rückgängig.

IANA pflegt das Register. Autoren definieren Inhalt. Implementierer wählen Unterstützung. Betreiber verantworten Version, Konfiguration und Rollback. Automatisierungsverantwortliche setzen die Beweisschwelle. Eine einzige Anzeige „YANG unterstützt“ verwischt diese Zuständigkeiten.

Der Name blieb, weil die Linie blieb. Das Modul änderte sich, weil Revisionen diese Linie entwickeln. Ein gutes Kontrollprotokoll bewahrt beides.

Quellen