A network engineer is hand-building an XML edit-config payload for an interface YANG module and wants the NETCONF server to accept it on the first attempt. The model defines containers, a list with a key leaf and several leaves, all under a module namespace. Which mapping rule makes this XML a valid instance of that model?
Select an answer to reveal the explanation.
Short Explanation
Your XML is a translation of the model, and the namespace is the address saying which YANG module each element came from. Match the model's node names exactly, and you'll find list keys sit as ordinary child elements.
Full Explanation
The correct rule follows YANG’s XML encoding: schema node names appear as XML element names in the namespace assigned to their defining module, and a list instance is an element containing child elements for its key and other leaves. The key leaf’s value identifies the entry, but it remains a child element; XML attributes are not the YANG data-node representation. Encoding the key as an attribute may be familiar from other XML vocabularies, yet it changes the modeled structure and does not satisfy the required list mapping. Resetting descendant elements to no namespace is also a valid XML namespace technique in general, but it assigns those elements to no module, so they no longer represent the module’s YANG nodes. Flattening a list entry’s leaves into the parent container omits the element that represents the list instance; the values then lose the list’s modeled grouping and entry boundary. Exam caveat: NETCONF adds protocol-level wrapper elements, and those do not replace the YANG-defined element structure inside the payload. Practical check: compare the payload’s element names, namespace URIs, and list-entry nesting with the module’s schema tree, then validate the edit-config against the server’s advertised YANG modules.