rfc8525.original | rfc8525.txt | |||
---|---|---|---|---|
Network Working Group A. Bierman | Internet Engineering Task Force (IETF) A. Bierman | |||
Internet-Draft YumaWorks | Request for Comments: 8525 YumaWorks | |||
Obsoletes: 7895 (if approved) M. Bjorklund | Obsoletes: 7895 M. Bjorklund | |||
Intended status: Standards Track Tail-f Systems | Category: Standards Track Tail-f Systems | |||
Expires: April 20, 2019 J. Schoenwaelder | ISSN: 2070-1721 J. Schoenwaelder | |||
Jacobs University | Jacobs University | |||
K. Watsen | K. Watsen | |||
Juniper Networks | Juniper Networks | |||
R. Wilton | R. Wilton | |||
Cisco Systems | Cisco Systems | |||
October 17, 2018 | January 2019 | |||
YANG Library | YANG Library | |||
draft-ietf-netconf-rfc7895bis-07 | ||||
Abstract | Abstract | |||
This document describes a YANG library that provides information | This document describes a YANG library that provides information | |||
about the YANG modules, datastores, and datastore schemas used by a | about the YANG modules, datastores, and datastore schemas used by a | |||
network management server. Simple caching mechanisms are provided to | network management server. Simple caching mechanisms are provided to | |||
allow clients to minimize retrieval of this information. This | allow clients to minimize retrieval of this information. This | |||
version of the YANG library supports the Network Management Datastore | version of the YANG library supports the Network Management Datastore | |||
Architecture by listing all datastores supported by a network | Architecture (NMDA) by listing all datastores supported by a network | |||
management server and the schema that is used by each of these | management server and the schema that is used by each of these | |||
datastores. | datastores. | |||
This document obsoletes RFC 7895. | This document obsoletes RFC 7895. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This is an Internet Standards Track document. | |||
provisions of BCP 78 and BCP 79. | ||||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF). Note that other groups may also distribute | ||||
working documents as Internet-Drafts. The list of current Internet- | ||||
Drafts is at http://datatracker.ietf.org/drafts/current/. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | This document is a product of the Internet Engineering Task Force | |||
and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Further information on | |||
Internet Standards is available in Section 2 of RFC 7841. | ||||
This Internet-Draft will expire on April 20, 2019. | Information about the current status of this document, any errata, | |||
and how to provide feedback on it may be obtained at | ||||
https://www.rfc-editor.org/info/rfc8525. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2019 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. YANG Library Data Model . . . . . . . . . . . . . . . . . . . 5 | 3. YANG Library Data Model . . . . . . . . . . . . . . . . . . . 5 | |||
4. YANG Library YANG Module . . . . . . . . . . . . . . . . . . 8 | 4. YANG Library YANG Module . . . . . . . . . . . . . . . . . . 8 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 | |||
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 | 7.1. Normative References . . . . . . . . . . . . . . . . . . 21 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . 22 | 7.2. Informative References . . . . . . . . . . . . . . . . . 22 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . 23 | Appendix A. Summary of Changes from RFC 7895 . . . . . . . . . . 23 | |||
Appendix A. Summary of Changes from RFC 7895 . . . . . . . . . . 24 | Appendix B. Example YANG Library Instance for a Basic Server . . 24 | |||
Appendix B. Example YANG Library Instance for a Basic Server . . 25 | Appendix C. Example YANG Library Instance for an Advanced Server 26 | |||
Appendix C. Example YANG Library Instance for an Advanced Server 27 | Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
1. Introduction | 1. Introduction | |||
There is a need for a standard mechanism to expose which YANG modules | There is a need for a standard mechanism to expose which YANG modules | |||
[RFC7950], datastores and datastore schemas [RFC8342] are in use by a | [RFC7950], datastores [RFC8342], and datastore schemas [RFC8342] are | |||
network management server. | in use by a network management server. | |||
This document defines the YANG module "ietf-yang-library" that | This document defines the YANG module "ietf-yang-library" that | |||
provides this information. This version of the YANG library is | provides this information. This version of the YANG library is | |||
compatible with the Network Management Datastore Architecture (NMDA) | compatible with the Network Management Datastore Architecture (NMDA) | |||
[RFC8342]. The previous version of the YANG library, defined in | [RFC8342]. The previous version of the YANG library, defined in | |||
[RFC7895], is not compatible with the NMDA since it assumes that all | [RFC7895], is not compatible with the NMDA since it assumes that all | |||
datastores have exactly the same schema. This is not necessarily | datastores have exactly the same schema. This is not necessarily | |||
true in the NMDA since dynamic configuration datastores may have | true in the NMDA since dynamic configuration datastores may have | |||
their own datastore schema. Furthermore, the operational state | their own datastore schema. Furthermore, the operational state | |||
datastore may support non-configurable YANG modules in addition to | datastore may support non-configurable YANG modules in addition to | |||
the YANG modules supported by conventional configuration datastores. | the YANG modules supported by conventional configuration datastores. | |||
The old YANG library definitions have been retained (for backwards | The old YANG library definitions have been retained (for backwards- | |||
compatibility reasons) but the definitions have been marked as | compatibility reasons), but the definitions have been marked as | |||
deprecated. For backwards compatibility, an NMDA-supporting server | deprecated. For backwards compatibility, an NMDA-supporting server | |||
SHOULD populate the deprecated "/modules-state" tree in a backwards- | SHOULD populate the deprecated "/modules-state" tree in a backwards- | |||
compatible manner. The new "/yang-library" tree would be ignored by | compatible manner. The new "/yang-library" tree will be ignored by | |||
legacy clients, while providing all the data needed for NMDA-aware | legacy clients but will provide all the data needed for NMDA-aware | |||
clients, which would themselves ignore the "/modules-state" tree. | clients (which will ignore the "/modules-state" tree). The | |||
The recommended approach to populate "/modules-state" is to report | recommended approach to populate "/modules-state" is to report the | |||
the schema for YANG modules that are configurable via conventional | schema for YANG modules that are configurable via conventional | |||
configuration datastores and for which config false data nodes are | configuration datastores and for which "config false" data nodes are | |||
returned via a NETCONF <get> operation, or equivalent. | returned via a Network Configuration Protocol (NETCONF) <get> | |||
operation or the equivalent. | ||||
The YANG library information can be different on every server and it | The YANG library information can be different on every server, and it | |||
can change at runtime or across a server reboot. If a server | can change at runtime or across a server reboot. If a server | |||
implements multiple network management protocols to access the | implements multiple network management protocols to access the | |||
server's datastores, then each such protocol may have its own | server's datastores, then each such protocol may have its own | |||
conceptual instantiation of the YANG library. | conceptual instantiation of the YANG library. | |||
If a large number of YANG modules are utilized by a server, then the | If a large number of YANG modules are utilized by a server, then the | |||
YANG library contents can be relatively large. Since the YANG | YANG library contents can be relatively large. Since the YANG | |||
library contents changes very infrequently, it is important that | library contents change very infrequently, it is important that | |||
clients be able to cache the YANG library contents and easily | clients be able to cache the YANG library contents and easily | |||
identify whether their cache is out of date. | identify whether their cache is out of date. | |||
1.1. Terminology | 1.1. Terminology | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
The following terms are defined in [RFC7950]: | The following terms are defined in [RFC7950]: | |||
o module | o module | |||
o submodule | o submodule | |||
o data node | o data node | |||
This document uses the phrase "implementing a module" as defined in | This document uses the phrase "implement a module" as defined in | |||
[RFC7950] Section 5.6.5. | Section 5.6.5 of [RFC7950]. | |||
The following terms are defined in [RFC8342]: | The following terms are defined in [RFC8342]: | |||
o datastore | o datastore | |||
o datastore schema | o datastore schema | |||
o configuration | o configuration | |||
o configuration datastore | o configuration datastore | |||
o conventional configuration | o conventional configuration | |||
o conventional configuration datastore | o conventional configuration datastore | |||
o operational state | o operational state | |||
o operational state datastore | o operational state datastore | |||
skipping to change at page 4, line 23 ¶ | skipping to change at page 4, line 16 ¶ | |||
o conventional configuration | o conventional configuration | |||
o conventional configuration datastore | o conventional configuration datastore | |||
o operational state | o operational state | |||
o operational state datastore | o operational state datastore | |||
o dynamic configuration datastore | o dynamic configuration datastore | |||
o client and server | o client | |||
o server | ||||
The following terms are used within this document: | The following terms are used within this document: | |||
o YANG library: A collection of YANG modules, submodules, | o YANG library: A collection of YANG modules, submodules, | |||
datastores, and datastore schemas used by a server. | datastores, and datastore schemas used by a server. | |||
o YANG library content identifier: A server-generated identifier of | o YANG library content identifier: A server-generated identifier of | |||
the contents of the YANG library. | the contents of the YANG library. | |||
Tree diagrams used in this document use the notation defined in | Tree diagrams in this document use the notation defined in [RFC8340]. | |||
[RFC8340]. | ||||
2. Objectives | 2. Objectives | |||
The following information is needed by a client application (for each | The following information is needed by a client application (for each | |||
YANG module in the library) to fully utilize the YANG data modeling | YANG module in the library) to fully utilize the YANG data modeling | |||
language: | language: | |||
o name: The name of the YANG module. | o name: The name of the YANG module. | |||
o revision: If defined in the YANG module or submodule, the revision | o revision: If defined in the YANG module or submodule, the revision | |||
is derived from the most recent revision statement within the | is derived from the most recent revision statement within the | |||
module or submodule. | module or submodule. | |||
o submodule list: The name, and if defined, revision of each | o submodule list: The name and (if defined) revision of each | |||
submodule used by the module must be identified. | submodule used by the module must be identified. | |||
o feature list: The name of each YANG feature supported by the | o feature list: The name of each YANG feature supported by the | |||
server, in a given datastore schema, must be identified. | server, in a given datastore schema, must be identified. | |||
o deviation list: The name of each YANG module with deviation | o deviation list: The name of each YANG module with deviation | |||
statements affecting a given YANG module, in a given datastore | statements affecting a given YANG module, in a given datastore | |||
schema, must be identified. | schema, must be identified. | |||
In addition, the following information is needed by a client | In addition, the following information is needed by a client | |||
application for each datastore supported by a server: | application for each datastore supported by a server: | |||
o identity: The YANG identity for the datastore. | o identity: The YANG identity for the datastore. | |||
o schema: The schema (i.e., the set of modules) implemented by the | o schema: The schema (i.e., the set of modules) implemented by the | |||
datastore. | datastore. | |||
In order to select one out of several possible data model designs, | In order to select one out of several possible designs for data | |||
the following criteria were used: | models, the following criteria were used: | |||
1. The information must be efficient for a client to consume. Since | 1. The information must be efficient for a client to consume. Since | |||
the size of the YANG library can be quite large, it should be | the size of the YANG library can be quite large, it should be | |||
possible for clients to cache the YANG library information. | possible for clients to cache the YANG library information. | |||
2. A dynamic configuration datastore must be able to implement a | 2. A dynamic configuration datastore must be able to implement a | |||
module or feature that is not implemented in the conventional | module or feature that is not implemented in the conventional | |||
configuration datastores. | configuration datastores. | |||
3. It must be possible to not implement a module or feature in | 3. It must be possible to not implement a module or feature in | |||
skipping to change at page 5, line 43 ¶ | skipping to change at page 5, line 39 ¶ | |||
4. A given module can only be implemented in one revision in all | 4. A given module can only be implemented in one revision in all | |||
datastores. If a module is implemented in more than one | datastores. If a module is implemented in more than one | |||
datastore, the same revision is implemented in all these | datastore, the same revision is implemented in all these | |||
datastores. | datastores. | |||
5. Multiple revisions can be used for import, if import-by revision | 5. Multiple revisions can be used for import, if import-by revision | |||
is used. | is used. | |||
6. It must be possible to use the YANG library by schema mount | 6. It must be possible to use the YANG library by schema mount | |||
[I-D.ietf-netmod-schema-mount]. | [RFC8528]. | |||
3. YANG Library Data Model | 3. YANG Library Data Model | |||
The "ietf-yang-library" YANG module provides information about the | The "ietf-yang-library" YANG module provides information about the | |||
modules, submodules, datastores, and datastore schemas supported by a | modules, submodules, datastores, and datastore schemas supported by a | |||
server. All data nodes in "ietf-yang-library" are "config false", | server. All data nodes in the "ietf-yang-library" module are "config | |||
and thus only accessible in the operational state datastore. | false" and thus only accessible in the operational state datastore. | |||
+-----------+ | +-----------+ | |||
| datastore | | | datastore | | |||
+-----------+ | +-----------+ | |||
| | | | |||
| has a | | has a | |||
V | V | |||
+-----------+ +--------+ +------------+ | +-----------+ +--------+ +------------+ | |||
| datastore | union of | module | consists of | modules + | | | datastore | union of | module | consists of | modules + | | |||
| schema |----------->| set |--------------->| submodules | | | schema |----------->| set |--------------->| submodules | | |||
+-----------+ +--------+ +------------+ | +-----------+ +--------+ +------------+ | |||
Figure 1 | Figure 1 | |||
The conceptual model of the YANG library is depicted in Figure 1. | The conceptual model of the YANG library is depicted in Figure 1. | |||
Following the NMDA, every datastore has an associated datastore | Following the NMDA, every datastore has an associated datastore | |||
schema. A datastore schema is a union of module sets and every | schema. A datastore schema is a union of module sets, and every | |||
module set is a collection of modules and submodules, including the | module set is a collection of modules and submodules, including the | |||
modules and submodules used for imports. Note that multiple | modules and submodules used for imports. Note that multiple | |||
datastores may refer to the same datastore schema. Furthermore, it | datastores may refer to the same datastore schema. Furthermore, it | |||
is possible that individual datastore schemas share module sets. A | is possible for individual datastore schemas to share module sets. A | |||
common use case is the operational state datastore schema which is a | common use case is the operational state datastore schema, which is a | |||
superset of the schema used by conventional configuration datastores. | superset of the schema used by conventional configuration datastores. | |||
Below is the YANG Tree Diagram for the "ietf-yang-library" module, | Below is the YANG tree diagram for the "ietf-yang-library" module, | |||
excluding the deprecated "modules-state" tree: | excluding the deprecated "modules-state" tree: | |||
module: ietf-yang-library | module: ietf-yang-library | |||
+--ro yang-library | +--ro yang-library | |||
+--ro module-set* [name] | +--ro module-set* [name] | |||
| +--ro name string | | +--ro name string | |||
| +--ro module* [name] | | +--ro module* [name] | |||
| | +--ro name yang:yang-identifier | | | +--ro name yang:yang-identifier | |||
| | +--ro revision? revision-identifier | | | +--ro revision? revision-identifier | |||
| | +--ro namespace inet:uri | | | +--ro namespace inet:uri | |||
skipping to change at page 8, line 11 ¶ | skipping to change at page 8, line 11 ¶ | |||
import-only-module" lists all modules (and their submodules) used | import-only-module" lists all modules (and their submodules) used | |||
only for imports. The assignment of a module to a module-set is | only for imports. The assignment of a module to a module-set is | |||
at the server's discretion. This revision of the YANG library | at the server's discretion. This revision of the YANG library | |||
attaches no semantics as to which module-set a module is listed | attaches no semantics as to which module-set a module is listed | |||
in. | in. | |||
o The "/yang-library/schema" list contains an entry for each | o The "/yang-library/schema" list contains an entry for each | |||
datastore schema supported by the server. All conventional | datastore schema supported by the server. All conventional | |||
configuration datastores use the same "schema" list entry. A | configuration datastores use the same "schema" list entry. A | |||
dynamic configuration datastore may use a different datastore | dynamic configuration datastore may use a different datastore | |||
schema from the conventional configuration datastores, and hence | schema from the conventional configuration datastores and hence | |||
may require a separate "schema" entry. A "schema" entry has a | may require a separate "schema" entry. A "schema" entry has a | |||
leaf-list of references to entries in the "module-set" list. The | leaf-list of references to entries in the "module-set" list. The | |||
schema consists of the union of all modules in all referenced | schema consists of the union of all modules in all referenced | |||
module sets. | module sets. | |||
o The "/yang-library/datastore" list contains one entry for each | o The "/yang-library/datastore" list contains one entry for each | |||
datastore supported by the server, and it identifies the datastore | datastore supported by the server, and it identifies the datastore | |||
schema associated with a datastore via a reference to an entry in | schema associated with a datastore via a reference to an entry in | |||
the "schema" list. Each supported conventional configuration | the "schema" list. Each supported conventional configuration | |||
datastore has a separate entry, pointing to the same "schema" list | datastore has a separate entry, pointing to the same "schema" list | |||
element. | element. | |||
o The "/yang-library/content-id" leaf contains the YANG library | o The "/yang-library/content-id" leaf contains the YANG library | |||
content identifier, which is an implementation-specific identifier | content identifier, which is an implementation-specific identifier | |||
representing the current information in the YANG library on a | representing the current information in the YANG library on a | |||
specific server. The value of this leaf MUST change whenever the | specific server. The value of this leaf MUST change whenever the | |||
information in the YANG library changes. There is no requirement | information in the YANG library changes. There is no requirement | |||
that the same information always results in the same "content-id" | that the same information always result in the same "content-id" | |||
value. This leaf allows a client to fetch all schema information | 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 | 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 | been changed. If the value of this leaf changes, the server also | |||
generates a "yang-library-update" notification. | generates a "yang-library-update" notification. | |||
Note that for a NETCONF server implementing the NETCONF extensions to | Note that for a NETCONF server implementing the NETCONF extensions to | |||
support the NMDA [I-D.ietf-netconf-nmda-netconf], a change of the | support the NMDA [RFC8526], a change of the YANG library content | |||
YANG library content identifier results in a new value for the :yang- | identifier results in a new value for the :yang-library:1.1 | |||
library:1.1 capability defined in [I-D.ietf-netconf-nmda-netconf]. | capability defined in [RFC8526]. Thus, if such a server implements | |||
Thus, if such a server implements NETCONF notifications [RFC5277], | NETCONF notifications [RFC5277] and the "netconf-capability-change" | |||
and the notification "netconf-capability-change" [RFC6470], a | notification [RFC6470], a "netconf-capability-change" notification is | |||
"netconf-capability-change" notification is generated whenever the | generated whenever the YANG library content identifier changes. | |||
YANG library content identifier changes. | ||||
4. YANG Library YANG Module | 4. YANG Library YANG Module | |||
The "ietf-yang-library" YANG module imports definitions from | The "ietf-yang-library" YANG module imports definitions from the | |||
"ietf-yang-types" and "ietf-inet-types" defined in [RFC6991] and from | "ietf-yang-types" and "ietf-inet-types" modules defined in [RFC6991] | |||
"ietf-datastores" defined in [RFC8342]. While the YANG module is | and from the "ietf-datastores" module defined in [RFC8342]. While | |||
defined using YANG version 1.1, the YANG library supports the YANG | the YANG module is defined using YANG version 1.1, the YANG library | |||
modules written in any version of YANG. | supports the YANG modules written in any version of YANG. | |||
RFC Ed.: update the date below with the date of RFC publication and | ||||
remove this note. | ||||
<CODE BEGINS> file "ietf-yang-library@2018-10-16.yang" | ||||
<CODE BEGINS> file "ietf-yang-library@2019-01-04.yang" | ||||
module ietf-yang-library { | module ietf-yang-library { | |||
yang-version 1.1; | yang-version 1.1; | |||
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-library"; | namespace "urn:ietf:params:xml:ns:yang:ietf-yang-library"; | |||
prefix "yanglib"; | prefix yanglib; | |||
import ietf-yang-types { | import ietf-yang-types { | |||
prefix yang; | prefix yang; | |||
reference "RFC 6991: Common YANG Data Types."; | reference | |||
"RFC 6991: Common YANG Data Types"; | ||||
} | } | |||
import ietf-inet-types { | import ietf-inet-types { | |||
prefix inet; | prefix inet; | |||
reference "RFC 6991: Common YANG Data Types."; | reference | |||
"RFC 6991: Common YANG Data Types"; | ||||
} | } | |||
import ietf-datastores { | import ietf-datastores { | |||
prefix ds; | prefix ds; | |||
reference "RFC 8342: Network Management Datastore Architecture."; | reference | |||
"RFC 8342: Network Management Datastore Architecture | ||||
(NMDA)"; | ||||
} | } | |||
organization | organization | |||
"IETF NETCONF (Network Configuration) Working Group"; | "IETF NETCONF (Network Configuration) Working Group"; | |||
contact | contact | |||
"WG Web: <http://tools.ietf.org/wg/netconf/> | "WG Web: <https://datatracker.ietf.org/wg/netconf/> | |||
WG List: <mailto:netconf@ietf.org> | WG List: <mailto:netconf@ietf.org> | |||
Author: Andy Bierman | Author: Andy Bierman | |||
<mailto:andy@yumaworks.com> | <mailto:andy@yumaworks.com> | |||
Author: Martin Bjorklund | Author: Martin Bjorklund | |||
<mailto:mbj@tail-f.com> | <mailto:mbj@tail-f.com> | |||
Author: Juergen Schoenwaelder | Author: Juergen Schoenwaelder | |||
<mailto:j.schoenwaelder@jacobs-university.de> | <mailto:j.schoenwaelder@jacobs-university.de> | |||
skipping to change at page 9, line 49 ¶ | skipping to change at page 9, line 46 ¶ | |||
<mailto:mbj@tail-f.com> | <mailto:mbj@tail-f.com> | |||
Author: Juergen Schoenwaelder | Author: Juergen Schoenwaelder | |||
<mailto:j.schoenwaelder@jacobs-university.de> | <mailto:j.schoenwaelder@jacobs-university.de> | |||
Author: Kent Watsen | Author: Kent Watsen | |||
<mailto:kwatsen@juniper.net> | <mailto:kwatsen@juniper.net> | |||
Author: Rob Wilton | Author: Rob Wilton | |||
<mailto:rwilton@cisco.com>"; | <mailto:rwilton@cisco.com>"; | |||
description | description | |||
"This module provides information about the YANG modules, | "This module provides information about the YANG modules, | |||
datastores, and datastore schemas used by a network | datastores, and datastore schemas used by a network | |||
management server. | management server. | |||
Copyright (c) 2018 IETF Trust and the persons identified as | Copyright (c) 2019 IETF Trust and the persons identified as | |||
authors of the code. All rights reserved. | authors of the code. All rights reserved. | |||
Redistribution and use in source and binary forms, with or | Redistribution and use in source and binary forms, with or | |||
without modification, is permitted pursuant to, and subject | without modification, is permitted pursuant to, and subject | |||
to the license terms contained in, the Simplified BSD License | to the license terms contained in, the Simplified BSD License | |||
set forth in Section 4.c of the IETF Trust's Legal Provisions | set forth in Section 4.c of the IETF Trust's Legal Provisions | |||
Relating to IETF Documents | Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info). | (https://trustee.ietf.org/license-info). | |||
This version of this YANG module is part of RFC XXXX; see | This version of this YANG module is part of RFC 8525; see | |||
the RFC itself for full legal notices."; | the RFC itself for full legal notices."; | |||
// RFC Ed.: update the date below with the date of RFC publication | revision 2019-01-04 { | |||
// and remove this note. | ||||
// RFC Ed.: replace XXXX with actual RFC number and remove this | ||||
// note. | ||||
revision 2018-10-16 { | ||||
description | description | |||
"Added support for multiple datastores according to the | "Added support for multiple datastores according to the | |||
Network Management Datastore Architecture (NMDA)."; | Network Management Datastore Architecture (NMDA)."; | |||
reference | reference | |||
"RFC XXXX: YANG Library."; | "RFC 8525: YANG Library"; | |||
} | } | |||
revision 2016-04-09 { | revision 2016-04-09 { | |||
description | description | |||
"Initial revision."; | "Initial revision."; | |||
reference | reference | |||
"RFC 7895: YANG Module Library."; | "RFC 7895: YANG Module Library"; | |||
} | } | |||
/* | /* | |||
* Typedefs | * Typedefs | |||
*/ | */ | |||
typedef revision-identifier { | typedef revision-identifier { | |||
type string { | type string { | |||
pattern '\d{4}-\d{2}-\d{2}'; | pattern '\d{4}-\d{2}-\d{2}'; | |||
} | } | |||
skipping to change at page 12, line 25 ¶ | skipping to change at page 12, line 17 ¶ | |||
Robust clients may want to make sure that they handle a | Robust clients may want to make sure that they handle a | |||
situation where a module deviates itself (directly or | situation where a module deviates itself (directly or | |||
indirectly) gracefully."; | indirectly) gracefully."; | |||
} | } | |||
} | } | |||
grouping module-set-parameters { | grouping module-set-parameters { | |||
description | description | |||
"A set of parameters that describe a module set."; | "A set of parameters that describe a module set."; | |||
leaf name { | leaf name { | |||
type string; | type string; | |||
description | description | |||
"An arbitrary name of the module set."; | "An arbitrary name of the module set."; | |||
} | } | |||
list module { | list module { | |||
key "name"; | key "name"; | |||
description | description | |||
"An entry in this list represents a module implemented by the | "An entry in this list represents a module implemented by the | |||
server, as per RFC 7950 section 5.6.5, with a particular set | server, as per Section 5.6.5 of RFC 7950, with a particular | |||
of supported features and deviations."; | set of supported features and deviations."; | |||
reference | reference | |||
"RFC 7950: The YANG 1.1 Data Modeling Language."; | "RFC 7950: The YANG 1.1 Data Modeling Language"; | |||
uses module-identification-leafs; | uses module-identification-leafs; | |||
leaf namespace { | leaf namespace { | |||
type inet:uri; | type inet:uri; | |||
mandatory true; | mandatory true; | |||
description | description | |||
"The XML namespace identifier for this module."; | "The XML namespace identifier for this module."; | |||
} | } | |||
uses location-leaf-list; | uses location-leaf-list; | |||
list submodule { | list submodule { | |||
key "name"; | key "name"; | |||
description | description | |||
"Each entry represents one submodule within the | "Each entry represents one submodule within the | |||
parent module."; | parent module."; | |||
uses module-identification-leafs; | uses module-identification-leafs; | |||
uses location-leaf-list; | uses location-leaf-list; | |||
} | } | |||
uses module-implementation-parameters; | uses module-implementation-parameters; | |||
} | } | |||
list import-only-module { | list import-only-module { | |||
key "name revision"; | key "name revision"; | |||
description | description | |||
"An entry in this list indicates that the server imports | "An entry in this list indicates that the server imports | |||
reusable definitions from the specified revision of the | reusable definitions from the specified revision of the | |||
module, but does not implement any protocol accessible | module but does not implement any protocol-accessible | |||
objects from this revision. | objects from this revision. | |||
Multiple entries for the same module name MAY exist. This | Multiple entries for the same module name MAY exist. This | |||
can occur if multiple modules import the same module, but | can occur if multiple modules import the same module but | |||
specify different revision-dates in the import statements."; | specify different revision dates in the import statements."; | |||
leaf name { | leaf name { | |||
type yang:yang-identifier; | type yang:yang-identifier; | |||
description | description | |||
"The YANG module name."; | "The YANG module name."; | |||
} | } | |||
leaf revision { | leaf revision { | |||
type union { | type union { | |||
type revision-identifier; | type revision-identifier; | |||
type string { | type string { | |||
length 0; | length "0"; | |||
} | } | |||
} | } | |||
description | description | |||
"The YANG module revision date. | "The YANG module revision date. | |||
A zero-length string is used if no revision statement | A zero-length string is used if no revision statement | |||
is present in the YANG module."; | is present in the YANG module."; | |||
} | } | |||
leaf namespace { | leaf namespace { | |||
type inet:uri; | type inet:uri; | |||
mandatory true; | mandatory true; | |||
skipping to change at page 14, line 21 ¶ | skipping to change at page 13, line 50 ¶ | |||
uses location-leaf-list; | uses location-leaf-list; | |||
} | } | |||
} | } | |||
} | } | |||
grouping yang-library-parameters { | grouping yang-library-parameters { | |||
description | description | |||
"The YANG library data structure is represented as a grouping | "The YANG library data structure is represented as a grouping | |||
so it can be reused in configuration or another monitoring | so it can be reused in configuration or another monitoring | |||
data structure."; | data structure."; | |||
list module-set { | list module-set { | |||
key name; | key "name"; | |||
description | description | |||
"A set of modules that may be used by one or more schemas. | "A set of modules that may be used by one or more schemas. | |||
A module set does not have to be referentially complete, | A module set does not have to be referentially complete, | |||
i.e., it may define modules that contain import statements | i.e., it may define modules that contain import statements | |||
for other modules not included in the module set."; | for other modules not included in the module set."; | |||
uses module-set-parameters; | uses module-set-parameters; | |||
} | } | |||
list schema { | list schema { | |||
key "name"; | key "name"; | |||
description | description | |||
"A datastore schema that may be used by one or more | "A datastore schema that may be used by one or more | |||
datastores. | datastores. | |||
The schema must be valid and referentially complete, i.e., | The schema must be valid and referentially complete, i.e., | |||
it must contain modules to satisfy all used import | it must contain modules to satisfy all used import | |||
statements for all modules specified in the schema."; | statements for all modules specified in the schema."; | |||
leaf name { | leaf name { | |||
type string; | type string; | |||
description | description | |||
"An arbitrary name of the schema."; | "An arbitrary name of the schema."; | |||
} | } | |||
leaf-list module-set { | leaf-list module-set { | |||
type leafref { | type leafref { | |||
path "../../module-set/name"; | path "../../module-set/name"; | |||
} | } | |||
description | description | |||
"A set of module-sets that are included in this schema. | "A set of module-sets that are included in this schema. | |||
If a non import-only module appears in multiple module | If a non-import-only module appears in multiple module | |||
sets, then the module revision and the associated features | sets, then the module revision and the associated features | |||
and deviations must be identical."; | and deviations must be identical."; | |||
} | } | |||
} | } | |||
list datastore { | list datastore { | |||
key "name"; | key "name"; | |||
description | description | |||
"A datastore supported by this server. | "A datastore supported by this server. | |||
Each datastore indicates which schema it supports. | Each datastore indicates which schema it supports. | |||
The server MUST instantiate one entry in this list per | The server MUST instantiate one entry in this list per | |||
specific datastore it supports. | specific datastore it supports. | |||
skipping to change at page 15, line 24 ¶ | skipping to change at page 14, line 47 ¶ | |||
list datastore { | list datastore { | |||
key "name"; | key "name"; | |||
description | description | |||
"A datastore supported by this server. | "A datastore supported by this server. | |||
Each datastore indicates which schema it supports. | Each datastore indicates which schema it supports. | |||
The server MUST instantiate one entry in this list per | The server MUST instantiate one entry in this list per | |||
specific datastore it supports. | specific datastore it supports. | |||
Each datstore entry with the same datastore schema SHOULD | Each datastore entry with the same datastore schema SHOULD | |||
reference the same schema."; | reference the same schema."; | |||
leaf name { | leaf name { | |||
type ds:datastore-ref; | type ds:datastore-ref; | |||
description | description | |||
"The identity of the datastore."; | "The identity of the datastore."; | |||
} | } | |||
leaf schema { | leaf schema { | |||
type leafref { | type leafref { | |||
path "../../schema/name"; | path "../../schema/name"; | |||
} | } | |||
mandatory true; | mandatory true; | |||
skipping to change at page 15, line 39 ¶ | skipping to change at page 15, line 13 ¶ | |||
description | description | |||
"The identity of the datastore."; | "The identity of the datastore."; | |||
} | } | |||
leaf schema { | leaf schema { | |||
type leafref { | type leafref { | |||
path "../../schema/name"; | path "../../schema/name"; | |||
} | } | |||
mandatory true; | mandatory true; | |||
description | description | |||
"A reference to the schema supported by this datastore. | "A reference to the schema supported by this datastore. | |||
All non import-only modules of the schema are implemented | All non-import-only modules of the schema are implemented | |||
with their associated features and deviations."; | with their associated features and deviations."; | |||
} | } | |||
} | } | |||
} | } | |||
/* | /* | |||
* Top-level container | * Top-level container | |||
*/ | */ | |||
container yang-library { | container yang-library { | |||
skipping to change at page 17, line 16 ¶ | skipping to change at page 16, line 36 ¶ | |||
leaf name { | leaf name { | |||
type yang:yang-identifier; | type yang:yang-identifier; | |||
status deprecated; | status deprecated; | |||
description | description | |||
"The YANG module or submodule name."; | "The YANG module or submodule name."; | |||
} | } | |||
leaf revision { | leaf revision { | |||
type union { | type union { | |||
type revision-identifier; | type revision-identifier; | |||
type string { | type string { | |||
length 0; | length "0"; | |||
} | } | |||
} | } | |||
status deprecated; | status deprecated; | |||
description | description | |||
"The YANG module or submodule revision date. | "The YANG module or submodule revision date. | |||
A zero-length string is used if no revision statement | A zero-length string is used if no revision statement | |||
is present in the YANG module or submodule."; | is present in the YANG module or submodule."; | |||
} | } | |||
} | } | |||
grouping schema-leaf { | grouping schema-leaf { | |||
status deprecated; | status deprecated; | |||
description | description | |||
"Common schema leaf parameter for modules and submodules."; | "Common schema leaf parameter for modules and submodules."; | |||
leaf schema { | leaf schema { | |||
type inet:uri; | type inet:uri; | |||
description | description | |||
"Contains a URL that represents the YANG schema | "Contains a URL that represents the YANG schema | |||
resource for this module or submodule. | resource for this module or submodule. | |||
skipping to change at page 18, line 19 ¶ | skipping to change at page 17, line 37 ¶ | |||
mandatory true; | mandatory true; | |||
status deprecated; | status deprecated; | |||
description | description | |||
"The XML namespace identifier for this module."; | "The XML namespace identifier for this module."; | |||
} | } | |||
leaf-list feature { | leaf-list feature { | |||
type yang:yang-identifier; | type yang:yang-identifier; | |||
status deprecated; | status deprecated; | |||
description | description | |||
"List of YANG feature names from this module that are | "List of YANG feature names from this module that are | |||
supported by the server, regardless whether they are | supported by the server, regardless of whether they are | |||
defined in the module or any included submodule."; | defined in the module or any included submodule."; | |||
} | } | |||
list deviation { | list deviation { | |||
key "name revision"; | key "name revision"; | |||
status deprecated; | status deprecated; | |||
description | description | |||
"List of YANG deviation module names and revisions | "List of YANG deviation module names and revisions | |||
used by this server to modify the conformance of | used by this server to modify the conformance of | |||
the module associated with this entry. Note that | the module associated with this entry. Note that | |||
the same module can be used for deviations for | the same module can be used for deviations for | |||
skipping to change at page 19, line 13 ¶ | skipping to change at page 18, line 31 ¶ | |||
module entry with conformance type 'implement' for a | module entry with conformance type 'implement' for a | |||
particular module name, since YANG 1.1 requires that | particular module name, since YANG 1.1 requires that | |||
at most one revision of a module is implemented. | at most one revision of a module is implemented. | |||
For YANG version 1 modules, there SHOULD NOT be more | For YANG version 1 modules, there SHOULD NOT be more | |||
than one module entry for a particular module name."; | than one module entry for a particular module name."; | |||
} | } | |||
enum import { | enum import { | |||
description | description | |||
"Indicates that the server imports reusable definitions | "Indicates that the server imports reusable definitions | |||
from the specified revision of the module, but does | from the specified revision of the module but does | |||
not implement any protocol accessible objects from | not implement any protocol-accessible objects from | |||
this revision. | this revision. | |||
Multiple module entries for the same module name MAY | Multiple module entries for the same module name MAY | |||
exist. This can occur if multiple modules import the | exist. This can occur if multiple modules import the | |||
same module, but specify different revision-dates in | same module but specify different revision dates in | |||
the import statements."; | the import statements."; | |||
} | } | |||
} | } | |||
mandatory true; | mandatory true; | |||
status deprecated; | status deprecated; | |||
description | description | |||
"Indicates the type of conformance the server is claiming | "Indicates the type of conformance the server is claiming | |||
for the YANG module identified by this entry."; | for the YANG module identified by this entry."; | |||
} | } | |||
list submodule { | list submodule { | |||
skipping to change at page 20, line 36 ¶ | skipping to change at page 20, line 4 ¶ | |||
*/ | */ | |||
notification yang-library-change { | notification yang-library-change { | |||
status deprecated; | status deprecated; | |||
description | description | |||
"Generated when the set of modules and submodules supported | "Generated when the set of modules and submodules supported | |||
by the server has changed."; | by the server has changed."; | |||
leaf module-set-id { | leaf module-set-id { | |||
type leafref { | type leafref { | |||
path "/yanglib:modules-state/yanglib:module-set-id"; | path "/yanglib:modules-state/yanglib:module-set-id"; | |||
} | } | |||
mandatory true; | mandatory true; | |||
status deprecated; | status deprecated; | |||
description | description | |||
"Contains the module-set-id value representing the | "Contains the module-set-id value representing the | |||
set of modules and submodules supported at the server | set of modules and submodules supported at the server | |||
at the time the notification is generated."; | at the time the notification is generated."; | |||
} | } | |||
} | } | |||
} | } | |||
<CODE ENDS> | <CODE ENDS> | |||
5. IANA Considerations | 5. IANA Considerations | |||
RFC 7895 previously registered one URI in the IETF XML registry | RFC 7895 previously registered one URI in the "IETF XML Registry" | |||
[RFC3688]. This document takes over this registration entry made by | [RFC3688]. This document takes over this registration entry made by | |||
RFC 7895 and changes the Registrant to the IESG according to | RFC 7895 and changes the Registrant Contact to the IESG according to | |||
Section 4 in [RFC3688]. | Section 4 of [RFC3688]. | |||
URI: urn:ietf:params:xml:ns:yang:ietf-yang-library | URI: urn:ietf:params:xml:ns:yang:ietf-yang-library | |||
Registrant Contact: The IESG. | Registrant Contact: The IESG. | |||
XML: N/A, the requested URI is an XML namespace. | XML: N/A, the requested URI is an XML namespace. | |||
RFC 7895 previously registered one YANG module in the "YANG Module | RFC 7895 previously registered one YANG module in the "YANG Module | |||
Names" registry [RFC6020] as follows: | Names" registry [RFC6020] as follows: | |||
name: ietf-yang-library | name: ietf-yang-library | |||
namespace: urn:ietf:params:xml:ns:yang:ietf-yang-library | namespace: urn:ietf:params:xml:ns:yang:ietf-yang-library | |||
prefix: yanglib | prefix: yanglib | |||
reference: RFC 7895 | reference: RFC 7895 | |||
This document takes over this registration entry made by RFC 7895. | This document takes over this registration entry made by RFC 7895. | |||
6. Security Considerations | 6. Security Considerations | |||
The YANG module specified in this document defines a schema for data | The YANG module specified in this document defines a schema for data | |||
that is accessed by network management protocols such as NETCONF | that is designed to be accessed via network management protocols such | |||
[RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the | as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer | |||
secure transport layer, and the mandatory-to-implement secure | is the secure transport layer, and the mandatory-to-implement secure | |||
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer | transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer | |||
is HTTPS, and the mandatory-to-implement secure transport is TLS | is HTTPS, and the mandatory-to-implement secure transport is TLS | |||
[RFC8446]. | [RFC8446]. | |||
The NETCONF access control model [RFC8341] provides the means to | The Network Configuration Access Control Model (NACM) [RFC8341] | |||
restrict access for particular NETCONF or RESTCONF users to a | provides the means to restrict access for particular NETCONF or | |||
preconfigured subset of all available NETCONF or RESTCONF protocol | RESTCONF users to a preconfigured subset of all available NETCONF or | |||
operations and content. | RESTCONF protocol operations and content. | |||
Some of the readable data nodes in this YANG module may be considered | Some of the readable data nodes in this YANG module may be considered | |||
sensitive or vulnerable in some network environments. It is thus | sensitive or vulnerable in some network environments. It is thus | |||
important to control read access (e.g., via get, get-config, or | important to control read access (e.g., via get, get-config, or | |||
notification) to these data nodes. These are the subtrees and data | notification) to these data nodes. These are the subtrees and data | |||
nodes and their sensitivity/vulnerability: | nodes and their sensitivity/vulnerability: | |||
The "/yang-library" subtree of the YANG library may help an attacker | The "/yang-library" subtree of the YANG library may help an attacker | |||
identify the server capabilities and server implementations with | identify the server capabilities and server implementations with | |||
known bugs since the set of YANG modules supported by a server may | known bugs since the set of YANG modules supported by a server may | |||
skipping to change at page 22, line 4 ¶ | skipping to change at page 21, line 20 ¶ | |||
Some of the readable data nodes in this YANG module may be considered | Some of the readable data nodes in this YANG module may be considered | |||
sensitive or vulnerable in some network environments. It is thus | sensitive or vulnerable in some network environments. It is thus | |||
important to control read access (e.g., via get, get-config, or | important to control read access (e.g., via get, get-config, or | |||
notification) to these data nodes. These are the subtrees and data | notification) to these data nodes. These are the subtrees and data | |||
nodes and their sensitivity/vulnerability: | nodes and their sensitivity/vulnerability: | |||
The "/yang-library" subtree of the YANG library may help an attacker | The "/yang-library" subtree of the YANG library may help an attacker | |||
identify the server capabilities and server implementations with | identify the server capabilities and server implementations with | |||
known bugs since the set of YANG modules supported by a server may | known bugs since the set of YANG modules supported by a server may | |||
reveal the kind of device and the manufacturer of the device. | reveal the kind of device and the manufacturer of the device. | |||
Although some of this information may be available to all NETCONF | Although some of this information may be available to all NETCONF | |||
users via the NETCONF <hello> message (or similar messages in other | users via the NETCONF <hello> message (or similar messages in other | |||
management protocols), this YANG module potentially exposes | management protocols), this YANG module potentially exposes | |||
additional details that could be of some assistance to an attacker. | additional details that could be of some assistance to an attacker. | |||
Server vulnerabilities may be specific to particular modules, module | Server vulnerabilities may be specific to particular modules, module | |||
revisions, module features, or even module deviations. For example, | revisions, module features, or even module deviations. For example, | |||
if a particular operation on a particular data node is known to cause | if a particular operation on a particular data node is known to cause | |||
a server to crash or significantly degrade device performance, then | a server to crash or significantly degrade device performance, then | |||
the module list information will help an attacker identify server | the module-list information will help an attacker identify server | |||
implementations with such a defect, in order to launch a denial-of- | implementations with such a defect, in order to launch a denial-of- | |||
service attack on the device. | service attack on the device. | |||
7. Acknowledgments | 7. References | |||
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 | ||||
and 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). | ||||
8. References | ||||
8.1. Normative References | 7.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- | DOI 10.17487/RFC2119, March 1997, | |||
editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, | [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, | |||
DOI 10.17487/RFC3688, January 2004, <https://www.rfc- | DOI 10.17487/RFC3688, January 2004, | |||
editor.org/info/rfc3688>. | <https://www.rfc-editor.org/info/rfc3688>. | |||
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for | [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for | |||
the Network Configuration Protocol (NETCONF)", RFC 6020, | the Network Configuration Protocol (NETCONF)", RFC 6020, | |||
DOI 10.17487/RFC6020, October 2010, <https://www.rfc- | DOI 10.17487/RFC6020, October 2010, | |||
editor.org/info/rfc6020>. | <https://www.rfc-editor.org/info/rfc6020>. | |||
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., | [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., | |||
and A. Bierman, Ed., "Network Configuration Protocol | and A. Bierman, Ed., "Network Configuration Protocol | |||
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, | (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, | |||
<https://www.rfc-editor.org/info/rfc6241>. | <https://www.rfc-editor.org/info/rfc6241>. | |||
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure | [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure | |||
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, | Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, | |||
<https://www.rfc-editor.org/info/rfc6242>. | <https://www.rfc-editor.org/info/rfc6242>. | |||
skipping to change at page 23, line 23 ¶ | skipping to change at page 22, line 32 ¶ | |||
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF | [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF | |||
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, | Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, | |||
<https://www.rfc-editor.org/info/rfc8040>. | <https://www.rfc-editor.org/info/rfc8040>. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration | [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration | |||
Access Control Model", STD 91, RFC 8341, | Access Control Model", STD 91, RFC 8341, | |||
DOI 10.17487/RFC8341, March 2018, <https://www.rfc- | DOI 10.17487/RFC8341, March 2018, | |||
editor.org/info/rfc8341>. | <https://www.rfc-editor.org/info/rfc8341>. | |||
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., | [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., | |||
and R. Wilton, "Network Management Datastore Architecture | and R. Wilton, "Network Management Datastore Architecture | |||
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, | (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, | |||
<https://www.rfc-editor.org/info/rfc8342>. | <https://www.rfc-editor.org/info/rfc8342>. | |||
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | |||
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | |||
<https://www.rfc-editor.org/info/rfc8446>. | <https://www.rfc-editor.org/info/rfc8446>. | |||
8.2. Informative References | 7.2. Informative References | |||
[I-D.ietf-netconf-nmda-netconf] | ||||
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., | ||||
and R. Wilton, "NETCONF Extensions to Support the Network | ||||
Management Datastore Architecture", draft-ietf-netconf- | ||||
nmda-netconf-07 (work in progress), October 2018. | ||||
[I-D.ietf-netconf-nmda-restconf] | ||||
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., | ||||
and R. Wilton, "RESTCONF Extensions to Support the Network | ||||
Management Datastore Architecture", draft-ietf-netconf- | ||||
nmda-restconf-05 (work in progress), October 2018. | ||||
[I-D.ietf-netmod-schema-mount] | ||||
Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- | ||||
ietf-netmod-schema-mount-11 (work in progress), August | ||||
2018. | ||||
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event | [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event | |||
Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, | Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, | |||
<https://www.rfc-editor.org/info/rfc5277>. | <https://www.rfc-editor.org/info/rfc5277>. | |||
[RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) | [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) | |||
Base Notifications", RFC 6470, DOI 10.17487/RFC6470, | Base Notifications", RFC 6470, DOI 10.17487/RFC6470, | |||
February 2012, <https://www.rfc-editor.org/info/rfc6470>. | February 2012, <https://www.rfc-editor.org/info/rfc6470>. | |||
[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module | [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module | |||
skipping to change at page 24, line 36 ¶ | skipping to change at page 23, line 28 ¶ | |||
RFC 8344, DOI 10.17487/RFC8344, March 2018, | RFC 8344, DOI 10.17487/RFC8344, March 2018, | |||
<https://www.rfc-editor.org/info/rfc8344>. | <https://www.rfc-editor.org/info/rfc8344>. | |||
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., | [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., | |||
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for | Ananthakrishnan, H., and X. Liu, "A YANG Data Model for | |||
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March | Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March | |||
2018, <https://www.rfc-editor.org/info/rfc8345>. | 2018, <https://www.rfc-editor.org/info/rfc8345>. | |||
[RFC8348] Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A | [RFC8348] Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A | |||
YANG Data Model for Hardware Management", RFC 8348, | YANG Data Model for Hardware Management", RFC 8348, | |||
DOI 10.17487/RFC8348, March 2018, <https://www.rfc- | DOI 10.17487/RFC8348, March 2018, | |||
editor.org/info/rfc8348>. | <https://www.rfc-editor.org/info/rfc8348>. | |||
[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for | [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for | |||
Routing Management (NMDA Version)", RFC 8349, | Routing Management (NMDA Version)", RFC 8349, | |||
DOI 10.17487/RFC8349, March 2018, <https://www.rfc- | DOI 10.17487/RFC8349, March 2018, | |||
editor.org/info/rfc8349>. | <https://www.rfc-editor.org/info/rfc8349>. | |||
[RFC8526] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., | ||||
and R. Wilton, "NETCONF Extensions to Support the Network | ||||
Management Datastore Architecture", RFC 8526, | ||||
DOI 10.17487/RFC8526, January 2019, | ||||
<https://www.rfc-editor.org/info/rfc8526>. | ||||
[RFC8528] Bjorklund, M. and L. Lhotka, "YANG Schema Mount", | ||||
RFC 8528, DOI 10.17487/RFC8528, January 2019, | ||||
<https://www.rfc-editor.org/info/rfc8528>. | ||||
Appendix A. Summary of Changes from RFC 7895 | Appendix A. Summary of Changes from RFC 7895 | |||
This document updates [RFC7895] in the following ways: | This document changes [RFC7895] in the following ways: | |||
o Renamed document title from "YANG Module Library" to "YANG | o Renamed document title from "YANG Module Library" to "YANG | |||
Library". | Library". | |||
o Added a new top-level "/yang-library" container to hold the entire | o Added a new top-level "/yang-library" container to hold the entire | |||
YANG library providing information about module sets, schemas, and | YANG library providing information about module sets, schemas, and | |||
datastores. | datastores. | |||
o Refactored the "/modules-state" container into a new | o Refactored the "/modules-state" container into a new | |||
"/yang-library/module-set" list. | "/yang-library/module-set" list. | |||
skipping to change at page 25, line 29 ¶ | skipping to change at page 24, line 29 ¶ | |||
the deprecated "yang-library-change" notification. | the deprecated "yang-library-change" notification. | |||
o Deprecated the "/modules-state" tree. | o Deprecated the "/modules-state" tree. | |||
o Deprecated the "/module-list" grouping. | o Deprecated the "/module-list" grouping. | |||
o Deprecated the "/yang-library-change" notification. | o Deprecated the "/yang-library-change" notification. | |||
Appendix B. Example YANG Library Instance for a Basic Server | Appendix B. Example YANG Library Instance for a Basic Server | |||
The following example shows the YANG Library of a basic server | The following example shows the YANG library of a basic server | |||
implementing the "ietf-interfaces" [RFC8343] and "ietf-ip" [RFC8344] | implementing the "ietf-interfaces" [RFC8343] and "ietf-ip" [RFC8344] | |||
modules in the <running>, <startup>, and <operational> datastores and | modules in the <running>, <startup>, and <operational> datastores and | |||
the "ietf-hardware" [RFC8348] module in the <operational> datastore. | the "ietf-hardware" [RFC8348] module in the <operational> datastore. | |||
Newlines in leaf values are added for formatting reasons. | Newlines in leaf values are added for formatting reasons. | |||
<yang-library | <yang-library | |||
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library" | xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library" | |||
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores"> | xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores"> | |||
<module-set> | <module-set> | |||
<name>config-modules</name> | <name>config-modules</name> | |||
<module> | <module> | |||
<name>ietf-interfaces</name> | <name>ietf-interfaces</name> | |||
<revision>2018-01-09</revision> <!-- RFC Ed. update this --> | <revision>2019-01-04</revision> | |||
<namespace> | <namespace> | |||
urn:ietf:params:xml:ns:yang:ietf-interfaces | urn:ietf:params:xml:ns:yang:ietf-interfaces | |||
</namespace> | </namespace> | |||
</module> | </module> | |||
<module> | <module> | |||
<name>ietf-ip</name> | <name>ietf-ip</name> | |||
<revision>2018-01-09</revision> <!-- RFC Ed. update this --> | <revision>2019-01-04</revision> | |||
<namespace> | <namespace> | |||
urn:ietf:params:xml:ns:yang:ietf-ip | urn:ietf:params:xml:ns:yang:ietf-ip | |||
</namespace> | </namespace> | |||
</module> | </module> | |||
<import-only-module> | <import-only-module> | |||
<name>ietf-yang-types</name> | <name>ietf-yang-types</name> | |||
<revision>2013-07-15</revision> | <revision>2013-07-15</revision> | |||
<namespace> | <namespace> | |||
urn:ietf:params:xml:ns:yang:ietf-yang-types | urn:ietf:params:xml:ns:yang:ietf-yang-types | |||
</namespace> | </namespace> | |||
skipping to change at page 26, line 27 ¶ | skipping to change at page 25, line 27 ¶ | |||
<namespace> | <namespace> | |||
urn:ietf:params:xml:ns:yang:ietf-inet-types | urn:ietf:params:xml:ns:yang:ietf-inet-types | |||
</namespace> | </namespace> | |||
</import-only-module> | </import-only-module> | |||
</module-set> | </module-set> | |||
<module-set> | <module-set> | |||
<name>state-modules</name> | <name>state-modules</name> | |||
<module> | <module> | |||
<name>ietf-hardware</name> | <name>ietf-hardware</name> | |||
<revision>2018-12-18</revision> <!-- RFC Ed. update this --> | <revision>2019-01-04</revision> | |||
<namespace> | <namespace> | |||
urn:ietf:params:xml:ns:yang:ietf-hardware | urn:ietf:params:xml:ns:yang:ietf-hardware | |||
</namespace> | </namespace> | |||
</module> | </module> | |||
<import-only-module> | <import-only-module> | |||
<name>ietf-inet-types</name> | <name>ietf-inet-types</name> | |||
<revision>2013-07-15</revision> | <revision>2013-07-15</revision> | |||
<namespace> | <namespace> | |||
urn:ietf:params:xml:ns:yang:ietf-inet-types | urn:ietf:params:xml:ns:yang:ietf-inet-types | |||
</namespace> | </namespace> | |||
</import-only-module> | </import-only-module> | |||
<import-only-module> | <import-only-module> | |||
<name>ietf-yang-types</name> | <name>ietf-yang-types</name> | |||
<revision>2013-07-15</revision> | <revision>2013-07-15</revision> | |||
<namespace> | <namespace> | |||
urn:ietf:params:xml:ns:yang:ietf-yang-types | urn:ietf:params:xml:ns:yang:ietf-yang-types | |||
</namespace> | </namespace> | |||
</import-only-module> | </import-only-module> | |||
<import-only-module> | <import-only-module> | |||
<name>iana-hardware</name> | <name>iana-hardware</name> | |||
<revision>2017-12-18</revision> <!-- RFC Ed. update this --> | <revision>2019-01-04</revision> | |||
<namespace> | <namespace> | |||
urn:ietf:params:xml:ns:yang:iana-hardware | urn:ietf:params:xml:ns:yang:iana-hardware | |||
</namespace> | </namespace> | |||
</import-only-module> | </import-only-module> | |||
</module-set> | </module-set> | |||
<schema> | <schema> | |||
<name>config-schema</name> | <name>config-schema</name> | |||
<module-set>config-modules</module-set> | <module-set>config-modules</module-set> | |||
skipping to change at page 27, line 36 ¶ | skipping to change at page 26, line 36 ¶ | |||
<datastore> | <datastore> | |||
<name>ds:operational</name> | <name>ds:operational</name> | |||
<schema>state-schema</schema> | <schema>state-schema</schema> | |||
</datastore> | </datastore> | |||
<content-id>75a43df9bd56b92aacc156a2958fbe12312fb285</content-id> | <content-id>75a43df9bd56b92aacc156a2958fbe12312fb285</content-id> | |||
</yang-library> | </yang-library> | |||
Appendix C. Example YANG Library Instance for an Advanced Server | Appendix C. Example YANG Library Instance for an Advanced Server | |||
The following example extends the preceding Basic Server YANG Library | The following example extends the example in Appendix B by using | |||
example, by using modules from [RFC8345] and [RFC8349], to illustrate | modules from [RFC8345] and [RFC8349] to illustrate a slightly more | |||
a slightly more advanced server that: | advanced server that: | |||
o Has a module with features only enabled in <operational>; the | o Has a module with features only enabled in <operational>; the | |||
"ietf-routing module" is supported in <running>, <startup>, and | "ietf-routing module" is supported in <running>, <startup>, and | |||
<operational>, but the "multiple-ribs" and "router-id" features | <operational>, but the "multiple-ribs" and "router-id" features | |||
are only enabled in <operational>. Hence the "router-id" leaf may | are only enabled in <operational>. Hence, the "router-id" leaf | |||
be read but not configured. | may be read but not configured. | |||
o Supports a dynamic configuration datastore "example-ds-ephemeral", | o Supports a dynamic configuration datastore "example-ds-ephemeral", | |||
with only the "ietf-network" and "ietf-network-topology" modules | with only the "ietf-network" and "ietf-network-topology" modules | |||
configurable via a notional dynamic configuration protocol. | configurable via a notional dynamic configuration protocol. | |||
o Shows an example of datastore specific deviations. The module | o Shows an example of datastore-specific deviations. The | |||
"example-vendor-hardware-deviations" is included in the schema for | "example-vendor-hardware-deviations" module is included in the | |||
<operational> to remove data nodes that cannot be supported by the | schema for <operational> to remove data nodes that cannot be | |||
server. | supported by the server. | |||
o Shows how module-sets can be used to organize related modules | o Shows how module-sets can be used to organize related modules | |||
together. | together. | |||
<yang-library | <yang-library | |||
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library" | xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library" | |||
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores" | xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores" | |||
xmlns:ex-ds-eph="urn:example:ds-ephemeral"> | xmlns:ex-ds-eph="urn:example:ds-ephemeral"> | |||
<module-set> | <module-set> | |||
<name>config-state-modules</name> | <name>config-state-modules</name> | |||
<module> | <module> | |||
<name>ietf-interfaces</name> | <name>ietf-interfaces</name> | |||
<revision>2018-01-09</revision> <!-- RFC Ed. update this --> | <revision>2019-01-04</revision> | |||
<namespace> | <namespace> | |||
urn:ietf:params:xml:ns:yang:ietf-interfaces | urn:ietf:params:xml:ns:yang:ietf-interfaces | |||
</namespace> | </namespace> | |||
</module> | </module> | |||
<module> | <module> | |||
<name>ietf-ip</name> | <name>ietf-ip</name> | |||
<revision>2018-01-09</revision> <!-- RFC Ed. update this --> | <revision>2019-01-04</revision> | |||
<namespace> | <namespace> | |||
urn:ietf:params:xml:ns:yang:ietf-ip | urn:ietf:params:xml:ns:yang:ietf-ip | |||
</namespace> | </namespace> | |||
</module> | </module> | |||
<module> | <module> | |||
<name>ietf-routing</name> | <name>ietf-routing</name> | |||
<revision>2018-01-25</revision> <!-- RFC Ed. update this --> | <revision>2019-01-04</revision> | |||
<namespace> | <namespace> | |||
urn:ietf:params:xml:ns:yang:ietf-routing | urn:ietf:params:xml:ns:yang:ietf-routing | |||
</namespace> | </namespace> | |||
</module> | </module> | |||
<import-only-module> | <import-only-module> | |||
<name>ietf-yang-types</name> | <name>ietf-yang-types</name> | |||
<revision>2013-07-15</revision> | <revision>2013-07-15</revision> | |||
<namespace> | <namespace> | |||
urn:ietf:params:xml:ns:yang:ietf-yang-types | urn:ietf:params:xml:ns:yang:ietf-yang-types | |||
</namespace> | </namespace> | |||
skipping to change at page 29, line 11 ¶ | skipping to change at page 28, line 11 ¶ | |||
urn:ietf:params:xml:ns:yang:ietf-inet-types | urn:ietf:params:xml:ns:yang:ietf-inet-types | |||
</namespace> | </namespace> | |||
</import-only-module> | </import-only-module> | |||
</module-set> | </module-set> | |||
<module-set> | <module-set> | |||
<name>config-only-modules</name> | <name>config-only-modules</name> | |||
<module> | <module> | |||
<name>ietf-routing</name> | <name>ietf-routing</name> | |||
<revision>2018-01-25</revision> <!-- RFC Ed. update this --> | <revision>2019-01-04</revision> | |||
<namespace> | <namespace> | |||
urn:ietf:params:xml:ns:yang:ietf-routing | urn:ietf:params:xml:ns:yang:ietf-routing | |||
</namespace> | </namespace> | |||
</module> | </module> | |||
</module-set> | </module-set> | |||
<module-set> | <module-set> | |||
<name>dynamic-config-state-modules</name> | <name>dynamic-config-state-modules</name> | |||
<module> | <module> | |||
<name>ietf-network</name> | <name>ietf-network</name> | |||
<revision>2017-12-18</revision> <!-- RFC Ed. update this --> | <revision>2019-01-04</revision> | |||
<namespace> | <namespace> | |||
urn:ietf:params:xml:ns:yang:ietf-network | urn:ietf:params:xml:ns:yang:ietf-network | |||
</namespace> | </namespace> | |||
</module> | </module> | |||
<module> | <module> | |||
<name>ietf-network-topology</name> | <name>ietf-network-topology</name> | |||
<revision>2017-12-18</revision> <!-- RFC Ed. update this --> | <revision>2019-01-04</revision> | |||
<namespace> | <namespace> | |||
urn:ietf:params:xml:ns:yang:ietf-network-topology | urn:ietf:params:xml:ns:yang:ietf-network-topology | |||
</namespace> | </namespace> | |||
</module> | </module> | |||
<import-only-module> | <import-only-module> | |||
<name>ietf-inet-types</name> | <name>ietf-inet-types</name> | |||
<revision>2013-07-15</revision> | <revision>2013-07-15</revision> | |||
<namespace> | <namespace> | |||
urn:ietf:params:xml:ns:yang:ietf-inet-types | urn:ietf:params:xml:ns:yang:ietf-inet-types | |||
</namespace> | </namespace> | |||
</import-only-module> | </import-only-module> | |||
</module-set> | </module-set> | |||
<module-set> | <module-set> | |||
<name>state-only-modules</name> | <name>state-only-modules</name> | |||
<module> | <module> | |||
<name>ietf-hardware</name> | <name>ietf-hardware</name> | |||
<revision>2018-12-18</revision> <!-- RFC Ed. update this --> | <revision>2019-01-04</revision> | |||
<namespace> | <namespace> | |||
urn:ietf:params:xml:ns:yang:ietf-hardware | urn:ietf:params:xml:ns:yang:ietf-hardware | |||
</namespace> | </namespace> | |||
<deviation>example-vendor-hardware-deviations</deviation> | <deviation>example-vendor-hardware-deviations</deviation> | |||
</module> | </module> | |||
<module> | <module> | |||
<name>ietf-routing</name> | <name>ietf-routing</name> | |||
<revision>2018-01-25</revision> <!-- RFC Ed. update this --> | <revision>2019-01-04</revision> | |||
<namespace> | <namespace> | |||
urn:ietf:params:xml:ns:yang:ietf-routing | urn:ietf:params:xml:ns:yang:ietf-routing | |||
</namespace> | </namespace> | |||
<feature>multiple-ribs</feature> | <feature>multiple-ribs</feature> | |||
<feature>router-id</feature> | <feature>router-id</feature> | |||
</module> | </module> | |||
<module> | <module> | |||
<name>example-vendor-hardware-deviations</name> | <name>example-vendor-hardware-deviations</name> | |||
<revision>2018-01-31</revision> | <revision>2018-01-31</revision> | |||
<namespace> | <namespace> | |||
skipping to change at page 30, line 36 ¶ | skipping to change at page 29, line 36 ¶ | |||
</import-only-module> | </import-only-module> | |||
<import-only-module> | <import-only-module> | |||
<name>ietf-yang-types</name> | <name>ietf-yang-types</name> | |||
<revision>2013-07-15</revision> | <revision>2013-07-15</revision> | |||
<namespace> | <namespace> | |||
urn:ietf:params:xml:ns:yang:ietf-yang-types | urn:ietf:params:xml:ns:yang:ietf-yang-types | |||
</namespace> | </namespace> | |||
</import-only-module> | </import-only-module> | |||
<import-only-module> | <import-only-module> | |||
<name>iana-hardware</name> | <name>iana-hardware</name> | |||
<revision>2017-12-18</revision> <!-- RFC Ed. update this --> | <revision>2019-01-04</revision> | |||
<namespace> | <namespace> | |||
urn:ietf:params:xml:ns:yang:iana-hardware | urn:ietf:params:xml:ns:yang:iana-hardware | |||
</namespace> | </namespace> | |||
</import-only-module> | </import-only-module> | |||
</module-set> | </module-set> | |||
<schema> | <schema> | |||
<name>config-schema</name> | <name>config-schema</name> | |||
<module-set>config-state-modules</module-set> | <module-set>config-state-modules</module-set> | |||
<module-set>config-only-modules</module-set> | <module-set>config-only-modules</module-set> | |||
skipping to change at page 31, line 31 ¶ | skipping to change at page 30, line 31 ¶ | |||
<schema>dynamic-config-schema</schema> | <schema>dynamic-config-schema</schema> | |||
</datastore> | </datastore> | |||
<datastore> | <datastore> | |||
<name>ds:operational</name> | <name>ds:operational</name> | |||
<schema>state-schema</schema> | <schema>state-schema</schema> | |||
</datastore> | </datastore> | |||
<content-id>14782ab9bd56b92aacc156a2958fbe12312fb285</content-id> | <content-id>14782ab9bd56b92aacc156a2958fbe12312fb285</content-id> | |||
</yang-library> | </yang-library> | |||
Acknowledgments | ||||
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). | ||||
Authors' Addresses | Authors' Addresses | |||
Andy Bierman | Andy Bierman | |||
YumaWorks | YumaWorks | |||
Email: andy@yumaworks.com | Email: andy@yumaworks.com | |||
Martin Bjorklund | Martin Bjorklund | |||
Tail-f Systems | Tail-f Systems | |||
End of changes. 107 change blocks. | ||||
208 lines changed or deleted | 177 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |