Summary

  • A confirmed commit is not a proposal waiting outside the device. Once accepted, the candidate becomes running configuration while the server keeps a timed obligation to restore the earlier state unless the procedure is completed.
  • Session-bound and persistent forms assign different authority. Losing the initiating session triggers reversion in the ordinary form; a persistent token lets the procedure survive and enables another session with the matching identifier to confirm, extend or cancel it.
  • Final running configuration remains only one layer. Access control, locks, startup persistence, intended-to-operational application, packet behavior and multi-device reconciliation need their own evidence.

The change was already real

A remote engineer edits a candidate configuration, validates it and sends <commit><confirmed/></commit>. The NETCONF server replies <ok>. At that moment, the change is not sitting in a review queue. The candidate has entered running configuration. Routes may be recalculated, interfaces may be reconfigured and the engineer's management path may already depend on the new state.

Yet the decision is not final. A confirmation timer is running, and the server has retained enough of the earlier configuration to restore it. If no valid confirmation arrives before the timer expires, the server must revert. If the device reboots first, it must revert. In the ordinary session-bound form, if the initiating NETCONF session ends before confirmation, the server must revert.

This is the mechanism's value: it gives an operator a bounded way to take a configuration risk without requiring continued access to undo a self-lockout. It is also the source of a dangerous vocabulary trap. The RPC was accepted, the configuration was committed and the new state began to execute. None of those statements says the change is final, durable across reboot, authorized for every affected node, successfully applied to hardware or safe across the network.

Confirmed commit is best understood as provisional execution with a retained restoration duty. It is neither a delayed write nor a protocol-level approval meeting.

Five datastores, five different claims

RFC 6241 defines the NETCONF base protocol and its configuration datastores. A server advertising :candidate gives clients a workspace in which edits can be assembled without immediately changing running configuration. An ordinary <commit> makes running equal to that candidate. The confirmed-commit capability adds a provisional finality rule to the same candidate-to-running transition.

Candidate answers: what complete configuration is being prepared? Running answers: what configuration is currently authoritative for the server's configuration system? Startup, when the server advertises :startup, answers a different question: what configuration should be loaded at the next boot? A NETCONF commit does not automatically prove that running was copied to startup. A client that requires reboot persistence must execute and verify that separate step.

RFC 8342 adds two distinctions that matter after commit. Intended is the configuration the system attempts to apply after transformations such as template expansion, removal of inactive nodes or insertion of system-controlled values. Operational is the configuration and state the system is actually using at the observation time.

A node can be valid in running and intended but absent from operational because the resource it addresses does not exist. Hardware can apply a value late or differently because of capacity, dependency or protocol state. That means a final confirmed commit can be true in the running datastore while the actual device remains partly on the old behavior, has rejected a resource internally or has created an unexpected forwarding result.

These are not five replicas that ought always to be identical. They are five evidence layers:

  • candidate: the assembled proposal;
  • running: the current configuration authority;
  • startup: the reboot input, when supported;
  • intended: the post-transformation target;
  • operational: the state actually in use.

A change report that records only “commit succeeded” destroys the distinction the architecture was designed to preserve.

The clock controls finality, not execution

The confirmed-commit lifecycle has more states than a start and an approval. If the request omits confirm-timeout, the NETCONF default is 600 seconds. The client may request another permitted interval. During that window, a subsequent confirming <commit> completes the procedure. Another confirmed <commit> can extend the outstanding procedure and set a renewed timeout. <cancel-commit> ends it by restoring the configuration that preceded the confirmed commit. Expiry produces the same restoration duty.

RFC 6470 gives operators a useful event vocabulary. A netconf-confirmed-commit notification can report start, extend, complete, cancel or timeout, with timeout data for the states that need it. Those events are much better evidence than a generic change-success message because they say which phase occurred.

They are still reports, not authority. A consumer can disconnect. A notification can be delayed or separated from its originating RPC. A device may emit complete while operational resources continue converging. Durable evidence must correlate the initiating session and user, the candidate and pre-change running fingerprints, the selected timeout, the server's timer epoch, later RPCs, notifications and the resulting running and operational state.

The default ten-minute value is a protocol default, not a universal safety judgment. A control-plane change that reconverges in seconds, a line-card operation that applies over minutes and a remote-site change with high-latency validation do not share one evidence window. Choosing the timeout is a local risk decision: it must leave enough time to observe the right canaries while limiting how long a harmful provisional state may continue.

