Zusammenfassung

  • draft-ietf-netmod-node-tags-11 behandelte Tags aus der Moduldefinition, aus einer Implementierung und aus Benutzerkonfiguration; exakte Werte in masked-tag sollten vor der operativen Anzeige entfernt werden.
  • Ein verbleibendes Tag belegt nur, was ein Server für einen Selektor, Datastore und Berechtigungskontext angezeigt hat. Es belegt weder Existenz und Aktualität des Knotens noch korrekte Implementierung, Standardisierung oder Einsatz des Entwurfs.

Ein Inventarsystem sucht alle als sicherheitsrelevant klassifizierten Knoten. Eine erwartete Schnittstelle fehlt in der Antwort. Dafür gibt es mehrere plausible Ursachen: kein Tag, ein Benutzermaskierung, NACM-Filterung, ein anderer Modulstand oder der falsche Datastore. Aus der bereinigten Liste lässt sich nicht erkennen, welche Ursache vorliegt.

Genau darin liegt der analytische Wert von YANG Data Model for Node Tags. Das vorgeschlagene Modul ietf-node-tags führt Assoziationen mit numerischer id, einem node-selector vom Typ nacm:node-instance-identifier, tag-Werten und masked-tag-Werten. Der Selektor kann einen Schemaknoten oder eine Dateninstanz bezeichnen. Zur Suche nennt der Text <get-data> im operational datastore, für Schemaknoten zusätzlich <get-schema>. Im Anhang wird ein gefundener Pfad anschließend in establish-subscription eingesetzt.

Diese Abfolge ist ein Beispiel, kein Betriebsnachweis. In den ausgewerteten Quellen finden sich weder produktiver Einsatz noch unabhängige Implementierungen, Interoperabilitätstests oder Lieferantenzusagen.

Zwischen Herkunft und Algorithmus bleibt eine Lücke

Die Herkunftsabschnitte unterscheiden Tags, die der Modulautor beim Entwurf vergibt, Tags einer Implementierung und Tags des Benutzers. Der Benutzer darf außerdem jeden Wert unabhängig von seiner Herkunft maskieren.

Die nummerierte Bildung der operativen Sicht ist weniger vollständig: Zuerst werden bei der Moduldefinition vergebene Tags mit system origin aufgenommen, dann benutzerkonfigurierte Tags mit intended origin, schließlich alle Werte entfernt, die einem masked-tag entsprechen. Ein eigener Implementierungsschritt wird nicht genannt.

Automatische Implementierungs-Tags als serverseitiges oder systemseitiges Material zu verstehen, ist eine vernünftige Lesart. Sie bleibt aber eine Interpretation, keine ausdrücklich beschriebene vierte Stufe. Ein Herkunftsnachweis muss diese Unschärfe erhalten.

Auch die Maske löscht keine Geschichte. Sie zieht einen identischen String aus dem sichtbaren Set ab. Daraus folgt weder, dass das Tag nie vorhanden war, noch dass es falsch war. Ein sichtbares vendor:critical verrät umgekehrt nicht, wer es wann, mit welcher Softwareversion und aufgrund welcher Beobachtung gesetzt hat.

Die Präfixe ietf:, vendor: und user: ordnen Namensräume. Selbst ein nicht registriertes Präfix bleibt laut Entwurf gültig und soll verarbeitet werden. Registrierung belegt daher Namenskoordination, nicht den Wahrheitsgehalt der Aussage hinter dem Doppelpunkt.

Der Selektor trägt sein Schema nicht mit

Der typisierte node-selector wirkt portabel, benötigt aber einen wirksamen Schemakontext. RFC 7950 definiert YANG. RFC 8525 beschreibt in der YANG Library Module, Revisionen, Features und Deviations. Ändert sich dieses Set oder ein Mount-Kontext, kann derselbe Pfad unauflösbar werden oder ein anderes Ziel bezeichnen.

RFC 8342 trennt intended und operational. Der Entwurf nutzt diese Unterscheidung für Benutzerkonfiguration und zusammengesetzte Sicht. „Operational“ bezeichnet dabei die vom Server erzeugte Datastore-Sicht, nicht unmittelbare Hardware- oder Paketrealität.

