YANG library

SR OS supports a mechanism, a YANG library, to identify the YANG modules and submodules that are implemented by the NETCONF server. NETCONF clients should be able to query or cache the YANG library contents and identify whether their cache is out-of-date.

The SR OS NETCONF server supports the ‟/yang-library” state model and advertises the following capability in the <hello> message (in accordance with RFC 8525):

<capability>urn:ietf:params:netconf:capability:yang-
library:1.1?revision=<date>&content-id=<content-id-value></capability>

The following is the YANG tree diagram for the ‟/yang-library” model:

 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 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

The SR OS NETCONF server advertises the following capability in the <hello> message:

<capability>urn:ietf:params:netconf:capability:yang-
library:1.0?revision=<revision-date>&amp;module-set-id=<string></capability>

The following is the YANG tree diagram for the modules-state model:

 +--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 submodule* [name revision]
       +--ro name        yang:yang-identifier
       +--ro revision    union
       +--ro schema?     inet:uri

The module-set-id is a mandatory leaf that identifies a set of YANG modules that the SR OS NETCONF server supports. The value of this leaf changes whenever there is a change in the set of modules or submodules in the YANG library. When this change occurs, SR OS changes the module-set-id value advertised in the NETCONF server <hello> message.

The modules-state can be used by the NETCONF client to fetch the YANG library, cache it, and re-fetch it only if the value of the module-set-id changes again. The YANG library is returned in the module list.

Example

If the SR OS NETCONF server advertises the following capability, the NETCONF client can use the advertised module-set-id to query the YANG library:

<capability>urn:ietf:params:netconf:capability:yang-library:1.0?revision=2018-
05-08&module-set-id=1234</capability>

The following example shows the NETCONF client using the advertised module-set-id to query the YANG library.

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
<get>
  <filter type="subtree">
    <modules-state xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
 <module-set-id>1234</module-set-id> 
          <module>
          </module>
        </modules-state>
      </filter>
     </get>
    </rpc>
    ]]>]]>

The following example shows the reply.

    <?xml version="1.0" encoding="UTF-8"?>
    <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <data>
            <modules-state xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
                <module-set-id>1234</module-set-id>
                <module>
                    <name>iana-if-type</name>
                    <revision>2014-05-08</revision>
                    <namespace>urn:ietf:params:xml:ns:yang:iana-if-type</namespace>
                    <conformance-type>implement</conformance-type>
                </module>
                             …
                             …
                <module>
                    <name>nokia-conf</name>
                    <revision>2016-07-06</revision>
                    <namespace>urn:nokia.com:sros:ns:yang:sr:conf</namespace>
                    <conformance-type>implement</conformance-type>
                    <submodule>
                        <name>nokia-conf-aa-common</name>
                       <revision>2018-04-23</revision>
                    </submodule>
                                    …
                                    …
                </module>
                             …
                             …
            </modules-state>
        </data>
    </rpc-reply>
    ]]>]]>