An automation engineer is writing a Python script with ncclient that sets a MOTD banner on an IOS XE router over NETCONF. The session opens and get_config returns data, but the edit_config call is rejected and the engineer is unsure which element must hold the configuration it sends. Which XML structure must the payload use to deliver the banner change to the target datastore?
Select an answer to reveal the explanation.
Short Explanation
ncclient builds the RPC frame for you, so your script only owes the inner config wrapper that carries the banner. You're mailing a document here, and content without the wrapper won't ship. Leave it out and the edit never reaches the datastore.
Full Explanation
In NETCONF, edit-config carries only the configuration content; ncclient generates the rpc envelope, the message-id and the session handling for you, and your script supplies the inner config element that the router's datastore layer parses, so the banner must sit inside that wrapper for the edit to reach the chosen target. Hand-building a complete rpc envelope duplicates what the library already produces and usually mismatches message-id or namespace, so the router rejects the frame before any edit runs. Placing the banner under the data element mirrors the structure you receive from get_config, but data is the retrieval shape rather than the payload shape for an edit, so nothing gets written. Wrapping the change in a lock element treats a separate session operation as payload content; locking does protect the datastore, yet it is issued as its own rpc instead of living in the configuration tree. Exam caveat: some platforms offer a candidate datastore with a separate commit step, so confirm which target your router accepts. Practical check: enable ncclient debug logging and dump the outgoing rpc to confirm the config wrapper is present.