draft-ietf-netconf-rfc7895bis-01.txt   draft-ietf-netconf-rfc7895bis-02.txt 
Network Working Group A. Bierman Network Working Group A. Bierman
Internet-Draft YumaWorks Internet-Draft YumaWorks
Obsoletes: rfc7895 (if approved) M. Bjorklund Obsoletes: rfc7895 (if approved) M. Bjorklund
Intended status: Standards Track Tail-f Systems Intended status: Standards Track Tail-f Systems
Expires: March 4, 2018 K. Watsen Expires: May 3, 2018 K. Watsen
Juniper Networks Juniper Networks
August 31, 2017 October 30, 2017
YANG Library YANG Library
draft-ietf-netconf-rfc7895bis-01 draft-ietf-netconf-rfc7895bis-02
Abstract Abstract
This document describes a YANG library that provides information This document describes a YANG library that provides information
about all the YANG modules used by a network management server (e.g., about all the YANG modules and datastores used by a network
a Network Configuration Protocol (NETCONF) server). Simple caching management server (e.g., a Network Configuration Protocol (NETCONF)
mechanisms are provided to allow clients to minimize retrieval of server). Simple caching mechanisms are provided to allow clients to
this information. minimize retrieval of this information.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 4, 2018. This Internet-Draft will expire on May 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 (http://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
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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
1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Motivation for rfc7895bis . . . . . . . . . . . . . . . . 4 1.3. Motivation for rfc7895bis . . . . . . . . . . . . . . . . 4
1.4. Summary of Changes from RFC 7895 . . . . . . . . . . . . 5 1.4. Summary of Changes from RFC 7895 . . . . . . . . . . . . 5
2. YANG Library . . . . . . . . . . . . . . . . . . . . . . . . 5 2. YANG Library . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. yang-library . . . . . . . . . . . . . . . . . . . . . . 6 2.1. yang-library . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1. yang-library/modules/module . . . . . . . . . . . . . 6 2.1.1. yang-library/modules/module . . . . . . . . . . . . . 7
2.1.2. yang-library/module-sets/module-set . . . . . . . . . 7 2.1.2. yang-library/module-sets/module-set . . . . . . . . . 8
2.1.3. yang-library/datastores/datastore . . . . . . . . . . 7 2.1.3. yang-library/datastores/datastore . . . . . . . . . . 8
2.2. YANG Library Module . . . . . . . . . . . . . . . . . . . 7 2.2. YANG Library Module . . . . . . . . . . . . . . . . . . . 9
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
3.1. YANG Module Registry . . . . . . . . . . . . . . . . . . 18 3.1. YANG Module Registry . . . . . . . . . . . . . . . . . . 20
4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.1. Normative References . . . . . . . . . . . . . . . . . . 19 6.1. Normative References . . . . . . . . . . . . . . . . . . 22
6.2. Informative References . . . . . . . . . . . . . . . . . 20 6.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
There is a need for standard mechanisms to provide the operational There is a need for standard mechanisms to provide the operational
state of the server. This includes, for instance, identifying the state of a network management server. This includes, for instance,
YANG modules and datastores that are in use by a server and how they identifying the YANG modules and datastores that are in use by a
relate to each other. server and how they relate to each other.
This document defines a YANG module that can be used to provide this
informaton, in a way that is compatible with the NMDA
[I-D.ietf-netmod-revised-datastores], but that is also backwards
compatible with the "YANG Module Library" YANG module defined in
[RFC7895].
If a large number of YANG modules are utilized by the server, then If a large number of YANG modules are utilized by the server, then
the YANG library contents needed can be relatively large. This the YANG library contents needed can be relatively large. This
information changes very infrequently, so it is important that information changes very infrequently, so 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.
YANG library information can be different on every server and can YANG library information can be different on every server and can
change at runtime or across a server reboot. change at runtime or across a server reboot.
skipping to change at page 3, line 14 skipping to change at page 3, line 18
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 identifier: a unique identifier for the module that includes the o identifier: a unique identifier for the module that includes the
module's name, revision, submodules, features, and deviations. module's name, revision, submodules, features, and deviations.
o name: The name of the YANG module. o name: The name of the YANG module.
o revision: Each YANG module and submodule within the library has a o revision: Each YANG module and submodule within the library SHOULD
revision. This is derived from the most recent revision statement have a revision. This is derived from the most recent revision
within the module or submodule. If no such revision statement statement within the module or submodule.
exists, the module's or submodule's revision is the zero-length
string.
o submodule list: The name and revision of each submodule used by o submodule list: The name, and if defined, revision of each
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 context, MUST be identified. server, in a given datastore schema, MUST be identified.
o deviation list: The name of each YANG module used for deviation o deviation list: The name of each YANG module used for deviation
statements, in a given context, MUST be identified. statements, in a given datastore schema, MUST be identified.
The following information is needed by a client application (for each The following information is needed by a client application (for each
datastore supported by the server) to fully access all the YANG- datastore supported by the server) to fully access all the YANG-
modelled data available on the server: modelled data available on the server:
o identity: the YANG identity for the datastore. o identity: the YANG identity for the datastore.
o modules: modules supported by the datastore, including any o modules: modules supported by the datastore, including any
features and deviations. features and deviations.
skipping to change at page 3, line 50 skipping to change at page 4, line 4
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "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 BCP
14, [RFC2119]. 14, [RFC2119].
The following terms are defined in [RFC6241]: The following terms are defined in [RFC6241]:
o client o client
o server o server
The following terms are defined in [RFC7950]: The following terms are defined in [RFC7950]:
o module o module
o submodule o submodule
The following terms are defined in ^NMDA":
o conventional configuration datastore
o operational datastore
o datastore schema
The following terms are used within this document: The following terms are used within this document:
o YANG library: A collection of metadata describing the server's o YANG library: A collection of metadata describing the server's
operational state. operational state.
1.2. Tree Diagrams 1.2. Tree Diagrams
A simplified graphical representation of the data model is used in A simplified graphical representation of the data model is used in
this document. The meaning of the symbols in these diagrams is as this document. The meaning of the symbols in these diagrams is as
follows: follows:
skipping to change at page 5, line 4 skipping to change at page 5, line 16
not. not.
RFC 7895 has a mandatory to implement 'modules-state' tree that a RFC 7895 has a mandatory to implement 'modules-state' tree that a
server uses to advertise all the modules it supports. However, this server uses to advertise all the modules it supports. However, this
module was designed assuming the all modules would be in all module was designed assuming the all modules would be in all
datastores, and with the same number of features and deviations. datastores, and with the same number of features and deviations.
However, this is not the case with NMDA-compatible servers that may However, this is not the case with NMDA-compatible servers that may
have some modules that only appear in <operational> (e.g., ietf- have some modules that only appear in <operational> (e.g., ietf-
network-topo) or only also appear in a dynamic datastore (e.g., i2rs- network-topo) or only also appear in a dynamic datastore (e.g., i2rs-
ephemeral-rib). It is also possible that a server only implements a ephemeral-rib). It is also possible that a server only implements a
module in <running>, at it hasn't yet coded support for returning the module in <running>, as it hasn't yet coded support for returning the
module's opstate yet. Presumably, an NMDA-supporting server would module's opstate yet. Presumably, an NMDA-supporting server would
return all modules implemented in every datastore, but this would be return all modules implemented in every datastore, but this would be
misleading to existing clients and unhelpful to NMDA-aware clients. misleading to existing clients and unhelpful to NMDA-aware clients.
In the end, it appears that the 'modules-state' node should be for In the end, it appears that the 'modules-state' node should be for
non-NMDA aware clients. For backwards compatability, an NMDA- non-NMDA aware clients. For backwards compatability, an NMDA-
supporting server SHOULD populate 'modules-state' in a backwards- supporting server SHOULD populate 'modules-state' in a backwards-
compatible manner. The new 'yang-library' node would be ignored by compatible manner. The new 'yang-library' node would be ignored by
legacy clients, while providing all the data needed for NMDA-aware legacy clients, while providing all the data needed for NMDA-aware
clients, which would themselves ignore the 'modules-state' tree. clients, which would themselves ignore the 'modules-state' tree.
In addition to resolving the 'modules-state' node NMDA- The solution presented in this document is further motivated by the
incompatibility issue described above, the solution presented in this following desires:
document is further motivated by the following desires:
o leverage Section 5.6.4 of RFC 7950 and Section 10 of RFC 8040. o leverage Section 5.6.4 of RFC 7950 and Section 10 of RFC 8040.
o indicate which modules are supported by each datastore o indicate which modules are supported by each datastore
o enable the features and deviations to vary by datastore o enable the features and deviations to vary by datastore
o structure extensible to support schema-mount o structure extensible to support schema-mount
o provide a top-level container for all server metadata o provide a top-level container for all server metadata
skipping to change at page 5, line 41 skipping to change at page 6, line 5
This document updates [RFC7895] in the following ways: This document updates [RFC7895] in the following ways:
o Renames document title from "YANG Module Library" to "YANG o Renames document title from "YANG Module Library" to "YANG
Library". Library".
o Adds a new top-level "yang-library" container to hold many types o Adds a new top-level "yang-library" container to hold many types
of server metadata: modules supported, datastores supported, of server metadata: modules supported, datastores supported,
relationships between datastores and modules, etc. relationships between datastores and modules, etc.
o Adds a set of new groupings as replacements for the deprecated
"module-list" grouping.
o Adds a "yang-library-update" notification as a replacement for the
deprecated "yang-library-change" notification.
o Deprecates the "modules-state" tree. o Deprecates the "modules-state" tree.
o Deprecates the "module-list" grouping. o Deprecates the "module-list" grouping.
o Deprecates the "yang-library-change" notification. o Deprecates the "yang-library-change" notification.
2. YANG Library 2. YANG Library
The "ietf-yang-library" module provides information about the modules The "ietf-yang-library" module provides information about the modules
used by a server. This module is defined using YANG version 1, but and datastores supported by a server. This module is defined using
it supports the description of YANG modules written in any revision YANG version 1.1, but it supports the description of YANG modules
of YANG. written in any revision of YANG.
Following is the YANG Tree Diagram for the "ietf-yang-library" Following is the YANG Tree Diagram for the "ietf-yang-library"
module, excluding the deprecated 'modules-state' tree: module, excluding the deprecated 'modules-state' tree:
module: ietf-yang-library module: ietf-yang-library
+--ro yang-library +--ro yang-library
+--ro modules +--ro modules
| +--ro module* [id] | +--ro module* [id]
| +--ro id string | +--ro id string
| +--ro name yang:yang-identifier | +--ro name yang:yang-identifier
| +--ro revision union | +--ro revision? revision-identifier
| +--ro schema? inet:uri | +--ro schema? inet:uri
| +--ro namespace inet:uri | +--ro namespace inet:uri
| +--ro feature* yang:yang-identifier | +--ro feature* yang:yang-identifier
| +--ro deviation* [name revision] | +--ro deviation* [module]
| | +--ro name yang:yang-identifier | | +--ro module -> ../../id
| | +--ro revision union
| +--ro conformance-type enumeration | +--ro conformance-type enumeration
| +--ro submodule* [name revision] | +--ro submodule* [name]
| +--ro name yang:yang-identifier | +--ro name yang:yang-identifier
| +--ro revision union | +--ro revision? revision-identifier
| +--ro schema? inet:uri | +--ro schema? inet:uri
+--ro module-sets +--ro module-sets
| +--ro module-set* [id] | +--ro module-set* [id]
| +--ro id string | +--ro id string
| +--ro module* -> ../../../modules/module/id | +--ro module* -> ../../../modules/module/id
+--ro datastores +--ro datastores
| +--ro datastore* [name] | +--ro datastore* [name]
| +--ro name identityref | +--ro name identityref
| +--ro module-set? | +--ro module-set
| -> ../../../module-sets/module-set/id | -> ../../../module-sets/module-set/id
+--ro checksum string +--ro checksum string
notifications: notifications:
+---n yang-library-update +---n yang-library-update
2.1. yang-library 2.1. yang-library
This mandatory container holds all of the server's metadata. This container holds all of the server's metadata.
2.1.1. yang-library/modules/module 2.1.1. yang-library/modules/module
This mandatory list contains one entry for each unique instance of a This list contains one entry for each unique instance of a module in
module in use by the server. Each entry is distiguished by the use by the server. Each entry is distinguished by the module's name,
module's name, revisions, features, and deviations. revisions, features, and deviations.
A server cannot implement different revisions of the same module in
different datastores, so there MUST only be a single revision of a
given module in the "module" list that has a "conformance-type" leaf
of "implement".
Although the server is at liberty to choose the unique "id" for each
entry in the "module" list, it is suggested to use an "id" that would
be meaningful to clients. For example, "ietf-interfaces@2017-08-17"
could be used as the "id" for a particular revision of the IETF
interfaces YANG module. For a module that holds deviations or
features specific to a datastore perhaps an "id" that also contains
the datastore name, like "ietf-interfaces-deviations@2017-08-17/
operational" could be used.
2.1.2. yang-library/module-sets/module-set 2.1.2. yang-library/module-sets/module-set
This mandatory list contains one entry for each module-set in use by A "module-set" represents the datastore schema that is used by one or
the server (e.g., presented by a datastore). more datastores.
This list contains one entry for each module set in use by the server
(e.g., presented by a datastore).
All conventional configuration datastores use the same datastore
schema, which can normally be modelled using a single module set.
A dynamic configuration datastore may use a different datastore
schema from the conventional configuration datastores, and hence may
require a separate module set definition.
The datastore schema for the operational datastore is the superset of
the datastore schema of all the configuration datastores, but can
have unsupported nodes removed via datastore specific deviations or
by omitting one or more modules from the module set associated with
the operational datastore.
However, where possible, the same module set used for conventional
configuration datatstores should also be used for the operational
datastore. For example, deviations that are specific to "config
false" nodes could still be applied to a common module instance that
is also included in the module set used for the conventional
datastores.
Although the server is at liberty to choose the unique "id" for the
"module-set" list entry, it is suggested to choose an "id" that would
be meaningful to clients, perhaps including the datastore name if the
module set is only relevant to a single datastore.
2.1.3. yang-library/datastores/datastore 2.1.3. yang-library/datastores/datastore
This mandatory list contains one entry for each datastore supported This list contains one entry for each datastore supported by the
by the server. Each datastore entry both identifies any special server, and identifes the datastore schema associated with a
propoerties it has and any module-sets it uses. datastore via a reference to a module-set. Each supported
conventional configuration datastore has a separate entry.
2.2. YANG Library Module 2.2. YANG Library Module
The "ietf-yang-library" module defines monitoring information for the The "ietf-yang-library" module defines monitoring information for the
YANG modules used by a server. YANG modules used by a server.
The modules "ietf-yang-types" and "ietf-inet-types" from [RFC6991] The modules "ietf-yang-types" and "ietf-inet-types" from [RFC6991]
and the module "ietf-datastores" from and the module "ietf-datastores" from
[I-D.ietf-netmod-revised-datastores] are used by this module for some [I-D.ietf-netmod-revised-datastores] are used by this module for some
type definitions. type definitions.
RFC Ed.: update the date below with the date of RFC publication and RFC Ed.: update the date below with the date of RFC publication and
remove this note. remove this note.
<CODE BEGINS> file "ietf-yang-library@2017-08-17.yang" <CODE BEGINS> file "ietf-yang-library@2017-10-30.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.";
} }
skipping to change at page 8, line 41 skipping to change at page 10, line 29
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://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 XXXX; 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 // RFC Ed.: update the date below with the date of RFC publication
// and remove this note. // and remove this note.
// RFC Ed.: replace XXXX with actual RFC number and remove this // RFC Ed.: replace XXXX with actual RFC number and remove this
// note. // note.
revision 2017-08-17 { revision 2017-10-30 {
description description
"Updated revision."; "Updated revision.";
reference reference
"RFC XXXX: YANG Library."; "RFC XXXX: 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.";
skipping to change at page 9, line 31 skipping to change at page 11, line 22
description description
"Parameters for identifying YANG modules and submodules."; "Parameters for identifying YANG modules and submodules.";
leaf name { leaf name {
type yang:yang-identifier; type yang:yang-identifier;
mandatory true; mandatory true;
description description
"The YANG module or submodule name."; "The YANG module or submodule name.";
} }
leaf revision { leaf revision {
type union { type revision-identifier;
type revision-identifier;
type string { length 0; }
}
mandatory true;
description description
"The YANG module or submodule revision date. "The YANG module or submodule revision date. If no revision
A zero-length string is used if no revision statement statement is present in the YANG module or submodule, this
is present in the YANG module or submodule."; leaf is not instantiated.";
} }
} }
grouping schema-leaf { grouping schema-leaf {
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
skipping to change at page 10, line 22 skipping to change at page 12, line 8
"Parameters for describing the implementation of a module."; "Parameters for describing the implementation of a module.";
leaf-list feature { leaf-list feature {
type yang:yang-identifier; type yang:yang-identifier;
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 defined supported by the server, regardless whether they are defined
in the module or any included submodule."; in the module or any included submodule.";
} }
list deviation { list deviation {
key "name revision"; key "module";
description description
"List of YANG deviation module names and revisions used by "List of YANG deviation modules used by
this server to modify the conformance of the module this server to modify the conformance of the module
associated with this entry. Note that the same module can associated with this entry. Note that the same module can
be used for deviations for multiple modules, so the same be used for deviations for multiple modules, so the same
entry MAY appear within multiple 'module' entries. entry MAY appear within multiple 'module' entries.";
The deviation module MUST be present in the 'module' list,
with the same name and revision values. The
'conformance-type' value will be 'implement' for the
deviation module.";
uses module-identification-leafs; leaf module {
type leafref {
path "../../id";
}
description
"The module that deviates the module associated with this
entry. The deviation modules MUST be part of the same
module-sets as the module it deviates.";
}
} }
leaf conformance-type { leaf conformance-type {
type enumeration { type enumeration {
enum implement { enum implement {
description description
"Indicates that the server implements one or more "Indicates that the server implements one or more
protocol-accessible objects defined in the YANG module protocol-accessible objects defined in the YANG module
identified in this entry. This includes deviation identified in this entry. This includes deviation
statements defined in the module. statements defined in the module.
skipping to change at page 11, line 34 skipping to change at page 13, line 23
} }
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.";
container modules { container modules {
description description
"A container holding a list of modules. Note, modules being "A container holding a list of modules. Modules being
listed here does not mean that they are supported by any listed here does not necessarily mean that they are
particular datastore."; supported by any particular datastore.
If a module has the value 'implemented' for it's
'conformance-type' leaf in the 'module' list, it means that
the server supports the rpcs and notifications defined in
the module (adjusted for features and deviations), even if
the module is not supported in any particular datastore.";
list module { list module {
key "id"; key "id";
description description
"Each entry represents one revision of one module "Each entry represents a revision of a module currently
currently supported by the server."; supported by the server with a particular set of supported
features and deviations";
leaf id { leaf id {
type string; type string;
description description
"A stable identifier, independent of any other part "A unique identifier, independent of any other part
of this module instance."; of this module instance.";
} }
uses module-identification-leafs; uses module-identification-leafs;
uses schema-leaf; uses schema-leaf;
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 implementation-parameters; uses implementation-parameters;
list submodule { list submodule {
skipping to change at page 12, line 14 skipping to change at page 14, line 12
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 implementation-parameters; uses implementation-parameters;
list submodule { list submodule {
key "name revision"; 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 schema-leaf; uses schema-leaf;
} }
} }
} }
container module-sets { container module-sets {
description description
"A container for a list of module-sets. Module-sets being "A container for the list of module-sets supported by the
listed here does not mean that they are used by any server";
particular datastore.";
list module-set { list module-set {
key "id"; key "id";
description description
"An arbitrary module-set definition provided by the "An arbitrary module-set definition provided by the
server."; server.
A module-set represents a datastore schema associated with
one or more datastores.
Module-sets being listed here does not necessarily mean
that they are used by any particular datastore.
In the case of a configuration datastore, only the config
true subset of a datastore schema is applicable to the
datastore, any config false schema nodes and any action
statements are ignored.";
leaf id { leaf id {
type string; type string;
description description
"A system-generated value that uniquely represents the "A system-generated value that uniquely represents the
referenced set of modules. Any change to the number referenced set of modules. Any change to the number
of modules referenced, or to the modules themselves, of modules referenced, or to the modules themselves,
generates a different value."; generates a different value.";
} }
leaf-list module { leaf-list module {
skipping to change at page 13, line 4 skipping to change at page 15, line 13
} }
leaf-list module { leaf-list module {
type leafref { type leafref {
path "../../../modules/module/id"; path "../../../modules/module/id";
} }
description description
"A module-instance supported by the server, including its "A module-instance supported by the server, including its
features and deviations."; features and deviations.";
} }
} }
} }
container datastores { container datastores {
description description
"A container for a list of datastores supported by the "A container for the list of datastores supported by the
server. Each datastore indicates which module-sets it server.";
supports.";
list datastore { list datastore {
key "name"; key "name";
description
"A datastore supported by this server.
Each datastore indicates which module-set it supports.
The server MUST instantiate one entry in this list per
specific datastore it supports.
Each datstore entry with the same datastore schema SHOULD
reference the same module-set.";
leaf name { leaf name {
type identityref { type identityref {
base ds:datastore; base ds:datastore;
} }
description description
"The identity of the datastore."; "The identity of the datastore.";
} }
leaf module-set { leaf module-set {
type leafref { type leafref {
path "../../../module-sets/module-set/id"; path "../../../module-sets/module-set/id";
} }
mandatory true;
description description
"A reference to a module-set supported by this "A reference to the module-set supported by this
datastore"; datastore";
} }
description
"A datastore supported by this server.";
} }
} }
} }
/* /*
* Top-level container * Top-level container
*/ */
container yang-library { container yang-library {
config false; config false;
description description
"Container providing all the YANG meta information the "Container providing all the YANG meta information the
server possesses."; server possesses.";
skipping to change at page 19, line 45 skipping to change at page 22, line 14
those of the author(s) and do not necessarily reflect the views of those of the author(s) and do not necessarily reflect the views of
The Space & Terrestrial Communications Directorate (S&TCD). The Space & Terrestrial Communications Directorate (S&TCD).
6. References 6. References
6.1. Normative References 6.1. Normative References
[I-D.ietf-netmod-revised-datastores] [I-D.ietf-netmod-revised-datastores]
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore and R. Wilton, "Network Management Datastore
Architecture", draft-ietf-netmod-revised-datastores-03 Architecture", draft-ietf-netmod-revised-datastores-05
(work in progress), July 2017. (work in progress), October 2017.
[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, <https://www.rfc-
editor.org/info/rfc2119>. 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, <https://www.rfc-
editor.org/info/rfc3688>. editor.org/info/rfc3688>.
 End of changes. 49 change blocks. 
98 lines changed or deleted 180 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/