Zusammenfassung

  • draft-ietf-netmod-immutable-flag-14 definiert die serverseitige Metadatenannotation immutable und die ausdrückliche Abfrage with-immutability. Das Flag beschreibt vorhandenes Verhalten, statt es zu erzeugen.
  • Die Aussage gilt für eine konkrete Instanz, kann vom Elternknoten geerbt und bei Nachfahren zurückgesetzt werden. Ein isolierter Pfad oder ein flacher Export verliert entscheidenden Kontext.
  • invalid-value belegt die Ablehnung einer bestimmten Änderung. Protokoll- und Benutzerkonsistenz, zeitliche Dauer, Datastore-Konvergenz, Laufzeitwirkung und Wiederanlauf bleiben eigene Nachweisfragen.

Zwei Protokolleinträge können wie ein vollständiger Beweis wirken. Zuerst liefert ein Lesezugriff immutable=true; danach scheitert ein anderer Wert mit invalid-value. Zusammen zeigen sie eine verständliche Folge: Der Server kündigte eine Grenze an und setzte sie bei dieser Anfrage durch. Das Wort „unveränderlich“ verleitet dennoch zu einer viel größeren Schlussfolgerung, als die Einträge tragen.

Revision 14 nennt das Flag ausdrücklich beschreibend und nicht vorschreibend. Es übersetzt eine schon bestehende Behandlung systembereitgestellter Konfiguration in maschinenlesbare Metadaten. Der Entwurf schafft die Serverregel nicht und prüft nicht, ob die interne Implementierung sie vollständig erfüllt.

Der IETF Datatracker führt den Text vom 2. Juli 2026 als aktiven NETMOD Internet-Draft mit Standards-Track-Ziel. Bearbeitungsstatus, Reviews und YANG-Validierung betreffen das Dokument. Sie messen weder ein benanntes Produkt noch ein Netz oder eine erfolgreiche Änderung.

Ohne Abfrage ist das Schweigen mehrdeutig

Die Annotation erscheint nur auf ausdrücklichen Wunsch. NETCONF ergänzt <get-data> um with-immutability; RESTCONF nutzt einen wertlosen GET-Parameter. Zulässig sind ausschließlich die schreibgeschützten Datastores <system>, <intended> und <operational>. Für eine andere Auswahl verlangt der Entwurf unknown-element. Ein unerwarteter RESTCONF-Parameterwert führt zu HTTP 400 und invalid-value.

Unterstützung wird separat angekündigt. NETCONF-Clients suchen in YANG Library nach ietf-immutable-annotation; RESTCONF veröffentlicht eine Capability-URI. Diese Angaben belegen eine behauptete Schnittstelle. Sie belegen noch nicht, dass jede sichtbare Instanz richtig markiert, jede Vererbung korrekt ausgeführt und jeder Schreibweg gleich behandelt wird.

Ein Altserver kann den unbekannten Parameter zurückweisen oder ignorieren. Fehlt die Annotation, müssen deshalb Capability, Anfrage und gewählter Datastore bekannt sein. Sonst lässt sich Nichtunterstützung nicht von Veränderbarkeit unterscheiden.

Die Instanz und ihr Stammbaum bilden den Beleg

Das Flag gehört zur Instanz. Zwei Einträge derselben Liste können verschiedene Werte tragen. Fehlt die Annotation bei einem Kind, übernimmt es den Elternwert; ein unmarkierter Top-Level-Knoten beginnt bei false. Ein Nachfahre kann den Zustand ausdrücklich zurücksetzen, und weitere Nachfahren können ihn erneut wechseln.

Ein Export nur der mit true markierten Blätter reicht daher nicht. Er kann den geerbten Ursprung verbergen. Ein Export nur der Eltern kann eine veränderbare Ausnahme übersehen. RFC 7952 erlaubt die Annotation zudem an einzelnen List- oder Leaf-List-Einträgen, nicht an der Sammlung als Ganzes; deren Zustand kann nur geerbt werden.

Die operative Bedeutung folgt dieser Struktur. Eine vollständig unveränderliche Liste erlaubt kein Hinzufügen, Entfernen oder benutzerdefiniertes Umordnen. Ein einzelner unveränderlicher Eintrag schützt zunächst sich und seine Nachfahren, nicht seine Geschwister. Derselbe Serverwert darf in running kopiert und die Kopie später entfernt werden, ohne dass sich intended ändert.

