Summary

  • Revision 10 of the NETCONF private-candidate draft gives each session its own configuration workspace and defines an atomic update procedure when running state has changed. A commit always uses revert-on-conflict, so unresolved overlap stops the commit rather than silently choosing a winner.
  • The explicit alternatives are consequential. prefer-candidate preserves the private value for a later overwrite of running; prefer-running erases the conflicting private edit. Server-side automatic update policy may also choose a resolution mode. Authentication, NACM permission and capability advertisement do not explain why that choice was authorized for this service and this change.
  • Operators therefore need a commit warrant that binds the exact branch base, conflict set, selected mode, overwritten or discarded values, decision owner, approved scope, tests, confirmed-commit conditions and rollback target. The warrant is Daniel Kade’s governance proposal, not an IETF requirement.

Isolation solves the first accident

The candidate datastore in RFC 6241 is useful because a client can prepare a complete configuration before making it active. Its weakness is also explicit: the candidate is shared. Another session can alter it. A client that does not lock or inspect carefully can commit a configuration containing changes it did not create and perhaps did not even see.

The active Internet-Draft draft-ietf-netconf-privcand-10 addresses that failure mode directly. It is a NETCONF Working Group document in Working Group Last Call, published on 24 August 2026 and expiring on 25 February 2027. It is intended for the Proposed Standard track, but it is not an RFC. Its central promise is narrower and valuable: multiple clients should be able to prepare changes at the same time, and each should commit only the changes it defined.

For NETCONF, the private-candidate capability applies to the whole session when both sides negotiate it. The first relevant operation creates a session-specific candidate from running. Edits in that branch are not visible to other configuration sessions, and other NETCONF clients cannot operate on it. If the session closes or is lost, the branch disappears and uncommitted changes are discarded.

That architecture eliminates the most embarrassing form of accidental co-commit. It also avoids treating a global lock as the only safe answer to concurrent work. RFC 5717 partial locking can narrow a lock, but the draft notes that it does not ensure a commit contains only one client’s edits, cannot solve concurrent edits to the same tree and demands knowledge of model dependencies.

Private isolation is therefore a real control, not decorative terminology. Yet the control moves the governance question. Once branches are separate, the difficult case is no longer “whose unnoticed edit did I commit?” It is “what should happen when the world changed while I was preparing mine?”

A branch carries an intention, not a right of way

The draft’s update operation rebases a private candidate on the current running datastore. Conceptually, the server replaces the old base with running and replays the client’s changes. The operation is atomic: either the requested update completes under its resolution rule or it does not leave a partial merge.

Conflict detection is deliberately tied to possible intent. A conflict can exist where running and the private candidate both changed the same configuration node during the preparation interval and the client might have acted differently had the new starting point been visible. Value, existence, user ordering, presence containers, leaf-lists, leaves and YANG metadata can all matter. A server may add further checks, including ones informed by a transaction identifier.

This definition is stronger than a crude text diff. It recognizes that configuration expresses desired state and that the significance of a node depends on its starting point. The draft represents the result internally as a per-node in conflict condition. The marking mechanism is outside its scope, and a child’s marker does not automatically climb to every ancestor. Conflict locations should be reported with XPath and values so a client can reevaluate its intent.

The phrase “reevaluate its intent” matters. The server can expose the collision, but it cannot know why an address, policy, route, certificate reference or administrative state was changed. It cannot infer whether running changed because of an emergency mitigation, whether the private branch belongs to a scheduled migration, or whether the two edits came from controllers with overlapping but differently bounded mandates.

Private ownership of a branch establishes provenance for staged work. It does not confer priority over the service.

Three modes encode three different losses

The draft does not hide conflict behind a generic merge. It names three resolution modes.

revert-on-conflict is mandatory and is the default. If any conflict exists, the update fails and no merge is performed. A commit always conducts an implicit update in this mode, regardless of a broader system default. A client whose commit fails must then change its edits, discard them, or deliberately invoke an update with a selected mode before trying again. This preserves the greatest visibility and control because the first collision does not silently choose a winner.

prefer-candidate keeps the private value for each conflicting node while incorporating non-conflicting changes from running. If the client later commits, its retained value overwrites the competing value in running. The loss is borne by the newer running intent.

prefer-running does the opposite. The current running value replaces the conflicting private edit while non-conflicting private work survives. The loss is borne by the branch author, whose intended change may disappear from the candidate before a later commit.

Neither preference is inherently legitimate. “Candidate” does not mean newer in organizational time, more carefully reviewed or more important. “Running” does not mean correct, approved for the next maintenance window or safe to preserve. The labels describe location in the protocol’s state model, not standing in an institution.

The distinction becomes more serious when update is automatic. The draft allows a server to select a different system resolution mode for updates triggered after running changes. A non-default choice must be advertised, and supported modes must be advertised when the implementation does not offer all three. That makes behaviour discoverable. It does not preserve why an operator selected that behaviour for a particular device class, service or period of risk.

