YANG Library

The YANG Library contains the standard mechanisms to identify the YANG modules and submodules that are in use by each server that utilizes YANG-based data models.

The YANG Library is a read-only inventory of the YANG modules used by the server
Clients can use this information to load the YANG modules needed to manage a server
There can be a large number of 'module' entries in the YANG library on a typical server.
The YANG library contents are usually set at boot-time, and changes very infrequently
An 'id' string is maintained by the server so a client can cache and reuse the YANG library contents from a server

The YANG Library utilizes 3 YANG modules:

ietf-yang-library.yang: Most YANG data definitions and notifications
ietf-yang-library-augmentedby.yang: 'augmented-by' leaf in the module entry
ietf-netconf-monitoring.yang: Protocol operation to retrieve a YANG module

The YANG library contents can change at run-time if any the following operations are used:

There are 2 versions of the YANG Library supported:

RFC 7895: Older Non-NMDA version
- Defines monitoring information about all the loaded YANG modules and submodules used by a server to represent management and protocol information.
- contains /modules-state subtree
- contains <yang-library-change> Event notification
- contains one module-set representing the the entire server
RFC 8525: Newer NMDA version (also contains all non-NMDA data)
- Defines NMDA-compatible version of the same information found in the older version. The structure of the new YANG library is more complex than the old structure.
- contains /yang-library subtree
- contains <yang-library-update> Event notification
- contains /modules-state subtree (deprecated)
- contains <yang-library-change> Event notification (deprecated)
- This version will be used if the --with-nmda=``true`` setting is used.
- This version will be used if the --with-new-yanglib='true' setting is used. This is the default setting since 24.10-1.
- Allowed to contain multiple module-sets, each one representing zero or more datastores.
- The server implementation contains one module-set named modules so it has the same structure as the non-NMDA version.

CLI Parameters for the YANG Library:

Refer to the Configuring the YANG Library section for details

Parameter	Description
--bundle	Load a bundle into the server at boot-time
--deviation	Load a deviation module into the server at boot-time
--feature-disable	Disable a YANG feature at boot-time
--feature-enable	Enable a YANG feature at boot-time
--feature-enable-default	Default value to enable a YANG feature at boot-time
--hide-module	Prevent a module from being included in the YANG library
--module	Load a module into the server at boot-time
--with-nmda	Use NMDA YANG library
--with-new-yanglib	Use the new YANG library even without NMDA
--with-yanglib-augmentedby	Add the new 'augmented-by' leaf to each module entry

Retrieving YANG Modules From the Server

A client can retrieve all the YANG modules from the server that are listed in the YANG library.

NETCONF Retrieval

NETCONF retrieval is done with the <get-schema> operation. This operation is built-in the server, provided by the ietf-netconf-monitoring.yang module,

The input parameters are derived from the 'name' and 'revision' fields in the module list entry.
The output 'data' anyxml container is treated as a string if the format is 'YANG'.

Example yangcli-pro request to retrieve a YANG module:

get-schema identifier=ietf-inet-types

Example server request in XML:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="3"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <get-schema xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
  <identifier>ietf-inet-types</identifier>
 </get-schema>
</rpc>

Example server reply in XML:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="6"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
module ietf-inet-types {

  namespace "urn:ietf:params:xml:ns:yang:ietf-inet-types";
  prefix "inet";

  // rest of module removed to keep example short


}

 </data>
</rpc-reply>

RESTCONF Retrieval

RESTCONF retrieval is done with the 'GET' method on a schema resource>. This method is built-in the server, if RESTCONF is enabled.

Only YANG format is supported in RESTCONF
The URL is copied from the 'schema' or 'location' leaf
The output contains just the YANG file
The output Content-Type is 'application/yang'
There is no 'data' wrapper like the NETCONF operation

Example curl request to retrieve the module-set-id:

curl http://localhost/restconf/yang/ietf-inet-types/2013-07-15

The RESTCONF server returns text containing the YANG module:

module ietf-inet-types {

  namespace "urn:ietf:params:xml:ns:yang:ietf-inet-types";
  prefix "inet";

