Two vendors both support the same OpenConfig model, yet your code works on one and fails on the other. Why?

Where the differences hide

• Deviations. A vendor module that says, for example:

  deviation "/oc-if:interfaces/oc-if:interface/oc-if:state/oc-if:counters/oc-if:in-fcs-errors" {
    deviate not-supported;
  }

  Other forms are deviate add, replace and delete to change defaults, types or constraints.
• Features. if-feature makes nodes optional. The server lists the features it implements.
• Revisions. The same module name with a different revision can rename or move nodes.
• Semantics. Two implementations can accept the same leaf but apply it differently, for example when an interface needs a sub-interface 0 before an IP address is valid.

How the device tells you

NETCONF 1.0-style servers list each module in the hello as a capability URI:

urn:ietf:params:xml:ns:yang:ietf-interfaces?module=ietf-interfaces&revision=2014-05-08&features=pre-provisioning,if-mib,arbitrary-names

A deviations= parameter, when present, names the vendor deviation modules. Newer servers point to the YANG library (ietf-yang-library, RFC 7895 and RFC 8525), which lists modules, revisions, features and deviations as data you can query. gNMI returns supported models in the Capabilities response.

How I protect the code

• Pin the platform and release in the test lab to the ones in production.
• Gather capabilities as part of pre-checks and fail fast if a required module or revision is missing.
• Keep per-platform translation in one place instead of scattering if vendor == through the code.