In YANG, which node does a when on an augment evaluate against, and what happens to augmented configuration once it turns false?
answer
- per entry, not per module
- the augment's target instance
- its own nodes hidden while evaluating
- deleted, not rejected
basics
~20 sA when on an augment is evaluated with the augment's target instance as context node, such as each interface entry. If an edit makes it false, the server silently deletes the augmented nodes; later writes to them get unknown-element.
solid answer
~40 sRFC 7950 §7.21.5 says the context node of a `when` under `augment` is the augment's **target node in the data tree**, so for `augment "/if:interfaces/if:interface"` the condition is evaluated per interface entry, and `if:type` means that entry's type. The nodes the augment adds are hidden from the expression while it runs, so it cannot depend on itself. While the condition is false the augmented nodes must not exist and their mandatory constraints are not enforced. If an edit, such as changing the interface type, makes it false, the server **deletes** the augmented configuration without an error (§8.2), and an `<edit-config>` touching those nodes gets `unknown-element`. That silent loss is the operational trap: unlike a `must`, nothing fails.
go deeper
Recall that a when on an augment means the added nodes only exist on some entries, for example only on one interface type.
Explain the context node rule for augment, why the augment's own nodes are hidden from the expression, and the difference between a false when and a false must.
Show the operational consequence: a type change silently deletes augmented configuration, so change review and automation must treat it as destructive and conditions must use static properties of the entry.
Weigh conditional composition, which keeps one shared tree tidy, against the audit cost of configuration that can vanish without an error, and set review rules for model changes accordingly.
## Why a when sits on an augment Most augments of the interface list are not meant for every interface. An Ethernet module's duplex settings mean nothing on a loopback, and a vendor's shaping knobs may apply only to the vendor's own interface type. So the augment carries a **`when`** statement, an XPath expression that decides, entry by entry, whether the augmented nodes may exist. RFC 8343 itself shows the pattern with `when "if:type = 'ianaift:ethernetCsmacd'"`, and RFC 9907 §4.18.2 says `when` SHOULD be used with `augment` or `uses` to achieve conditional model composition. ## What the XPath is evaluated against RFC 7950 §7.21.5 fixes the context for a `when` that is a child of `augment`: 1. The **context node is the augment's target node in the data tree**, if the target is a data node. For `augment "/if:interfaces/if:interface"` that is each `interface` entry in turn, so `if:type` means *this entry's* type. 2. If the target is not a data node (an `input`, `output` or `notification`, say), the context node is the closest ancestor that is a data node, and the root if there is none. 3. While the expression is evaluated, the accessible tree is **tentatively stripped of the nodes this augment adds**, so the condition cannot depend on its own additions. This differs from a `when` on an ordinary leaf, where the context node is a dummy stand-in for that leaf itself. The XPath syntax is a separate subject; the point here is *which node* `if:type` is read from. | `when` placed on | Context node | |---|---| | an `augment` of a data node | the target node instance (each augmented entry) | | a `uses`, `choice` or `case` | the closest data-node ancestor | | any other data definition | a dummy node standing in for the node itself | ## What happens when the condition is or becomes false - **Absent while false.** RFC 7950 §8.1: there MUST be no nodes tagged with `when` present if the condition evaluates to false. The augment's `when` governs every node the augment adds. - **Mandatory nodes are dormant.** The mandatory, `min-elements` and `max-elements` constraints are not enforced for a node whose `when` (or an ancestor's) is false. This is what makes a conditionally mandatory augment possible. - **Silent deletion on change.** §8.2: if a request modifies configuration so that a node's `when` becomes false, the server **deletes** that node. RFC 9907 is blunt: data is "silently deleted as soon as the condition becomes false", and a false `when` is not an error. - **Writes are refused.** §8.3.2: a NETCONF `<edit-config>` that modifies a node tagged with `when` whose condition is false MUST get an `unknown-element` error-tag. ## A worked case The vendor module augments each interface with `qos-profile`, conditioned on the interface's type being the vendor's `shaped-ethernet` identity. 1. `eth0` has type `shaped-ethernet` and `qos-profile` is `gold`. 2. An operator changes `eth0`'s type to `ethernetCsmacd`, and the server accepts the change. 3. The condition on `eth0` is now false, so the server deletes `qos-profile` from `eth0`. No error is returned, because none is due. 4. A later attempt to set `qos-profile` on `eth0` is rejected with `unknown-element`. The operator sees no failure, only a configuration that has quietly lost a setting. Changing the type back does not restore it either: the deleted value is gone and has to be set again. That is the difference from a `must`, which would have rejected the type change with a validation error and left the setting in place. ## Writing the condition well - Base it on **static properties of the augmented entry**, as RFC 9907 recommends: its key leafs, or a type chosen when the entry was created. A condition on volatile values makes nodes appear and vanish with them. - Keep it **inside the target entry**. For a conditionally mandatory augment RFC 9907 makes this a MUST, since the client cannot control data elsewhere. - Remember that **list keys** cannot carry a `when` at all (§7.21.5), so the condition belongs on the augment, not on the key. - Treat a type change as a **destructive edit** in review and in change tooling, because it can delete configuration that no error message will mention.
- How does this differ from putting a must on the augmented leaf?A `must` is a validity constraint: if it is false the edit fails with an error and the data stays as it was. A `when` decides whether the nodes may exist at all, so a false `when` is not an error; the server removes the nodes. Choose `when` for 'this applies only to these entries' and `must` for 'this value is only valid if'.
- What is the context node if the augment targets an rpc's input?An `input` node is not a data node, so the context node is the closest ancestor that is a data node; for a top-level rpc there is none, so it is the root node. The condition then has to be written from there rather than from an entry.
saying these in an interview costs you the question
- A false when on an augment makes the edit fail with a validation error.
- The when on an augment is evaluated once for the whole module, not per entry.
- A mandatory leaf inside the augment is still enforced while the when is false.
- A conditionally mandatory augment's when may safely test data outside the augmented entry.
- A when can be placed on a list key to control which entries get augmented.