  // rest of module removed to keep example short

}

YANG Library Update Notifications

The following information is used in order to identify if the YANG-Library cache is out-of-date and if the set of modules have changed.

/modules-state/module-set-id
- Contains a server-specific identifier representing the current set of modules and submodules. The server will change the value of this leaf if the information represented by the 'module' list instances has changed.
/yang-library/content-id
- Contains the NMDA copy of the 'module-set-id' leaf

The server will generate notifications for the 'NETCONF' event stream when the YANG library changes. The actual events sent depend on the CLI configuration settings. No events are actually generated unless there is at least one active 'NETCONF' event stream subscription.

Example: A module named 'test1' was added to the YANG library.

The server should send 1 'yang-library-change' event:

<?xml version="1.0" encoding="UTF-8"?>
 <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
  <eventTime>2026-01-24T19:32:30.949240Z</eventTime>
  <yang-library-change xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
   <module-set-id>5866</module-set-id>
  </yang-library-change>
 </notification>

The server should send 1 'yang-library-update' event (if --with-nmda='true'):

<?xml version="1.0" encoding="UTF-8"?>
 <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
  <eventTime>2026-01-24T19:32:30.949257Z</eventTime>
  <yang-library-update xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
   <content-id>5866</content-id>
  </yang-library-update>
 </notification>

The server should send 1 'netconf-capability-change' event:

<?xml version="1.0" encoding="UTF-8"?>
 <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
  <eventTime>2026-01-24T19:32:30.949386Z</eventTime>
  <netconf-capability-change xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-notifications">
   <changed-by>
    <username>andy</username>
    <session-id>3</session-id>
    <source-host>127.0.0.1</source-host>
   </changed-by>
  <added-capability>http://netconfcentral.org/ns/test1?module=test1&amp;revision=2008-10-12</added-capability>
  </netconf-capability-change>
 </notification>

Non-NMDA YANG Library Structure

The following tree diagram represents the contents of the older YANG module:

module: ietf-yang-library
  +--ro modules-state
     +--ro module-set-id    string
     +--ro module* [name revision]
        +--ro name                yang:yang-identifier
        +--ro revision            union
        +--ro schema?             inet:uri
        +--ro namespace           inet:uri
        +--ro feature*            yang:yang-identifier
        +--ro deviation* [name revision]
        |  +--ro name        yang:yang-identifier
        |  +--ro revision    union
        +--ro conformance-type    enumeration
        +--ro augmented-by*   -> ../../yanglib:module/name
        +--ro submodule* [name revision]
           +--ro name        yang:yang-identifier
           +--ro revision    union
           +--ro schema?     inet:uri

  notifications:
    +---n yang-library-change
       +--ro module-set-id    -> /modules-state/module-set-id

Example module-set-id Retrieval

The YANG library contents can be cached on the client. The 'module-set-id' leaf is a string that represents the state of all the YANG library contents.

The server uses a numeric checksum for this string

Example yangcli-pro request to retrieve the module-set-id:

sget /modules-state/module-set-id

Example server reply in yangcli-pro ($$display-mode='json')

{
  "ietf-yang-library:modules-state": {
    "module-set-id":"8551"
  }
}

Example Library Retrieval

The entire library is retrieved but only the first 'module' entry is shown to keep the example short.

Example yangcli-pro request to retrieve the entire YANG library:

sget /modules-state

Example server reply in yangcli-pro ($$display-mode='json')

{
  "ietf-yang-library:modules-state": {
    "module-set-id":"8422",
    "module": [
      {
        "name":"ietf-netconf",
        "revision":"2011-06-01",
        "namespace":"urn:ietf:params:xml:ns:netconf:base:1.0",
        "feature": [
          "candidate",
          "confirmed-commit",
          "rollback-on-error",
          "validate",
          "url",
          "xpath"
        ],
        "conformance-type":"implement",
        "ietf-yang-library-augmentedby:augmented-by": [
          "ietf-netconf-with-defaults",
          "yuma-time-filter",
          "yumaworks-system",
          "yumaworks-templates"
        ]
      }
    ]
  }
}

