skip to content

In YANG, what does config false mean on an interface's counters, and why can a NETCONF client not write them?

level: middleimportance: must knowfreq 22%

answer

  1. set versus observed
  2. which datastores hold the node
  3. inherited from the parent
  4. nothing writable below state
  5. one datastore holds both

basics

~20 s

In YANG, config false marks state data: values the device reports, such as counters and oper-status. State nodes belong to no configuration datastore, so a NETCONF edit has nothing to write them into; clients read them instead.

solid answer

~40 s

The `config` statement splits a schema into configuration, which an operator sets and which lives in `<running>` and the other configuration datastores, and state, which the device observes — `in-octets`, `oper-status`. A node without its own `config` inherits its parent's, a top-level node defaults to `true`, and below a `config false` node nothing may be `config true`. State is in no configuration datastore, so NETCONF's `<get-config>` never returns it and `<edit-config>` has no place to put it; `<get>` returns both. Under NMDA (RFC 8342), the read-only `<operational>` datastore holds config true and config false nodes together, which is why RFC 8343 folded the old `/interfaces-state` tree into `/interfaces`. Rules follow from the split: key leafs share their list's `config` value, a state list need not have a key, and `ordered-by` is ignored on state.

code

yang · 16 lines
yang
list interface {
  key "name";
  config true;
  leaf name { type string; }
  leaf speed {
    type enumeration {
      enum 10m;
      enum 100m;
      enum auto;
    }
  }
  leaf observed-speed {
    type uint32;
    config false;
  }
}

go deeper

for a junior

Recall that config true is what an operator sets and config false is what the device reports, and that config is inherited from the parent node.

for a middle

Explain the inheritance rules, why state is not in any configuration datastore, and what <get-config>, <get> and NMDA's <operational> each return.

for a senior

Show how the split shapes models in practice: state reported inside the configured entry, the deprecated /interfaces-state tree, and why counter resets are operations rather than writes.

for a principal

Weigh migrating clients from split config and state trees to NMDA: one model is simpler, but older clients may still need the deprecated tree served alongside.

## Two kinds of data on one device A network device holds two different kinds of data. **Configuration** is what an operator sets to move the device from its initial state to the one wanted: an interface's description, whether it is enabled, its MTU. **State** (also called non-configuration or operational data) is what the device observes and reports: whether the link is up, how many octets have arrived, when the counters were last reset. NETCONF (RFC 6241 §1.4) explains why the two must be kept apart: configuration comparisons would drown in changing statistics, incoming edits could try to write read-only values, and restoring an archived configuration would have to strip values nobody can set. YANG (RFC 7950) marks the split with one statement on the schema node: `config true` for configuration, `config false` for state. ## How a node's config value is decided RFC 7950 §7.21.1 fixes the rules: 1. A node with its own `config` statement uses it. 2. A node without one **inherits** its parent schema node's value; under a case, the value comes from the case's parent choice. 3. A top-level node with no `config` statement defaults to **true**. 4. Once a node is `config false`, **no node beneath it may be `config true`**. So a `statistics` container marked `config false` makes every counter in it state data without repeating the statement. The reverse nesting is allowed: RFC 7950's own example (§4.2.3) places a configured `speed` leaf and a `config false` `observed-speed` leaf side by side in a configuration `interface` list. The list entry and its key give the state its context; that is why state values appear under the same `interface` entry that configures the port. ## Where each kind lives NMDA, the Network Management Datastore Architecture (RFC 8342), names the datastores: | datastore | holds | writable by a client | |---|---|---| | `<running>`, `<candidate>`, `<startup>` | config true nodes | yes, through configuration operations | | `<intended>` | config true nodes, after the device's own processing | no | | `<operational>` | config true **and** config false nodes | no, read-only | A config false node is **not part of any configuration datastore** (RFC 7950 §7.21.1). That is the whole reason a client cannot write `in-octets`: `<edit-config>` targets a configuration datastore, and that datastore's schema has no such node to set. `<get-config>` returns configuration only; NETCONF's `<get>` returns `<running>` together with state. RFC 8526 adds NMDA-aware NETCONF operations. `<get-data>` reads from a named datastore, including `<operational>`, and its `config-filter` parameter selects only config true nodes when set to `true`, only config false nodes when set to `false`, and everything when left out. The `config` property of a schema node is therefore something a client can filter on directly, not just a modelling annotation. ## Why two interface trees became one Before NMDA, state lived in no datastore of its own. Because `<get>` merged `<running>` with state, a model could not show state whose lifetime differed from configuration — an interface physically present but not configured, or configured but missing — unless state lived in a **separate branch**. The original interfaces model therefore had `/interfaces` for configuration and `/interfaces-state` for state, and every interface was modelled twice. RFC 8342 added `<operational>`, which holds config true nodes as well as config false ones, so the value actually in use and the observed state can be read in one tree. RFC 8343, which obsoletes RFC 7223, **deprecated** `/interfaces-state` and moved all config false nodes under `/interfaces`; servers that serve non-NMDA clients MAY still implement the deprecated tree. ## Rules that follow from config false - **Key leafs** must carry the same `config` value as their list, so a configuration list cannot be keyed by a counter. - A **state list** MAY omit its key; a configuration list MUST have one. - **ordered-by** is ignored on state lists, because nobody edits their order. - A **state leaf-list** may repeat values in YANG 1.1; a configuration leaf-list may not. - In an RFC 8340 **tree diagram**, `rw` marks configuration and `ro` marks state, so the split is visible at a glance. ## The practical consequence When a client wants a counter to read zero, it cannot write zero into it. If a device offers a counter reset at all, that is an operation some model defines (an RPC or an action), not a write to the counter, and the counter itself stays read-only state. RFC 8343's interfaces model instead reports a state leaf, `discontinuity-time`, beside the counters, so a collector computing deltas can tell a counter discontinuity from traffic.

  • Why did RFC 8343 deprecate the separate /interfaces-state tree?
    Without an operational datastore, state had to sit in its own config false branch so a model could show interfaces whose state outlives or precedes their configuration. NMDA's `<operational>` (RFC 8342) holds config true and config false nodes together, so RFC 8343 moved all state under `/interfaces` and kept `/interfaces-state` only as a deprecated tree for clients that do not implement NMDA.
  • Can a config false node sit inside a config true list, and can the reverse happen?
    Yes to the first: RFC 7950 puts a config false `observed-speed` leaf beside a configured `speed` leaf inside a configuration `interface` list, so the state is reported in the entry it describes. The reverse is illegal: under a config false node nothing may be config true, and a list's key leafs must share the list's own config value.

A thermostat has a dial and a thermometer. You can turn the dial (configuration), but you cannot write the room temperature (state); you read it, and the dial's setting only influences it.

saying these in an interview costs you the question

  • config false means the node is optional or not configured yet.
  • A child of a config false container can be marked config true to make it writable.
  • <get-config> returns the counters along with the configuration.
  • Every YANG list needs a key, state lists included.
  • Under NMDA, <operational> holds only the config false nodes.