skip to content

How does a NETCONF client learn which YANG modules, revisions, features and deviations a device implements, and what changed with YANG 1.1?

level: middleimportance: must knowfreq 18%

answer

  1. two places a server announces modules
  2. namespace URI plus query parameters
  3. module, revision, features, deviations
  4. a library read with an ordinary get
  5. an identifier that changes with the list

basics

~20 s

YANG 1.0 modules appear in the NETCONF hello as capability URIs carrying module, revision, features and deviations parameters. YANG 1.1 moved the list into the ietf-yang-library data, read with <get>; the hello carries only an identifier that changes when that list does.

solid answer

~40 s

Two mechanisms coexist. Under RFC 6020 a server advertises each YANG 1.0 module as a capability in its `<hello>`: the module's namespace URI followed by `?module=`, `revision=`, `features=` (the optional features it supports) and `deviations=` (the names of modules that deviate from it). RFC 7950 changed that for YANG 1.1: the server MUST implement `ietf-yang-library` and list every module it implements there, and YANG 1.1 modules are no longer listed as hello capabilities. The hello instead carries `urn:ietf:params:netconf:capability:yang-library:1.0` with a `module-set-id`, or, on a server with the RFC 8526 NMDA extensions, `yang-library:1.1` with a `content-id`. The client reads the library once with `<get>`, caches it, and rereads it only when that identifier changes.

go deeper

for a junior

Recall that a NETCONF device announces its YANG modules, and that older modules appear in the hello while newer ones live in a YANG library you read with an ordinary get.

for a middle

Explain the four hello URI parameters, why YANG 1.1 modules are found only in ietf-yang-library, and how module-set-id or content-id lets a client cache the list.

for a senior

Show you treat features and deviations as part of the schema, read the library from the right tree on old and NMDA servers, and refresh caches only when the identifier changes.

for a principal

Discuss how hello-based and library-based discovery coexist on a mixed fleet, and what a platform loses if it trusts module names and revisions while ignoring features and deviations.