Implemented Module Example Entry

Example yangcli-pro request to retrieve one module entry:

sget /modules-state/module[name='ietf-yang-push']

Example server reply in yangcli-pro ($$display-mode='json')

{
  "ietf-yang-library:modules-state": {
    "module": [
      {
        "name":"ietf-yang-push",
        "revision":"2019-09-09",
        "schema":"http://localhost/restconf/yang/ietf-yang-push/2019-09-09",
        "namespace":"urn:ietf:params:xml:ns:yang:ietf-yang-push",
        "feature": [
          "on-change"
        ],
        "deviation": [
          {
            "name":"yumaworks-yangpush2-dev",
            "revision":"2025-09-13"
          }
        ],
        "conformance-type":"implement",
        "ietf-yang-library-augmentedby:augmented-by": [
          "ietf-distributed-notif"
        ]
      }
    ]
  }
}

Imported Module Example Entry

Example yangcli-pro request to retrieve one module entry:

sget /modules-state/module[name='ietf-inet-types']

Example server reply in yangcli-pro ($$display-mode='json')

{
  "ietf-yang-library:modules-state": {
    "module": [
      {
        "name":"ietf-inet-types",
        "revision":"2013-07-15",
        "schema":"http://localhost/restconf/yang/ietf-inet-types/2013-07-15",
        "namespace":"urn:ietf:params:xml:ns:yang:ietf-inet-types",
        "conformance-type":"import"
      }
    ]
  }
}

NMDA YANG Library Structure

The following tree diagram represents the contents of the newer YANG module:

The entire non-NMDA version is also contained in this module.

module: ietf-yang-library
  +--ro yang-library
  |  +--ro module-set* [name]
  |  |  +--ro name                  string
  |  |  +--ro module* [name]
  |  |  |  +--ro name         yang:yang-identifier
  |  |  |  +--ro revision?    revision-identifier
  |  |  |  +--ro namespace    inet:uri
  |  |  |  +--ro location*    inet:uri
  |  |  |  +--ro submodule* [name]
  |  |  |  |  +--ro name        yang:yang-identifier
  |  |  |  |  +--ro revision?   revision-identifier
  |  |  |  |  +--ro location*   inet:uri
  |  |  |  +--ro feature*     yang:yang-identifier
  |  |  |  +--ro deviation*   -> ../../module/name
  |  |  |  +--ro augmented-by* -> ../../yanglib:module/name
  |  |  +--ro import-only-module* [name revision]
  |  |     +--ro name         yang:yang-identifier
  |  |     +--ro revision     union
  |  |     +--ro namespace    inet:uri
  |  |     +--ro location*    inet:uri
  |  |     +--ro submodule* [name]
  |  |        +--ro name        yang:yang-identifier
  |  |        +--ro revision?   revision-identifier
  |  |        +--ro location*   inet:uri
  |  +--ro schema* [name]
  |  |  +--ro name          string
  |  |  +--ro module-set*   -> ../../module-set/name
  |  +--ro datastore* [name]
  |  |  +--ro name      ds:datastore-ref
  |  |  +--ro schema    -> ../../schema/name
  |  +--ro content-id    string

 notifications:
    +---n yang-library-update
        +--ro content-id    -> /yang-library/content-id

Example module-set-id Retrieval

The YANG library contents can be cached on the client. The 'module-set-id' leaf is a string that represents the state of all the YANG library contents.

The server uses a numeric checksum for this string

Example yangcli-pro request to retrieve the module-set-id:

sget /modules-state/module-set-id

Example server reply in yangcli-pro ($$display-mode='json')

{
  "ietf-yang-library:modules-state": {
    "module-set-id":"8551"
  }
}

Example content-id Retrieval

The YANG library contents can be cached on the client. The 'content-id' leaf is a string that represents the state of all the YANG library contents.

The server uses a numeric checksum for this string
This is the same value as the 'module-set-id' leaf

Example yangcli-pro request to retrieve the module-set-id:

sget /yang-library/content-id

