LEARN. PRACTICE. GROW.Discover before changing
A NETCONF session announces capabilities. NETCONF availability does not guarantee candidate, confirmed-commit or rollback-on-error. In a fictional APS exercise, the script expects candidate but the recovery device advertises a different set. Start by recording capabilities and version and comparing the plan with the target. Automatically switching to running changes the risk: an edit may immediately affect active configuration. Define the response to a missing capability beforehand. Also identify the models and namespaces used by the payload; well-formed XML does not establish that a device recognizes its contents. Equivalence between two equipment models needs its own evidence.
Candidate has a scope
Candidate allows preparation before applying configuration to running. Do not treat it as a private copy merely because you opened a new session. Without evidence of isolation, assume other sessions can edit the same candidate. Acquire the appropriate lock and inspect its contents before starting. A lock acquired later does not remove another operator’s pending changes. In a description-change case, committing a candidate that already contains a routing edit can publish more than the approved request. Coordinate ownership of those changes. discard-changes resets candidate from running; it does not identify and remove only your own fields.
Stopping and restoring are separate decisions
In edit-config, stop-on-error stops processing when an error occurs; it does not promise restoration of everything already changed. When the server supports rollback-on-error, that option requests restoration to the state at the start of that operation. Its scope is the request, not the entire pipeline or every device. If three earlier requests succeeded, failure of the fourth does not imply automatic reversal of the three. Record sequence, identifiers and each outcome, and plan compensation where required. On shared datastores, locking helps prevent restoration from interfering with others’ changes. Inspect the error response and observed state too; a rollback attempt can itself fail.
Confirmed commit needs evidence
Where supported, a confirmed commit applies a change temporarily and requires confirmation before its deadline. Choose the deadline from the time needed to validate service and recover access. Do not send confirmation merely because the initial RPC succeeded. For a management-access change, open a new connection from the authorized network, observe the intended state and test expected denials too. Distinguish an existing session from new access. Persistence across sessions depends on parameters and capabilities; losing a session does not have one universal result. Configuration restoration also does not automatically recover application sessions interrupted during the trial.
Accept by device and by service
A commit on one router does not create a distributed transaction with its neighbor. For a two-sided change, define the permitted order, tolerable intermediate states and response if only one side accepts. Retain evidence by target and service, including configuration readback and operational observation. An administratively enabled interface can still lack a physical link; the interface model distinguishes enabled from oper-status. Handover should identify what was actually tested, dependencies and reversal conditions. NETCONF flows in this lesson are protocol-based analysis exercises. The next lesson’s lab exercises local HTTP and does not establish NETCONF execution or recovery on Cisco equipment.
# Reading exercise only; capability and ownership checks precede edits.
# 1. Inspect hello capabilities and models.
# 2. Lock the relevant datastore; inspect existing pending changes.
# 3. Edit candidate, validate, inspect the approved diff.
# 4. Use confirmed commit only if supported and recovery is planned.
# 5. Verify NEW management access and operational service checks.
# 6. Confirm within the deadline only after acceptance; release locks.
# An RPC result does not establish application health.
A description change finds a pending route in candidate. The lock does not make that route part of the approval; the team must resolve ownership before commit.
Common pitfalls
Candidate as private; locking as cleanup; stop-on-error as rollback; commit as functional testing; two devices as one transaction.
Related topics: RESTCONF and concurrency · Access and recovery
Define the scope of each guarantee and verify the result where service is consumed.
Reference: NETCONF protocol · 350-401 ENCOR v1.2, effective 2026-03-19; core component of CCNP Enterprise