A developer builds a RESTCONF URI for an IOS XE interface. The device exposes both IETF interfaces and Cisco-IOS-XE-native models. Which practice keeps the request valid?
Select an answer to reveal the explanation.
Short Explanation
Pick one language for the whole sentence—IETF or native—don’t mash half-Spanish and half-French into one street address and expect the mailman to guess.
Full Explanation
Building a RESTCONF URI for an IOS XE interface when both IETF interfaces and Cisco-IOS-XE-native models are exposed requires staying inside one module’s path for that request—do not mix IETF and native prefixes in a single URI. That practice keeps the request valid because each YANG module defines its own namespace, list keys, and leaf names; RESTCONF paths are module-qualified, and blending two models in one path produces an address the device cannot resolve as a single resource. Municipal developers pick one tree (IETF or native), walk its hierarchy, and encode keys the way that module defines them.
Concatenating ietf-interfaces and Cisco-IOS-XE-native prefixes in one path segment fails because URI path segments are not a “union for completeness”; mixed prefixes break module identity. Omitting the module prefix entirely so the device invents the correct model fails conceptually: RESTCONF expects explicit module qualification for data resources, not ambiguous bare names. Using NX-OS OpenConfig modules on an IOS XE URI fails because platform YANG catalogs differ; assuming all YANG is interchangeable invents cross-OS paths that IOS XE will not serve.
Exam caveat: you may use different modules in different requests; the rule is consistency within a single URI/payload binding, not a ban on ever using both models on the box. Operational check: document which model the city’s playbooks use per feature, validate paths against the device’s YANG library or RESTCONF root, and fail CI if a URI string contains two competing module prefixes.