Example server reply in yangcli-pro ($$display-mode='json')

{
  "ietf-yang-library:yang-library": {
    "content-id":"8551"
  }
}

Example Library Retrieval

The entire library is retrieved but only the first 'module' and 'import-only-module' entries are shown to keep the example short.

Example yangcli-pro request to retrieve the entire YANG library:

sget /yang-library

Example server reply in yangcli-pro ($$display-mode='json')

{
  "ietf-yang-library:yang-library": {
    "module-set": [
      {
        "name":"modules",
        "module": [
          {
            "name":"ietf-netconf",
            "revision":"2011-06-01",
            "namespace":"urn:ietf:params:xml:ns:netconf:base:1.0",
            "feature": [
              "candidate",
              "confirmed-commit",
              "rollback-on-error",
              "validate",
              "url",
              "xpath"
            ],
            "ietf-yang-library-augmentedby:augmented-by": [
              "ietf-netconf-with-defaults",
              "yuma-time-filter",
              "yumaworks-system",
              "yumaworks-templates"
            ]
          }
        ],
        "import-only-module": [
          {
            "name":"iana-tls-cipher-suite-algs",
            "revision":"2024-03-16",
            "namespace":"urn:ietf:params:xml:ns:yang:iana-tls-cipher-suite-algs",
            "location": [
              "http://localhost/restconf/yang/iana-tls-cipher-suite-algs/2024-03-16"
            ]
          },
        ]
      }
    ],
    "schema": [
      {
        "name":"schema1",
        "module-set": [
          "modules"
        ]
      }
    ],
    "datastore": [
      {
        "name":"ietf-datastores:candidate",
        "schema":"schema1"
      },
      {
        "name":"ietf-datastores:running",
        "schema":"schema1"
      }
    ],
    "content-id":"8422"
  }
}

Implemented Module Example Entry

Example yangcli-pro request to retrieve one module entry:

sget /yang-library/module-set/module[name='ietf-yang-push']

Example server reply in yangcli-pro ($$display-mode='json')

{
  "ietf-yang-library:yang-library": {
    "module-set": [
      {
        "name":"modules",
        "module": [
          {
            "name":"ietf-yang-push",
            "revision":"2019-09-09",
            "namespace":"urn:ietf:params:xml:ns:yang:ietf-yang-push",
            "location": [
              "http://localhost/restconf/yang/ietf-yang-push/2019-09-09"
            ],
            "feature": [
              "on-change"
            ],
            "deviation": [
              "yumaworks-yangpush2-dev"
            ],
            "ietf-yang-library-augmentedby:augmented-by": [
              "ietf-distributed-notif"
            ]
          }
        ]
      }
    ]
  }
}

Imported Module Example Entry

Example yangcli-pro request to retrieve one module entry:

sget /yang-library/module-set/import-only-module[name='ietf-inet-types']

Example server reply in yangcli-pro ($$display-mode='json')

{
  "ietf-yang-library:yang-library": {
    "module-set": [
      {
        "name":"modules",
        "import-only-module": [
          {
            "name":"ietf-inet-types",
            "revision":"2013-07-15",
            "namespace":"urn:ietf:params:xml:ns:yang:ietf-inet-types",
            "location": [
              "http://localhost/restconf/yang/ietf-inet-types/2013-07-15"
            ]
          }
        ]
      }
    ]
  }
}

YANG Library Module Fields

The following information is used by the library (for each YANG module in the library) to fully utilize monitoring mechanism. The fields are slightly different in each YANG library version.

Common Fields:

name: The mandatory YANG module name is unique within a YANG library.
- All modules and submodules share the same namespace, including modules used for deviations.
revision: Each YANG module within the library should have a revision date.
- This is derived from the most recent revision statement within the module or submodule.
- If no revision statements are present then an empty string will be used for this field.
namespace: The XML namespace identifier for this module.
submodule: List containing the name, revision date, and retrieval URL of each submodule used by main module.
feature: Leaf-list of the name of each YANG feature defined in the module, which is supported by the server.
deviation: Leaf-list of the name of each YANG module used for deviation statements, applied to the module entry.
augmented-by: Leaf-list of the name of each YANG module used for augment statements, applied to the module entry.
- This field is present if the --with-yanglib-augmentedby='true' setting is used.

