A campus engineer must add a new loopback description on IOS XE via NETCONF edit-config without replacing sibling config. The device enforces strict schema validation and rejects payloads with wrong namespaces. Which XML payload structure performs the targeted edit-config on IOS XE?
Select an answer to reveal the explanation.
Short Explanation
You're doing surgery, not a remodel — precise cuts win. That namespaced subtree tells IOS XE just where to merge your change.
Full Explanation
The correct structure places the interface configuration inside the NETCONF config element, uses the namespace expected by the IOS XE model, and limits the edit to the loopback node with merge semantics. This directs the edit-config operation at the intended configuration without replacing sibling settings, while satisfying strict schema validation. A replace operation can be appropriate when an entire targeted resource is deliberately being rewritten, but applying it at the interface node risks removing sibling configuration and violates the requirement to preserve it. The standard IETF interfaces namespace is a legitimate choice on devices and models that support it; however, it does not meet this scenario’s requirement to use the device’s required model namespace, so strict validation can reject the payload. The ethernetCsmacd type is valid for physical Ethernet interfaces, but it contradicts the stated loopback interface; a loopback must use the loopback interface type supported by the chosen model. Exam caveat: NETCONF operation attributes and supported namespaces depend on the device’s YANG models and implementation, so a payload valid on one IOS XE release may not validate on another. Practical check: inspect the device’s advertised capabilities and YANG library, then validate the payload and confirm the resulting interface configuration while checking that existing sibling settings remain unchanged.