skip to content

In YANG 1.1 conformance, what is the difference between a server implementing a module and only importing it?

level: middleimportance: nice to knowfreq 7%

answer

  1. protocol-accessible objects or not
  2. typedefs and groupings only
  3. one implemented revision per module
  4. leafref or augment forces implement

basics

~20 s

Implementing a module means serving its data nodes, RPCs, actions, notifications and deviations. Importing it only means other modules use its reusable definitions such as typedefs and groupings; none of its own objects are served. Only one revision may be implemented.

solid answer

~40 s

RFC 7950 §5.6.5 says a server implements a module if it implements the module's data nodes, RPCs, actions, notifications and deviations. A module the server only imports supplies reusable definitions, typedefs, groupings, identities, to other modules and exposes nothing protocol-accessible of its own; RFC 8525's example lists `ietf-inet-types` that way. A server MUST NOT implement more than one revision of a module, while several import-only revisions may coexist when modules import different revision dates. Some uses force implementation: if an implemented module points into another module from an `augment` or a leafref `path` the server supports, the server must implement a revision of that module defining those nodes. A deviation module is implemented, since deviations are part of what a server implements.

go deeper

for a junior

Remember that implementing a YANG module means serving its data and operations, while importing it only borrows definitions such as typedefs.

for a middle

Explain RFC 7950's definition of implement, the one-implemented-revision rule, why several import-only revisions can coexist, and which uses force a module to be implemented.

for a senior

Use the implement versus import distinction to debug pushes that fail on a device: check the implemented revision and whether the target module is served at all before blaming the payload.

for a principal

Pin automation to implemented revisions per platform and treat a revision change of a core module as a contract change that needs its own validation, not a routine upgrade.

## Two ways a server can relate to a module A YANG module can contribute two very different things to a server: **objects a client can reach** (data nodes, `rpc` and `action` operations, notifications) and **reusable definitions** (`typedef`, `grouping`, `identity`) that other modules borrow. YANG conformance separates the two. - **Implement.** RFC 7950 §5.6.5: "A server implements a module if it implements the module's data nodes, RPCs, actions, notifications, and deviations." Clients can configure, read, invoke and subscribe to what the module defines, subject to its features and any deviations. - **Import only.** The server uses the module because other modules import it, but implements none of its protocol-accessible objects. RFC 8525 describes such an entry as one where the server "imports reusable definitions from the specified revision of the module but does not implement any protocol-accessible objects from this revision." | | Implemented | Import-only | |---|---|---| | Data nodes, RPCs, actions, notifications | served | not served | | Typedefs, groupings, identities | available | available to importers | | Revisions at once | at most one | several may coexist | | Deviations it contains | in force | not in force | ## Why only one revision can be implemented A server MUST NOT implement more than one revision of a module (§5.6.5): two revisions of the same data nodes in one namespace would give clients two contracts for the same paths. Import-only is different. YANG 1.1 allows a module to be imported by several revisions, and RFC 8525 says multiple import-only entries for one module name MAY exist when different importers pin different revision dates with `revision-date`. NMDA does not loosen the first rule: RFC 8525 requires a non-import-only module that appears in several module sets of one schema to carry an identical revision, features and deviations in each. ## When importing is not enough §5.6.5 forces implementation in some cases: 1. If an implemented module A imports module B and uses a node from B in an `augment` or `path` statement the server supports, the server MUST implement a revision of B that defines those nodes, whether A pinned B's revision or not. A leafref into another module's data cannot point at data the server does not serve. 2. If A imports a module C **without** a revision date and the server does not implement C, for example because C only defines typedefs, the server must still list C, as import-only. 3. When several listed modules import C without a revision date, the server MUST use the definitions from the most recent revision of C it lists. The reason, in the RFC's words, is that clients need to know the exact structure and types of every leaf the server implements. ## Where deviations and features fit - **Deviation modules are implemented.** Deviations count among what a server implements, so a module that only holds deviations is implemented even though it defines no data nodes of its own. RFC 8525's deprecated tree says the same: the `conformance-type` value will be `implement` for a deviation module. - **Features are stated per implemented module.** RFC 8525 attaches the list of supported features to each implemented module's entry, next to the list of deviation modules that modify it. ## How the distinction is recorded, briefly The YANG library records the distinction. RFC 7895 used one leaf, `conformance-type`, with the values `implement` and `import`. RFC 8525, which obsoletes RFC 7895, splits them into a `module` list for implemented modules and an `import-only-module` list, keeping the old `/modules-state` tree only as deprecated. How a client fetches and caches that information is a topic of its own. ## Why automation teams care - A module that appears only as import-only offers **no data** even if it defines containers; pushing configuration into it fails because those nodes are not in the server's schema. - The **implemented revision** is the contract. A playbook written against a newer revision of a module silently assumes nodes the device's single implemented revision may not have. - A device that **imports two revisions** of a types module is normal, not a defect; it reflects importers pinning different dates. - A **deviation module** missing from the implemented set is a red flag: its deviations would not be in force, so the schema the device actually enforces is not the one the client computed.

  • Why must a server implement, not just import, a YANG module that an implemented module's leafref points into?
    RFC 7950 §5.6.5: if an implemented module uses a node from an imported module in a `path` or `augment` statement the server supports, the server MUST implement a revision of that module defining those nodes. A leafref is a reference to instance data; if the target module's data were not served, every reference would point at nothing the client could read or create.
  • Can a YANG module that defines containers be listed by a server as import-only?
    Yes. Import-only means the server uses the module's reusable definitions without implementing any of its protocol-accessible objects, so its containers simply are not part of the server's schema. A client that tries to configure them is sending data outside what the server implements.

saying these in an interview costs you the question

  • An import-only module's data nodes are readable but not writable
  • A server may implement two revisions of a module during a migration
  • A deviation module only needs to be imported because it adds no data
  • Each NMDA datastore may implement a different revision of the same module
  • A leafref into another module only needs that module imported for its types