skip to content

In a YANG model, what does typing a VLAN ID leaf as uint16 with range "1..4094" buy you over a plain string?

level: juniorimportance: should knowfreq 18%

answer

  1. validation before the wire
  2. a value space, not free text
  3. the server's parse-time error
  4. one rule for every client

basics

~10 s

The type fixes the leaf's value space, so any client holding the module can reject 0, 4095 or "ten" before sending, and the server must refuse them too; a plain string accepts all three.

solid answer

~50 s

A YANG `type` is a contract on the value space. `uint16` already limits the leaf to whole numbers from 0 to 65535, and `range "1..4094"` narrows it to the usable VLAN IDs. Because the module is published, a client, a controller or a review pipeline can validate a payload against it **before** anything reaches the device, and the server enforces the same rule: RFC 7950 §8.3.1 says a NETCONF server MUST answer a value that breaks the type, including its `range`, `length` or `pattern`, with an `invalid-value` error. The type also fixes how the value is read and written (decimal text in XML, a number in the RFC 7951 JSON encoding) and lets tools generate typed code. With `type string`, the device is the first place a typo can be caught, and nothing defines whether "010" and "10" are the same VLAN.

go deeper

for a junior

Recall that every YANG leaf has a type, that uint16 means 0 to 65535, and that range narrows it. Say plainly that a bad value is rejected, not stored.

for a middle

Explain value space versus lexical form, name the invalid-value error a NETCONF server must return, and show why string loses both validation and a defined encoding.

for a senior

Show how typed models move failure left: pipelines validate changes against the module before any device sees them, and typedefs keep one definition of a VLAN ID across many modules.

for a principal

Weigh strict types against model churn: a tight range is cheap to relax in a new revision but costly to tighten later, so decide which constraints belong in the type.

## What a YANG type is In YANG (RFC 7950, version 1.1), every `leaf` and `leaf-list` carries a `type` statement. The type defines the **value space**: the complete set of values the node may hold. It also defines the **lexical representation** (how a value is written in XML or in a module's `default`) and, for most types, a **canonical form** that a server uses when it sends data back. A value outside the value space is not a slightly wrong configuration; it is not valid data at all, and anyone who holds the module can say so without asking the device. That is the point behind the usual one-line summary: strong typing is why YANG-driven configuration can be validated before it is sent. ## The built-in types RFC 7950 §9 defines a small set of **built-in types**. Every other type is a **derived type** made with `typedef`, and every derived type traces back to a built-in one. | Built-in type | Value space | Restriction it accepts | |---|---|---| | `int8` to `int64`, `uint8` to `uint64` | signed and unsigned integers, 8 to 64 bits | `range` | | `decimal64` | `i x 10^-n`, where `fraction-digits` n is 1 to 18 | `range` | | `string` | Unicode text | `length`, `pattern` | | `binary` | octets, written as base64 | `length` | | `boolean` | `true` or `false` | none | | `enumeration` | a set of assigned names | `enum` (a subset) | | `bits` | a set of named flags | `bit` (a subset) | | `empty` | presence only, no value | none | | `union` | a value of one of its member types | none on the union itself | | `leafref`, `instance-identifier` | a reference to a leaf value or to a data node | `require-instance` | | `identityref` | a reference to an identity | none (its `base` is mandatory) | ## Narrowing uint16 to a VLAN ID The VLAN ID is the 12-bit field of the VLAN tag, and the RFC 4363 Bridge MIB extensions define a `VlanId` with the range 1 to 4094, keeping 0 ("no VLAN") and 4095 ("any VLAN") for separate conventions. The example VLAN module in RFC 8343's appendix types its `vlan-id` leaf exactly as the question does: - `uint16` alone admits 0 to 65535, which already rules out negatives, fractions and text. - `range "1..4094"` (RFC 7950 §9.2.4) cuts that down to the usable IDs; 0, 4095 and 5000 fall outside it. - Wrapping the restricted type in a `typedef` named, say, `vlan-id` lets every module reuse one definition instead of restating the range, and occasionally restating it wrongly. - RFC 9907, the authoring guidelines, adds that signed types such as `int16` SHOULD NOT be used unless negative values make sense, so `uint16` is the right base. With `type string`, "10", "010", "ten", "4095" and the empty string are all valid data. ## Where the check happens 1. **In the client or controller.** Anyone holding the module can validate a payload before sending it, so a provisioning pipeline can fail a change at review time instead of on the device. 2. **When the payload reaches the server.** RFC 7950 §8.3.1 says a NETCONF server MUST reply with an `invalid-value` error-tag when a leaf value does not match its type, including `range`, `length` and `pattern`, and attach the restriction's `error-app-tag` and `error-message` if the module defines them. 3. **In every data tree.** RFC 7950 §8.1 requires all leaf values to match their type constraints in any data tree: configuration, state, notification content and operation input and output. The type also fixes how text is read. Inside a module, a `default` for an integer may be written in hexadecimal (`0x0a`) or octal (a leading `0`), but in XML data an integer is always decimal. In the JSON encoding of RFC 7951 a `uint16` is a JSON number, so a quoted "10" is a different thing from 10. ## What typing does not do - **It does not relate leaves to each other.** "If a VLAN ID is set, a base interface must be set too" is a `must` expression, the job of YANG's constraint statements. - **It does not know the network.** VLAN 999 is a valid value whether or not anything on the device uses it; only a reference type such as `leafref` can insist that a target exists. - **It does not replace authorisation.** The server still decides whether this client may make this edit. ## Why interviewers ask it The question separates people who have read YANG as documentation from people who have used it as a contract. A good answer names the value space, shows the narrowing (`uint16`, then `range`), and says where a bad value is stopped: before sending, and at the server with a defined error.

  • Why does "052" mean different numbers in a YANG module's integer default and in XML data?
    RFC 7950 §9.2.1 lets a `default` inside a module use hexadecimal (`0x`) or octal notation, and a leading zero there means octal, so `052` is 42. In the XML encoding an integer is always decimal and leading zeros are allowed, so `052` is 52. The canonical form a server sends back has no leading zeros, so it would answer `52`.
  • Since 4094 fits in int16, why should a YANG VLAN ID be uint16 rather than int16?
    Both hold 4094, but RFC 9907 §4.11 says the signed types SHOULD NOT be used unless negative values are allowed by the semantics. A VLAN ID is never negative, so `uint16` states the intent, and the `range` then trims it to 1..4094.

saying these in an interview costs you the question

  • A YANG type is only documentation; the device decides what is valid.
  • A string leaf is more flexible, so it is the safer choice for IDs.
  • range "1..4094" also proves the VLAN is configured on the switch.
  • The server clamps an out-of-range value to the nearest bound.
  • Type checking needs a round trip to the device.