A CI pipeline's NETCONF commit to a router might cut off the pipeline's own management path; how does a confirmed commit protect it, and when does it roll back?

## The failure it exists for A CI pipeline manages a router over NETCONF, reaching it through the same interfaces it is about to reconfigure. The change replaces an access list on the management interface. If the new list omits the pipeline's own address, the commit succeeds, the reply may never arrive, and nothing can reach the router to undo the mistake. Someone drives to the site. **Confirmed commit** (RFC 6241 §8.4) turns that into a self-healing event. The device applies the change, but treats it as provisional: unless the client proves it can still talk to the device by confirming, the device puts the old configuration back on its own. ## The mechanism The capability is `:confirmed-commit:1.1` (`urn:ietf:params:netconf:capability:confirmed-commit:1.1`), and it is only relevant together with `:candidate`. It adds four parameters to `<commit>` and one new operation: | Element | Meaning | |---|---| | `<confirmed/>` | make this commit provisional | | `<confirm-timeout>` | seconds to wait for confirmation; **600 by default** | | `<persist>` | a token that lets the commit survive the session ending | | `<persist-id>` | quotes that token from a later session | | `<cancel-commit>` | revert now instead of waiting for the timer | The life cycle runs like this: 1. The client sends `<commit>` with `<confirmed/>`. `running` takes the candidate's contents and a timer starts. 2. The client tests the device - reachability, routing, the new peer coming up. 3. To keep the change, it sends a **confirming commit**: a `<commit>` **without** `<confirmed/>`. 4. If no confirming commit arrives before the timer expires, the server **MUST** restore the configuration to its state before the confirmed commit. A **follow-up confirmed commit** - another `<commit>` with `<confirmed/>` before the timer expires - resets the timer to its new value. Both it and the confirming commit may carry further changes. ## When the server rolls back - **Timer expiry** with no confirming commit. - **The issuing session ends** for any reason before the timer expires - unless the commit carried `<persist>`. - **The device reboots** before the timer expires, with or without `<persist>`. - **`<cancel-commit>`**, which reverts at once. Without `<persist-id>` it must come from the issuing session; with `<persist-id>`, a value that does not match fails with `invalid-value`. - **`<kill-session>`** received while a confirmed commit is in progress: RFC 6241 §7.9 requires the server to restore the pre-commit configuration. In the lockout case the second rule usually fires first: the access list cuts the management path, the SSH connection carrying the session dies, and the server reverts as soon as it notices the session is gone - often well before 600 seconds. ## persist: surviving a dropped session Without `<persist>`, every follow-up commit and the confirming commit MUST come from the session that issued the confirmed commit. That is fragile for automation: if the pipeline's runner restarts mid-job, the session ends and the change reverts even though the router is fine. `<persist>` sets a token on the pending commit. The commit then survives the session ending, and any session may confirm, extend or cancel it by sending the token back as `<persist-id>`. The cost is real: a persistent confirmed commit no longer reverts when the session drops, so a change that cuts the management path stays in place until the timer expires. Choose the timeout with that in mind. The `:confirmed-commit:1.0` capability of RFC 4741 had neither `<persist>` nor `<cancel-commit>`; version 1.1 added both. ## Why locks still matter The revert restores **the configuration as it was before the confirmed commit**. If another session changed `running` in the meantime, the revert can alter or remove that work. RFC 6241 therefore says locking **SHOULD** be used with confirmed commit on shared datastores. The protocol also helps from its side: while one session's confirmed commit is pending, another session's `<lock>` on `running` is refused, and RFC 5717 denies a partial lock with `in-use` and `error-app-tag` `outstanding-confirmed-commit`. ## Operating notes - Size `<confirm-timeout>` to cover the post-change tests, not the default by habit. - Confirm only after testing over the path you might have broken. - A confirmed commit does not save to `startup`; with `:startup`, a separate `<copy-config>` from `running` to `startup` is still needed. - RFC 6470 defines a `netconf-confirmed-commit` notification whose `confirm-event` is `start`, `cancel`, `timeout`, `extend` or `complete` - the audit trail of every provisional change.