A large retailer uses Cisco and non-Cisco switches and routers and wants model-driven automation for VLANs and interfaces plus Cisco-specific telemetry and QoS features. Engineers debate IETF, OpenConfig, and Cisco native YANG models for NETCONF and gNMI playbooks. Which YANG model strategy best supports interoperable automation while preserving Cisco-specific features?
Select an answer to reveal the explanation.
Short Explanation
You're mixing standard tools with specialty tools in one toolbox. Open standards cover the common multi-vendor tasks cleanly, while Cisco native models unlock the extra platform-specific capabilities.
Full Explanation
The correct strategy works because IETF and OpenConfig models provide vendor-neutral abstractions for common VLAN and interface constructs that render consistently across Cisco and third-party platforms via NETCONF and gNMI, while Cisco native models expose proprietary counters, model-driven telemetry paths, and advanced QoS hierarchies with no standardized equivalent, so combining them delivers both portability and full feature coverage. Standardizing entirely on open models with best-effort mapping for Cisco QoS fails on proprietary depth because open models intentionally generalize, leaving Cisco-specific queuing, platform telemetry subscriptions, and feature knobs unavailable or lossy when translated. Relying on OpenConfig for configuration plus legacy SNMP polling for monitoring fails on model-driven telemetry because SNMP cannot provide the high-frequency, subscription-based structured streaming over gNMI that the scenario explicitly requires for Cisco telemetry. Splitting automation by vendor dialect to preserve fidelity fails on interoperability because maintaining separate Cisco native and OpenConfig playbooks for the same VLANs and interfaces duplicates logic, breaks uniform templating, and prevents a single source of truth across the mixed estate. Exam caveat is to distinguish transport from payload, remembering that NETCONF and gNMI can carry any YANG model, so the choice of IETF versus OpenConfig versus native is about data-model coverage rather than protocol capability. Practical check is to browse the device YANG suite with pyang or a NETCONF explorer, confirm VLAN and interface coverage in the open model, then verify the Cisco-specific QoS and telemetry XPaths only exist in native Cisco modules before committing playbooks.