A managed-service team runs one Python inventory job across a fabric where the second vendor documents OpenConfig support for interfaces and BGP but implements only a subset of the IETF models. The job must also set a Cisco-only QoS behaviour that exists only in the platform's own model. Which YANG model family should the team choose for each part of the job?
Select an answer to reveal the explanation.
Short Explanation
You can keep the shared interface and BGP data portable by using OpenConfig, while remembering that the second vendor supports only a subset. The Cisco-only QoS behaviour needs the native Cisco model because it is not available in a shared model.
Full Explanation
Use OpenConfig for shared interface and BGP data because the second vendor documents support for those models, while keeping in mind that its implementation covers only a subset. Use the Cisco platform’s native model for the Cisco-only QoS behaviour, which exists only in that model and cannot be expressed through a shared model. Using IETF interface and BGP models where available may seem standards-first, but the scenario identifies OpenConfig—not IETF models—as the documented support on the second vendor, and its limited coverage could leave required data unavailable. Using standard OpenConfig QoS policies with capability-based fallback supports portability where the behaviour is represented, but capability checks cannot make a standard model express a behaviour that exists only in Cisco’s native model. Using Cisco-native models for interface, BGP, and QoS with an adapter for the second platform may help translate shared data between systems, but an adapter cannot make Cisco-native models available on a platform that does not support them. Exam caveat: advertised support for a model family does not guarantee support for every revision, path, or operation. Practical check: query device capabilities and validate the exact model paths and QoS behaviour on representative devices from both vendors before deploying the job.