Zusammenfassung

  • Revision 10 des Private-Candidate-Entwurfs gibt jeder NETCONF-Sitzung einen eigenen Konfigurationsraum. Ändert sich running, aktualisiert der Server diesen Raum atomar; ein Commit verwendet stets implizit revert-on-conflict und scheitert bei offenem Konflikt.
  • Die bewussten Alternativen verteilen Verluste: prefer-candidate bewahrt den privaten Wert für die spätere Überschreibung von running, prefer-running entfernt die kollidierende private Änderung. NACM-Rechte und Capability-Anzeigen begründen nicht, warum eine Organisation genau diesen Verlust autorisiert hat.
  • Ein Commit-Mandat sollte Basis, Konfliktmenge, Modus, verlorene Werte, Entscheidungsverantwortung, genehmigten Umfang, Tests, Confirmed-Commit-Bedingungen und Rücksprungziel verbinden. Das ist Daniel Kades Governance-Vorschlag, keine IETF-Vorgabe.

Getrennte Werkbänke enden am selben Gerät

Der Candidate Datastore aus RFC 6241 bietet einen wertvollen Zwischenraum: Ein Client kann eine vollständige Konfiguration vorbereiten, bevor sie aktiv wird. Der Raum ist jedoch gemeinsam. Eine andere Sitzung darf ihn ändern. So kann ein Client neben seinem eigenen Entwurf unbemerkt auch fremde Arbeit committen.

Ein Lock kann das verhindern, blockiert aber andere Teilnehmer. Partial Locking nach RFC 5717 verkleinert den gesperrten Bereich, garantiert laut Entwurf jedoch weder einen Commit mit ausschließlich einem Autor noch eine Lösung für gleichzeitige Bearbeitung desselben Baums. Zudem muss der Client die Abhängigkeiten des Datenmodells kennen.

draft-ietf-netconf-privcand-10 setzt an dieser Stelle an. Das Dokument wurde am 24. August 2026 veröffentlicht, befindet sich als aktiver NETCONF-Entwurf im Working Group Last Call und strebt Proposed Standard an. Es ist noch kein RFC und kein Nachweis einer bestimmten Implementierung.

In NETCONF gilt der private Modus für die gesamte ausgehandelte Sitzung. Die erste einschlägige Operation erzeugt aus running einen sitzungseigenen Kandidaten. Andere NETCONF-Konfigurationssitzungen sehen und bearbeiten dessen Änderungen nicht. Endet die Verbindung, werden der Kandidat und alle nicht committeten Änderungen verworfen.

Damit verschwindet eine konkrete Unfallklasse: Ein Client aktiviert nicht länger versehentlich den unfertigen Entwurf eines anderen. Parallelität benötigt nicht zwingend eine globale Sperre. Doch während jeder private Zweig fortbesteht, darf sich running weiterentwickeln. Beim Wiederzusammenführen wird aus der Frage nach Urheberschaft eine Frage nach Vorrang.

Privat bezeichnet den Arbeitsraum, nicht das Entscheidungsrecht über den Dienst.

Der Konflikt liegt auch im verlorenen Ausgangspunkt

Die Operation update ersetzt die alte Basis des privaten Kandidaten durch das aktuelle running und spielt die Clientänderungen erneut ein. Sie ist atomar, sodass kein halber Merge zurückbleibt.

Der Konfliktbegriff berücksichtigt mögliche Absicht. Während der Vorbereitungszeit müssen sowohl running als auch der Kandidat denselben Konfigurationsknoten geändert haben, und der Client hätte angesichts des neuen Ausgangspunkts möglicherweise anders gehandelt. Wert, Existenz, benutzerdefinierte Reihenfolge, Presence Container, Leaf-Lists, Leaves und YANG-Metadaten können betroffen sein. Server dürfen zusätzliche Prüfungen sowie Transaktionskennungen einbeziehen.

Intern wird der Zustand je Knoten als in conflict geführt. Wie er markiert wird, bleibt außerhalb des Entwurfs; die Markierung steigt auch nicht automatisch zu allen Vorfahren auf. Der Client sollte Konfliktorte als XPath- und Wertlisten erhalten, damit er seine Absicht neu bewerten kann.

