What do YANG's four deviate arguments, not-supported, add, replace and delete, each change, and which precondition does each carry?

middleshould knowfreq 10%

answer

remove, add, swap, strip
single-valued properties and existence
delete must match exactly
the result must still be a valid model

basics

~20 s

not-supported removes the target node; add attaches properties a single-valued slot must not already hold; replace swaps properties that must exist; delete removes properties whose keyword and argument match exactly. The deviated model must remain valid.

solid answer

~40 s

A deviation targets one schema node by absolute path and carries one or more deviate statements (RFC 7950 §7.20.3.2). not-supported says the server does not implement the node at all. add attaches properties, and a property that may appear only once must not already exist, so a leaf with a default cannot gain another by add. replace swaps properties that must already exist, for example a new type or max-elements. delete removes properties, and the keyword and argument string must equal the target's exactly, so deleting a must repeats its expression verbatim. The deviable properties are config, default, mandatory, max-elements, min-elements, must, type, unique and units. After all deviations are applied, in any order, the resulting model must still be valid.

A `deviation` targets one schema node by absolute path and carries one or more `deviate` statements (RFC 7950 §7.20.3.2). `not-supported` says the server does not implement the node at all. `add` attaches properties, and a property that may appear only once must not already exist, so a leaf with a default cannot gain another by `add`. `replace` swaps properties that must already exist, for example a new `type` or `max-elements`. `delete` removes properties, and the keyword and argument string must equal the target's exactly, so deleting a `must` repeats its expression verbatim. The deviable properties are `config`, `default`, `mandatory`, `max-elements`, `min-elements`, `must`, `type`, `unique` and `units`. After all deviations are applied, in any order, the resulting model must still be valid.

go deeper

for a junior

Recall the four deviate arguments, not-supported, add, replace and delete, and that a deviation points at one target node by its absolute schema path.

for a middle

Explain the precondition behind each argument and list which properties a deviate may touch, using a default or max-elements change as the worked case.

for a senior

Choose the narrowest honest deviation, relaxing or narrowing before removing, and check that the combined set still yields a valid model with no order-dependent results.

for a principal

Set authoring rules for a platform team's deviation modules: one deviation per target, resource limits as deviations rather than model edits, and review of every not-supported as a portability cost.

The deviation statement in one paragraph

A deviation is a server's declaration that it does not implement a node of some module faithfully. Its argument is an absolute schema node identifier, the path to the target node with module prefixes such as /if:interfaces/if:interface/if:enabled, and its body holds one or more deviate statements plus an optional description and reference (RFC 7950 §7.20.3.1). Each deviate takes exactly one of four arguments.

The four arguments

deviate	What it does	Precondition
`not-supported`	the target node is not implemented by this server	none beyond a valid target
`add`	adds properties to the target node	a property that can appear only once MUST NOT already exist
`replace`	replaces properties of the target node	the properties being replaced MUST exist
`delete`	deletes properties from the target node	keyword MUST match and argument string MUST be equal

The properties add, replace and delete may touch are fixed by the substatement table in §7.20.3.2:

config, default, mandatory, type, units
max-elements, min-elements
must and unique, which may appear several times

Anything outside that list, such as a list's key, its when condition or the node's name, cannot be deviated by these statements. A property defined by an extension can be deviated only if the extension allows it (§7.19).

Worked examples on ietf-interfaces

RFC 8343 gives each interface a leaf enabled with default "true" and a leaf description of type string. Two honest deviations:

yang

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

The first says new interfaces start administratively down on this device. It must be replace: a leaf's default appears at most once, the target already has one, and add would break the "MUST NOT exist" rule. The second narrows the description to 64 characters, the size RFC 2863 gives ifAlias, which RFC 8343 lets a server map description onto.

RFC 7950's own examples cover the rest:

deviate not-supported on /base:system/base:daytime: the service is not offered.
deviate add { default "admin"; } on a leaf that had no default.
deviate replace { max-elements 3; } on a name-server list.
deviate delete { must "daytime or time"; }: the expression is repeated character for character.

Getting delete and not-supported right

delete is literal. The keyword and the argument string must both match the target. A must with an equivalent but differently written expression is not a match, and the deviation is in error.
not-supported removes the node from the server's schema. Everything beneath it goes with it, data sent for it is outside the schema, and a default it carried no longer applies anywhere.
delete versus not-supported. Deleting mandatory or a must keeps the node and relaxes it; not-supported removes it. Choosing the weaker statement is what makes a deviation honest rather than sweeping.
add on a repeatable property appends. must and unique may appear several times, so deviate add with another must simply adds a constraint; the "MUST NOT already exist" rule bites only on single-valued properties such as default on a leaf, type or units.

Rules that keep deviations sane

The result must be valid. After applying all deviations a server announces, in any order, the model MUST still be valid (§7.20.3). A deviation that, for example, leaves a mandatory leaf with a default has produced an invalid model.
One deviation per target per module. RFC 9907 §4.20 notes that evaluation order can change the result and says multiple deviation statements for the same target in the same module SHOULD NOT be used. RFC 7950's "in any order" rule is about validity; RFC 9907's warning is about the outcome, and the two together argue for a single, combined deviation.
Platform limits belong here, not in the model. RFC 9907 says max-elements in a published module states an architectural limit; a platform's hard resource limit is declared with deviate add or replace of max-elements in a deviation.
Last resort. RFC 7950 calls deviations strongly discouraged; a server that deviates is not fully compliant with the module.

