A network engineer hand-writes a NETCONF edit-config payload from a YANG module that defines a container 'bgp' holding a leaf 'router-id'. The router parses the XML cleanly but rejects the request, reporting that bgp is absent from the schema although the module clearly defines it. Which namespace rule makes the instance match the YANG model?
Select an answer to reveal the explanation.
Short Explanation
An XML instance matches a YANG model only when every element sits in the namespace of the module that defines it, whatever prefix you type. Your prefix is a nickname, but the namespace URI is the street address the parser compares. That's why a renamed prefix still commits while a borrowed namespace fails.
Full Explanation
YANG modules map to XML namespaces: every element in a valid instance belongs to the namespace of the module that declared it, and the parser matches that URI before it looks at the node name. Because a default namespace declared on an ancestor covers its descendants, placing it on the container or higher up produces a valid instance. Prefixing every element with the module name treats the prefix as significant, but a prefix is only a local alias inside one document, so example-bgp:bgp and bgp:bgp resolve to the same element for the parser. Attaching a revision date to the namespace repeats a pattern from versioned service schemas; YANG namespaces are module-scoped, so every revision of a module shares one namespace. Using the NETCONF base namespace for the data confuses envelope with payload: the rpc, edit-config and config wrappers live in the base namespace while the data belongs to the model. Caveat: a document that mixes modules needs a separate declaration for each one, so a single default will not cover the second module. Practical check: print each element's resolved namespace with an XML parser and compare it with the module namespace.