## Why a client has to ask A NETCONF client cannot build a correct `<edit-config>` or parse a `<get>` reply until it knows the **data model** the device runs: which YANG **modules** are implemented, at which **revision**, with which optional **features** switched on, and which **deviations** (declared departures from the standard module) apply. Two devices that both "support the interfaces module" can disagree on every one of those four points. NETCONF has two standard places where a server states them, and which one a client reads depends on the YANG language version of the modules involved. ## The YANG 1.0 way: capability URIs in the hello When a session opens, each side sends a `<hello>` listing its **capabilities** as URIs (the exchange itself belongs to the transport discussion; what matters here is what the module entries say). RFC 6020 section 5.6.4 makes the server advertise every YANG 1.0 module it implements as one capability string: the module's **namespace URI** with a query-style parameter list. | Parameter | Carries | Example value | |---|---|---| | `module` | the name in the `module` statement | `example-syslog` | | `revision` | the revision date implemented | `2008-04-01` | | `features` | comma-separated features the device supports | `local-storage` | | `deviations` | comma-separated names of modules holding deviations | `example-syslog-devs` | Each parameter appears at most once. Note what `deviations` holds: **module names**, not the deviation statements. The client must also obtain that deviation module (it is advertised in the same hello) to learn what actually differs. ```xml <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <capabilities> <capability>urn:ietf:params:netconf:base:1.1</capability> <capability>urn:example:syslog?module=example-syslog&amp;revision=2008-04-01&amp;features=local-storage&amp;deviations=example-syslog-devs</capability> <capability>urn:example:syslog-devs?module=example-syslog-devs</capability> </capabilities> </hello> ``` ## The YANG 1.1 way: the YANG library RFC 7950 (YANG 1.1) changed the NETCONF mapping. A server **MUST** implement the `ietf-yang-library` module and list every implemented module in it, and YANG 1.1 modules are **not** listed as hello capabilities any more. RFC 7950 does not obsolete RFC 6020, and its coexistence section still has a server advertise YANG version 1 modules under RFC 6020's rules where a version 1 module imports one that moved to 1.1. On a mixed device the hello may therefore list some modules, while the library lists all of them. The library itself has two generations: - **RFC 7895** defined the `/modules-state` tree, with one `module-set-id` for the whole set and a `conformance-type` of `implement` or `import` per module. RFC 8525 obsoletes RFC 7895 and keeps that tree only as **deprecated**. - **RFC 8525** defines `/yang-library`, built for the Network Management Datastore Architecture (NMDA, RFC 8342): **module sets** (each module with its features, deviation modules, submodules and optional `location` URLs, plus an `import-only-module` list), **schemas** made of module sets, a **datastore** list mapping each datastore to a schema, and a single **`content-id`**. - The per-datastore schema matters because the operational state datastore may implement modules the configuration datastores do not. The hello still says something: the server advertises the **library capability** with a change identifier. 1. `urn:ietf:params:netconf:capability:yang-library:1.0?revision=<date>&module-set-id=<id>` (RFC 7950, pointing at `/modules-state`). 2. `urn:ietf:params:netconf:capability:yang-library:1.1?revision=<date>&content-id=<id>` (RFC 8526, which updates RFC 7950 to allow this instead, pointing at `/yang-library`). The `:1.0` and `:1.1` here version the **capability**, not the YANG language. ## Caching and change detection The identifier exists so a client does not reread the library on every connection: 1. On first contact, read the library with a `<get>` filtered to `/yang-library` (or `/modules-state` on an older server) and cache the result against that server. 2. On every later session, compare the `content-id` or `module-set-id` in the hello with the cached one. 3. If it is unchanged, reuse the cache; if it changed, reread the library and fetch any module source you lack. RFC 8525 requires `content-id` to change whenever the library content changes, and adds a `yang-library-update` notification carrying the new value for clients that hold a long-lived notification subscription. ## Where answers go wrong - Expecting to find a YANG 1.1 module as a hello capability, and concluding the device lacks it. - Reading `yang-library:1.1` as "the device speaks YANG 1.1". - Treating `features=` as the list of features the module defines; it lists the ones this device supports. - Ignoring `deviations=`: the advertised revision is then a promise the device does not keep. - Reading only the deprecated `/modules-state` tree on an NMDA server, and so missing modules that exist only in the operational state datastore's schema. - Rereading the library on every connection: harmless on one device, a measurable load across a large estate, and exactly what the identifier makes unnecessary. ## Reading the library itself The library is ordinary `config false` data, so the client fetches it with `<get>` and a subtree filter naming `<yang-library/>` in the `urn:ietf:params:xml:ns:yang:ietf-yang-library` namespace (or `<modules-state/>` on a server that only implements RFC 7895). The reply gives, per module, its name, revision, namespace, features and deviation modules, which is the same information the RFC 6020 URI carried, in a structured and filterable form.

  • What does the YANG library tell a client that hello capability URIs cannot?
    RFC 8525's library is structured data rather than one string per module: it lists submodules, modules used only for imports, optional `location` URLs to fetch each source, and a separate schema per datastore, so the operational state datastore can show modules the configuration datastores lack. It can be filtered and read like any other data, and it signals changes through `content-id` and the `yang-library-update` notification.
  • Does the `yang-library:1.1` capability mean the device supports YANG language version 1.1?
    No. The suffix versions the capability: `yang-library:1.0` is RFC 7950's, pointing at the `/modules-state` tree with a `module-set-id`; `yang-library:1.1` is RFC 8526's, pointing at RFC 8525's `/yang-library` tree with a `content-id`. Either can describe modules written in either YANG version; each module's own `yang-version` statement says which language it uses.

saying these in an interview costs you the question

  • Every YANG module, YANG 1.1 ones included, appears as a capability URI in the hello.
  • The yang-library:1.1 capability means the device speaks YANG language version 1.1.
  • The features parameter lists every feature the module defines.
  • The deviations parameter carries the deviation statements themselves.
  • A client must reread the whole YANG library at the start of every session.