Use NETCONF confirmed commit only with a rehearsed confirmation path

NETCONF confirmed commit can automatically revert an unconfirmed change, which is valuable when management reachability is at risk. It is still a stateful workflow with capability, timing, locking, and concurrency conditions that must be rehearsed on the exact device.

Source fact:

IETF RFC 6241 defines NETCONF operations and optional capabilities. With the confirmed-commit capability and candidate configuration support, a client can commit configuration provisionally. If the commit is not confirmed before the timeout, the server restores the configuration that was in effect before the provisional change. The protocol defines a default timeout of 600 seconds when a different value is not supplied.

The RFC distinguishes a normal confirmed commit from a persistent confirmed commit that can be completed through another session using a persistence identifier. It also defines cancellation and behavior related to session termination or device events. The safety property depends on the server implementing and advertising the relevant capabilities and on the client following the defined sequence.

Boundary

Automatic configuration reversion does not guarantee service recovery. Runtime state, dynamic adjacencies, external systems, or a partial device failure may not return with configuration alone. Vendor implementations can impose constraints beyond the RFC. Another session modifying shared configuration during the confirmation window can complicate the result, particularly without appropriate locking and change coordination. A timeout that is too short can revert a good change; one that is too long can extend an outage.

Applicability questions

• Does the server advertise candidate and confirmed-commit capabilities, including persistent mode if needed?
• What exact configuration snapshot is restored after timeout, cancellation, session loss, and reboot?
• Can another tool or administrator edit the same datastore during the pending commit?
• Which independent service checks must pass before confirmation?
• How long does the full validation take under realistic latency and operational response?

DSE recommendation:

Capture capability discovery and test the workflow on every supported device family and release. In a lab, issue a benign provisional change, allow it to time out, explicitly cancel it, drop the client session, and test a restart if the vendor supports that scenario. Compare the resulting configuration and service state each time. Determine whether the automation needs persistent mode and how it protects the persistence identifier.

Choose a timeout from measured validation and recovery time with a documented margin. Acquire supported locks or otherwise serialize changes so no unrelated writer modifies the candidate or running state. Confirm only after out-of-band reachability, routing, forwarding, security policy, and a representative application probe pass. If the verification channel depends on the changed path, create an independent check before using the feature as protection.

Verification and evidence

Retain capabilities, device/version matrix, datastore snapshots, RPC and reply logs, timeout rationale, session-loss and cancellation tests, independent probe results, and operator runbook. Evidence should demonstrate both paths: a successful change that is deliberately confirmed and a harmful test change that reverts within the accepted window. Requalify after NETCONF client or device upgrades.

Official references

• IETF RFC 6241