Pushing the same 200-line NETCONF change to one router with :candidate and one with only :writable-running, how must the plan differ, and why?

## Read the capabilities first Every plan starts from the server's `<hello>`. The two routers in this scenario advertise: - Router A: `urn:ietf:params:netconf:capability:candidate:1.0` (and possibly `:validate:1.1`, `:startup:1.0`). - Router B: `urn:ietf:params:netconf:capability:writable-running:1.0` and no `:candidate`. On router B, `<commit>` and `<discard-changes>` do not exist: RFC 6241 says that without `:candidate` the `<commit>` operation is not available. A script written for router A fails on router B as soon as it names the candidate, and a script that simply retargets the same edits at running inherits every risk described below. ## Why the same 200 lines behave differently The difference comes from **when YANG constraints are enforced**. RFC 7950 Section 8.3.3 says that when the datastore is running or startup, constraints must be enforced at the end of each `<edit-config>` or `<copy-config>`; when it is the candidate, enforcement is delayed until `<commit>` or `<validate>`. | Concern | Router A: candidate | Router B: writable running only | |---|---|---| | When an edit becomes live | only at `<commit>` | as soon as each `<edit-config>` succeeds | | When constraints are checked | at `<validate>` or `<commit>` | at the end of every `<edit-config>` | | Splitting the change into many RPCs | harmless | exposes each intermediate state on the live network | | Failure partway through | running unchanged; fix the candidate | earlier edits already applied | | Abandoning the change | `<discard-changes>` | restore a saved copy of running | Suppose the change creates an interface and then adds routes and policy that reference it. On router A the reference may be staged before the interface exists, because nothing is checked until the end. On router B, an `<edit-config>` whose YANG reference (a `leafref`, for example) points at an interface that does not exist yet fails, and an `<edit-config>` that creates the interface goes live before its policy does. ## The plan for the candidate router 1. Confirm `:candidate`, and note `:validate` and `:startup`. 2. Send `<discard-changes/>` so the candidate starts equal to running, and guard the candidate against other writers for the duration. 3. Stage the change in as many `<edit-config>` calls with target `<candidate/>` as is convenient. 4. Send `<validate>` with `<candidate/>` as the source if `:validate` is advertised, and fix any `<rpc-error>`. 5. Send `<commit/>`. RFC 6241 says that if the device cannot commit all of the changes, running must remain unchanged. 6. Test, then `<copy-config>` running to startup if the device has a distinct startup. ## The plan for the running-only router 1. **Checkpoint running.** RFC 6241 Appendix E uses `<copy-config>` from running to a URL target, which needs the `:url` capability; otherwise read running with `<get-config>` and keep it client-side. 2. **Check before writing** where the server allows it. With `:validate`, `<validate>` accepts an inline `<config>` holding a complete configuration, so the client can submit the full intended configuration for checking; `<edit-config>` also has its own test option. 3. **Send the change as one `<edit-config>`**, ordered so the result is valid, so the constraints are checked once against the finished configuration and the network never runs on a half-applied version. 4. **Decide the error behaviour**: how `<edit-config>` reacts to a failure partway through is set by its error option, and the all-or-nothing choice needs its own capability. 5. Test, then save to startup, or restore the checkpoint if the tests fail. A commit that reverts by itself if the operator loses access is a candidate-side feature, so router B has no such safety net and the checkpoint is the rollback plan. ## The judgment call The candidate gives a **staging area and a single switch-over point**; writable running gives neither, so the client has to supply them itself: - **one RPC instead of twenty**, so the network never runs on a partial change; - **a checkpoint instead of `<discard-changes>`**, because there is no scratch copy to throw away; - **validation before writing**, using `<validate>` on a complete inline configuration or the edit's own test option, because the server checks running only as each edit lands; - **an external test before any save**, the same on both routers. Routers that advertise **both** capabilities let a client choose either path. Mixing them across tools on one device is how a direct write and a candidate commit end up racing, so automation should pick one path per device and stick to it. For a fleet, the capability list is the input that decides which plan a change runs, and a change pipeline that cannot tell the two kinds of router apart will eventually run the candidate plan against a running-only device.