Why does YANG require a key on a configuration list, and what changes when a state list has none?
answer
- identity of an entry
- edits name entries, not positions
- every key leaf supplied on create
- state lists may skip it
- no single entry to address
basics
~20 sA YANG configuration list needs a key because every edit must name the exact entry it touches, and the key leafs' combined values are that name. A state list may omit the key, but then no single entry can be addressed.
solid answer
~50 sConfiguration is edited entry by entry: NETCONF's `<edit-config>` and RESTCONF's resource paths both identify a list entry by the values of its key leafs, so RFC 7950 §7.8.2 says `key` MUST be present on a list that represents configuration. All key leafs must be given values when an entry is created — a default or `mandatory` on a key leaf is ignored — and a NETCONF request that leaves a key out gets a `missing-element` error. Key leafs carry the same `config` value as their list, and the key is the entry's identity, so changing a key value means a different entry. A state (`config false`) list MAY omit the key, which suits records with no natural identity, but then no single entry can be addressed: a client reads the whole list and picks entries out by their content.
go deeper
Recall that a list holds many entries and its key leafs say which entry is which; a configuration list must declare one.
Explain how edits name entries by key values, why defaults and mandatory are ignored on key leafs, and what missing-element means.
Show the design judgement: keys must be stable because renaming means delete and create, and keyless state lists cost clients the ability to fetch one entry.
Weigh key choice across a model family: natural keys read well but may change, while synthetic ones stay stable but push meaning into other leafs.
## What a list key is A YANG **list** is a node that occurs many times; each occurrence is a **list entry**. The `key` statement names one or more of the list's child leafs, separated by spaces, and **the combined values of those leafs identify an entry** (RFC 7950 §7.8.2). An `interface` list keyed by `name` has one entry per interface name; a list keyed by `"ip port"` has one entry per address-and-port pair, as in RFC 7950's own server example. ``` list interface { key "name"; leaf name { type string; } leaf mtu { type uint16; } } ``` ## Why configuration needs one Configuration is changed one entry at a time, and every protocol that changes it must say **which** entry: - In a NETCONF `<edit-config>`, "the values of all keys are used to uniquely identify a list entry" (§7.8.6). A request that does not give all of them is rejected with a `missing-element` error. - A RESTCONF resource path encodes the key values in the path segment for the list, so a URL can name one interface; how that encoding works belongs to RESTCONF's own rules. - A position ("the third interface") would be fragile: entries are added and removed, and a server may reorder a system-ordered list as it likes. Hence the rule: `key` **MUST** be present if the list represents configuration, and MAY be present otherwise. The key also shapes the encoding. In XML each list entry is one element, and its key leafs are encoded **first**, as subelements in the order the `key` statement lists them, before any other child (RFC 7950 §7.8.5). A reader can identify an entry from its first children without parsing the rest. With a composite key such as `"ip port"`, every component is part of the identity: two entries with the same address and different ports are two different entries. ## Rules on key leafs RFC 7950 constrains the leafs a key names: 1. Each must be a **child leaf** of the list, defined directly or brought in from a grouping; none may appear twice in the key. 2. **All key leafs must be given values when an entry is created.** A default on a key leaf, or on its type, is ignored, and so is a `mandatory` statement. 3. Key leafs carry the **same `config` value** as the list, so a configuration list cannot be keyed by a counter. 4. A key leaf may be of any built-in or derived type; YANG 1.1 explicitly added type `empty` to what a key may use. 5. YANG 1.1 made `when` and `if-feature` **illegal on key leafs** — a backward-incompatible change from YANG 1.0. A key that could cease to exist would leave entries with no identity. RFC 9907, the YANG authoring guidelines (obsoleting RFC 8407), adds that key leafs SHOULD be defined first, in order, as the list's first children, unless they come from a grouping. ## The key is the identity Because the key is what makes an entry that entry, there is no in-place rename. Changing an interface's `name` key addresses **a different entry**: the client deletes the old one and creates the new one, and whatever referred to the old name must follow. Choosing a key is therefore a design decision — pick a value that is stable for the life of the thing it names. ## Keyless state lists A list marked `config false` MAY omit its key. That fits state with no natural identity, such as a history of events in which no field is unique. The cost is addressability: | | configuration list | state list without a key | |---|---|---| | `key` statement | MUST be present | may be omitted | | one entry addressable by protocol | yes, by key values | no | | editable by a client | yes | no, state is read-only | | `ordered-by` | honoured | ignored | RESTCONF (RFC 8040) states it directly: a non-configuration list is not required to define keys, and in that case a single list instance cannot be accessed. A client reads the whole list and picks out the entries it wants by their content. When a state list does have a natural identity — a neighbour table keyed by address, for instance — giving it a key costs little and lets clients fetch one entry. ## Key versus other uniqueness A key is identity, not merely a uniqueness check. YANG has a separate statement for requiring that other leaf combinations be unique across entries, which belongs with the language's constraints; it does not make those leafs usable for addressing an entry.
- How do you rename a YANG list entry whose key is its name?You cannot rename it in place: the key values are the entry's identity, so a new name addresses a different entry. The client deletes the old entry and creates a new one with the same settings, and anything that referenced the old name must be updated with it. That is why a key should be a value that stays stable for the life of the thing.
- Why are when and if-feature illegal on key leafs in YANG 1.1?Every entry needs all of its key values, because together they identify it. A `when` condition or an `if-feature` could make a key leaf not exist, leaving entries with no identity. RFC 7950 made both illegal on list keys, a backward-incompatible change from YANG 1.0, so a 1.0 module that used them must drop them when it moves to 1.1.
saying these in an interview costs you the question
- Every YANG list must have a key, state lists included.
- A key leaf with a default can be left out when creating an entry.
- You change an entry's key by editing the key leaf like any other leaf.
- Key leafs of a configuration list can be config false counters.
- The key fixes the order in which a server must return entries.