When a lost session decides—and when it does not

In the ordinary form, the initiating NETCONF session owns the confirmed-commit procedure. If that session terminates before completion, the server restores the old configuration. This makes management-path survival an implicit signal. The client that started the risk must remain present long enough to confirm it.

The :confirmed-commit:1.1 capability also defines a persistent form. The initiating client supplies an opaque persist value. The procedure then survives termination of that session. A later session can present the matching value as persist-id when it completes, extends or cancels the outstanding work under the relevant RPC.

Persistent confirmation solves real operational problems. An orchestrator can start a change, release a fragile session and let a separate worker validate and decide. A human can recover a stranded procedure from another connection. But the token changes the authority model. Loss of the original session no longer means “restore.” The actor holding the matching identifier may now determine whether the provisional state survives.

The token must not be promoted into a claim it never made. It is not a human identity. It does not prove that a second person reviewed the change. It does not establish why the holder may confirm. It is an opaque equality condition inside the protocol. If an organization wants proposer-confirmer separation, it needs separate identities, credentials, NACM rules, job ownership and audit. Giving the same automation service both the change credential and the persistence token may be operationally convenient while providing no independent approval at all.

Logging the raw token everywhere creates another problem: operational evidence becomes reusable authority. A safer record can retain a keyed or salted fingerprint for correlation while keeping the live value in a tightly controlled custody path. Teams should know who can retrieve, rotate, cancel and recover a persistent decision before they enable it at scale.

Rollback restores a state, not an inverse patch

The comforting mental model of rollback is that the server reverses only the lines one engineer changed. Confirmed commit promises something broader: restoration of the configuration that was in effect before the procedure. That difference matters when other writers are allowed to work during the confirmation window.

RFC 6241 warns that changes made after the confirmed commit can be altered or removed by the later reversion. Imagine that change A enters running under a five-minute confirmation window. Two minutes later, change B modifies an unrelated-looking part of the same shared configuration. When A times out, the server restores the earlier baseline. Unless the system has proved a narrower merge behavior, B may disappear with it.

Locks therefore belong to the safety argument. A global NETCONF lock can exclude other NETCONF writers from a datastore while the procedure is outstanding. RFC 5717 defines partial locking for narrower regions, but it also exposes the conflict directly: a server must deny a partial lock on running while a confirmed commit is in progress because it may need the freedom to restore that datastore.

Locking is not a proof of correctness. It establishes exclusion over its actual scope. It does not tell the server that an interface address is right, that a policy was approved or that the packet path will survive. Nor can an operator cite “we use locks” without showing which datastore or nodes were covered, which protocols and automation identities respected the boundary, who owned the lock and how the session ended.

The safe rollback question is not simply “can the device go back?” It is “which exact baseline can it restore, which later work would be swept into that restoration, and what evidence proves that no uncoordinated writer crossed the boundary?”

The other API that can finalize the decision

Cross-protocol behavior makes the authority boundary less intuitive. RFC 8040 describes RESTCONF operating over a co-located NETCONF conceptual datastore. When that server uses candidate, a successful RESTCONF edit automatically commits the edited candidate.

If an ordinary non-persistent NETCONF confirmed commit is already outstanding, that new commit acts as a confirming commit. A RESTCONF writer that may not even know the original engineer's intention can therefore end the rollback window. The RESTCONF edit is not merely concurrent work; it changes the finality of the NETCONF procedure.

The persistent form has a different result. RESTCONF provides no persist-id field. If the outstanding procedure requires that identifier, the edit must fail with HTTP 409 in-use rather than silently confirm it. A NETCONF lock can also produce 409 when it blocks the datastore RESTCONF needs.

This is why protocol names are not sufficient ownership boundaries. If NETCONF and RESTCONF share the same underlying configuration state, their credentials, write paths and maintenance automation participate in the same commit lifecycle. Monitoring must connect them. A team that watches only NETCONF RPCs can miss the operation that finalized its change.

RESTCONF also highlights the startup distinction. RFC 8040 says a successful edit updates startup automatically when that co-located server supports startup. That is a RESTCONF transaction rule; it does not retroactively make ordinary NETCONF commit synonymous with copying running to startup. Operators need to record which protocol performed the write and which persistence behavior actually followed.

Authentication, authorization and validity are different gates

