Our team standard mandates a NETCONF-only client for an IOS XE router, built in Python with an XML RPC envelope. The script must first read the entire configuration datastore while leaving out interface counters and link state, then place a change so it only becomes active after a commit step. Which NETCONF operation pair fits this workflow?
Select an answer to reveal the explanation.
Short Explanation
Nice, you caught the difference between the two read calls. get-config stays inside the configuration datastore, like a librarian handing over only the archive boxes instead of the whole storeroom, and edit-config holds your change until you commit, so you can review it first. A plain get can return counters and other state data, while a subtree-filtered read hands back only part of the config, so it isn't the full picture either.
Full Explanation
A get-config request with running as its source returns configuration from that datastore, not interface counters or link state. Pairing that read with an edit-config on the candidate gives you the staging behaviour you asked for: the change sits in the candidate datastore and becomes active only when a commit is issued. The copy-config route satisfies the read half but fails staging, because it copies the source configuration to the destination datastore, making the new configuration live when the copy to running finishes. The get approach fails the scope half, since it can return configuration plus state data, including counters. The filtered get-config fails the other edge of that same scope rule, because subtree filtering returns only the selected part of the configuration rather than the entire datastore. Not every image exposes a candidate datastore, so confirm that the device supports the candidate capability before relying on this workflow.