A device advertising the YANG module ietf-interfaces accepts an edit but silently ignores one leaf; what should it have declared, and why is silence worse?

seniormust knowfreq 14%

answer

error or ignore: neither is acceptable
know before you push
a separate module that imports the base
deviate not-supported on the target node

basics

~20 s

The device should have shipped a YANG deviation, in a separate module, marking that leaf not-supported or narrowed. A declared gap lets automation adapt before pushing; a silent one leaves intent and device diverging with every edit reporting success.

solid answer

~50 s

RFC 7950 §7.20.3 covers this exact case: when a device cannot support part of a module, rejecting edits or ignoring them are both called unacceptable. Instead the server documents the gap with a deviation statement, an absolute path to the target node plus one or more deviate substatements, here deviate not-supported on /if:interfaces/if:interface/if:description, or deviate replace with a narrower type if the leaf works only within limits. RFC 9907 suggests putting deviations in a separate module that imports ietf-interfaces, never in the standard module. Silence is worse because nothing fails: the <rpc-reply> says <ok/>, read-back of the configuration may show the leaf, and the only symptom is behaviour that never matches intent. A declared deviation changes the schema the client sees, so tooling refuses or adapts before the push, and an edit that still carries the leaf fails loudly.

RFC 7950 §7.20.3 covers this exact case: when a device cannot support part of a module, rejecting edits or ignoring them are both called unacceptable. Instead the server documents the gap with a `deviation` statement, an absolute path to the target node plus one or more `deviate` substatements, here `deviate not-supported` on `/if:interfaces/if:interface/if:description`, or `deviate replace` with a narrower `type` if the leaf works only within limits. RFC 9907 suggests putting deviations in a separate module that imports `ietf-interfaces`, never in the standard module. Silence is worse because nothing fails: the `<rpc-reply>` says `<ok/>`, read-back of the configuration may show the leaf, and the only symptom is behaviour that never matches intent. A declared deviation changes the schema the client sees, so tooling refuses or adapts before the push, and an edit that still carries the leaf fails loudly.

code

yang · 7 lines

yang

deviation /if:interfaces/if:interface/if:description {
  deviate replace {
    type string {
      length "0..64";
    }
  }
}

go deeper

for a junior

Recall that a YANG deviation is a device's declaration that it implements part of a standard model differently or not at all, and that it lives in its own module.

for a middle

Explain the deviation statement's shape: an absolute path to the target node plus deviate not-supported, add, replace or delete, in a separate module that imports the standard one.

for a senior

Argue from RFC 7950 why both rejecting and silently ignoring are unacceptable, show how a silent gap passes idempotency checks, and describe catching undeclared gaps by comparing intent with the operational datastore.

for a principal

Treat deviations as a per-platform capability register: their count against a standard model measures what that model's portability really costs on each device and software release.

The scenario

An automation team pushes interface configuration to a device that advertises the standard YANG module ietf-interfaces (RFC 8343). The NETCONF edit returns <ok/>. Weeks later someone notices that one leaf, say each interface's description, never shows up where it should. The device never supported it, never said so, and accepted it anyway.

What RFC 7950 says about this exact choice

RFC 7950 §7.20.3 describes the situation directly. A device that lacks the hardware or software to support part of a standard module can:

treat attempts to configure the unsupported part as an error reported back to the unsuspecting application, or
ignore those incoming requests.

Its verdict is that neither choice is acceptable. Instead, YANG lets the server document the parts of a base module it does not support, or supports with different syntax, using the deviation statement. §5.6.3 shows what an error alone misses: its example is a BGP model allowing any number of peers on a server that supports 16. The 17th peer fails, but an application that knew the limit in advance would never have started down a path that could not succeed.

Declaring the gap

A deviation names a target node with an absolute schema node identifier and says how the server departs from it with deviate (§7.20.3.2): not-supported, add, replace or delete. For the scenario:

yang