Non-NMDA Only Fields:

conformance-type:
- If 'implement', then the server is claiming conformance to the YANG module identified in this entry.
- If 'import', then the server is not claiming any conformance for the YANG module identified by this entry. The module may be needed for reusable definitions, such as extensions, features, identifies, typedefs, or groupings.
schema: Contains a URL that represents the YANG schema resource for the module or submodule.
- This leaf will only be present if there is a URL available for retrieval of the schema for this entry.
- The URL can only be used in the server if the RESTCONF protocol is enabled.

NMDA Only Fields:

import-only-module: A separate YANG list is used for modules that are loaded but not implemented.
- This list replaces the 'conformance-type' leaf in the non-NMDA version.
location: Contains a URL that represents the YANG schema resource for the module or submodule.
- This is the NMDA version of the 'schema' leaf.

Configuring the YANG Library

There are several CLI parameters that affect how the server implements the YANG library.

New vs. Old YANG Library

There are two versions of the YANG library supported:

RFC 7895 is the obsolete version, but still widely used. The data structure '/modules-state' is used to store the information.
RFC 8525 is the current version, which has a replacement data structure called '/yang-library' to store the information.

Note

The new YANG Library contains both data structures so it is backward-compatible with the old YANG library.

The new YANG library must be used f --with-nmda is set to 'true'. If NMDA is not used, the default is to still use the new YANG library. The --with-new-yanglib CLI parameter is used to control this behavior. Although not recommended, the obsolete YANG library can still be used.

Implemented vs. Imported

A 'implemented' module is supported by the server. This is reflected in the YANG library:

New: The '/yang-library/module-set/module' list is used
Old: The '/modules-state/module/conformance-type' leaf is set to implement

An 'imported' module is imported directly or indirectly by an implemented module. This is reflected in the YANG library:

New: The '/yang-library/module-set/import-only-module' list is used
Old: The '/modules-state/module/conformance-type' leaf is set to import

If a module is explicitly loaded into the server using the --module, --bundle, or --deviation parameter, then it is listed as 'implemented'.

If the --loadpath parameter is used, and a module is found in the loadpath, that is not included in any bundles, and that also has a SIL library present, will be listed as 'implemented'.

If a module is imported into another module loaded into the server, then it is listed as 'imported', unless the imported module is being augmented. Then YANG requires the imported module to be implemented.

Exceptions:

A module must be loaded (e.g. using the --module parameter) and identified as 'implemented' if any YANG features are supported in the module. The iana-crypt-hash.yang module is an example of such a module.
A module must be loaded (e.g. using the --module parameter) and identified as 'implemented' if any identities are implemented in the module. The IETF 'iana-if-types.yang' module should be explicitly loaded if the ietf-interfaces.yang module is loaded.

Features and Deviations

A 'feature' entry will only be created for enabled features:

A feature identified with the --feature-enable CLI parameter.
The --feature-enable-default is 'true' and no --feature-disable CLI parameter is present for the module
The feature is enabled via API function from a SIL module

A 'deviation' entry will only be created for explicit deviations:

A deviation identified with the --deviation CLI parameter.

Deviations can still be used and hidden from the client by using the --annotation parameter instead of the --deviation CLI parameter.

Hidden Modules

Some internal YumaPro modules are automatically hidden from the YANG Library. It is also possible to configure additional YANG modules that should be hidden using the --hide-module CLI parameter.

Complete NETCONF Hello Messages

By default, the NETCONF "<hello>" message only contains module capabilities for YANG 1.0 modules. The client must retrieve the YANG library to get the information for YANG 1.1 modules. The --with-yang11-hello CLI parameter can be used to include the YANG 1.1 modules and avoid the need to retrieve the YANG library at session startup.

Using the YANG Library

In order to retrieve the whole set of modules currently supported by the server the following command is used.

