draft-ietf-netconf-nmda-netconf-06.txt   draft-ietf-netconf-nmda-netconf-07.txt 
Network Working Group M. Bjorklund Network Working Group M. Bjorklund
Internet-Draft Tail-f Systems Internet-Draft Tail-f Systems
Updates: 6241, 7950 (if approved) J. Schoenwaelder Updates: 6241, 7950 (if approved) J. Schoenwaelder
Intended status: Standards Track Jacobs University Intended status: Standards Track Jacobs University
Expires: November 29, 2018 P. Shafer Expires: April 12, 2019 P. Shafer
K. Watsen K. Watsen
Juniper Networks Juniper Networks
R. Wilton R. Wilton
Cisco Systems Cisco Systems
May 28, 2018 October 9, 2018
NETCONF Extensions to Support the Network Management Datastore NETCONF Extensions to Support the Network Management Datastore
Architecture Architecture
draft-ietf-netconf-nmda-netconf-06 draft-ietf-netconf-nmda-netconf-07
Abstract Abstract
This document extends the NETCONF protocol defined in RFC 6241 in This document extends the NETCONF protocol defined in RFC 6241 in
order to support the Network Management Datastore Architecture order to support the Network Management Datastore Architecture
defined in RFC 8342. defined in RFC 8342.
This document updates both RFC 6241 and RFC 7950. The update to RFC This document updates both RFC 6241 and RFC 7950. The update to RFC
6241 adds new operations <get-data> and <edit-data>, and augments 6241 adds new operations <get-data> and <edit-data>, and augments
existing operations <lock>, <unlock>, and <validate>. The update to existing operations <lock>, <unlock>, and <validate>. The update to
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 November 29, 2018. This Internet-Draft will expire on April 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3
2. Datastore and YANG Library Requirements . . . . . . . . . . . 3 2. Datastore and YANG Library Requirements . . . . . . . . . . . 3
3. NETCONF Extensions . . . . . . . . . . . . . . . . . . . . . 4 3. NETCONF Extensions . . . . . . . . . . . . . . . . . . . . . 4
3.1. New NETCONF Operations . . . . . . . . . . . . . . . . . 4 3.1. New NETCONF Operations . . . . . . . . . . . . . . . . . 4
3.1.1. The <get-data> Operation . . . . . . . . . . . . . . 4 3.1.1. The <get-data> Operation . . . . . . . . . . . . . . 4
3.1.2. The <edit-data> Operation . . . . . . . . . . . . . . 8 3.1.2. The <edit-data> Operation . . . . . . . . . . . . . . 8
3.2. Augmentations to NETCONF Operations . . . . . . . . . . . 9 3.2. Augmentations to NETCONF Operations . . . . . . . . . . . 10
4. NETCONF Datastores YANG Module . . . . . . . . . . . . . . . 9 4. NETCONF Datastores YANG Module . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Normative References . . . . . . . . . . . . . . . . . . 19 7.1. Normative References . . . . . . . . . . . . . . . . . . 20
7.2. Informative References . . . . . . . . . . . . . . . . . 20 7.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
This document extends the NETCONF protocol defined in [RFC6241] in This document extends the NETCONF protocol defined in [RFC6241] in
order to support the Network Management Datastore Architecture (NMDA) order to support the Network Management Datastore Architecture (NMDA)
defined in [RFC8342]. defined in [RFC8342].
This document updates [RFC6241] in order to enable NETCONF clients to This document updates [RFC6241] in order to enable NETCONF clients to
interact with all the datastores supported by a server implementing interact with all the datastores supported by a server implementing
the NMDA. The update both adds new operations <get-data> and the NMDA. The update both adds new operations <get-data> and
skipping to change at page 3, line 31 skipping to change at page 3, line 31
1.2. Tree Diagrams 1.2. Tree Diagrams
Tree diagrams used in this document follow the notation defined in Tree diagrams used in this document follow the notation defined in
[RFC8340]. [RFC8340].
2. Datastore and YANG Library Requirements 2. Datastore and YANG Library Requirements
RFC Ed.: Update 201X-XX-XX below with correct date. RFC Ed.: Update 201X-XX-XX below with correct date.
An NMDA-compliant NETCONF server MUST support the operational state An NMDA-compliant NETCONF server MUST implement the module
datastore and it MUST implement at least revision 201X-XX-XX of the "ietf-netconf-nmda" defined in this document, MUST support the
"ietf-yang-library" module defined in [I-D.ietf-netconf-rfc7895bis]. operational state datastore, and it MUST implement at least revision
201X-XX-XX of the "ietf-yang-library" module defined in
[I-D.ietf-netconf-rfc7895bis].
A NETCONF client can discover which datastores and YANG modules the A NETCONF client can discover which datastores and YANG modules the
server supports by reading the YANG library information from the server supports by reading the YANG library information from the
operational state datastore. operational state datastore.
The server MUST advertise the following capability in the <hello> The server MUST advertise the following capability in the <hello>
message (line breaks and whitespaces are used for formatting reasons message (line breaks and whitespaces are used for formatting reasons
only): only):
urn:ietf:params:netconf:capability:yang-library:1.1? urn:ietf:params:netconf:capability:yang-library:1.1?
skipping to change at page 5, line 37 skipping to change at page 5, line 37
The <get-data> operation accepts a content filter parameter, similar The <get-data> operation accepts a content filter parameter, similar
to the "filter" parameter of <get-config>, but using explicit nodes to the "filter" parameter of <get-config>, but using explicit nodes
for subtree filtering ("subtree-filter") and XPath filtering for subtree filtering ("subtree-filter") and XPath filtering
("xpath-filter"). ("xpath-filter").
The "config-filter" parameter can be used to retrieve only "config The "config-filter" parameter can be used to retrieve only "config
true" or "config false" nodes. true" or "config false" nodes.
The "origin-filter" parameter, which can be present multiple times, The "origin-filter" parameter, which can be present multiple times,
selects nodes matching any of the given values. The selects nodes equal to or derived from any of the given values. The
"negated-origin-filter", which can be present multiple times, selects "negated-origin-filter", which can be present multiple times, selects
nodes that do not match all given values. The "origin-filter" and nodes that do are not equal or derived from any of the given values.
"negated-origin-filter" parameters cannot be used together. The "origin-filter" and "negated-origin-filter" parameters cannot be
used together.
The "max-depth" parameter can be used by the client to limit the The "max-depth" parameter can be used by the client to limit the
number of sub-tree levels that are returned in the reply. number of sub-tree levels that are returned in the reply.
3.1.1.1. With-defaults interactions 3.1.1.1. Origin Metadata Attribute
The <get-data> operation defines a parameter named "with-origin",
which if present, requests that the server includes "origin" metadata
annotations 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 Section 4). 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 [RFC8342].
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 [RFC8342].
The "with-origin" parameter is OPTIONAL to support. It is identified
with the feature "origin".
3.1.1.2. With-defaults interactions
If the "with-defaults" capability is supported by the server, then If the "with-defaults" capability is supported by the server, then
the "with-defaults" parameter, defined in [RFC6243], is supported for the "with-defaults" parameter, defined in [RFC6243], is supported for
<get-data> operations that target conventional configuration <get-data> operations that target conventional configuration
datastores. datastores.
The "with-defaults" parameter is optional to support for <get-data> The "with-defaults" parameter is OPTIONAL to support for <get-data>
operations that target <operational>. The associated capability to operations that target <operational>. The associated capability to
indicate a server's support is identified with the URI: indicate a server's support is identified with the URI:
urn:ietf:params:netconf:capability:with-operational-defaults:1.0 urn:ietf:params:netconf:capability:with-operational-defaults:1.0
If the "with-defaults" parameter is supported for <get-data> If the "with-defaults" parameter is supported for <get-data>
operations on <operational>, then all retrieval modes specified in operations on <operational>, then all retrieval modes specified in
either the 'basic-mode' or 'also-supported' parameters of the either the 'basic-mode' or 'also-supported' parameters of the
"with-defaults" capability are permitted. The behavior of the "with-defaults" capability are permitted. The behavior of the
"with-defaults" parameter for <operational> is defined as below: "with-defaults" parameter for <operational> is defined as below:
skipping to change at page 6, line 32 skipping to change at page 7, line 10
value is being used by the server. If the "with-defaults" value is being used by the server. If the "with-defaults"
parameter is set to "report-all-tagged", any values that match the parameter is set to "report-all-tagged", any values that match the
schema default are tagged with additional metadata, as described schema default are tagged with additional metadata, as described
in [RFC6243] section 3.4. in [RFC6243] section 3.4.
o If the "with-defaults" parameter is set to "trim", all "in use" o If the "with-defaults" parameter is set to "trim", all "in use"
values are returned, except that the output is filtered to exclude values are returned, except that the output is filtered to exclude
any values that match the default defined in the YANG schema. any values that match the default defined in the YANG schema.
Support for "with-defaults" in <get-data> operations on any datastore Support for "with-defaults" in <get-data> operations on any datastore
not defined in [RFC8342] SHOULD be defined by the specification for not defined in [RFC8342] should be defined by the specification for
the datastore. the datastore.
3.1.1.2. Origin Metadata Attribute
The <get-data> operation defines a parameter named "with-origin",
which if present, requests that the server includes "origin" metadata
annotations 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 Section 4). 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 [RFC8342].
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 [RFC8342].
The "with-origin" parameter is optional to support. It is identified
with the feature "origin".
3.1.1.3. Example: Retrieving an entire subtree from <running> 3.1.1.3. Example: Retrieving an entire subtree from <running>
The following example shows the <get-data> version of the The following example shows the <get-data> version of the
<get-config> example shown in Section 7.1 of [RFC6241]. <get-config> example shown in Section 7.1 of [RFC6241], which selects
the entire "/users" subtree:
<rpc message-id="101" <rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda" <get-data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores"> xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
<datastore>ds:running</datastore> <datastore>ds:running</datastore>
<subtree-filter> <subtree-filter>
<top xmlns="http://example.com/schema/1.2/config"> <top xmlns="http://example.com/schema/1.2/config">
<users/> <users/>
</top> </top>
skipping to change at page 8, line 5 skipping to change at page 8, line 5
<dept>1</dept> <dept>1</dept>
<id>1</id> <id>1</id>
</company-info> </company-info>
</user> </user>
<!-- additional <user> elements appear here... --> <!-- additional <user> elements appear here... -->
</users> </users>
</top> </top>
</data> </data>
</rpc-reply> </rpc-reply>
3.1.1.4. Example: Retrieving a filtered subtree from <operational>
The following example shows how the "origin-filter" can be used to
retrieve nodes from <operational>. The example uses the fictional
data model defined in Appendix C of [RFC8342].
<rpc message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores"
xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
<datastore>ds:operational</datastore>
<subtree-filter>
<bgp xmlns="http://example.com/ns/bgp"/>
</subtree-filter>
<origin-filter>or:intended</origin-filter>
<origin-filter>or:system</origin-filter>
<with-origin/>
</get-data>
</rpc>
<rpc-reply message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda">
<bgp xmlns="http://example.com/ns/bgp"
xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
or:origin="or:intended">
<peer>
<name>2001:db8::2:3</name>
<local-port or:origin="or:system">60794</local-port>
<state>established</state>
</peer>
</bgp>
</data>
</rpc-reply>
3.1.2. The <edit-data> Operation 3.1.2. The <edit-data> Operation
The <edit-data> operation changes the contents of a writable The <edit-data> operation changes the contents of a writable
datastore, similar to the <edit-config> operation defined in datastore, similar to the <edit-config> operation defined in
[RFC6241], but with additional flexibility in naming the target [RFC6241], but with additional flexibility in naming the target
datastore. If an <edit-data> operation is invoked on a non-writable datastore. If an <edit-data> operation is invoked on a non-writable
datastore, then an error is returned, as specified in datastore, then an error is returned, as specified in
"ietf-netconf-nmda" (see Section 4). "ietf-netconf-nmda" (see Section 4).
+---x edit-data +---x edit-data
skipping to change at page 8, line 27 skipping to change at page 9, line 18
+---w default-operation? enumeration +---w default-operation? enumeration
+---w (edit-content) +---w (edit-content)
+--:(config) +--:(config)
| +---w config? <anydata> | +---w config? <anydata>
+--:(url) +--:(url)
+---w url? inet:uri {nc:url}? +---w url? inet:uri {nc:url}?
The "datastore" parameter is a datastore identity that indicates the The "datastore" parameter is a datastore identity that indicates the
desired target datastore where changes should be made. desired target datastore where changes should be made.
The "default-operation" parameter is a copy of the The "default-operation" parameter selects the default operation to
"default-operation" parameter of the <edit-config> operation. use. It is a copy of the "default-operation" parameter of the
<edit-config> operation.
The "edit-content" choice mirrors the "edit-content" choice of the The "edit-content" parameter specifies the content for the edit
<edit-config> operation. Note, however, that the "config" element in operation. It mirrors the "edit-content" choice of the <edit-config>
the "edit-content" choice of <edit-data> uses "anydata" (introduced operation. Note, however, that the "config" element in the
in YANG 1.1) while the "config" element in the "edit-content" choice "edit-content" choice of <edit-data> uses "anydata" (introduced in
of <edit-config> used "anyxml". 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 The <edit-data> operation does not support the "error-option" and the
"test-option" parameters that were part of the <edit-config> "test-option" parameters that were part of the <edit-config>
operation. The error behaviour of <edit-data> corresponds to the operation. The error behaviour of <edit-data> corresponds to the
"error-option" "rollback-on-error". "error-option" "rollback-on-error".
If the "with-defaults" capability is supported by the server, the If the "with-defaults" capability is supported by the server, the
semantics of editing modes is the same as for <edit-config>, as semantics of editing modes is the same as for <edit-config>, as
described in section 4.5.2 of [RFC6243]. described in section 4.5.2 of [RFC6243].
Semantics for "with-defaults" in <edit-data> operations on any non Semantics for "with-defaults" in <edit-data> operations on any non
conventional configuration datastores SHOULD be defined by the conventional configuration datastores should be defined by the
specification for the datastore. specification for the datastore.
3.1.2.1. Example: Setting a leaf of an interface in <running> 3.1.2.1. Example: Setting a leaf of an interface in <running>
The following example shows the <edit-data> version of the first The following example shows the <edit-data> version of the first
<edit-config> example in Section 7.2 of [RFC6241], setting the MTU to <edit-config> example in Section 7.2 of [RFC6241], setting the MTU to
1500 on an interface named "Ethernet0/0" in the running configuration 1500 on an interface named "Ethernet0/0" in the running configuration
datastore. datastore.
<rpc message-id="102" <rpc message-id="103"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda" <edit-data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores"> xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
<datastore>ds:running</datastore> <datastore>ds:running</datastore>
<config> <config>
<top xmlns="http://example.com/schema/1.2/config"> <top xmlns="http://example.com/schema/1.2/config">
<interface> <interface>
<name>Ethernet0/0</name> <name>Ethernet0/0</name>
<mtu>1500</mtu> <mtu>1500</mtu>
</interface> </interface>
</top> </top>
</config> </config>
</edit-data> </edit-data>
</rpc> </rpc>
<rpc-reply message-id="102" <rpc-reply message-id="103"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/> <ok/>
</rpc-reply> </rpc-reply>
The other <edit-config> examples shown in Section 7.2 can be The other <edit-config> examples shown in Section 7.2 can be
translated to <edit-data> examples in a similar way. translated to <edit-data> examples in a similar way.
3.2. Augmentations to NETCONF Operations 3.2. Augmentations to NETCONF Operations
Several of the operations defined in the base NETCONF YANG module Several of the operations defined in the base NETCONF YANG module
skipping to change at page 10, line 8 skipping to change at page 10, line 47
"ietf-netconf-nmda" (see Section 4). "ietf-netconf-nmda" (see Section 4).
4. NETCONF Datastores YANG Module 4. NETCONF Datastores YANG Module
This module imports definitions from [RFC6991], [RFC6241], [RFC6243], This module imports definitions from [RFC6991], [RFC6241], [RFC6243],
and [RFC8342]. and [RFC8342].
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-netconf-nmda@2018-05-22" <CODE BEGINS> file "ietf-netconf-nmda@2018-10-09"
module ietf-netconf-nmda { module ietf-netconf-nmda {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"; namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-nmda";
prefix ncds; prefix ncds;
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 11, line 35 skipping to change at page 12, line 27
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX This version of this YANG module is part of RFC XXXX
(http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself (http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself
for full legal notices."; 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 2018-05-22 { revision 2018-10-09 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: NETCONF Extensions to Support the Network Management "RFC XXXX: NETCONF Extensions to Support the Network Management
Datastore Architecture"; Datastore Architecture";
} }
feature origin { feature origin {
description description
"Indicates that the server supports the 'origin' annotation."; "Indicates that the server supports the 'origin' annotation.";
skipping to change at page 12, line 11 skipping to change at page 13, line 4
feature with-defaults { feature with-defaults {
description description
"NETCONF :with-defaults capability; If the server advertises "NETCONF :with-defaults capability; If the server advertises
the :with-defaults capability for a session, then this the :with-defaults capability for a session, then this
feature must also be enabled for that session. Otherwise, feature must also be enabled for that session. Otherwise,
this feature must not be enabled."; this feature must not be enabled.";
reference reference
"RFC 6243: With-defaults Capability for NETCONF, section 4; and "RFC 6243: With-defaults Capability for NETCONF, section 4; and
RFC XXXX: NETCONF Extensions to Support the Network Management RFC XXXX: NETCONF Extensions to Support the Network Management
Datastore Architecture, section 3.1.1.1."; Datastore Architecture, section 3.1.1.1.";
} }
rpc get-data { rpc get-data {
description description
"Retrieve data from an NMDA datastore. The content returned "Retrieve data from an NMDA datastore. The content returned
by get-data must satisfy all filters, i.e., the filter by get-data must satisfy all filters, i.e., the filter
criteria are logically ANDed. criteria are logically ANDed.
Any ancestor nodes (including list keys) of nodes selected by
the filters are included in the response.
The 'with-origin' parameter is only valid for an operational The 'with-origin' parameter is only valid for an operational
datastore. If 'with-origin' is used with an invalid datastore, datastore. If 'with-origin' is used with an invalid datastore,
then the server MUST return an <rpc-error> element with an then the server MUST return an <rpc-error> element with an
<error-tag> value of 'invalid-value'. <error-tag> value of 'invalid-value'.
The 'with-defaults' parameter only applies to the operational The 'with-defaults' parameter only applies to the operational
datastore if the NETCONF :with-defaults and datastore if the NETCONF :with-defaults and
:with-operational-defaults capabilities are both advertised. :with-operational-defaults capabilities are both advertised.
If the 'with-defaults' parameter is present in a request for If the 'with-defaults' parameter is present in a request for
which it is not supported, then the server MUST return an which it is not supported, then the server MUST return an
skipping to change at page 13, line 41 skipping to change at page 14, line 36
o The context node is the root node of the target o The context node is the root node of the target
datastore."; datastore.";
} }
} }
leaf config-filter { leaf config-filter {
type boolean; type boolean;
description description
"Filter for nodes with the given value for their "Filter for nodes with the given value for their
'config' property."; 'config' property. If this leaf is not present, all
nodes are selected.
For example, when this leaf is set to 'true', only 'config
true' nodes are selected.";
} }
choice origin-filters { choice origin-filters {
when 'derived-from-or-self(datastore, "ds:operational")'; when 'derived-from-or-self(datastore, "ds:operational")';
if-feature origin; if-feature origin;
description description
"Filters based on the 'origin' annotation."; "Filters based on the 'origin' annotation.";
leaf-list origin-filter { leaf-list origin-filter {
type or:origin-ref; type or:origin-ref;
description description
"Filter based on the 'origin' annotation. A node matches "Filter based on the 'origin' annotation. A node matches
the filter if its 'origin' annotation is derived from or the filter if its 'origin' annotation is derived from or
equal to any of the given filter values."; equal to any of the given filter values.";
} }
leaf-list negated-origin-filter { leaf-list negated-origin-filter {
type or:origin-ref; type or:origin-ref;
description description
"Filter based on the 'origin' annotation. A node matches "Filter based on the 'origin' annotation. A node matches
the filter if its 'origin' annotation is not derived the filter if its 'origin' annotation is not derived
from and not equal to all of the given filter values."; from and not equal to any of the given filter values.";
} }
} }
leaf max-depth { leaf max-depth {
type union { type union {
type uint16 { type uint16 {
range "1..65535"; range "1..65535";
} }
type enumeration { type enumeration {
enum "unbounded" { enum "unbounded" {
description description
"All descendant nodes are included."; "All descendant nodes are included.";
} }
} }
} }
default "unbounded"; default "unbounded";
description description
"For each node selected by the filter, this parameter "For each node selected by the filters, this parameter
selects how many conceptual sub-tree levels should be selects how many conceptual sub-tree levels should be
returned in the reply. If the depth is 1, the reply returned in the reply. If the depth is 1, the reply
includes just the selected nodes but no children. If the includes just the selected nodes but no children. If the
depth is 'unbounded', all descendant nodes are included."; depth is 'unbounded', all descendant nodes are included.";
} }
leaf with-origin { leaf with-origin {
when 'derived-from-or-self(../datastore, "ds:operational")'; when 'derived-from-or-self(../datastore, "ds:operational")';
if-feature origin; if-feature origin;
type empty; type empty;
skipping to change at page 18, line 8 skipping to change at page 19, line 8
<CODE ENDS> <CODE ENDS>
5. IANA Considerations 5. IANA Considerations
This document registers two capability identifier URNs in the This document registers two capability identifier URNs in the
"Network Configuration Protocol (NETCONF) Capability URNs" registry: "Network Configuration Protocol (NETCONF) Capability URNs" registry:
Index Index
Capability Identifier Capability Identifier
--------------------- ---------------------
:yang-library :yang-library:1.1
urn:ietf:params:netconf:capability:yang-library:1.1 urn:ietf:params:netconf:capability:yang-library:1.1
:with-operational-defaults :with-operational-defaults
urn:ietf:params:netconf:capability:with-operational-defaults:1.0 urn:ietf:params:netconf:capability:with-operational-defaults:1.0
This document registers a URI in the "IETF XML Registry" [RFC3688]. This document registers a URI in the "IETF XML Registry" [RFC3688].
Following the format in RFC 3688, the following registration has been Following the format in RFC 3688, the following registration has been
made. made.
URI: urn:ietf:params:xml:ns:yang:ietf-netconf-nmda URI: urn:ietf:params:xml:ns:yang:ietf-netconf-nmda
skipping to change at page 19, line 12 skipping to change at page 20, line 12
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-netconf-rfc7895bis] [I-D.ietf-netconf-rfc7895bis]
Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K.,
and R. Wilton, "YANG Library", draft-ietf-netconf- and R. Wilton, "YANG Library", draft-ietf-netconf-
rfc7895bis-06 (work in progress), April 2018. rfc7895bis-06 (work in progress), April 2018.
[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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, <https://www.rfc-editor.org/info/ DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
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>.
[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, <https://www.rfc-
editor.org/info/rfc6020>. editor.org/info/rfc6020>.
skipping to change at page 19, line 38 skipping to change at page 20, line 38
<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>.
[RFC6243] Bierman, A. and B. Lengyel, "With-defaults Capability for [RFC6243] Bierman, A. and B. Lengyel, "With-defaults Capability for
NETCONF", RFC 6243, DOI 10.17487/RFC6243, June 2011, NETCONF", RFC 6243, DOI 10.17487/RFC6243, June 2011,
<https://www.rfc-editor.org/info/rfc6243>. <https://www.rfc-editor.org/info/rfc6243>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc- RFC 6991, DOI 10.17487/RFC6991, July 2013,
editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[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, DOI 10.17487/ Access Control Model", STD 91, RFC 8341,
RFC8341, March 2018, <https://www.rfc-editor.org/info/ DOI 10.17487/RFC8341, March 2018, <https://www.rfc-
rfc8341>. 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>.
7.2. Informative References 7.2. Informative References
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
 End of changes. 30 change blocks. 
72 lines changed or deleted 122 lines changed or added

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