Genau dort endet das Wissen der Maschine. Sie erkennt den überlappenden Knoten, nicht aber den Notfallauftrag hinter dem laufenden Wert, den genehmigten Migrationsplan hinter dem privaten Zweig oder die Serviceabhängigkeit über einem unscheinbaren Leaf. Zwei authentisierte Identitäten können technisch gleich berechtigt sein und dennoch unterschiedliche, zeitlich begrenzte Mandate tragen.

Konflikterkennung bewahrt den Widerspruch. Sie entscheidet nicht über seine institutionelle Gültigkeit.

Drei Modi bestimmen drei Formen des Verlusts

revert-on-conflict muss unterstützt werden und ist der Standard. Sobald ein Konflikt besteht, scheitert das Update ohne Merge. Jeder Commit führt zuerst genau dieses implizite Update aus, unabhängig von einem anderen Systemstandard für automatische Aktualisierungen. Danach muss der Client seinen Entwurf ändern, verwerfen oder bewusst einen Auflösungsmodus wählen. Der Abbruch schafft einen prüfbaren Entscheidungspunkt vor dem Verlust.

prefer-candidate behält kollidierende private Werte und übernimmt nur konfliktfreie Änderungen aus running. Bei einem späteren Commit überschreibt der Kandidat die betreffenden laufenden Werte. Verloren geht die Absicht, die nach Erstellung des Zweigs in Produktion gelangte.

prefer-running drückt die laufenden Konfliktwerte in den privaten Kandidaten und überschreibt dort die konkurrierenden Edits. Der restliche Zweig bleibt erhalten, doch ein Teil seines geplanten Zwecks verschwindet.

Keiner der Namen enthält eine Legitimitätsordnung. Ein Kandidat kann veraltet oder schlecht geprüft sein. Running kann eine vorübergehende Notmaßnahme darstellen, die eine geplante Wartung bewusst ablösen soll. Technischer Ort und Schreibzeitpunkt ersetzen keine Zuständigkeit.

Für automatische Updates nach Änderungen an running darf der Server einen anderen Systemmodus wählen. Abweichungen vom Standard müssen angezeigt werden; ebenso die unterstützten Modi, falls nicht alle drei vorhanden sind. Eine Capability beschreibt Verhalten. Sie bewahrt weder Begründung noch Geltungsbereich oder Ablaufdatum der Richtlinie.

Der endgültige Commit kann deshalb grün erscheinen, obwohl die entscheidende Auswahl bereits bei einem automatischen Update fiel. Das Commit-Protokoll nennt den Aktivierenden, nicht zwingend den Eigentümer der Regel, die das Ergebnis zusammensetzte.

NETCONF und RESTCONF haben unterschiedliche Entscheidungsuhren

NETCONF handelt den privaten Modus für eine Sitzung aus. Fordert der Client ihn bei einem nicht unterstützenden Server an, darf dieser die Bitte aus Kompatibilitätsgründen ignorieren oder die Sitzung schließen; für neue Implementierungen empfiehlt der Entwurf eher das Schließen. Eine Clientkonfiguration allein beweist daher keine private Isolation.

RESTCONF besitzt keine gleichartige Client-Capability. Zeigt der Server Unterstützung an, verwendet eine Schreibanfrage einen anfrageeigenen Kandidaten und committet ihn automatisch. Damit bleibt die unmittelbare Semantik für Clients erhalten, die die Erweiterung nicht kennen. Es handelt sich nicht um einen langlebigen, mehrere Operationen umfassenden NETCONF-Zweig.

Das beeinflusst die Genehmigung. Eine NETCONF-Sitzung kann Änderungen an Produktion, NACM und Wartungsfenster überdauern. RESTCONF komprimiert Vorbereitung und Aktivierung in eine Anfrage. Ein menschlicher Kontrollpunkt zwischen Edit und Commit lässt sich nicht unverändert übertragen.

Zugriffsrecht ist kein Auftrag zur Verdrängung

NACM aus RFC 8341 kann Lese-, Schreib- und Ausführungsrechte nach Benutzer und Inhalt begrenzen. Der Entwurf bezeichnet update als sensibel und warnt vor unbeabsichtigten Änderungen durch unberechtigten Zugriff. Gegenseitige Authentisierung und sichere Übertragung bleiben notwendig.

