A logistics company runs an all-Cisco IOS XE estate. Its automation must configure standard interface settings plus one Cisco-specific platform feature, and every change has to arrive through a single NETCONF session driven by one Python code path. Which YANG model family should the team standardize on?
Select an answer to reveal the explanation.
Short Explanation
Native Cisco models are written for IOS XE itself, so they describe both everyday features and platform-specific knobs that standard models leave out. With every change riding in one model tree, your Python service keeps a single code path for the whole device. It's like buying the manufacturer's full toolbox instead of a generic set that misses the odd-sized spanner.
Full Explanation
Choosing a model family is about coverage first: the estate is entirely Cisco IOS XE and one required platform feature has no OpenConfig or IETF definition, so only the native Cisco models describe it. Native models also carry standard building blocks such as interface configuration inside the same container tree, which lets a single Python service open one NETCONF session and drive every change through one code path. The OpenConfig route leans on deviation statements, and a deviation can only declare that an implementation departs from a standard node; it cannot add a configuration node for a feature the standard model never defined, so the platform feature stays unreachable. Choosing IETF standards-track modules pursues portability the requirements never ask for and still leaves the same coverage gap. Keeping OpenConfig for common features plus native models for the rest is a legitimate production pattern, but it breaks the stated single model set per device and doubles schema handling in the client. Exam caveat: which native modules exist varies by IOS XE release, so confirm the feature tree against the device's YANG library. Practical check: query the schema on a lab switch and look for the feature's container before committing to a family.