YANG Library
obsoletes
- rfc-7895 — YANG Module Library
Extracted elements (27)
A given YANG module can only be implemented in one revision across all datastores — if implemented in more than one datastore, the same revision is used in all of them. This constraint simplifies client logic and avoids revision conflicts.
Module sets are designed to be shareable across schemas — for example, the operational state datastore schema is commonly a superset of the conventional configuration datastore schema by referencing both the config module-set and additional state-only module-sets.
RFC 7895 assumed all datastores share exactly one schema, which is incompatible with NMDA where dynamic configuration datastores may have their own schema and the operational state datastore may support additional non-configurable modules. RFC 8525 introduces per-datastore schema references to resolve this.
The content-id caching mechanism exists because YANG library contents can be large (many modules) but change very infrequently. Clients fetch the library once, cache it, and only re-fetch when the content-id changes, minimizing retrieval overhead.
The 'yang-library-parameters' grouping is defined separately so the YANG library data structure can be reused in configuration or other monitoring data structures, and to support schema mount (RFC 8528) use cases.
For a NETCONF server implementing RFC 8526 NMDA extensions, a change in the YANG library content identifier results in a new value for the ':yang-library:1.1' capability, which in turn triggers a 'netconf-capability-change' notification (RFC 6470) if NETCONF notifications (RFC 5277) are implemented.
The new '/yang-library' tree is ignored by legacy RFC 7895 clients, while NMDA-aware clients ignore the deprecated '/modules-state' tree. This split allows a single server to serve both legacy and NMDA-aware clients simultaneously without breaking either.
The YANG library is designed to be usable with YANG Schema Mount (RFC 8528). The 'yang-library-parameters' grouping is factored out specifically to support reuse in schema mount and other monitoring contexts.
A deviation leaf-list entry MUST NOT (directly or indirectly) refer to the module being deviated. Robust clients should handle the case where a module deviates itself gracefully.
A schema entry must be valid and referentially complete — it must contain modules to satisfy all used import statements for all modules specified in the schema.
An NMDA-supporting server SHOULD populate the deprecated '/modules-state' tree in a backwards-compatible manner, reporting YANG modules with 'config true' nodes configurable via conventional datastores and 'config false' nodes returned via NETCONF <get>.
For YANG version 1 modules, there SHOULD NOT be more than one 'module' entry (in the legacy /modules-state list) for a particular module name with conformance-type 'implement', since YANG 1.1 requires at most one revision be implemented.
The server MUST change the value of '/yang-library/content-id' whenever the information represented by the '/yang-library' tree (except the content-id leaf itself) has changed. There is no requirement that the same information always result in the same content-id value.
The server MUST instantiate one entry in the '/yang-library/datastore' list per specific datastore it supports. Each datastore entry with the same datastore schema SHOULD reference the same schema entry.
The deprecated '/modules-state' container (from RFC 7895) is retained for backwards compatibility. It holds a 'module-set-id' leaf and a flat 'module' list with 'conformance-type' (implement/import) enumeration. All nodes carry YANG status 'deprecated'.
The deprecated 'yang-library-change' notification (from RFC 7895) carries a mandatory 'module-set-id' leafref to '/modules-state/module-set-id'. It is superseded by 'yang-library-update' and carries YANG status 'deprecated'.
The 'import-only-module' list within a module-set records modules whose reusable definitions are imported but whose protocol-accessible objects are not implemented. Multiple entries for the same module name are allowed to handle different import revisions.
The '/yang-library' container is the top-level read-only container (config false) holding the entire YANG library. It contains the module-set list, schema list, datastore list, and content-id leaf.
The '/yang-library/content-id' leaf holds a mandatory server-generated string identifier representing the current YANG library contents. Clients use it as a cache key; a value change also triggers a 'yang-library-update' notification.
The '/yang-library/datastore' list contains one entry per supported datastore identified by a 'ds:datastore-ref' identity, with a mandatory reference to an entry in the 'schema' list.
The '/yang-library/module-set' list groups YANG modules and submodules together. Each entry has a name, a 'module' list of implemented modules (with namespace, features, deviations, and submodules), and an 'import-only-module' list for modules used solely for imports.
The '/yang-library/schema' list contains one entry per datastore schema. Each entry references one or more module-sets; the schema is the union of all modules in the referenced module-sets. All conventional configuration datastores share a single schema entry.
The 'yang-library-update' notification is generated whenever any YANG library information changes. It carries a mandatory 'content-id' leaf referencing the new '/yang-library/content-id' value at notification generation time.
RFC 8525 registers the 'ietf-yang-library' module in the IANA YANG Module Names registry (RFC 6020) with namespace 'urn:ietf:params:xml:ns:yang:ietf-yang-library' and prefix 'yanglib'.
RFC 8525 updates the IETF XML Registry (RFC 3688) entry previously registered by RFC 7895: URI 'urn:ietf:params:xml:ns:yang:ietf-yang-library', with registrant contact changed to the IESG.
NACM (RFC 8341) MUST be used to restrict read access to the YANG library data nodes. NETCONF is secured via SSH (RFC 6242) as the mandatory-to-implement transport; RESTCONF is secured via TLS (RFC 8446).
The '/yang-library' subtree may help an attacker identify server capabilities and implementations with known bugs, since the set of supported YANG modules can reveal device type and manufacturer. Server vulnerabilities may be specific to particular modules, revisions, features, or deviations.