In an RFC 8340 YANG tree diagram, what do the markers rw, ro, *, ?, ! and [name] tell you about a node?

## What a tree diagram is for A YANG module is long, and its shape is hard to see in the statements. **RFC 8340** (BCP 215) defines **YANG tree diagrams**: a compact, indented outline of a module's schema, one line per node. Standards documents include them so a reader can see the structure before the definitions, and engineers use them to answer quick questions — is this writable, is it a list, what is its key — without reading every statement. ## Anatomy of one line RFC 8340 §2.6 prints each node as: `<status>--<flags> <name><opts> <type> <if-features>` | field | values | meaning | |---|---|---| | status | `+`, `x`, `o` | current, deprecated, obsolete | | flags | `rw`, `ro`, `-w`, `-u`, `-x`, `-n`, `mp` | what the node is for | | name | `name`, `(name)`, `:(name)` | data node, choice node, case node | | opts | `?`, `!`, `*`, `[keys]` | how the node occurs | | type | a type name, or `-> path` for a leafref | leafs and leaf-lists only | | if-features | `{feature}?` | features the node depends on | ## The flags: what a node is for - **`rw`** — a configuration data node (or a choice inside configuration). A client can write it. - **`ro`** — a non-configuration (state) node, and also RPC or action output and notification parameters. A client can only read it. - **`-w`** — an input parameter of an RPC or action. - **`-x`** — an RPC or action; **`-n`** — a notification. - **`-u`** — a `uses` of a grouping printed without expanding it, as in `+---u tls-transport`. - **Case nodes carry no flags** at all. ## The options: how a node occurs - **`*`** — a list or leaf-list: many instances. - **`[name]`** — the list's key leafs, in key order, right after the `*`. - **`?`** — an optional leaf, choice, anydata or anyxml. A leaf printed **without** `?` is therefore a list key or a mandatory leaf. - **`!`** — a presence container, one whose existence carries meaning. A plain container prints with no option at all. ## A worked reading An illustrative interface module, drawn by the rules above: ``` module: example-router-if +--rw interfaces +--rw interface* [name] +--rw name string +--rw mtu? uint16 +--rw (encapsulation)? | +--:(dot1q) | | +--rw vlan-id? uint16 | +--:(untagged) | +--rw untagged? empty +--rw loopback! | +--rw mode? enumeration +--ro oper-status enumeration +--ro statistics +--ro in-octets? uint64 ``` Read it top down: 1. `interfaces` is a configuration container with no option, so a plain organising container. 2. `interface* [name]` is a configuration **list** keyed by `name`; `name` has no `?` because it is the key. 3. `mtu?` is an optional configuration leaf of type `uint16`. 4. `(encapsulation)?` is an optional **choice** with two **cases**, `:(dot1q)` and `:(untagged)`; only one case's nodes can exist at a time, and neither name appears in the data. 5. `loopback!` is a **presence container**: creating it means something, and `mode` configures it further. 6. `oper-status` and `statistics` are `ro`, so state the device reports; `oper-status` has no `?`, so the model declares it mandatory. RFC 8343's standard interfaces tree reads the same way: `+--rw interface* [name]`, `+--rw type identityref` without `?` because `type` is mandatory, and an `ro` `statistics` container of counters. ## Other notation worth knowing - A node added to the tree by another module is printed as `<prefix>:<name>`, with the prefix of the module that defines it, so you can see at a glance which nodes are not native to the module. - A leafref leaf prints its type as `-> TARGET`, the path it points at, or simply as `leafref`. - `{feature}?` after a node lists the features it depends on; a server that does not support them does not have the node. - `...` stands for nodes collapsed out of the picture, and `//` starts a comment. ## What the diagram does not show The line format has no field for many things a client still needs, so the module text stays the contract: - type restrictions such as ranges, lengths and patterns — only the type's name is printed; - `must` and `when` expressions, defaults and element-count limits; - whether a list is `ordered-by user`; - descriptions, which often carry the real semantics. A diagram is for orientation and review. Before writing a client against a model, read the statements behind the lines that matter.