How does a YANG data model differ from an SMIv2 MIB module, and why does the difference matter for automating device configuration?
answer
- trees versus imaginary tables
- config true, config false
- constraints the server enforces
- RowStatus versus list entries
- translation works in one direction
basics
~20 sSMIv2 describes scalar objects arranged into conceptual tables, with writability as an access level. YANG describes nested configuration trees, marks configuration apart from state, and states constraints and references that the server must enforce before a change is accepted.
solid answer
~40 sAn SMIv2 MIB module (RFC 2578) defines scalar objects named by object identifiers; RFC 2578 calls tables an imaginary structure imposed on them, indexed by `INDEX`, with rows created through a `RowStatus` column. Writability is a `MAX-ACCESS` value, and RFC 3535 found that for many features configuration and operational state are not told apart. YANG (RFC 7950, YANG 1.1) models a hierarchy of containers and lists, marks state with `config false`, and expresses rules formally: `must` and `when` expressions, `leafref` references, ranges and patterns, `mandatory` and `unique`. The server must enforce these when a datastore is validated, so a candidate that breaks a rule fails `<validate>` or `<commit>` and never reaches running. RFC 7950 notes that MIB modules translate into YANG for read-only access, and that the reverse is not a goal.
code
yang · 15 lineslist tunnel {
key "name";
leaf name { type string; }
leaf source-interface {
type leafref {
path "/if:interfaces/if:interface/if:name";
}
mandatory true;
}
leaf mtu { type uint16 { range "1280..9000"; } }
leaf oper-status {
config false;
type enumeration { enum up; enum down; }
}
}go deeper
Recall that SNMP data is described in SMIv2 MIB modules and NETCONF data in YANG modules, and that YANG marks state with config false.
Explain scalars and conceptual tables with RowStatus versus YANG containers and keyed lists, and name the YANG constraints a server enforces: must, when, leafref, range.
Show why server-side validation changes how automation fails: a candidate that breaks a constraint is rejected at commit as a unit, instead of half-applied through a series of sets.
Weigh model strategy: reading legacy MIB data through translated read-only YANG versus waiting for native modules, and how deviations and augments affect portability across a mixed fleet.
## Two schema languages A **schema language** says what data a device exposes, its types and its rules. SNMP uses **SMIv2**, the Structure of Management Information version 2 (RFC 2578-2580, STD 58). NETCONF uses **YANG**: YANG 1.0 is RFC 6020 and YANG 1.1 is RFC 7950. Both are still used; they were built for different jobs. ## How SMIv2 shapes data - **Scalar objects with object identifiers.** Every value is an `OBJECT-TYPE` with a `SYNTAX` (such as `Counter64` or `Integer32`) and an OID. RFC 2578 says management operations "apply exclusively to scalar objects". - **Conceptual tables.** A table is an "imaginary, tabular structure": a `SEQUENCE OF` an entry type, whose rows are identified by the values of the `INDEX` objects encoded into each instance's OID. `AUGMENTS` lets another module add columns to an existing row. - **Access, not intent.** `MAX-ACCESS` says whether an object is `read-only`, `read-write`, `read-create`, `accessible-for-notify` or `not-accessible`. It says who may write, not whether a value was configured by an administrator or learned by the device; RFC 3535 found that distinction missing for many features. - **Row lifecycle through a status column.** New rows are usually created by setting a `RowStatus` column (RFC 2579) to `createAndGo` or `createAndWait`, a protocol dance every manager must perform correctly. - **Rules mostly in prose.** Dependencies between objects live in `DESCRIPTION` text. RFC 3535 describes MIB modules as "a list of ingredients without a recipe" and lists the lack of structured types among SMI's problems. ## How YANG shapes data - **Trees.** `container`, `list` (with a `key`), `leaf` and `leaf-list` nest to any depth, so a tunnel can hold its own list of peers. - **Configuration versus state.** A node tagged `config false` is state data; the rest is configuration. That is what lets `<get-config>` return configuration alone, and NMDA (RFC 8342) builds the `<intended>` and `<operational>` datastores on it. - **Machine-checkable rules.** `must` and `when` hold XPath expressions; `leafref` points at another node and, by default, requires the target to exist; types carry `range`, `length` and `pattern`; lists carry `unique`, `min-elements` and `max-elements`. - **Enforcement by the server.** RFC 7950 section 8 says all `must` constraints and referential integrity must hold in a valid data tree. For `running` the check runs at the end of `<edit-config>`; for `candidate` at `<validate>` or `<commit>`. - **Operations and events in the model.** `rpc`, `action` and `notification` statements define operations and event content alongside the data. - **Extension and honesty.** `augment` adds nodes to another module's tree; `deviation` lets a server declare where it departs from a module. ## Side by side | Question | SMIv2 MIB module | YANG module | |---|---|---| | Shape of data | scalars, conceptual tables | nested containers and lists | | Configuration vs state | `MAX-ACCESS` only | `config true` / `config false` | | Cross-object rules | prose in `DESCRIPTION` | `must`, `when`, `leafref`, `unique` | | Who checks the rules | each agent, as written | the server, at validation | | Creating an entry | `RowStatus` column | create the list entry by its key | | Events | `NOTIFICATION-TYPE` | `notification` statement | ## Common misreadings - **"YANG is SMIv2 in XML."** YANG is its own language with its own statements; XML, or JSON under RFC 7951, is only how the data it describes is encoded on the wire. - **"SMIv2 cannot be extended."** `AUGMENTS` adds columns to another module's row; YANG's `augment` is simply more general, reaching any point in a tree. - **"Writable means configured."** A `read-write` object may hold a value the device learned; only a model that separates configuration from state, as YANG's `config` statement does, answers that question. ## Why it matters for automation 1. A tool can generate a whole intended configuration from a YANG model and know the server will reject it as a unit if a reference dangles or a value is out of range. 2. Reading back configuration and state separately lets automation compare intent with reality. 3. RFC 7950 notes that SMIv2 modules can be translated automatically into YANG for **read-only** access (RFC 6643), so existing MIB data can be read through YANG-based tooling; it is not concerned with translating YANG back into SMIv2. SMIv2 remains a good fit for what it was built for: counters and status with stable OIDs that every poller understands.
- When does a NETCONF server check YANG must and leafref constraints?RFC 7950 section 8.3.3 ties it to the datastore. For `running` or `startup`, constraints are enforced at the end of the `<edit-config>` or `<copy-config>`. For `candidate`, enforcement waits until `<validate>` or `<commit>`, so a client can build an intermediate state that breaks a rule and fix it before committing.
- Can an SMIv2 module be extended without editing it?Yes, within limits. An `AUGMENTS` clause lets a new module add columns to an existing conceptual row, sharing its index. YANG's `augment` is more general: it can add containers, lists and leaves anywhere in another module's tree, optionally guarded by a `when` condition.
saying these in an interview costs you the question
- YANG is just SMIv2 rewritten in XML.
- SMIv2 has no way to extend another module's table.
- YANG must statements are comments; servers do not enforce them.
- A read-write MIB object tells you the value was configured, not learned.
- Any MIB module converts automatically into a writable YANG model.