Example Request:

sget /modules-state

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="6" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get>
    <filter type="subtree">
      <modules-state xmlns="urn:ietf:params:xml:ns:yang:ietf-yang- library"/>
    </filter>
  </get>
</rpc>

Example Reply:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="6" xmlns:ncx="http://netconfcentral.org/ns/yuma-ncx"
 ncx:last-modified="2015-06-17T19:00:37Z"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <data>
  <modules-state xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
   <module>
    <name>ietf-inet-types</name>
    <revision>2013-07-15</revision>
    <namespace>urn:ietf:params:xml:ns:yang:ietf-inet-types</namespace>
    <schema>http://localhost/yang-api/yang/ietf-inet-types/2013-07-15</schema>
    <conformance-type>import</conformance-type>
   </module>
   <module>
    <name>yumaworks-system</name>
    <revision>2014-10-16</revision>
    <namespace>http://yumaworks.com/ns/yumaworks-system</namespace>
    <schema>http://localhost/yang-api/yang/yumaworks-system/2014-10-16</schema>
    <conformance-type>implement</conformance-type>
   </module>
   <module>
    <name>yumaworks-types</name>
    <revision>2014-09-06</revision>
    <namespace>http://yumaworks.com/ns/yumaworks-types</namespace>
    <schema>http://localhost/yang-api/yang/yumaworks-types/2014-09-06</schema>
    <conformance-type>import</conformance-type>
   </module>
   <module-set-id>3521</module-set-id>
  </modules-state>
 </data>
</rpc-reply>

Example RESTCONF Request:

GET /restconf/data/modules-state/module=example-jukebox,2014-07-03/schema HTTP/1.1
Host: example.com
Accept: application/yang-data+json

The server might respond:

HTTP/1.1 200 OK
Date: Mon, 25 Apr 2012 11:10:30 GMT
Server: example-server
Content-Type: application/yang-data+json

{
  "ietf-yang-library:schema": "https://example.com/mymodules/example-jukebox/2015-06-04"
}

Using the Server in Library Mode

The server supports a special mode of operation with the --library-mode CLI parameter. In this mode, the server will only operate as a YANG Library Schema Server.

Note

All vendor-added YANG instrumentation is ignored in Library Mode!
The --module, --bundle, and --loadpath CLI parameters are ignored in Library Mode.
The <load>, <load-bundle>, <unload> and <unload-bundle> RPC operations cannot be used in Library Mode.
The server will search for all valid YANG modules in the module search path.
All found modules will be added to the YANG Library
No found modules will be accessible or implemented in the server.
The server will scan the module search path and add all revisions of all modules it finds to the YANG library “module” list.
Only one copy of each revision will be loaded in case the same file existing in multiple places in the module search path.

Discover the Modules Available for Retrieval

The YANG library needs to be scanned by the client.
- The non-NMDA module entry provides a schema leaf that can be used by RESTCONF to retrieve the YANG module.
- The NMDA module entry provides a location leaf that can be used by RESTCONF to retrieve the YANG module.
The module list entry will contain the name and revision string for the found module. These values are used as parameters in the <get-schema> operation.

Only 6 RPC Operations are allowed in Library Mode

<get>
<get-config>
<get-data> (if ietf-netconf-nmda.yang is loaded)
<get-schema>
<restart> (only if yuma-system.yang is loaded)
<shutdown> (only if yuma-system.yang is loaded)

The Server is not Fully YANG Library Compliant in Library Mode

The /netconf-state/schemas/schema subtree will contain list entries for modules which are enabled in the server configuration. Not all of these modules will be usable in Library Mode.
- For example, the <get-bulk> operation will not be allowed even if it is loaded using --with-yumaworks-getbulk is set.
The /modules-state/module subtree will contain list entries for all valid found modules in the module search path. These modules are not all implemented in the server. The conformance leaf will be set to import for all modules.
The /yang-library/module-set/module subtree will contain list entries for all valid found modules in the module search path. These modules are not all implemented in the server.
Only the <get-schema> operation will be available for the discovered modules.