A Python script using ncclient pushes a new hostname and an interface description to an IOS XE router. The session authenticates and opens normally, but every edit_config call fails with a parser error about unexpected elements, so nothing changes on the router. Which payload structure lets the ncclient edit-config call succeed on this router?
Select an answer to reveal the explanation.
Short Explanation
You only need to give ncclient the configuration data, not the NETCONF envelope it builds around the request. Send one config element with both leaves in their defining namespaces and in the IOS XE hierarchy, and the router can parse it.
Full Explanation
The successful payload is one XML config element containing the hostname and interface description in the IOS XE YANG hierarchy, with each element in the namespace of the module that defines it. ncclient supplies the surrounding NETCONF edit-config RPC and config wrapper, so this is the structure the call expects. A complete edit-config RPC envelope passed as config is the wrong layer: ncclient builds its own envelope, which can result in unexpected nesting or malformed XML. Using the right namespaces but placing hostname and interface directly beneath config still fails because XML elements must follow the device’s YANG parent-child hierarchy; namespaces alone do not make those locations valid. An RFC 7951 JSON body is also unsuitable because ncclient’s NETCONF edit_config call expects an XML configuration payload, and module-qualified JSON keys do not turn JSON into XML. Exam caveat: matching the namespaces is not enough; the ancestry must match the router’s schema, and IOS XE model details can vary by release. Practical check: inspect the generated XML RPC and compare the payload’s namespaces and hierarchy with the router’s advertised YANG modules or a known-good NETCONF example.