Zusammenfassung

  • Explizite Nicht-Vorlagenkonfiguration hat Vorrang; der innere Vorfahr schlägt den äußeren; am selben Knoten gewinnt bei Konflikten die erste anwendbare Vorlage in der vom Client geordneten Liste.
  • Reproduktion verlangt vollständiges, zeitgleiches running und system, Definitionen, Orte und Reihenfolge, I-Regexp-Schlüsselabgleich und explizite Überschreibungen. Client-Ursprung, Rennfreiheit, NACM, Implementierung und Betrieb werden damit nicht bewiesen.

Ein belastbarer Reproduzierbarkeitstest beginnt nicht mit dem Ausgabebaum, sondern mit der Frage, ob zwei Rechner wirklich dasselbe Experiment erhalten haben. Bei draft-tt-netmod-yang-config-templates-03 gehört dazu mehr als die sichtbare Liste von Vorlagennamen. Ort, Tiefe, Reihenfolge und der übrige Datenbestand entscheiden mit.

Die Vorrangregeln haben drei Ebenen. Gewöhnliche, explizit gesetzte Konfiguration in running oder system steht über Vorlagenwerten. Bei geerbten Anwendungen hat der dem Ziel nächste Vorfahr Vorrang vor einem weiter außen liegenden. Treffen Vorlagen am selben Knoten aufeinander, entscheidet die vom Client gelieferte Reihenfolge.

Der Ethernet-Fall des Entwurfs zeigt die Richtung: ethernet-interface base-interface. Für passende Einträge setzt sich der MTU-Wert 1500 der ersten Vorlage gegen 65536 der zweiten durch. Die erste anwendbare Vorlage ist also höher priorisiert. Eine alphabetische Sortierung oder eine Speicherung als ungeordnete Menge verändert die Bedeutung.

Auch das Ändern der Metadaten ist genau definiert. Ein nicht leerer Wert ersetzt die ganze Liste; ein leerer oder nur aus Leerzeichen bestehender Wert entfernt die Anwendung; ohne Metadatum bleibt die bisherige Liste bestehen. Ein Änderungsprotokoll, das nur einzelne Zugänge und Abgänge nennt, kann die Client-Eingabe nicht zuverlässig wiedergeben.

Regulärer Ausdruck plus Auswertungsmenge

Listeneinträge dürfen über reguläre Ausdrücke adressiert werden, wenn der eingebaute Schlüsseltyp string ist oder davon abgeleitet wurde. Grundlage ist I-Regexp aus RFC 9485, eine bewusst begrenzte Teilmenge der XML-Schema-Ausdrücke. Sie reduziert Implementierungsunterschiede, ersetzt aber nicht den Auswertungskontext.

eth.* sagt allein nicht, welche Schnittstellen getroffen wurden. Dafür braucht man die konkreten Schlüssel derselben Aufnahme, die Regelversion und die Interpretation des Motors. Umbenennungen, fehlende system-Einträge oder zeitlich versetzte Datensätze verändern die Treffermenge bei unverändertem Muster.

Vorlagen dürfen unvollständige Fragmente sein. Der Server soll sie soweit möglich prüfen; das zusammengeführte Ergebnis muss die einschlägigen YANG-Bedingungen erfüllen. Datatracker meldet derzeit 0 Fehler und 0 Warnungen für die Werkzeugprüfung des extrahierten Moduls ietf-config-template (revision 2026-07-03). Das ist ein Dokumenten- und Werkzeugbeleg, keine NETMOD-Annahme, IETF-Billigung oder Produktkonformität.

Ein Ausgabebaum ist keine eindeutige Vorgeschichte

Unter NMDA bleibt running kompakt und enthält Definitionen, Anwendungsmetadaten sowie explizite Werte. Die Transformation wird in intended sichtbar. Ändert sich eine angewandte Vorlage in running oder system, soll sich der beabsichtigte Zustand ändern.

Eine noch verwendete Vorlage darf nicht gelöscht werden; Revision 03 verlangt eine Ablehnung mit data-missing. Zuerst sind alle Anwendungen zu ändern, danach die Definition. Diese Reihenfolge beweist keine Atomizität über mehrere Anfragen. Zwischen Bestandsaufnahme und Löschung kann ein anderer Client eine Referenz setzen. Transaktion, Sperre oder Wartungsfenster müssen für den konkreten Server belegt werden.

Ebenso lässt sich aus einem intended-Readback nicht zwingend die ursprüngliche Eingabe ableiten. Verschiedene Definitionen können durch denselben expliziten Wert verdeckt werden. Eine andere Reihenfolge bleibt unsichtbar, solange keine kollidierenden Werte vorliegen. Die Lesung belegt einen beobachteten Ausgang, nicht alle Ursachen.

Was ein unabhängiger Expander erhalten muss

Das Belegpaket umfasst: genaue Entwurfs- und Regelrevision; Server- und Expander-Identität; vollständige, zeitgleiche running- und system-Bestände; alle Definitionen; Anwendungspfade und Vorfahrentiefe; geordnete Listen; I-Regexp-Semantik und Kandidatenschlüssel; explizite Überschreibungen; sowie Versionen oder Zeitbeziehungen, die die Bestandteile an eine Aufnahme binden.

Gehasht wird das Paket, nicht nur das Ergebnis. Stimmen unabhängige Expansion und Server-Readback Knoten für Knoten überein, ist damit die Gleichheit zweier Transformationen für diese Eingaben belegt. Eine identische Implementierung bei allen Herstellern folgt daraus nicht.

NETCONF- und RESTCONF-Erfolge sind Protokollbelege, keine späteren Anwendungsnachweise. NACM nach RFC 8341 ist rollenweise zu testen. RFC 8342 trennt intended von operational, weil Ressourcen oder Ausführungsfehler eine Umsetzung verhindern können. FIB-Programmierung, Paketfluss und Dienstqualität brauchen nochmals eigene Beobachter.

Dokumentstatus getrennt wiedergeben

Revision 03 ist auf den 3. Juli 2026 datiert; im Kopf steht „Intended status: Standards Track“. Datatracker führt sie getrennt als aktiven individuellen Internet-Draft ohne Stream und ohne intended RFC status mit dem Zustand I-D Exists. Korrekt ist die Wiedergabe beider Felder, nicht die Behauptung einer Arbeitsgruppenannahme oder eines vorgesehenen RFC.

Quellen

Primärquellen: Revision 03; Datatracker; YANG 1.1, RFC 7950; YANG Metadata, RFC 7952; NMDA, RFC 8342; NACM, RFC 8341; NETCONF, RFC 6241; RESTCONF, RFC 8040; I-Regexp, RFC 9485. Verlauf: Datatracker-Historie. Quellen zur Abgrenzung: System Configuration Revision 20; Lu Heng über das Primat des laufenden Codes, die minimale Anfangsspezifikation und Realitätsebenen.