A developer hand-writes a NETCONF edit-config XML payload for a YANG module that defines interface configuration. The server rejects it, saying the target node does not exist, even though the tag names and hierarchy match the model. Which statement about the namespaces in that XML instance is accurate?
Select an answer to reveal the explanation.
Short Explanation
The server matches tags by the namespace URI, so the prefix is only a label you pick. Unqualified top-level elements land in no namespace at all, which is why a perfectly named tree still gets rejected. Prefixes behave like nicknames you can't count on to stay the same.
Full Explanation
An XML instance is a set of namespace-qualified elements: each tag must resolve through its namespace URI to a node in the YANG module, and that URI comes from the module's namespace statement rather than from any file or prefix. Because a prefix is only a local shorthand for the URI, you may bind any string you like as long as the URI behind it is the module's own. Treating the module's prefix as the identifier fails, because the server resolves namespaces rather than the spelling you chose. Leaving top-level elements unqualified fails, because an element with no namespace sits in a different namespace than the module's nodes and can never match, even when the local names are identical. Using the YANG file name as the namespace fails, because file naming and module identity are unrelated and only the namespace statement counts. Exam caveat: the URI that appears in the NETCONF hello capability statement identifies the module but qualifies nothing inside the payload. Practical check: add a default xmlns carrying the module URI to the root element and confirm the server then accepts the same tree.