How should a multi-vendor estate choose between IETF YANG, OpenConfig and vendor-native models for automation, and where do deviations fit in that choice?
answer
- portability against coverage
- who publishes and how it versions
- count the deviations per platform
- one writer per setting
basics
~20 sPrefer a standard model, IETF or OpenConfig, where every platform implements it with few deviations; fall back to vendor-native models where coverage matters more than portability. Track each platform's deviations and features as the measured cost of that choice.
solid answer
~50 sIt is a trade of **portability against coverage**. IETF models are Standards Track RFCs with dated revisions and NMDA alignment, but cover only what a working group standardised and move slowly. OpenConfig models come from an operator working group outside the IETF, are not RFCs, and version semantically; they are the schemas gNMI assumes by default. Vendor-native models cover every knob a platform has but port nowhere. I would decide per functional domain, not per estate: use a standard model where each platform's deviation and feature set against it is small, and native where the standard lacks what we must configure. The deviations are the evidence: each `not-supported` is a hole the automation must handle per device, so their count per platform and release is the real cost. Never let two models write the same setting, and verify against operational state rather than trusting `<ok/>`.
go deeper
Recall the three families: IETF models published as RFCs, OpenConfig models from an operator group, and vendor-native models from each device maker.
Explain what separates them: who publishes each, how each is versioned, and why native models cover more but port nowhere.
Read a platform's deviations and features against a standard model to decide whether it is usable, and catch undeclared gaps by comparing pushed intent with operational state.
Set the estate's policy per functional domain, quantify portability with a per-release deviation ledger, enforce one writer per setting, and own the trade between a translation layer and lock-in.
## The decision in one line A multi-vendor automation estate wants **one model per concept** so that the same intent renders the same way on every device. No single family of YANG models delivers that completely, so the choice is a trade between **portability** (one model, many platforms) and **coverage** (every setting the hardware has). Deviations and features are how you measure where each platform sits on that trade. ## The three families | | IETF models | OpenConfig models | Vendor-native models | |---|---|---|---| | Publisher | IETF working groups, as RFCs | an operator working group, outside the IETF | each device maker | | Status | Standards Track RFCs, e.g. RFC 8343 `ietf-interfaces`, RFC 8349 `ietf-routing` | not RFCs | not standards | | Versioning | dated `revision` statements | semantic version strings | the maker's schedule | | Coverage | what the group standardised | what the operators prioritised | the whole platform | | Portability | high where implemented | high where implemented | none | - **IETF** models follow the NMDA datastore architecture of RFC 8342 and the authoring rules of RFC 9907, and never contain deviations: RFC 7950 forbids deviations in a published standard. - **OpenConfig** models are the schemas the gNMI specification, itself an OpenConfig document rather than an RFC, assumes; a gNMI path with no origin should default to `openconfig`. RFC 9232 describes gNMI as coming from the OpenConfig Operator Working Group. - **Vendor-native** models track the platform exactly, so a software upgrade can change them on a schedule the operator does not control. Both standard families are optional in parts (features) and unevenly implemented (deviations). The gNMI specification's model catalog entries can themselves describe a deviation, so the mechanism applies to OpenConfig models as well as IETF ones. ## Deviations as the cost ledger A device that implements a standard model honestly ships a deviation module saying what it does not support or supports differently, and a feature list saying which optional parts it has. For a strategy, read them as data: 1. Per platform and software release, collect the implemented revision, supported features and deviations for each candidate model. 2. Count the `not-supported` deviations that hit nodes your intent actually uses; ignore gaps in parts you never configure. 3. Weigh `replace` deviations that narrow a type or a limit: they are portable only if your intent stays inside the narrowest platform. 4. Where the standard model needs per-platform branches on most of what you configure, it is no longer buying portability, and the native model is cheaper. An **undeclared** gap breaks this ledger: the count looks small while the device silently ignores data. That is why acceptance testing pushes intent and compares it with the `<operational>` datastore, not with the `<ok/>` reply. ## Mixing models safely - **One writer per setting.** If a standard model and a native model both reach the same underlying configuration, letting automation write through both makes each overwrite the other. The gNMI specification itself warns that a CLI origin and an OpenConfig origin can be different views of the same data, with complex interaction. - **Decide per domain.** Interfaces may be portable through `ietf-interfaces` or OpenConfig while a platform-specific forwarding feature stays native. The boundary should be documented, not discovered. - **Pin revisions.** Automation targets the revision each device implements; RFC 7950 allows only one implemented revision per module, so a revision change is a contract change. ## What has no single right answer - How many deviations make a standard model not worth it depends on how much of the model the estate uses. - Whether to build a translation layer from one internal intent model to each device model, or to push device models directly, trades engineering effort against vendor lock-in. - How fast to follow new revisions trades new coverage against re-validation work. - Whether to wait for a device maker to ship an honest deviation module or to keep the team's own record of observed gaps trades accuracy against time; most estates need both. A principal answer names these trades, puts numbers on them per platform, and keeps the deviation ledger current as releases change it. The ledger is also the negotiating document: a platform whose deviations against the chosen model shrink release by release is converging, and one whose list grows is telling you to change course.
- Why can't the platform gaps simply be fixed by publishing a new revision of the standard YANG model with the deviations folded in?Because a deviation describes one implementation's departure, not the standard. RFC 7950 says deviations MUST never be part of a published standard, since they are how implementations are known to vary from it. Folding them in would make the model describe the weakest device rather than the intended contract, and a device maker cannot revise a standard module it does not own anyway.
- What do you test before trusting that a platform implements a standard YANG model well enough for production automation?Collect its implemented revision, features and declared deviations, then push the intent you actually use and compare it with the operational datastore. Declared gaps tell you what to branch on; differences that no deviation explains are silent gaps, and they are the reason not to rely on a successful edit reply alone.
saying these in an interview costs you the question
- OpenConfig models are IETF Standards Track RFCs
- Deviations apply only to IETF modules, not to OpenConfig models
- A standard model is portable no matter how many deviations each platform declares
- Writing one setting through both a standard and a native model is harmless
- Vendor-native models should never be used once any standard model exists