Summary

  • Revision 10 proposes session-specific candidate datastores, an atomic rebase-like update, node-overlap conflict detection, three resolution modes and optional comparison with creation or last-update points.
  • Those mechanisms can protect edit custody without proving that the baseline stayed fresh, every relevant concurrent change was visible, automatic resolution matched human intent, committed configuration became operational or the affected service improved.

A branch is a custody boundary, not a time machine

The most useful promise in draft-ietf-netconf-privcand-10 is modest: one client should not accidentally commit another client's unfinished candidate changes. The draft creates a private candidate when a qualifying operation first needs it, copies the current running datastore, and keeps later edits with the NETCONF session or RESTCONF client that created it.

That is stronger custody than a shared candidate. It is not continuous freshness. While the branch remains open, other sessions can alter running. The draft explicitly says a private candidate may become significantly out of sync. Freshness returns only through a defined update, an implementation's advertised automatic-update behavior, or the implicit update that precedes commit.

The document's status deserves equal precision. The Datatracker record shows revision 10 as an active NETCONF Working Group Internet-Draft in Working Group Last Call, intended for Proposed Standard. The history dates this revision to 24 August 2026. It is not an RFC, an implementation report or deployment evidence.

Receipt one: the baseline that actually existed

At creation, the private candidate receives a full copy of running. A defensible baseline receipt needs more than a creation timestamp: the exact running revision or digest, YANG library/schema state, defaults and server identity; whether trigger=all-updates was negotiated; and the latest manual or automatic update that changed the branch.

This matters because a compare against creation-point answers a different question from a compare against last-update, and both differ from a compare against current running. After discard-changes, the candidate returns to creation or latest-update state, whichever is newer; the draft warns that this state may still differ from current running.

Receipt two: who owned the edits

For NETCONF, both client and server advertise the new capability before the session uses private-candidate mode. A server that does not support the client request may ignore it and continue without private candidates or close the session. A server-side capability observed elsewhere is therefore not proof that this session obtained isolation.

The ownership receipt should bind authenticated session, user, negotiated capabilities, candidate lifetime and each edit operation to one immutable change-set digest. The draft confines visibility through NETCONF or RESTCONF, but it leaves exposure through other device interfaces out of scope. “Private” describes the proposed protocol surface, not every possible administrative path.

RESTCONF has a different boundary. RFC 8040 has no client capability exchange; under the draft, a server advertising private candidates uses one for edits to the data resource and automatically commits it so existing clients retain immediate-commit behavior. The same evidence label cannot be applied blindly to both protocols.

Receipt three: what “no difference” meant

The draft extends RFC 9144 comparison so the current private candidate can be checked against running, creation point or last update. The reference-point extension is optional. RFC 9144 also permits subtree or XPath filters and distinguishes “no matches”—nothing was compared—from a comparison that found no differences.

An empty output is credible only with its source, target, reference point, filter, all flag, schema, default handling and visible-node set. RFC 8341 applies access control to operations and content; unreadable data can be silently omitted. A clean compare may be exact within the client's authorized view and still be incomplete for a wider change decision.

Receipt four: which concurrency was covered

Revision 10 defines conflict around overlapping modification of the same configuration nodes. Value and existence changes count, as do order changes in user-ordered lists and leaf-lists, presence containers, leaves and YANG metadata. Servers may add checks and may consider transaction identifiers.

That is a deterministic and implementable core. It is not a proof of every semantic conflict. Two clients can edit different nodes that jointly exceed capacity, remove redundancy, violate a routing policy or create an invalid service combination. Those changes need not collide under the core same-node test. The concurrency receipt must list all writers and intervals and separately evaluate cross-node operational invariants.

Receipt five: who chose the winner

Manual update offers three choices. revert-on-conflict fails the whole update and imports nothing. prefer-candidate keeps conflicting candidate values while bringing in non-conflicting running changes. prefer-running overwrites conflicting candidate edits with running values.

The system default matters only for automatic updates after another commit to running. If automatic updating is enabled, the client may not know its private branch changed; a later manual update may be a no-op. A mechanically resolved conflict is not automatically an authorized decision. Record the trigger, mode, affected nodes, before-and-after values, discarded intent and accountable approver.

Receipt six: what commit acknowledged

Commit follows two steps: an atomic implicit update using revert-on-conflict, then copying the private candidate into running if the update succeeds. The draft requires commit to fail when that implicit update finds conflict. This is useful: the protocol refuses to hide unresolved overlap behind a green response.

But RFC 6241 defines <ok> as the reply when the operation produced no protocol error. Preserve the message ID, candidate digest, implicit-update result, conflict report and resulting running revision. Do not translate that receipt into “the device behaved correctly.” Confirmed-commit timers and rollback remain a separate post-running question, already covered by BTW's dedicated Article.

Receipt seven: whether configuration converged

RFC 8342 separates running, intended and operational. Templates or transformations may alter the intended projection. Missing resources can leave intended configuration unapplied. Remnant state can persist after deletion. RFC 8526 provides NETCONF access to these NMDA datastores; it does not collapse them.

After commit, compare the resulting running revision with intended and operational at a declared time, on an identified device, across a stable observation window. Record every resource or application exception. A conflict-free candidate can still become partially ineffective configuration.

Receipt eight: whether the service changed

The final observer should be independent of the configuration transaction. Verify the relevant control session, interface, route, queue, security policy or forwarding behavior, then test the affected customer, SLA or business population. State the rollback condition and residual risk. Device state is not automatically traffic behavior; traffic behavior is not automatically customer recovery.

That final separation is why private candidates matter without becoming magical. They narrow one source of accidental coupling. They do not eliminate the need to prove every later transition.

Sources and review boundary

The draft's security section requires secure transport, mutual authentication and controlled access to sensitive operations. The historical OPSDIR review of revision 06 raised questions about checkpoint/reference-point support, datastore definition and security guidance; the YANG Doctors review of revision 06 was “Almost ready.” Neither is a fresh verdict on revision 10.

The protocol context also includes RFC 6241, RFC 8040, RFC 8341, RFC 8342, RFC 8526 and RFC 9144. These sources define protocol, access, datastore and comparison semantics; they do not document a named deployment.