NETCONF Extensions to Support the Network Management Datastore ArchitectureTail-f Systemsmbj@tail-f.comJacobs Universityj.schoenwaelder@jacobs-university.deJuniper Networksphil@juniper.netJuniper Networkskwatsen@juniper.netCisco Systemsrwilton@cisco.com
This document extends the NETCONF protocol defined in RFC 6241 in
order to support the Network Management Datastore Architecture
defined in I-D.ietf-netmod-revised-datastores.
This document updates both RFC 6241 and RFC 7950. The update to
RFC 6241 adds new operations <get‑data> and <edit‑data>, and
augments existing operations <lock>, <unlock>, and <validate>.
The update to RFC 7950 requires the usage of I-D.ietf-netconf-rfc7895bis
by NETCONF servers implementing the Network Management Datastore
Architecture.
REF Editor: please replace "I‑D.ietf‑netmod‑revised‑datastores" and
"I‑D.ietf‑netconf‑rfc7895bis" above with their final RFC assignments.
This document extends the NETCONF protocol defined in in
order to support the Network Management Datastore Architecture (NMDA)
defined in .
This document updates in order to enable NETCONF clients to
interact with all the datastores supported by a server implementing
the NMDA. The update both adds new operations <get‑data> and
<edit‑data>, and augments existing operations <lock>, <unlock>, and
<validate>.
This document also updates in order to enable NETCONF
clients to both discover which datastores are supported by the
NETCONF server, as well as determine which modules are supported
in each datastore. The update requires NETCONF servers implementing
the NMDA to support .
This document uses the terminology defined by the NMDA
.
The following term is defined in :
YANG library checksum
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14, when, and only when, they appear in all capitals,
as shown here.
Tree diagrams used in this document follow the notation defined in
.
RFC Ed.: Update 201X-XX-XX below with correct date.
An NMDA-compliant NETCONF server MUST support the operational state
datastore and it MUST implement at least revision 201X-XX-XX of the
"ietf‑yang‑library" module defined in .
The server MUST advertise the
following capability in the <hello> message (line breaks and
whitespaces are used for formatting reasons only):
The parameter "revision" has the same value as the revision date of
the "ietf‑yang‑library" module implemented by the server. This
parameter MUST be present.
The parameter "checksum" contains the YANG library checksum
. This parameter MUST be present.
With this mechanism, a client can cache the supported modules for a
server and only update the cache if the "checksum" value in the
<hello> message changes.
This document updates , Section 5.6.4, to allow servers to
advertise the capability :yang-library:1.1 instead of
:yang-library:1.0, and to implement the subtree "/yang‑library"
instead of "/modules‑state".
This section describes the NETCONF extensions needed to support the
NMDA. These changes are defined in a new YANG () module
"ietf‑netconf‑nmda".
These changes include the use of source and target parameters based on
the "datastore" identity defined in the "ietf‑datastores" module
. The use of identities allows
future expansion in a way that the choice-based strategy from the
original operations (e.g., <get‑config>, <edit‑config>) does not.
Two new operations <get‑data> and <edit‑data> are defined in this
document in order to support the NMDA. These operations are similar
to the <get‑config> and <edit‑config> operations but they can work
on an extensible set of datastores.
The <get‑data> operation retrieves data from a specific NMDA
datastore. This operation is similar to NETCONF's <get‑config>
operation defined in , but it adds the flexibility to
select the source datastore.
The "datastore" parameter indicates the datastore which is the source
of the data to be retrieved. This is a datastore identity.
The <get‑data> operation accepts a content filter parameter, similar
to the "filter" parameter of <get‑config>, but using explicit nodes
for subtree filtering ("subtree‑filter") and XPath filtering
("xpath‑filter").
The "config‑filter" parameter can be used to retrieve only "config
true" or "config false" nodes. The "origin‑filter" can be used to
select nodes matching any of a set of given "origin" values.
The "max‑depth" parameter can be used by the client to limit the
number of sub-tree levels that are returned in the reply.
The <get‑data> operation also supports the "with‑defaults" parameter
as defined in . The supported values follow the constraints
given by the "with‑defaults" capability.
The "with‑defaults" parameter does not apply when interacting with an
operational datastore. This means that all "in use" values, as defined
in section 5.3, are returned from
the operational state datastore, even if a node happens to have a
default statement in the YANG module, and this default value is being
used by the server. If the "with‑defaults" parameter is present in a
request to such a datastore, then the server MUST return an error, as
specified in "ietf‑netconf‑nmda" (see ).
The <get‑data> operation defines a parameter named "with‑origin",
which if present, requests that the server includes "origin" metadata
anotations in its response, as detailed in the NMDA. This parameter
is only valid for the operational state datastore and any datastores
with identities derived from the "operational" identity. Otherwise,
if an invalid datastore is specified then an error is returned, as
specified in "ietf‑netconf‑nmda" (see ). Note that "origin"
metadata annotations are not included in a response unless a client
explicitly requests them.
Data in the operational state datastore can come from multiple
sources. The server should return the most accurate value for the
"origin" metadata annotation as possible, indicating the source of the
operational value, as specified in Section 5.3.4 of
.
When encoding the origin metadata annotation for a hierarchy of
returned nodes, the annotation may be omitted for a child node when
the value matches that of the parent node, as described in the
"ietf‑origin" YANG module .
The "with‑origin" parameter is optional to support. It is identified
with the URI:
The <edit‑data> operation changes the contents of a writable
datastore, similar to the <edit‑config> operation defined in
, but with additional flexibility in naming the target
datastore. If an <edit‑data> operation is invoked on a non-writable
datastore, then an error is returned, as specified in
"ietf‑netconf‑nmda" (see ).
The "datastore" parameter is a datastore identity that indicates the
desired target datastore where changes should be made.
The "default‑operation" parameter is a copy of the "default‑operation"
parameter of the <edit‑config> operation.
The "edit‑content" choice mirrors the "edit‑content" choice of the
<edit‑config> operation. Note, however, that the "config" element in
the "edit‑content" choice of <edit‑data> uses "anydata" (introduced in
YANG 1.1) while the "config" element in the "edit‑content" choice of
<edit‑config> used "anyxml".
The <edit‑data> operation does not support the "error‑option" and the
"test‑option" parameters that were part of the <edit‑config>
operation.
Several of the operations defined in the base NETCONF YANG module
"ietf‑netconf" may be used with new datastores. Hence, the
<lock>, <unlock>, and <validate> operations are augmented with a new
"datastore" leaf that can select the desired datastore. If a <lock>,
<unlock>, or <validate> operation is not supported on a particular
datastore then an error is returned, as specified in
"ietf‑netconf‑nmda" (see ).
This module imports definitions from , , ,
and .
RFC Ed.: update the date below with the date of RFC publication and
remove this note.
<CODE BEGINS> file "ietf-netconf-nmda@2018-02-05.yang"<CODE ENDS>
This document registers two capability identifier URNs in the "Network
Configuration Protocol (NETCONF) Capability URNs" registry:
This document registers a URI in the "IETF XML Registry" .
Following the format in RFC 3688, the following registration has been
made.
This document registers a YANG module in the "YANG Module Names"
registry .
The YANG module defined in this document extends the base operations
of the NETCONF protocol. The lowest NETCONF layer is the
secure transport layer and the mandatory-to-implement secure transport
is Secure Shell (SSH) .
The network configuration access control model
provides the means to restrict access
for particular NETCONF users to a preconfigured subset of all
available NETCONF protocol operations and content.
The security considerations for the base NETCONF protocol operations
(see Section 9 of ) apply to the new NETCONF <get‑data> and
<edit‑data> operations defined in this document.
Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.The IETF XML RegistryThis document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]Network Configuration Protocol (NETCONF)The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]Using the NETCONF Protocol over Secure Shell (SSH)This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK]With-defaults Capability for NETCONFThe Network Configuration Protocol (NETCONF) defines ways to read and edit configuration data from a NETCONF server. In some cases, part of this data may not be set by the NETCONF client, but rather a default value known to the server is used instead. In many situations the NETCONF client has a priori knowledge about default data, so the NETCONF server does not need to save it in a NETCONF configuration datastore or send it to the client in a retrieval operation reply. In other situations the NETCONF client will need this data from the server. Not all server implementations treat this default data the same way. This document defines a capability-based extension to the NETCONF protocol that allows the NETCONF client to identify how defaults are processed by the server, and also defines new mechanisms for client control of server processing of default data. [STANDARDS-TRACK]Common YANG Data TypesThis document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021.The YANG 1.1 Data Modeling LanguageYANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Network Management Datastore ArchitectureDatastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as NETCONF and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950.YANG LibraryThis document describes a YANG library that provides information about all the YANG modules and datastores used by a network management server (e.g., a Network Configuration Protocol (NETCONF) server). Simple caching mechanisms are provided to allow clients to minimize retrieval of this information.Network Configuration Access Control ModuleThe standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a pre-configured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536.YANG Tree DiagramsThis document captures the current syntax used in YANG module Tree Diagrams. The purpose of the document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.