An advertised default can become invisible governance. A controller may reconnect, discover a consistent private branch and later commit successfully, while the decisive loss occurred during an automatic update. The final commit record then answers who activated the result but not who chose the rule that constructed it.

NETCONF and RESTCONF do not create the same workspace

The private-candidate idea crosses protocol boundaries carefully. NETCONF clients advertise support and negotiate private mode for a session. If a client asks for it and the server does not support it, the server may ignore the request for backward compatibility or close the session; newer implementations are advised toward closure. Operators therefore need to observe negotiated state rather than infer it from client preference.

RESTCONF has no equivalent client capability advertisement. Where a server advertises private-candidate support, a write request uses a request-private candidate and automatically commits it. That choice preserves the immediate-change expectations of clients unaware of the extension. It should not be described as a long-lived, multi-operation private workspace equivalent to a NETCONF session.

The governance implication is practical. A NETCONF branch can remain open while running evolves, accumulating a history of creation, updates and explicit conflict handling. A RESTCONF request compresses preparation and activation into a much smaller boundary. A control that expects a human approval between edit and commit cannot be copied from one protocol to the other merely because both use the words private candidate.

Permission is not the missing evidence

RFC 8341 NACM can restrict which users may read or write content and execute operations. The private-candidate draft identifies update as sensitive and warns that unauthorized access can produce unintended changes. Mutual authentication and secure transport are indispensable.

But an authenticated principal with write and execute rights can still exceed a current mandate. A platform service account may be technically allowed to edit an interface subtree while its automation is approved only for address rotation, not for reversing an emergency shutdown. A senior engineer may hold broad rights but lack the incident commander’s permission to displace a live mitigation. An orchestrator may be authorized for one tenant while a shared ancestor carries another tenant’s dependency.

Access control asks whether this principal may invoke this operation on this content. Change governance asks whether this principal, acting through this workflow, may choose this value over that conflicting value now. Conflating the two turns standing credentials into a perpetual policy vote.

Comparison is evidence, not judgment, too. The draft extends RFC 9144 so a private candidate can be compared with running, its creation point or its last-update point when the server supports those reference points. That can make the delta and intervening change legible. It cannot decide whether either intent is safe for the service, nor whether the visible nodes cover every dependency that gives the change meaning.

The commit warrant

The missing artifact is not another protocol datastore. It is a short-lived governance record surrounding a consequential resolution. Call it a commit warrant.

The warrant begins by fixing identity: device, datastore, NETCONF session or RESTCONF request, authenticated principal and the owner of any automation acting through that principal. It records the private candidate’s creation point and latest update point together with a stable identifier for the running revision. Without these bases, a later diff is a story without a starting scene.

It then captures the exact candidate delta and the complete server-reported conflict set. Local policy should add service or ancestor context where a leaf-level marker understates the operational dependency. It records the server’s advertised default, every supported resolution mode, whether the update was automatic or explicit and which mode actually applied.

The destructive consequence must be written in plain terms. For prefer-candidate, list the running values that a later commit will overwrite. For prefer-running, list the private edits that have been removed. For revert-on-conflict, retain the unresolved set and the next authorized action rather than treating failure as noise.

The warrant also records the NACM policy version but refuses to treat it as sufficient approval. A named human or automation decision owner supplies the reason, approved service scope, maintenance window, blast-radius limit and expiry. Comparison results, configuration validation and representative service checks attach to that decision.

Finally, it fixes recoverability: whether confirmed commit is used, its timeout and persistence identifiers where applicable, the observers that must report health and the exact state to restore. Closure records the commit result and a fingerprint of resulting running. Any changed premise—new running state, expired window, altered policy or missing observer—expires the warrant and forces reevaluation.

This proposal is Daniel Kade’s, not text from the IETF draft. Its purpose is not to slow every conflict with paperwork. It is to make the rare choice that destroys a valid competing intent durable enough to audit and bounded enough to automate.

Rollback does not retroactively authorize the winner

Confirmed commit remains a powerful safety mechanism. Under the draft, if a client disconnects during a private-candidate confirmed commit, running is immediately reverted and the proposed changes are discarded. That can sharply limit the damage of losing the control session.

Yet rollback answers a different question: can the system return after evidence of failure or loss of confirmation? It does not prove that the initial choice between candidate and running was properly authorized. A change can be recoverable and still violate another team’s mandate. Conversely, an authorized emergency choice may be legitimate even if the rollback mechanism is imperfect; that imperfection should stop execution, not rewrite the authority question.

The semantics of discard-changes also deserve precision. Discarding resets a private candidate to its creation or last-update state, whichever is later. That reference may no longer equal current running. An operator who reports “discarded back to production” may therefore be claiming a convergence that did not occur.

The stable operating principle is simple: isolation preserves authorship, conflict detection preserves disagreement, and rollback preserves a route home. None of them preserves the mandate that allowed one intent to win. The commit warrant exists for that last job.

Sources