Which YANG Model?

A device may support several YANG models for the same function (e.g. interface-related modules). In most cases, these models expose the same underlying configuration in different ways:

The device (or its datastore) has one underlying source of truth for configuration.
Multiple YANG modules can each provide a view onto that source of truth, and more than one of those modules may be usable to write configuration.
The operator or automation team picks one model family to standardize on for their automation.

When discovering the interface-related models supported by each vendor, we find that Arista cEOS supports both IETF and OpenConfig models:

~/tutorial/scripts/netconf_tool.py cos-01 modules | grep interfaces

ietf-interfaces, rev=2018-02-20
openconfig-interfaces, rev=2026-01-06
arista-interfaces-notsupported-deviations, rev=2026-06-09

Nokia SR Linux supports an additional Native model:

~/tutorial/scripts/netconf_tool.py srl-01 modules | grep interfaces

ietf-interfaces, rev=2014-05-08
openconfig-interfaces, rev=2024-12-05
srl_nokia-interfaces, rev=2026-07-31
deviations=openconfig-srl-deviations

In the two lists above, Arista adds a deviations module that describes which OpenConfig elements are "not supported," telling NETCONF/gNMI automation that those elements will be ignored. Nokia's deviations go further: in addition to flagging unsupported elements, they describe reshaping some elements to match SR Linux's native typing and validation rules.

In both cases, the IETF interface models serve as the standard baseline for compliance but are not used directly for configuration. The OpenConfig modules import the IETF model for reference only. On SR Linux specifically, the IETF module is visible in the schema and useful for NETCONF/schema-interop purposes, but it cannot be used directly via the CLI or gNMI.

This reflects a general pattern in model-driven NOSes: the device keeps one internal configuration/state representation, and each YANG module (IETF, OpenConfig, native) is a view onto it. Reads and writes made through a non-native model are translated to and from the internal representation by a mapping layer, so:

IETF models exist mainly for standards interoperability and NETCONF/schema exposure.
OpenConfig models exist for vendor-neutral, multi-vendor automation.
Native vendor models exist for full feature coverage, including constructs (platform-specific port naming, hardware hierarchy, vendor-only features) that have no IETF or OpenConfig equivalent.

Nokia SR Linux

For NETCONF, SR Linux supports both the Native and OpenConfig models simultaneously. You can retrieve the configuration using either model by choosing the relevant path:

~/tutorial/nc_wrapper.sh srl-01 --get-config --filter /interface
# or
~/tutorial/scripts/netconf_tool.py srl-01 config '<interface/>'

<?xml version="1.0" encoding="UTF-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
  <interface xmlns="urn:nokia.com:srlinux:chassis:interfaces">
    <name>ethernet-1/2</name>
    <admin-state>enable</admin-state>
  </interface>
  ...
</data>

SR Linux also allows editing the configuration through either the native or the OpenConfig module. See the documentation on operations and mixed module author groups.

For OpenConfig, use /interfaces (plural):

~/tutorial/nc_wrapper.sh srl-01 --get-config --filter /interfaces
# or
~/tutorial/scripts/netconf_tool.py srl-01 config '<interfaces/>'

<?xml version="1.0" encoding="UTF-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
  <interfaces xmlns="http://openconfig.net/yang/interfaces">
    <interface>
      <name>ethernet-1/2</name>
      <config>
        <name>ethernet-1/2</name>
        <type xmlns:iana-if-type="urn:ietf:params:xml:ns:yang:iana-if-type">iana-if-type:ethernetCsmacd</type>
        <enabled>true</enabled>
      </config>
    </interface>
  </interfaces>
  ...
</data>

For gNMI, the default model is Native; you must switch the default to OpenConfig explicitly via the CLI:

enter candidate
set system grpc-server mgmt yang-models openconfig openconfig
commit now

Only one of the following two requests will work at a time, depending on the model currently selected:

gnmic --config ../srl-gnmic.yml get --path /interface
# or
gnmic --config ../srl-gnmic.yml get --path /interfaces

Deviations from OpenConfig Defaults

Deviations modules do more than flag unsupported elements or strip defaults — they can also adjust types, ranges, and constraints so the OpenConfig model matches what the platform actually supports. Examples include restricting interface name patterns to match the vendor's naming scheme, narrowing MTU ranges, or marking specific leaves (e.g. loopback-mode) as unsupported outright.

One concrete default-handling example, worth calling out on its own: the OpenConfig standard assumes an interface is enabled by default. SR Linux strips that default in its deviations, so the interface's admin state must be set explicitly.

deviation ".../config/openconfig-interfaces:enabled" {
  deviate delete {
    default true;
  }
}

A similar example appears with subinterface IPv4 defaults. In standard OpenConfig, IPv4 on a subinterface defaults to enabled, so automation scripts can skip setting it when adding an address. On SR Linux, you must set enabled explicitly.

deviation ".../subinterfaces/subinterface/openconfig-if-ip:ipv4/config/openconfig-if-ip:enabled" {
  deviate delete {
    default true;
  }
}

Automation Strategy: Picking a Model

As a rule of thumb when deciding which family to standardize on:

Prefer OpenConfig for portable, multi-vendor automation. The same paths and structure work across Arista, Nokia, and other OpenConfig-supporting platforms, with vendor deviations handling the edge cases.
Use the native model (e.g. srl_nokia-interfaces) only when you need a feature, port type, or platform capability that OpenConfig doesn't cover, or when you're deliberately building vendor-specific tooling.
Treat IETF models as an interoperability/compliance baseline; they're mainly relevant where a tool or integration strictly expects standard IETF YANG.