## The deviation statement in one paragraph A **deviation** is a server's declaration that it does not implement a node of some module faithfully. Its argument is an **absolute schema node identifier**, the path to the target node with module prefixes such as `/if:interfaces/if:interface/if:enabled`, and its body holds one or more `deviate` statements plus an optional `description` and `reference` (RFC 7950 §7.20.3.1). Each `deviate` takes exactly one of four arguments. ## The four arguments | deviate | What it does | Precondition | |---|---|---| | `not-supported` | the target node is not implemented by this server | none beyond a valid target | | `add` | adds properties to the target node | a property that can appear only once MUST NOT already exist | | `replace` | replaces properties of the target node | the properties being replaced MUST exist | | `delete` | deletes properties from the target node | keyword MUST match and argument string MUST be equal | The properties `add`, `replace` and `delete` may touch are fixed by the substatement table in §7.20.3.2: - `config`, `default`, `mandatory`, `type`, `units` - `max-elements`, `min-elements` - `must` and `unique`, which may appear several times Anything outside that list, such as a list's `key`, its `when` condition or the node's name, cannot be deviated by these statements. A property defined by an extension can be deviated only if the extension allows it (§7.19). ## Worked examples on ietf-interfaces RFC 8343 gives each interface a leaf `enabled` with `default "true"` and a leaf `description` of type `string`. Two honest deviations: ```yang deviation /if:interfaces/if:interface/if:enabled { deviate replace { default "false"; } } deviation /if:interfaces/if:interface/if:description { deviate replace { type string { length "0..64"; } } } ``` The first says new interfaces start administratively down on this device. It must be `replace`: a leaf's default appears at most once, the target already has one, and `add` would break the "MUST NOT exist" rule. The second narrows the description to 64 characters, the size RFC 2863 gives `ifAlias`, which RFC 8343 lets a server map `description` onto. RFC 7950's own examples cover the rest: 1. `deviate not-supported` on `/base:system/base:daytime`: the service is not offered. 2. `deviate add { default "admin"; }` on a leaf that had no default. 3. `deviate replace { max-elements 3; }` on a name-server list. 4. `deviate delete { must "daytime or time"; }`: the expression is repeated character for character. ## Getting delete and not-supported right - **delete is literal.** The keyword and the argument string must both match the target. A `must` with an equivalent but differently written expression is not a match, and the deviation is in error. - **not-supported removes the node from the server's schema.** Everything beneath it goes with it, data sent for it is outside the schema, and a default it carried no longer applies anywhere. - **delete versus not-supported.** Deleting `mandatory` or a `must` keeps the node and relaxes it; `not-supported` removes it. Choosing the weaker statement is what makes a deviation honest rather than sweeping. - **add on a repeatable property appends.** `must` and `unique` may appear several times, so `deviate add` with another `must` simply adds a constraint; the "MUST NOT already exist" rule bites only on single-valued properties such as `default` on a leaf, `type` or `units`. ## Rules that keep deviations sane - **The result must be valid.** After applying all deviations a server announces, in any order, the model MUST still be valid (§7.20.3). A deviation that, for example, leaves a mandatory leaf with a default has produced an invalid model. - **One deviation per target per module.** RFC 9907 §4.20 notes that evaluation order can change the result and says multiple deviation statements for the same target in the same module SHOULD NOT be used. RFC 7950's "in any order" rule is about validity; RFC 9907's warning is about the outcome, and the two together argue for a single, combined deviation. - **Platform limits belong here, not in the model.** RFC 9907 says `max-elements` in a published module states an architectural limit; a platform's hard resource limit is declared with `deviate add` or `replace` of `max-elements` in a deviation. - **Last resort.** RFC 7950 calls deviations strongly discouraged; a server that deviates is not fully compliant with the module.

Why can a YANG deviate add not give a new default to the ietf-interfaces leaf enabled?
Because `enabled` already has `default "true"`, and a leaf's default can appear only once. RFC 7950 §7.20.3.2 says that when `add` targets a single-valued property, that property MUST NOT already exist. The device must use `deviate replace { default "false"; }`, which in turn requires the property to exist, as it does here.
Why does RFC 9907 discourage two separate YANG deviation statements for the same target node in one module?
RFC 9907 §4.20 notes that the order in which deviations are evaluated can affect the result, so two deviations of the same node invite an outcome that depends on the reader's processing order. RFC 7950 requires only that the end model be valid in any order; combining the changes into one deviation removes the ambiguity entirely.

saying these in an interview costs you the question

deviate add can overwrite a default the target leaf already has
deviate delete removes a must as long as the logic is equivalent
deviate replace can introduce a property the node never had
A deviation can rename a node or change a list's key
deviate not-supported hides the node but keeps its default value active

What do YANG's four deviate arguments, not-supported, add, replace and delete, each change, and which precondition does each carry?

§ answer

basics

solid answer

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The deviation statement in one paragraph

The four arguments

Worked examples on ietf-interfaces

Getting delete and not-supported right

Rules that keep deviations sane

▾common follow-ups2 questions

▾red flags5 flags

The deviation statement in one paragraph

The four arguments

Worked examples on ietf-interfaces

Getting delete and not-supported right

Rules that keep deviations sane

answer

go deeper