Zusammenfassung

  • draft-ietf-netmod-yang-anydata-validation-00 wollte die codierte Identität eines Knotens mit einem Schema aus der RFC-8525-YANG-Library verbinden, um Nachfahren von anydata zu prüfen.
  • anydata-complete sollte sämtliche Regeln des passenden Schemas anwenden; anydata-candidate verzichtete bewusst auf Constraint-Prüfungen. Beide Resultate beweisen weder Herkunft und Berechtigung noch Betriebszustand oder Wirkung.

Ein alter Datensatz wird erneut geprüft und fällt durch, obwohl seine Bytes identisch geblieben sind. Dazwischen änderten sich eine Modulrevision, eine aktivierte Feature und der Parser. Wer nur das frühere grüne Häkchen speicherte, besitzt keinen Widerspruch, sondern zwei nicht vergleichbare Behauptungen.

Genau an dieser Stelle setzte Revision 00 von Validating anydata in YANG Library context an. YANG 1.1 verwendet anydata für mit YANG modellierbare Knoten, deren konkretes Modell beim Entwurf des umschließenden Moduls noch unbekannt war. Filter, Datastore-Ausgaben, Edits, Instance-Dateien und Benachrichtigungen nutzen diesen offenen Behälter. Der Empfänger muss aber entscheiden, welches Schema den Inhalt beurteilen darf.

Der Entwurf nahm die Identität aus der Codierung. XML liefert lokalen Namen und Modul-Namespace, JSON einen gegebenenfalls modulqualifizierten Bezeichner, CBOR etwa SID, SID delta, qualifizierten Namen oder instance-identifier. Damit sollte der Validator den entsprechenden Datenknoten in der YANG Library finden.

Diese Library ist kein statisches Wörterbuch. Nach RFC 8525 verweist ein Datastore auf ein Schema, ein Schema vereinigt Module-Sets, und deren Einträge tragen Revisionen, Submodule, Features und Deviations. Der content-id muss sich bei einer Änderung der Library-Information ändern, ist aber implementierungsspezifisch und kein universeller Hash. Unter einem Schema Mount kommt ein weiterer Auflösungskontext hinzu.

Complete und candidate schulden unterschiedliche Antworten

anydata-complete sollte den Subtree gegen alle Validierungsregeln des zugeordneten Schemas prüfen. anydata-candidate wandte Constraint Checks nicht an. Die Begriffe lehnen sich an RFC 7950 an: Bei running und startup folgen Constraints auf den Abschluss einer Operation; beim candidate datastore können sie bis commit oder validate warten.

Ein candidate pass sagt deshalb nur, dass der Kandidatenpfad die Struktur ohne vollständige Constraint-Prüfung angenommen hat. Ein complete pass sagt, dass eine benannte Implementierung unter benannten Eingaben keine Verletzung der angewandten Regeln fand. Aus beiden pauschal „YANG-valid“ zu machen, beseitigt die entscheidende Differenz.

Auch ein Fehler bleibt begrenzt. Er kann Typ, Bereich, must, when, Kardinalität, unbekannten Knoten oder Kontextkonflikt nennen. Er beweist nicht, wer den Fehler verursachte. Sender, Zwischenkonverter, falsche Library-Auswahl und Validator können jeweils beteiligt sein. Das Ergebnis trägt Quarantäne und Untersuchung, aber kein automatisches Schuldurteil.

Der Entwurf beschreibt einen negativen Interface-Octet-Counter in einer YANG-Push-Nachricht. Ein Analyseprozess könnte damit Verkehr, Abrechnung oder Kapazitätsplanung falsch berechnen. Vollständige Schemaprüfung kann diese Fehlerklasse finden. Ein nichtnegativer Wert ist dadurch noch nicht aktuell, vollständig, authentisch oder dem erwarteten Interface zugeordnet.

Ein Nachweis braucht mehr als einen Exit-Code

Ein reproduzierbarer Beleg speichert Payload-Hash, Zeitpunkt, Encoding und decodierte Knotenidentität. Er bindet content-id an einen eingefrorenen YANG-Library-Snapshot und erfasst Datastore, Schema, Module-Sets, Modul- und Submodulrevisionen, Features, Deviations sowie Mount-Pfad. Hinzu kommen Validator, Build, Flags, Modus, Diagnose und weitere Behandlung.

Das ist Betriebsinformation. Ein Feature-Wechsel kann einen Knoten entfernen, eine Deviation eine Regel ändern, ein Mount den Namensraum verschieben und ein Upgrade Grenzfälle anders parsen. Kippt dasselbe Payload, lässt sich zuerst der Kontextunterschied untersuchen, statt sofort Manipulation zu behaupten.

Der Entwurf machte die Prüfung optional und überließ dem Konsumenten, eine nicht konforme Nachricht zu ignorieren, zu protokollieren oder zu melden. Damit bleibt die Entscheidung dort, wo die Folgen getragen werden: Der Datenverantwortliche muss festlegen, welche Fehler Automatisierung stoppen, einen Retry erlauben oder eine menschliche Prüfung verlangen.

Abgelaufen heißt nicht beinahe standardisiert

Datatracker nennt den 2. Dezember 2025 als Datum der jüngsten Revision und verzeichnet an diesem Tag die WG-Version 00. Der Text lief am 3. Juni 2026 ab. Heute stehen dort Expired Internet-Draft, Expired & archived, Dead WG Document und IESG Expired; Intended RFC status ist strukturiert mit None angegeben.

Im historischen Masthead stand separat Intended status: Standards Track. Das war eine Absicht im Entwurf, keine IETF-Billigung. Die Sicherheitsanalyse blieb unvollständig, ein IANA-Antrag fehlte und Datatracker nennt keinen Shepherd.

Der Abschnitt Implementation Status verwies für anydata-candidate auf einen libyang-Branch und sollte vor einer RFC-Veröffentlichung entfernt werden. Ein Branch belegt höchstens einen experimentellen Codepfad, nicht Merge, unabhängige Implementierung, Interoperabilität oder Produktionseinsatz.

Schemakonformität ersetzt keine Betriebsbeobachtung

RFC 8342 trennt running, intended und operational. Ein gültiger Wert beweist nicht, dass ihn das Gerät anwendet. RFC 8341 regelt Zugriff: richtige Struktur ist keine NACM-Berechtigung. Subscription- und YANG-Push-Regeln behandeln Auswahl und Zustellung; ein gültiger Subtree widerlegt weder Verlust noch Replay, falsche Reihenfolge oder Umschreiben.

Senderidentität, Transportintegrität und Custody brauchen eigene Belege. Gerätezähler, FIB, Paketmitschnitt, Gegenstellenbeobachtung und finanzielle Abstimmung beantworten andere Fragen. Ein maschinenlesbarer Exit-Code darf diese Ebenen nicht stellvertretend bestätigen.

Der bleibende Wert von Revision 00 liegt daher nicht in einem neuen Gütesiegel. Er liegt in der Idee, einen zuvor opaken Subtree unter einem benannten Kontext prüfbar zu machen und zwei Belegstärken auseinanderzuhalten. Mit Kontext grenzt die Prüfung einen Fehler ein. Ohne ihn verschiebt das grüne Häkchen die Unsicherheit nur.

Quellen

Entwurf: Revision 00, aktueller Datatracker-Status und Historie.

Technischer Kontext: RFC 7950, RFC 8525, RFC 8342, RFC 8341, RFC 8528, RFC 8639 und RFC 8641.

Analyserahmen: Minimum Initial Specification, On Reality Layers und Running Code Primary.