YANG LibraryYumaWorksandy@yumaworks.comTail-f Systemsmbj@tail-f.comJacobs Universityj.schoenwaelder@jacobs-university.deJuniper Networkskwatsen@juniper.netCisco Systemsrwilton@cisco.com
This document describes a YANG library that provides information about
the YANG modules, datastores, and datastore schemas used by a network
management server. Simple caching mechanisms are provided to allow
clients to minimize retrieval of this information. This version of the
YANG library supports the Network Management Datastore Architecture (NMDA) by
listing all datastores supported by a network management server and
the schema that is used by each of these datastores.
This document obsoletes RFC 7895.
There is a need for a standard mechanism to expose which YANG modules
, datastores , and datastore schemas
are in use by a network
management server.
This document defines the YANG module "ietf&nbhy;yang&nbhy;library" that
provides this information. This version of the YANG library is
compatible with the Network Management Datastore Architecture (NMDA)
. The previous version of the YANG
library, defined in , is not compatible with the NMDA since
it assumes that all datastores have exactly the same schema. This is
not necessarily true in the NMDA since dynamic configuration datastores
may have their own datastore schema. Furthermore, the operational
state datastore may support non-configurable YANG modules in addition
to the YANG modules supported by conventional configuration
datastores.
The old YANG library definitions have been retained (for
backwards-compatibility reasons), but the definitions have been marked as
deprecated. For backwards compatibility, an NMDA-supporting server
SHOULD populate the deprecated "/modules&nbhy;state" tree in a
backwards-compatible manner. The new "/yang&nbhy;library" tree will be
ignored by legacy clients but will provide all the data needed for
NMDA-aware clients (which will ignore the "/modules&nbhy;state"
tree).
The recommended approach to populate "/modules-state" is to report
the YANG modules with "config true" data nodes that are
configurable via conventional configuration datastores and the
YANG modules with "config false" data nodes that are returned via a
Network Configuration Protocol (NETCONF) <get>
operation or equivalent.
The YANG library information can be different on every server, and it
can change at runtime or across a server reboot. If a server
implements multiple network management protocols to access the
server's datastores, then each such protocol may have its own
conceptual instantiation of the YANG library.
If a large number of YANG modules are utilized by a server, then the
YANG library contents can be relatively large. Since the YANG library
contents change very infrequently, it is important that clients be
able to cache the YANG library contents and easily identify whether
their cache is out of date.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14
when, and only when, they appear in all capitals, as shown here.
The following terms are defined in :
module
submodule
data node
This document uses the phrase "implement a module" as defined in
Section 5.6.5 of .
The following terms are defined in :
datastore
datastore schema
configuration
conventional configuration datastore
operational state
operational state datastore
dynamic configuration datastore
client
server
The following terms are used within this document:
YANG library: A collection of YANG modules, submodules, datastores,
and datastore schemas used by a server.
YANG library content identifier: A server-generated identifier of
the contents of the YANG library.
Tree diagrams in this document use the notation defined in
.
The following information is needed by a client application (for each
YANG module in the library) to fully utilize the YANG data modeling
language:
name: The name of the YANG module.
revision: If defined in the YANG module or submodule, the revision
is derived from the most recent revision statement within the module
or submodule.
submodule list: The name and (if defined) revision of each submodule
used by the module must be identified.
feature list: The name of each YANG feature supported by the
server must be identified.
deviation list: The name of each YANG module with deviation
statements affecting a given YANG module must be identified.
In addition, the following information is needed by a client
application for each datastore supported by a server:
identity: The YANG identity for the datastore.
schema: The schema (i.e., the set of modules) implemented by the
datastore.
In order to select one out of several possible designs for the YANG
library data model, the following criteria were used:
The information must be efficient for a client to consume.
Since the size of the YANG library can be quite large, it should
be possible for clients to cache the YANG library information.
A dynamic configuration datastore must be able to implement a module
or feature that is not implemented in the conventional configuration
datastores.
It must be possible to not implement a module or feature in
<operational>, even if it is implemented in some other datastore.
This is required for transition purposes; a server that wants to
implement <operational> should not have to implement all modules at
once.
A given module can only be implemented in one revision in all
datastores. If a module is implemented in more than one
datastore, the same revision is implemented in all these
datastores.
Multiple revisions can be used for import, if import-by revision
is used.
It must be possible to use the YANG library by schema mount
.
The "ietf&nbhy;yang&nbhy;library" YANG module provides information about the
modules, submodules, datastores, and datastore schemas supported by a
server. All data nodes in the "ietf&nbhy;yang&nbhy;library" module are
"config false" and
thus only accessible in the operational state datastore.
The conceptual model of the YANG library is depicted in
Figure 1. Following the NMDA, every datastore has an associated datastore
schema. A datastore schema is a union of module sets, and every module
set is a collection of modules and submodules, including the modules
and submodules used for imports. Note that multiple datastores may
refer to the same datastore schema. Furthermore, it is possible for
individual datastore schemas to share module sets. A common use case is the
operational state datastore schema, which is a superset of the schema
used by conventional configuration datastores.
Below is the YANG tree diagram for the "ietf&nbhy;yang&nbhy;library" module,
excluding the deprecated "/modules&nbhy;state" tree:
The "/yang&nbhy;library" container holds the entire YANG library. The
container has the following child nodes:
The "/yang&nbhy;library/module&nbhy;set" contains entries representing module
sets. The list "/yang&nbhy;library/module&nbhy;set/module" enumerates the
modules that belong to the module set. A module is listed together
with its submodules (if any), a set of features, and any deviation
modules. The list "/yang&nbhy;library/module&nbhy;set/import&nbhy;only&nbhy;module"
lists all modules (and their submodules) used only for imports. The
assignment of a module to a module set is at the server's
discretion. This revision of the YANG library attaches no semantics
as to which module set a module is listed in.
The "/yang&nbhy;library/schema" list contains an entry for each datastore
schema supported by the server. All conventional configuration
datastores use the same "schema" list entry. A dynamic configuration
datastore may use a different datastore schema from the conventional
configuration datastores and hence may require a separate "schema"
entry. A "schema" entry has a leaf-list of references to entries in
the "module&nbhy;set" list. The schema consists of the union of all
modules in all referenced module sets.
The "/yang&nbhy;library/datastore" list contains one entry for each
datastore supported by the server, and it identifies the datastore
schema associated with a datastore via a reference to an entry in
the "schema" list. Each supported conventional configuration
datastore has a separate entry, pointing to the same "schema" list
element.
The "/yang&nbhy;library/content&nbhy;id" leaf contains the YANG library
content identifier, which is an implementation-specific identifier
representing the current information in the YANG library on a
specific server. The value of this leaf MUST change whenever the
information in the YANG library changes. There is no requirement
that the same information always result in the same "content&nbhy;id"
value. This leaf allows a client to fetch all schema information
once, cache it, and only refetch it if the value of this leaf has
been changed. If the value of this leaf changes, the server also
generates a "yang&nbhy;library&nbhy;update" notification.
Note that for a NETCONF server implementing the NETCONF extensions to
support the NMDA , a change of the YANG
library content identifier results in a new value for the
:yang-library:1.1 capability defined in
. Thus, if such a server implements
NETCONF notifications and the
"netconf&nbhy;capability&nbhy;change" notification , a
"netconf&nbhy;capability&nbhy;change"
notification is generated whenever the YANG library content identifier
changes.
The "ietf&nbhy;yang&nbhy;library" YANG module imports definitions from
the "ietf&nbhy;yang&nbhy;types" and
"ietf&nbhy;inet&nbhy;types" modules defined in and
from the
"ietf&nbhy;datastores" module defined in .
While the YANG module is defined using YANG version 1.1, the YANG
library supports the YANG modules written in any version of YANG.
<CODE BEGINS> file "ietf-yang-library@2019-01-04.yang"<CODE ENDS>
RFC 7895 previously registered one URI in the "IETF XML Registry"
. This document takes over this registration entry made by
RFC 7895 and changes the Registrant Contact to the IESG according to Section 4
of .
This document registers a YANG module in the "YANG Module
Names" registry :
This document takes over this registration entry made by RFC 7895.
The YANG module specified in this document defines a schema for data that is
designed to be accessed via network management protocols such as NETCONF
or RESTCONF .
The lowest NETCONF layer is the secure transport layer, and the
mandatory-to-implement secure transport is Secure Shell (SSH) . The lowest RESTCONF layer is HTTPS, and the
mandatory-to-implement secure transport is TLS .
The Network Configuration Access Control Model (NACM)
provides the means to restrict access for particular NETCONF or RESTCONF users
to a preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.
Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus important to
control read access (e.g., via get, get-config, or notification) to these data
nodes. These are the subtrees and data nodes and their
sensitivity/vulnerability:
The "/yang&nbhy;library" subtree of the YANG library may help an attacker
identify the server capabilities and server implementations with known
bugs since the set of YANG modules supported by a server may reveal
the kind of device and the manufacturer of the device. Although some
of this information may be available to all NETCONF users via the
NETCONF <hello> message (or similar messages in other management
protocols), this YANG module potentially exposes additional details
that could be of some assistance to an attacker. Server
vulnerabilities may be specific to particular modules, module
revisions, module features, or even module deviations. For example, if
a particular operation on a particular data node is known to cause a
server to crash or significantly degrade device performance, then the
"module" list information will help an attacker identify server
implementations with such a defect, in order to launch a
denial-of-service attack on the device.
NETCONF Extensions to Support the Network Management Datastore ArchitectureYANG Schema Mount
This document changes in the following ways:
Renamed document title from "YANG Module Library" to "YANG Library".
Added a new top-level "/yang&nbhy;library" container to hold the entire
YANG library providing information about module sets, schemas, and
datastores.
Refactored the "/modules&nbhy;state" container into a new
"/yang&nbhy;library/module&nbhy;set" list.
Added a new "/yang&nbhy;library/schema" list and a new
"/yang&nbhy;library/datastore" list.
Added a set of new groupings as replacements for the deprecated
groupings.
Added a "yang&nbhy;library&nbhy;update" notification as a replacement for the
deprecated "yang&nbhy;library&nbhy;change" notification.
Deprecated the "/modules&nbhy;state" tree.
Deprecated the "/module&nbhy;list" grouping.
Deprecated the "/yang&nbhy;library&nbhy;change" notification.
The following example shows the YANG library of a basic server
implementing the "ietf&nbhy;interfaces" and
"ietf&nbhy;ip" modules in the <running>,
<startup>, and <operational> datastores and the "ietf&nbhy;hardware"
module in the <operational> datastore.
Newline characters in leaf values are added for formatting reasons.
The following example extends the example in
by using modules from and to illustrate
a slightly more advanced server that:
Has a module with features only enabled in <operational>; the
"ietf-routing module" is supported in <running>, <startup>, and
<operational>, but the "multiple&nbhy;ribs" and "router&nbhy;id" features are
only enabled in <operational>. Hence, the "router&nbhy;id" leaf may be
read but not configured.
Supports a dynamic configuration datastore
"example&nbhy;ds&nbhy;ephemeral", with only the "ietf&nbhy;network" and
"ietf&nbhy;network&nbhy;topology" modules configurable via a notional dynamic
configuration protocol.
Shows an example of datastore-specific deviations. The
"example&nbhy;vendor&nbhy;hardware&nbhy;deviations" module is included in
the schema for <operational> to remove data nodes that cannot be
supported by the server.
Shows how module-sets can be used to organize related modules together.
Contributions to this material by Andy Bierman are based upon work
supported by the The Space & Terrestrial Communications Directorate
(S&TCD) under Contract No. W15P7T-13-C-A616. Any opinions, findings,
conclusions, or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect the views of
The Space & Terrestrial Communications Directorate (S&TCD).