Zusammenfassung

  • Revision 10 schlägt einen sitzungsspezifischen Candidate-Datastore, ein atomares update, Konflikte anhand überlappender Knoten, drei Auflösungsmodi und optionale Vergleiche mit Erzeugungs- oder letztem Update-Zeitpunkt vor.
  • Diese Mechanik schützt die Verwahrung von Änderungen, belegt aber weder eine aktuelle Basis noch semantisch vollständige Konkurrenzprüfung, menschliche Entscheidungsabsicht, operative Anwendung oder Geschäftswirkung.

Ein privater Zweig hält die Außenwelt nicht an

draft-ietf-netconf-privcand-10 adressiert ein enges, reales Problem: In einem gemeinsam genutzten Candidate kann ein Client unfertige Änderungen eines anderen mit veröffentlichen. Beim ersten relevanten Zugriff kopiert der Server running in einen privaten Candidate und bindet ihn an eine NETCONF-Sitzung oder einen RESTCONF-Client.

Danach kann running durch andere Schreiber weiterlaufen. Der Entwurf warnt selbst vor starkem Auseinanderdriften. Erst update, eine angekündigte automatische Aktualisierung oder das implizite Update vor dem Commit stellt wieder einen Bezug zur aktuellen Basis her.

Der Datatracker-Eintrag führt Revision 10 als aktiven NETCONF-WG-Entwurf im Working Group Last Call mit Ziel Proposed Standard. Die Historie datiert sie auf den 24. August 2026. Das ist kein Implementierungsnachweis.

Acht Nachweise

Basis. Geräteidentität, exakte Running-Revision oder Hash, YANG Library, Schema, Defaults, Erzeugung, letztes Update und trigger=all-updates gehören zusammen. creation-point, last-update und aktuelles running beantworten andere Fragen. Auch discard-changes kann auf einen veralteten Stand zurücksetzen.

Eigentum. Bei NETCONF müssen Client und Server die Fähigkeit ankündigen. Ein nicht unterstützender Server darf die Anfrage ignorieren und ohne privaten Candidate fortfahren oder die Sitzung schließen. Authentifizierter Nutzer, Sitzung, Aushandlung, Lebensdauer, Operationen und Change-Set-Hash bilden den Nachweis. Andere Gerätezugänge sind ausdrücklich außerhalb des Entwurfs.

RESTCONF besitzt keine clientseitige Capability-Ankündigung. Unter RFC 8040 lässt der Entwurf den privaten Candidate automatisch committen, damit ältere Clients sofortige Wirkung sehen. Das ist nicht dieselbe Sitzungsgrenze wie bei NETCONF.

Differenz. Die Erweiterung von RFC 9144 kann mit running, Erzeugung oder letztem Update vergleichen; Reference Points sind optional. Filter, all, Schema, Defaults und lesbare Knoten begrenzen die Antwort. no-matches heißt: Es wurde nichts verglichen.

RFC 8341 autorisiert Operationen und Inhalte getrennt; nicht lesbare Daten können still fehlen. Ein leerer Vergleich gilt nur für die tatsächlich sichtbare Menge.

Konkurrenz. Der Kern erkennt gleichzeitige Änderungen desselben Knotens: Wert, Existenz, Benutzerreihenfolge, Presence Container, Leaves und Metadaten. Implementierungen dürfen mehr prüfen. Änderungen verschiedener Knoten können gemeinsam dennoch Kapazität überschreiten, Redundanz beseitigen oder Policy verletzen. Solche knotenübergreifenden Invarianten brauchen eigene Tests.

Auflösungsbefugnis. revert-on-conflict verwirft das gesamte Update, prefer-candidate hält den Konfliktwert des Zweigs, prefer-running überschreibt ihn. Bei automatischer Aktualisierung kann der Systemmodus den Zweig unbemerkt ändern. Trigger, Modus, Knoten, Vorher/Nachher, verlorene Absicht und Entscheider müssen feststehen.

Commit. Zuerst läuft ein atomares implizites Update mit revert-on-conflict; nur danach wird der Candidate nach running kopiert. Konflikt erzwingt Fehler. Das <ok> aus RFC 6241 bestätigt lediglich eine fehlerfreie Protokolloperation. Message ID, Candidate-Hash, Update-Ergebnis, Konfliktbericht und neue Running-Revision bleiben gebunden.

Konvergenz. RFC 8342 trennt running, intended und operational. Transformation, fehlende Ressource und Verzögerung können Unterschiede erzeugen. RFC 8526 macht diese Sichten per NETCONF zugänglich, aber nicht identisch. Prüfen auf dem bezeichneten Gerät in einem stabilen Zeitfenster.

Ergebnis. Ein unabhängiger Beobachter prüft Interface, Route, Queue, Sicherheitsregel oder Forwarding und danach die betroffene Kunden-, SLA- oder Geschäftspopulation. Angewendeter Zustand und Diensterholung sind getrennte Aussagen.

Quellen und Review-Grenze

Der historische OPSDIR-Review von -06 fragte nach Reference Points, Datastore-Definition und Sicherheit. Der YANG-Doctors-Review von -06 lautete „Almost ready“. Beides sind keine neuen Urteile über -10.

Der technische Rahmen umfasst RFC 6241, RFC 8040, RFC 8341, RFC 8342, RFC 8526 und RFC 9144. Diese Texte beschreiben Semantik, keinen benannten Einsatz.