skip to content

A NETCONF client meets a device module it has no copy of; how does it find and fetch that module's source from the device itself?

level: middleimportance: should knowfreq 9%

answer

  1. a monitoring module, not the base protocol
  2. a schemas list with three keys
  3. a special location value
  4. identifier mandatory, version and format optional

basics

~10 s

The client reads the schemas list of the ietf-netconf-monitoring module (RFC 6022) with <get>, then sends <get-schema> with the module's identifier, ideally its version, and format yang; the reply's <data> holds the module text.

solid answer

~40 s

RFC 6022's `ietf-netconf-monitoring` module exposes `/netconf-state/schemas`, a list keyed by `identifier`, `version` and `format`, with a `namespace` and one or more `location` values per entry. A location is either a URL for another protocol or the special value `NETCONF`, meaning the device serves it itself. The client sends `<get-schema>` (in the monitoring module's namespace) with the mandatory `identifier`, the `version` (for YANG, the newest revision date) and `format`, which defaults to `yang`. The module text comes back inside `<data>`. If nothing matches the server answers `invalid-value`; if several entries match, say two revisions and no version given, it answers `operation-failed` with `data-not-unique`. The server advertises the monitoring module in its hello when it implements it, so check before relying on it.

go deeper

for a junior

Remember that a NETCONF device can hand over its own YANG modules, and that the operation for it is get-schema from the monitoring module.

for a middle

Walk through listing the schemas, the three keys, what location NETCONF means, the format default and the two failure answers.

for a senior

Show you always pass a version, verify the fetched revision against what the device advertised, and fall back cleanly when a server lacks the monitoring module.

for a principal

Weigh fetching from every device against a shared, verified module store, and how deviations and features keep one revision from meaning one schema.

## The problem A device's hello or YANG library tells a client **which** modules it implements, by name and revision. That is not enough to talk to it: the client needs the module **source** to know the data nodes, types and constraints. A public repository may hold the standard modules, but a device's own models and its **deviation modules** are often published nowhere else. RFC 6022, the NETCONF monitoring module, gives the device a way to hand them over. ## Step 1: list what can be fetched The module `ietf-netconf-monitoring` (namespace `urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring`) holds a **schemas** list under `/netconf-state/schemas`. A server that implements it MUST advertise its capability URI in the hello, which is how a client knows the list and the operation exist. Each entry has: | Leaf | Meaning | |---|---| | `identifier` (key) | the schema's name, used by `<get-schema>` | | `version` (key) | for YANG, the most recent `revision` date, or the empty string if the module has none | | `format` (key) | the language: identities `yang`, `yin`, `xsd`, `rng`, `rnc` | | `namespace` | the XML namespace the schema defines | | `location` | one or more places to get it: a URL, or the value `NETCONF` | The client retrieves the list with an ordinary `<get>` filtered to `<netconf-state><schemas/></netconf-state>`. The reply contains the list entries only, never the schema text. RFC 6022 allows several versions of one identifier to be listed at once, each as its own entry. The YANG library (RFC 8525) offers a parallel hint: each module and submodule entry may carry `location` URLs. When a URL is present and reachable, fetching from it is equally valid; `<get-schema>` is the path that works over the NETCONF session itself. ## Step 2: fetch it ```xml <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get-schema xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring"> <identifier>example-acl</identifier> <version>2024-03-15</version> <format>yang</format> </get-schema> </rpc> ``` The parameters follow RFC 6022 section 3.1: - **`identifier`** is mandatory. - **`version`** is optional, but leaving it out is only safe when the server lists one version. - **`format`** is optional and defaults to `yang`. The positive reply is an `<rpc-reply>` with a `<data>` element (in the monitoring namespace) whose content is the module text. ## Reading the reply The answer to a successful request is the module text wrapped in the reply's `<data>` element: ```xml <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring"> module example-acl { yang-version 1.1; namespace "urn:example:acl"; prefix acl; revision 2024-03-15; } </data> </rpc-reply> ``` A YANG module is returned as text, so the client takes the character content of `<data>` and hands it to its YANG parser; a YIN or XSD schema arrives as XML elements instead. ## When it fails 1. **No matching entry** returns an `<rpc-error>` with error-tag `invalid-value`. Typical cause: an identifier misspelt, or a version taken from another device. 2. **More than one entry matches** returns error-tag `operation-failed` with error-app-tag `data-not-unique`. Typical cause: the server lists two revisions and the request gave no version. The fix is to send the version, which the server never guesses. 3. **The operation is unknown** because the server does not implement the monitoring module. The client then falls back to a `location` URL or to module bundles the device's maker publishes. ## Doing it for a whole model One module rarely stands alone. A module's imports and submodules must be fetched too; the YANG library names them (submodules per module, and modules used only for imports), and each is fetched the same way. Resolving which revision of an import applies is a matter of YANG module rules rather than of `<get-schema>`. ## Operator notes - Prefer fetching by `identifier` **and** `version`: it is the only request guaranteed to be unambiguous. - Check the fetched source's newest `revision` statement against what the device advertised; a mismatch means a stale cache or a mislabelled entry. - Store fetched modules keyed by name and revision, and remember that the same revision with different features or deviations is a different schema for that device. - Fetch deviation modules as eagerly as the modules they modify: without them the client believes nodes exist that the device has removed. - Treat the schemas list and `<get-schema>` as read access worth controlling; they reveal exactly what software the device runs.

  • Why might a NETCONF client prefer a location URL from the YANG library over <get-schema>?
    A URL lets the client fetch sources outside the management session, for example from an internal mirror shared by many devices, without loading the device with schema transfers. `<get-schema>` exists only where the server implements `ietf-netconf-monitoring`, while the library's `location` leaf is present only when the server knows a URL. Clients commonly try a local repository, then the URL, then `<get-schema>`.
  • The schemas list shows a YANG module with an empty version; what does that mean and how do you fetch it?
    RFC 6022 sets the version of a YANG entry to the most recent `revision` date in the module, or to the empty string when the module has no `revision` statement. Fetch it with its identifier and the empty version, or with the identifier alone if that is the only entry listed for it.

saying these in an interview costs you the question

  • <get-schema> is a base NETCONF operation every server supports.
  • Leaving out the version makes the server return the newest revision.
  • The schemas list read with <get> already contains each module's text.
  • A location of NETCONF is a URL to download the module from.
  • <get-schema> defaults to the YIN format because NETCONF is XML.