module example-if-deviations {
  yang-version 1.1;
  namespace "urn:example:if-deviations";
  prefix exd;
  import ietf-interfaces {
    prefix if;
  }
  revision 2026-10-01;
  deviation /if:interfaces/if:interface/if:description {
    deviate not-supported;
  }
}

If the leaf works but only within limits, an honest deviate replace narrows it instead: a device mapping description onto the IF-MIB's ifAlias, which RFC 2863 sizes at 0..64, could replace its type with a string of length "0..64".

Rules that apply here:

Never in the standard. RFC 7950: deviations MUST never be part of a published standard, because they are how implementations are known to vary from it. RFC 9907 §4.20 restates that they cannot appear in IETF modules.
A separate module. RFC 9907 suggests deviation modules distinct from regular definitions, so deviations can be platform-specific and temporary. RFC 7950's example says the server advertises both the base module and the deviation module.
Implemented, not just imported. RFC 7950 §5.6.5 counts a module's deviations among what a server implements.
Last resort. Deviations are "strongly discouraged"; a server that deviates is not fully compliant with the module.
Still valid. After all announced deviations are applied, the resulting model MUST still be valid.

How the device announces the deviation module to clients is a separate mechanism; this answer stops at what it declares.

Why the undeclared gap is worse

	Declared deviation	Silent ignore
When the client learns	before the first push, from the schema	after a human notices behaviour
What an edit with the leaf does	fails as data outside the server's schema	returns `<ok/>`
Configuration read-back	consistent with the declared schema	may echo the leaf, proving nothing
Effect on automation	adapt, skip or pick another model	believes intent was applied

An idempotent workflow re-pushes, gets <ok/>, and reports no drift, so the silent gap survives every run.
Validation against the published model passes, because the payload is valid for the model; the device's real schema is what differs.
The cost lands far from the cause: a missing description, a missing limit or an unenforced constraint surfaces in an incident, not in the pipeline.

Detecting what was never declared

Under NMDA (RFC 8342), configuration datastores such as <running> hold what was asked for, while <operational> reports what is in use; functionality that is neither enabled nor operational SHOULD be omitted from it. Comparing intended configuration with <operational> is how a team finds silent gaps, and RFC 8342 also says deviations SHOULD be used when a device is known in advance not to conform to the <operational> schema. The fix belongs upstream: the device's maintainer ships the deviation, and the automation team treats each one as an entry in a per-platform capability register. Until that happens, the team's own record of the gap, kept per platform and software release, is the only thing standing between the next push and the same silent loss.