Vom Client gesendete immutable-Annotationen muss der Server ignorieren. Die Kennzeichnung ist eine Aussage der Serverseite. Auch ein kryptografisch authentisierter Client kann sich damit keine neue Unveränderlichkeit verleihen.

Zugriffsentscheidung und Sachentscheidung trennen

Die NETCONF- und RESTCONF-Beispiele des Entwurfs liefern Pfad, Schweregrad, invalid-value und eine Begründung. Ein solcher vollständiger Beleg ist aussagekräftig, bleibt aber an Identität, Operation, Zielwert und Zeitpunkt gebunden.

Mit NACM wird zuerst der Zugriff geprüft. Fehlt die Berechtigung, lautet der Fehler access-denied, bevor die Unveränderlichkeit bewertet wird. Unterschiedliche Nutzerantworten können also aus der Kontrollreihenfolge entstehen. Sie beweisen weder eine benutzerabhängige Eigenschaft noch die Gleichheit der nachgelagerten Ausführung.

Auch die Schnittstelle begrenzt die Aussage. Eine NETCONF-Ablehnung testet nicht RESTCONF, eine lokale Konsole, Herstellerwerkzeuge, Boot- oder Upgrade-Prozesse und servereigene Änderungen. Die im Entwurf geforderte Unabhängigkeit von Nutzer und Protokoll muss an einer Implementierung nachgewiesen werden.

Der Server bleibt veränderungsberechtigt

Das Flag begrenzt vor allem Autorität, nicht Zeit. Ein Client darf keinen anderen Wert durchsetzen; der Server kontrolliert seine Konfiguration weiter. Softwarestand, Hardwarebestand, Lizenz, aktivierte Funktion oder verfügbare Ressource können ändern, welche Instanz bereitgestellt oder als immutable betrachtet wird.

Die Eigenschaft kann ohne sichtbaren <system>-Datastore bestehen, und nicht jede Systemkonfiguration ist unveränderlich. Das Thema ist deshalb enger als die allgemeine Herkunfts- und Zusammenführungslogik von Systemkonfiguration. Entscheidend ist: Sichtbarkeit in running und Kontrolle über den wirksamen Wert sind nicht dasselbe.

RFC 8342 trennt intended und operational. Ein koordinierter Gleichstand in system, intended und operational ist ein wertvoller Zeitpunktbeleg. Er garantiert weder den nächsten Zeitpunkt noch Ressourcenbestand, Paketweiterleitung, Servicewirkung oder erfolgreiche Rücknahme.

Acht getrennte Prüfungen

Eine belastbare Kette beginnt mit Anfrage, Identität und Datastore. Dann folgen Capability und effektives Schema; vollständiger Teilbaum mit expliziten, geerbten und zurückgesetzten Zuständen; authentisierte Änderung samt Antwort; abgestimmte Datastore- und Nutzeransichten; ein Software-, Hardware-, Lizenz- oder Ressourcenereignis; Telemetrie und Diensttest; schließlich ausgeführte Wiederherstellung und Ergebnis.

Der geschlossene Primärquellenbestand umfasst Revision 14, Datatracker-Datensatz und -Historie, RFC 7952, 7950, 8342, 8525, 8526, 8527, 6241, 8040, 8341 und 9907 sowie system-configuration 20: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-immutable-flag-14; https://datatracker.ietf.org/doc/draft-ietf-netmod-immutable-flag/; https://datatracker.ietf.org/doc/draft-ietf-netmod-immutable-flag/history/; https://www.rfc-editor.org/rfc/rfc7952.html; https://www.rfc-editor.org/rfc/rfc7950.html; https://www.rfc-editor.org/rfc/rfc8342.html; https://www.rfc-editor.org/rfc/rfc8525.html; https://www.rfc-editor.org/rfc/rfc8526.html; https://www.rfc-editor.org/rfc/rfc8527.html; https://www.rfc-editor.org/rfc/rfc6241.html; https://www.rfc-editor.org/rfc/rfc8040.html; https://www.rfc-editor.org/rfc/rfc8341.html; https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-20; https://www.rfc-editor.org/rfc/rfc9907.html.

Diese Quellen belegen vorgeschlagene Semantik und Protokollgrenzen. Sie belegen keine Herstellerkonformität, Verbreitung, vermiedene Störung, Wiederherstellung oder Kundenwirkung. Auch die Implementierungsliste im Anhang bleibt eine Aussage des Entwurfs, kein unabhängiger Interoperabilitätstest.