Die schwierigsten Konflikte entstehen trotzdem zwischen berechtigten Akteuren. Ein Plattformkonto darf vielleicht den Interface-Baum ändern, aber nicht eine Incident-Sperre aufheben. Ein Administrator besitzt breite Rechte, jedoch keine Genehmigung, die Abhängigkeit eines anderen Dienstes zu überschreiben. Die Credentials einer Automation funktionieren womöglich noch, nachdem ihr Wartungsfenster endete.

Zugriffskontrolle fragt, ob diese Identität diese Operation auf diesem Inhalt ausführen darf. Change Governance fragt, ob dieser Ablauf jetzt diesen Wert gegenüber einer anderen gültigen Absicht durchsetzen darf. Wer beides gleichsetzt, macht ein dauerhaftes Credential zum unbefristeten Stimmrecht.

Auch der Vergleich bleibt Beweismittel. Die Erweiterung von RFC 9144 erlaubt, sofern Referenzpunkte unterstützt werden, Vergleiche des privaten Kandidaten mit running, Erstellungspunkt oder letztem Update. Der Delta wird verständlicher; Servicewirkung, Vollständigkeit der Abhängigkeiten und Entscheidungsmandat folgen daraus nicht.

Ein Commit-Mandat hält die Entscheidung zusammen

Der fehlende Baustein muss kein weiteres Protokoll-Datastore sein. Ein kurzlebiges Commit-Mandat kann eine einzelne destruktive Auflösung begleiten.

Es fixiert Gerät, Datastore, Sitzung oder Request, authentisierten Principal und Automationsverantwortlichen. Erstellungsbasis, letzte Updatebasis und eine stabile Kennung von running werden gebunden. Danach folgen der exakte Kandidaten-Delta und die vollständige Server-Konfliktmenge, ergänzt um bekannte Service- und Vorfahrenbezüge.

Das Mandat nennt angekündigten Standard, verfügbare Modi, automatischen oder expliziten Auslöser und tatsächlich verwendeten Modus. Den Verlust schreibt es aus: laufende Werte, die prefer-candidate überschreiben wird; private Änderungen, die prefer-running entfernt hat; oder offene Konflikte und nächste erlaubte Aktion nach revert-on-conflict.

Die NACM-Policy-Version dokumentiert den Zugriffsrahmen, ersetzt aber keine Freigabe. Ein benannter Mensch oder Automationspfad liefert Grund, Serviceumfang, Wartungsfenster, Auswirkungsgrenze und Ablaufzeit. Vergleich, Validierung und repräsentative Diensttests stützen diese Entscheidung.

Schließlich enthält das Mandat Confirmed-Commit-Nutzung und Timeout, gegebenenfalls persistente Kennungen, erwartete Gesundheitssignale und das genaue Rollback-Ziel. Nach Abschluss speichert es Ergebnis und Fingerprint des neuen running. Ändert sich eine Prämisse, verfällt es.

Das Commit-Mandat ist Daniel Kades Vorschlag, keine IETF-Anforderung, kein RPC und kein YANG-Knoten. Es bewahrt die Begründung, wenn Sitzung, Kandidat und Konfliktmarken längst verschwunden sind.

Rückkehrfähigkeit legitimiert nicht den Hinweg

Confirmed Commit ist eine starke Sicherung. Bricht die Clientverbindung während eines bestätigten Commits vom privaten Kandidaten ab, wird running sofort zurückgesetzt und die vorgeschlagenen Änderungen werden verworfen. Das begrenzt den Verlust des Steuerkanals.

Rollback beantwortet jedoch, ob eine Rückkehr möglich ist, nicht ob der ursprüngliche Gewinner befugt war. Eine unzulässige Entscheidung kann hervorragend reversibel sein. Eine legitime Notfallentscheidung kann ohne verlässliche Rückkehr zu riskant sein; dann muss der fehlende Rückweg die Ausführung stoppen, nicht die Zuständigkeitsfrage verdecken.

Auch discard-changes bedeutet nicht zwingend Rückkehr zum aktuellen Produktionszustand. Der Kandidat wird auf seinen Erstellungs- oder letzten Updatepunkt zurückgesetzt, je nachdem, welcher später liegt. Dieser Punkt kann sich von running unterscheiden.

Isolation schützt Urheberschaft. Konflikterkennung schützt den sichtbaren Widerspruch. Rollback schützt einen Heimweg. Warum eine Absicht gewinnen durfte, bleibt nur erhalten, wenn das Mandat im Moment der Auswahl entsteht.

Quellen