## The scenario An automation team pushes interface configuration to a device that advertises the standard YANG module `ietf-interfaces` (RFC 8343). The NETCONF edit returns `<ok/>`. Weeks later someone notices that one leaf, say each interface's `description`, never shows up where it should. The device never supported it, never said so, and accepted it anyway. ## What RFC 7950 says about this exact choice RFC 7950 §7.20.3 describes the situation directly. A device that lacks the hardware or software to support part of a standard module can: 1. treat attempts to configure the unsupported part as an error reported back to the unsuspecting application, or 2. ignore those incoming requests. Its verdict is that **neither choice is acceptable**. Instead, YANG lets the server *document* the parts of a base module it does not support, or supports with different syntax, using the `deviation` statement. §5.6.3 shows what an error alone misses: its example is a BGP model allowing any number of peers on a server that supports 16. The 17th peer fails, but an application that knew the limit in advance would never have started down a path that could not succeed. ## Declaring the gap A **deviation** names a target node with an absolute schema node identifier and says how the server departs from it with `deviate` (§7.20.3.2): `not-supported`, `add`, `replace` or `delete`. For the scenario: ```yang module example-if-deviations { yang-version 1.1; namespace "urn:example:if-deviations"; prefix exd; import ietf-interfaces { prefix if; } revision 2026-10-01; deviation /if:interfaces/if:interface/if:description { deviate not-supported; } } ``` If the leaf works but only within limits, an honest `deviate replace` narrows it instead: a device mapping `description` onto the IF-MIB's `ifAlias`, which RFC 2863 sizes at 0..64, could replace its `type` with a `string` of `length "0..64"`. Rules that apply here: - **Never in the standard.** RFC 7950: deviations MUST never be part of a published standard, because they are how implementations are known to vary from it. RFC 9907 §4.20 restates that they cannot appear in IETF modules. - **A separate module.** RFC 9907 suggests deviation modules distinct from regular definitions, so deviations can be platform-specific and temporary. RFC 7950's example says the server advertises both the base module and the deviation module. - **Implemented, not just imported.** RFC 7950 §5.6.5 counts a module's deviations among what a server implements. - **Last resort.** Deviations are "strongly discouraged"; a server that deviates is not fully compliant with the module. - **Still valid.** After all announced deviations are applied, the resulting model MUST still be valid. How the device announces the deviation module to clients is a separate mechanism; this answer stops at what it declares. ## Why the undeclared gap is worse | | Declared deviation | Silent ignore | |---|---|---| | When the client learns | before the first push, from the schema | after a human notices behaviour | | What an edit with the leaf does | fails as data outside the server's schema | returns `<ok/>` | | Configuration read-back | consistent with the declared schema | may echo the leaf, proving nothing | | Effect on automation | adapt, skip or pick another model | believes intent was applied | - An idempotent workflow re-pushes, gets `<ok/>`, and reports *no drift*, so the silent gap survives every run. - Validation against the published model passes, because the payload is valid for the model; the device's real schema is what differs. - The cost lands far from the cause: a missing description, a missing limit or an unenforced constraint surfaces in an incident, not in the pipeline. ## Detecting what was never declared Under NMDA (RFC 8342), configuration datastores such as `<running>` hold what was asked for, while `<operational>` reports what is in use; functionality that is neither enabled nor operational SHOULD be omitted from it. Comparing intended configuration with `<operational>` is how a team finds silent gaps, and RFC 8342 also says deviations SHOULD be used when a device is known in advance not to conform to the `<operational>` schema. The fix belongs upstream: the device's maintainer ships the deviation, and the automation team treats each one as an entry in a per-platform capability register. Until that happens, the team's own record of the gap, kept per platform and software release, is the only thing standing between the next push and the same silent loss.

Is rejecting every edit to the unsupported YANG leaf with an error enough to make deviations unnecessary?
No. RFC 7950 §7.20.3 lists rejection alongside ignoring and calls neither acceptable. An error tells the application only after it has started a change that cannot succeed, possibly mid-way through a multi-device rollout. A deviation gives that knowledge in advance, as part of the schema, so the client can plan around the gap. Rejecting stray data is still right; it just does not replace declaring the gap.
Why does RFC 9907 recommend a deviation for a platform's resource limit rather than max-elements in the standard YANG list?
RFC 9907 §4.20 says max-elements in a published module describes an architectural limit of the model, not a platform's limit. A device that can hold only ten entries declares that with a deviation, `deviate add { max-elements 10; }`, so the standard stays general and the limit is visible exactly where it applies.

A restaurant that prints 'sold out' next to a dish lets you order something else; a kitchen that takes the order and never cooks it leaves you waiting with a receipt that says everything went fine.

saying these in an interview costs you the question

Ignoring an unsupported leaf is harmless as long as the edit returns ok
The vendor should add its deviations to the ietf-interfaces module itself
Rejecting edits to unsupported nodes makes declaring a deviation unnecessary
A device with deviations is still fully compliant with the standard module
Reading the leaf back from running proves the device applied it

A device advertising the YANG module ietf-interfaces accepts an edit but silently ignores one leaf; what should it have declared, and why is silence worse?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The scenario

What RFC 7950 says about this exact choice

Declaring the gap

Why the undeclared gap is worse

Detecting what was never declared

▾common follow-ups2 questions

▾analogy~20 s

▾red flags5 flags

The scenario

What RFC 7950 says about this exact choice

Declaring the gap

Why the undeclared gap is worse

Detecting what was never declared

answer

go deeper