You export a NETCONF edit-config payload from YANG Suite for a new loopback interface and its IPv4 address. The tool shows the module, the container tree, and the operation attribute before you copy the XML. Which structural feature makes the export a valid instance of the YANG model?
Select an answer to reveal the explanation.
Short Explanation
Your export is a valid instance when it follows the model’s own shape: each leaf sits at the declared depth, and each model element uses its defining module’s namespace. A namespace declaration can be inherited in XML, so check the namespace as well as the nesting.
Full Explanation
A valid export must match the YANG data tree in both hierarchy and namespace: each element appears at the model-defined level, and its XML namespace identifies the module that defines it. Correct nesting and module qualification let the NETCONF server interpret the payload as the intended interface configuration, not merely well-formed XML. Using the defining module’s namespace but placing the IPv4 address directly under the interface entry fails because the address belongs inside its IPv4 container; the XML may be well formed, but its tree does not match the schema. Putting the elements in the correct hierarchy but using the NETCONF base namespace fails because that namespace applies to protocol operations and envelope elements, while modeled data elements use their defining YANG module namespaces. Using the right namespaces and hierarchy but omitting the interface name also fails: a list entry must include its key to identify the interface being configured. Exam caveat: XML namespace prefixes are arbitrary aliases; the namespace URI, not the prefix spelling, identifies the module. Practical check: compare exported element paths and namespace URIs with the YANG schema, and confirm that every list entry includes its key before sending the edit-config.