RFC 8341 kann über NACM sowohl die Assoziation als auch den Zielknoten verbergen. RFC 6241 und RFC 8040 definieren NETCONF und RESTCONF, doch eine erfolgreiche Transaktion belegt nur die Antwort für diese Identität. Ein fehlender Eintrag ist ohne weitere Kontrolle kein Nichtexistenzbeweis.

RFC 7952 bietet einen aufschlussreichen Vergleich: Metadaten-Anmerkungen begleiten Dateninstanzen, während node-tags Assoziationen über Selektoren zentralisiert. Keine Variante liefert automatisch Autor, Zeitpunkt, Verwahrungskette oder Aktualität.

Eine Beweiskette statt eines Vertrauenssprungs

Das Archivdokument belegt, dass Revision 11 vorgeschlagen wurde. Datatracker belegt den Dokumentlebenszyklus. Ein registriertes Präfix belegt eine Namensraumzuweisung. Ein Abfrageergebnis belegt, dass ein Server nach Komposition ein Tag in einem konkreten Zugriffs- und Datastore-Kontext gezeigt hat.

Wird der Selektor gegen einen eingefrorenen YANG-Library-Stand aufgelöst, ist sein Ziel in diesem Schema belegt. Eine autorisierte Leseoperation belegt die Serverantwort dieser Transaktion. Aktualität, Vollständigkeit, korrekte Implementierung, Benachrichtigungszustellung, FIB, Paketweiterleitung und Dienstwirkung brauchen weitere Beobachtungen.

RFC 8639 und RFC 8641 ermöglichen Subscriptions und YANG-Push. RFC 9195 und RFC 9196 modellieren Instanzdaten und Fähigkeiten. Keiner dieser Mechanismen macht aus einer Klassifikation einen Zustell- oder Ausführungsbeweis. Auch Anbieterkennungen nach RFC 9371 ordnen Namen, bestätigen aber kein Produktverhalten.

Der Entwurf warnt selbst, dass Tags Nutzung und Angriffswege eines Knotens offenlegen können. Hinzufügen und Entfernen müssen privilegiert sein; auf Tags gestützte Aktionen liegen außerhalb des Anwendungsbereichs. Wer ein Tag mit Freigabe, Sperre oder Konfigurationsänderung verbindet, schafft eine eigene Kontrollregel und muss deren Autorität begründen.

Ein benachbarter RFC heilt den Status nicht

Revision 11 ist vom 21. Oktober 2023 und nennt den 23. April 2024 als Ablaufdatum. Datatracker führt sie als Expired Internet-Draft, Expired & archived und Dead WG Document; der IESG-Status lautet Expired. Beabsichtigt war Proposed Standard, ein RFC entstand nicht.

Die YANG-Validierung zeigt null Fehler und null Warnungen. Das belegt bestandene Werkzeugprüfungen der eingereichten Module, nicht Annahme, Interoperabilität, Einsatz oder korrekte operative Komposition.

RFC 8819 ist der nächste standardisierte Verwandte und behandelt Tags auf Ebene ganzer YANG-Module, einschließlich Definition, Implementierung, Benutzer und Maskierung. Node-tags wollte dieses Muster auf Knoten erweitern. Der Standards-Track-Status von RFC 8819 geht nicht auf den abgelaufenen Entwurf über.

Heng Lus Texte zu Mindestspezifikation, Autorität, Implementierungsmacht, Realitätsschichten und Running Code dienen hier ausschließlich als redaktionelle Linse. Sie trennen koordinierende Symbole von beobachtbarer Ausführung und fügen keine IETF-Anforderung hinzu. Praktisch heißt das: Das Tag bleibt ein Suchhinweis und darf sich keine Beweiskraft vom Dokument, Register oder Server leihen.

Quellen

Primärnachweis: Revision 11, aktueller Datatracker-Status und Verlauf.

Modell und Zugriff: RFC 6241, RFC 7950, RFC 7952, RFC 8040, RFC 8341, RFC 8342, RFC 8407, RFC 8525 und RFC 8526.

Tags, Subscriptions und Nachbarmodelle: RFC 8639, RFC 8641, RFC 8819, RFC 9195, RFC 9196 und RFC 9371.

Analytische Linse: Minimum Initial Specification, On Authority, Implementation Power, Reality Layers und Running Code Primary.