RFC 6242 maps NETCONF over SSH. The protected channel and authenticated peer are foundational, but they do not decide whether this user may invoke <commit>, alter an access-control node or change a particular interface.

RFC 8341 defines the Network Configuration Access Control Model. NACM separates operation access from data-node access and notification access. An authenticated operator can be denied an RPC. An allowed operation can still encounter nodes the user may not modify. Recovery sessions may receive exceptional implementation-specific authority, which makes their use more—not less—important to audit.

RFC 7950 supplies the YANG schema and constraint language. Validation can show that a complete candidate satisfies the server's modeled types, references and rules. It cannot show that the address belongs to the intended site, that capacity is sufficient, that a route policy matches a maintenance decision or that a service owner accepted the risk.

The schema itself is also evidence. RFC 8525 lets a client discover the server's modules, features, deviations and datastore associations, along with a server-specific content-id that changes when the library information changes. A candidate validated under one feature or deviation set should not be reported as the same decision after that set changes unnoticed.

A mature change record therefore keeps four separate results:

  1. the transport authenticated this peer and session;
  2. access control allowed this operation and these data nodes;
  3. the candidate was valid under this exact schema set;
  4. the commit lifecycle reached this exact state.

None is permission to invent the next result.

One server is not a distributed transaction

RFC 6244 places NETCONF and YANG inside a broader network-management architecture. Controllers can of course use confirmed commit as a building block for a network-wide change. The building block does not become distributed atomicity merely because one controller called it many times.

Each server advertises its own capabilities, starts its own timer, saves its own baseline and applies configuration through its own hardware and protocol dependencies. RPC latency means the timers do not begin together. One server may require a persistent identifier while another supports only a different workflow. One may reboot. One may deny a lock. One may report a final running state while a line card remains unapplied.

If a controller starts five confirmed commits and receives four <ok> replies, it has a partial network state. If it confirms the four before the fifth fails, it has made that partial state final. If it cancels all four, it still needs proof that their old operational and forwarding behavior returned. The protocol does not select the orchestration policy.

Network-wide authority therefore sits one layer above the device RPCs. It needs a transaction identity, per-device baselines, bounded clock skew, a decision about confirmation order, abort conditions, canary evidence, compensation and reconciliation. A controller may choose all-or-nothing, staged canaries or quorum-like service objectives. Whatever it chooses must be explicit. A row of green protocol acknowledgements is not a shared finality point.

The evidence ladder after <ok>

The first useful record is not a screenshot of a successful client. It is a chain that another operator can independently reconstruct:

  • exact server identity, software state, YANG-library content-id and advertised capabilities;
  • authenticated user, session, authorization-policy version and separate RPC/data-node decisions;
  • candidate and pre-change running fingerprints, semantic diff and validation result;
  • lock scope, owner and concurrent-writer history;
  • confirmed-commit request, timeout, server response, timer epoch and persistence-token fingerprint;
  • start, extend, complete, cancel or timeout events plus session-loss and reboot evidence;
  • provisional and final running fingerprints, explicit startup status and restoration baseline;
  • intended and operational state for the resources the change was meant to affect;
  • packet, routing, adjacency, interface, application and management-path canaries;
  • per-device outcome and reconciliation for every network-wide transaction.

This is running-code primacy applied to change authority. The standard's vocabulary is necessary because independent clients and servers need a thin shared contract. The strongest operational claim, however, comes from the state the running system actually enforced and exposed.

A useful dashboard should allow three apparently contradictory statements to coexist: the RPC succeeded; the confirmed commit later timed out; the operational network recovered only partially. Collapsing them into one red or green change status turns evidence into ceremony.

What confirmed commit earns

Confirmed commit earns a precise and valuable claim. A capable server can accept a candidate into running, retain a known earlier baseline and bind finality to an observable procedure. That procedure can survive or depend on a session according to an explicit mode. It can be extended, completed, cancelled or timed out. On reboot before completion, it has a defined restoration duty.

It does not earn the claim that the right person made the change, that no other writer interfered, that reboot will preserve the final state, that the device applied every intended value, that traffic works or that several devices changed as one. Those claims are available—but only to teams that collect the separate evidence.

The disciplined sentence after a change is therefore longer than “the commit passed.” It is: this authorized session placed this validated candidate into running under this lock and timeout; this identity completed or cancelled the procedure; this startup state was recorded; these intended and operational states followed; and these network canaries proved the bounded outcome. Every omitted clause is still an unanswered question.

Sources