Zusammenfassung

  • draft-ietf-netmod-yang-xml-00 löst die XML-Darstellung von YANG-Daten aus der Sprachspezifikation: Elementnamen, Namespaces, Listenordnung, Typwerte, Metadaten und Referenzen.
  • Wohlgeformtes, validiertes oder kanonisch gleiches XML beantwortet eine Darstellungsfrage. Effektive Defaults, Protokollannahme, Datastore-Änderung und externe Wirkung bleiben getrennte Behauptungen.

Vor einem Wartungsfenster vergleicht ein Controller zwei Sicherungen. Die eine nutzt einen Default-Namespace, die andere einen frei gewählten Prefix. Ein Canonicalizer beseitigt Attributreihenfolge und Leerraum; die Hashes stimmen. Trotzdem stammt eine Sicht von einem trim-Server, die andere enthält explizit geschriebene Defaultwerte. Nach einer Modelländerung verhalten sich die beiden Historien verschieden.

XML Encoding of Data Modeled with YANG, Revision 00 vom 8. Juni 2026, soll die normative XML-Kodierung aus RFC 7950 in eine eigene Standards-Track-Spezifikation verschieben. Sie umfasst Konfiguration, Zustandsdaten, RPC/action-Parameter und Notifications. Der Text ist ein Internet-Draft bis 10. Dezember 2026; IANA- und Sicherheitsabschnitt stehen noch auf FIXME. Das ist keine abgeschlossene Sicherheits- oder Implementierungszusage.

Der Namespace trägt Identität, nicht der Prefix

Eine YANG-Knoteninstanz wird als XML-Element kodiert. Der lokale Name entspricht dem YANG-Identifier, der Namespace dem definierenden Modul. Top-Level-Elemente setzen ihn; bei einem Kind aus einem augmentierenden Modul muss er wechseln.

Verschiedene Prefixes dürfen dieselbe URI binden. Textvergleich meldet dann fälschlich eine Änderung. Werden Prefixes ohne ihre Bindungen vereinheitlicht, entsteht die gegenteilige Gefahr: verschiedene Namen erscheinen gleich.

Bei identityref liegt der qualifizierte Name im Wert. Dieselbe Identity kann mit verschiedenen lokalen Prefixes auftreten. Ein instance-identifier verlangt zwar explizite Prefixes für alle Knotennamen, doch auch sie gelten nur im jeweiligen Dokument. Zur Auflösung braucht es das richtige Schema; eine auflösbare Zeichenfolge beweist nicht, dass der Zielknoten im relevanten Datastore existiert.

Reihenfolge ist eine Modellentscheidung

Gewöhnliche Container-Kinder dürfen beliebig angeordnet werden. RPC/action input und output folgen der Schema-Reihenfolge. List-Keys stehen vor den übrigen Kindern. Bei ordered-by user bleibt die Nutzerreihenfolge erhalten, bei system-ordered entscheidet die Implementierung.

Ein Diff, der alles sortiert, entfernt harmlose Unterschiede und kann zugleich eine Prioritäts- oder First-Match-Regel zerstören. Ein Diff, der jede Bewegung wertet, erzeugt Lärm. Die Bewertung braucht den YANG-Pfad, ordered-by, Originalsequenz und Server-Readback.

Ein fehlender Knoten kann wirksam sein

Revision 00 definiert keine NETCONF-Defaultmodi. RFC 7950 bestimmt, wann ein Default in use ist und der Server sich so verhalten muss, als sei der Knoten vorhanden; when oder if-feature können ihn ausschließen. RFC 6243 definiert report-all, trim, explicit und report-all-tagged.

Fehlen im XML bedeutet daher nicht Fehlen im effektiven Baum. Ein expliziter Defaultwert verrät nicht, ob Client oder Server ihn gesetzt oder gespeichert hat. Vor dem Vergleich muss die Sicht benannt werden: Wire bytes, gespeicherte Konfiguration, accessible tree mit Defaults oder eine konkrete with-defaults-Antwort.

Canonical XML kennt keine YANG-Anwendung

Canonical XML 1.1 stabilisiert Zeichencodierung, Attribut- und Namespace-Deklarationsreihenfolge. Das W3C erklärt ausdrücklich, dass anwendungsspezifische Äquivalenz außerhalb eines allgemeinen XML-Verfahrens liegt. Verschiedene kanonische Formen können anwendungsseitig gleich sein; gleiche Formen übernehmen keine externen Regeln.

YANG ergänzt Revisionen, Features, Deviations, lexikalische und kanonische Typformen, Defaults, Ordnung, Constraints und Referenzauflösung. C14N wählt kein Modulset, erweitert keine Defaults und dereferenziert keinen leafref.

RFC 8525 lässt YANG Library ein Schema-Set melden; die Meldung muss noch mit den tatsächlich geladenen Bytes verbunden werden. RFC 8528 erlaubt für verschiedene Instanzen desselben Mount Points verschiedene mounted schemas. Ein isoliertes XML-Fragment verliert diesen Kontext.

RFC 7952 transportiert Metadaten als XML-Attribute. Wer unbekannte Attribute entfernt, kann weiterhin valide Nutzdaten liefern und zugleich Herkunft oder Qualifikation verlieren. Bei schema-losem anydata und anyxml gibt es außerdem keine allgemeine verlustfreie XML–JSON–XML-Zusage.

Protokollerfolg ist nicht Endzustand

Eine gültige Datei belegt keinen empfangenen NETCONF-RPC. RFC 6241 trennt <rpc-reply>, <rpc-error> und <ok>. <ok> steht für Verarbeitung ohne Fehler oder Warnung und ohne Rückgabedaten, nicht für jede spätere Gerätewirkung.

Ein belastbarer Datensatz verbindet Request, message-id, authentifizierte Session, Capabilities, YANG Library, Reply und Datastore vor/nach dem Eingriff. RFC 8342 trennt running, intended und operational, weil gültige Konfiguration, transformierte Absicht und tatsächlich genutzter Zustand auseinanderfallen können. Erst eine unabhängige Messung belegt die Dienstwirkung.

Eine Spezifikation definiert erwartbare Bedeutung. Running code liefert beobachtete Folgen. Präzision entsteht, wenn beide sauber verbunden und nicht verwechselt werden.

Quellen