draft-ietf-netconf-nmda-netconf-02.txt   draft-ietf-netconf-nmda-netconf-03.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: July 21, 2018 P. Shafer Expires: August 9, 2018 P. Shafer
K. Watsen K. Watsen
Juniper Networks Juniper Networks
R. Wilton R. Wilton
Cisco Systems Cisco Systems
January 17, 2018 February 5, 2018
NETCONF Extensions to Support the Network Management Datastore NETCONF Extensions to Support the Network Management Datastore
Architecture Architecture
draft-ietf-netconf-nmda-netconf-02 draft-ietf-netconf-nmda-netconf-03
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 I-D.ietf-netmod-revised-datastores. defined in I-D.ietf-netmod-revised-datastores.
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 July 21, 2018. This Internet-Draft will expire on August 9, 2018.
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 . . . . . . . . . . . . . . 6 3.1.2. The <edit-data> Operation . . . . . . . . . . . . . . 6
3.2. Augmentations to NETCONF Operations . . . . . . . . . . . 6 3.2. Augmentations to NETCONF Operations . . . . . . . . . . . 7
4. NETCONF Datastores YANG Module . . . . . . . . . . . . . . . 7 4. NETCONF Datastores YANG Module . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . 16 7.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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 [I-D.ietf-netmod-revised-datastores]. defined in [I-D.ietf-netmod-revised-datastores].
This document updates [RFC6241] in order to enable NETCONF clients to This document updates [RFC6241] in order to enable NETCONF clients to
skipping to change at page 3, line 13 skipping to change at page 3, line 13
clients to both discover which datastores are supported by the clients to both discover which datastores are supported by the
NETCONF server, as well as determine which modules are supported in NETCONF server, as well as determine which modules are supported in
each datastore. The update requires NETCONF servers implementing the each datastore. The update requires NETCONF servers implementing the
NMDA to support [I-D.ietf-netconf-rfc7895bis]. NMDA to support [I-D.ietf-netconf-rfc7895bis].
1.1. Terminology 1.1. Terminology
This document uses the terminology defined by the NMDA This document uses the terminology defined by the NMDA
[I-D.ietf-netmod-revised-datastores]. [I-D.ietf-netmod-revised-datastores].
The following term is defined in [I-D.ietf-netconf-rfc7895bis]:
o YANG library checksum
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] [RFC8174] when, and only when, they appear in all 14, [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
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
[I-D.ietf-netmod-yang-tree-diagrams]. [I-D.ietf-netmod-yang-tree-diagrams].
skipping to change at page 3, line 43 skipping to change at page 3, line 47
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?
revision=<date>&checksum=<checksum-value> revision=<date>&checksum=<checksum-value>
The parameter "revision" has the same value as the revision date of The parameter "revision" has the same value as the revision date of
the "ietf-yang-library" module implemented by the server. This the "ietf-yang-library" module implemented by the server. This
parameter MUST be present. parameter MUST be present.
The parameter "checksum" has the same value as the leaf The parameter "checksum" contains the YANG library checksum
"/yang-library/checksum" from "ietf-yang-library". This parameter [I-D.ietf-netconf-rfc7895bis]. This parameter MUST be present.
MUST be present.
With this mechanism, a client can cache the supported modules for a With this mechanism, a client can cache the supported modules for a
server and only update the cache if the "checksum" value in the server and only update the cache if the "checksum" value in the
<hello> message changes. <hello> message changes.
This document updates [RFC7950], Section 5.6.4, to allow servers to This document updates [RFC7950], Section 5.6.4, to allow servers to
advertise the capability :yang-library:1.1 instead of :yang- advertise the capability :yang-library:1.1 instead of :yang-
library:1.0, and to implement the subtree "/yang-library" library:1.0, and to implement the subtree "/yang-library"
[I-D.ietf-netconf-rfc7895bis] instead of "/modules-state". [I-D.ietf-netconf-rfc7895bis] instead of "/modules-state".
skipping to change at page 4, line 45 skipping to change at page 5, line 14
+---x get-data +---x get-data
+---w input +---w input
| +---w datastore ds:datastore-ref | +---w datastore ds:datastore-ref
| +---w (filter-spec)? | +---w (filter-spec)?
| | +--:(subtree-filter) | | +--:(subtree-filter)
| | | +---w subtree-filter? <anydata> | | | +---w subtree-filter? <anydata>
| | +--:(xpath-filter) | | +--:(xpath-filter)
| | +---w xpath-filter? yang:xpath1.0 {nc:xpath}? | | +---w xpath-filter? yang:xpath1.0 {nc:xpath}?
| +---w config-filter? boolean | +---w config-filter? boolean
| +---w origin-filter? identityref {origin}? | +---w origin-filter* identityref {origin}?
| +---w max-depth? union | +---w max-depth? union
| +---w with-origin? empty {origin}? | +---w with-origin? empty {origin}?
| +---w with-defaults? with-defaults-mode | +---w with-defaults? with-defaults-mode
+--ro output +--ro output
+--ro data? <anydata> +--ro data? <anydata>
The "datastore" parameter indicates the datastore which is the source The "datastore" parameter indicates the datastore which is the source
of the data to be retrieved. This is a datastore identity. of the data to be retrieved. This is a datastore identity.
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. The "origin-filter" can be used to true" or "config false" nodes. The "origin-filter" can be used to
select nodes matching a given "origin" value. select nodes matching any of a set of given "origin" values.
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.
The <get-data> operation also supports the "with-defaults" parameter The <get-data> operation also supports the "with-defaults" parameter
as defined in [RFC6243]. The supported values follow the constraints as defined in [RFC6243]. The supported values follow the constraints
given by the "with-defaults" capability. given by the "with-defaults" capability.
The "with-defaults" parameter does not apply when interacting with an The "with-defaults" parameter does not apply when interacting with an
operational datastore. This means that all "in use" values, as operational datastore. This means that all "in use" values, as
skipping to change at page 7, line 17 skipping to change at page 7, line 39
"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 [I-D.ietf-netmod-revised-datastores]. and [I-D.ietf-netmod-revised-datastores].
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-01-17.yang" <CODE BEGINS> file "ietf-netconf-nmda@2018-02-05.yang"
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;
} }
import ietf-inet-types { import ietf-inet-types {
skipping to change at page 8, line 34 skipping to change at page 9, line 7
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions 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). (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.";
revision 2018-01-17 { revision 2018-02-05 {
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 9, line 21 skipping to change at page 9, line 43
The 'with-defaults' parameter does not apply to operational The 'with-defaults' parameter does not apply to operational
datastores. If the 'with-defaults' parameter is present in a datastores. If the 'with-defaults' parameter is present in a
request to an operational datastore, then the server MUST request to an operational datastore, then the server MUST
return an <rpc-error> element with an <error-tag> value of return an <rpc-error> element with an <error-tag> value of
'invalid-value'."; 'invalid-value'.";
input { input {
leaf datastore { leaf datastore {
type ds:datastore-ref; type ds:datastore-ref;
mandatory true; mandatory true;
description description
"Datastore from which to retrieve data."; "Datastore from which to retrieve data.
If the datastore is not supported by the server, then the
server MUST return an <rpc-error> element with an
<error-tag> value of 'invalid-value'.";
} }
choice filter-spec { choice filter-spec {
description description
"The content filter specification for this request."; "The content filter specification for this request.";
anydata subtree-filter { anydata subtree-filter {
description description
"This parameter identifies the portions of the "This parameter identifies the portions of the
target datastore to retrieve."; target datastore to retrieve.";
skipping to change at page 10, line 22 skipping to change at page 10, line 48
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.";
} }
leaf origin-filter { leaf-list origin-filter {
when 'derived-from-or-self(../datastore, "or:operational")'; when 'derived-from-or-self(../datastore, "ds:operational")';
if-feature origin; if-feature origin;
type identityref { type identityref {
base or:origin; base or:origin;
} }
description description
"Filter based on 'origin' annotation. A node matches the "Filter based on 'origin' annotation. A node matches the
filter if its 'origin' annotation is derived from or filter if its 'origin' annotation is derived from or
equal to the given filter value."; 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";
} }
skipping to change at page 11, line 4 skipping to change at page 11, line 31
default "unbounded"; default "unbounded";
description description
"For each node selected by the filter, this parameter "For each node selected by the filter, 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, "or:operational")'; when 'derived-from-or-self(../datastore, "ds:operational")';
if-feature origin; if-feature origin;
type empty; type empty;
description description
"If this parameter is present, the server will return "If this parameter is present, the server will return
the 'origin' annotation for the nodes that has one."; the 'origin' annotation for the nodes that has one.";
} }
uses ncwd:with-defaults-parameters; uses ncwd:with-defaults-parameters;
} }
skipping to change at page 11, line 36 skipping to change at page 12, line 16
rpc edit-data { rpc edit-data {
description description
"Edit data in an NMDA datastore."; "Edit data in an NMDA datastore.";
input { input {
leaf datastore { leaf datastore {
type ds:datastore-ref; type ds:datastore-ref;
description description
"Datastore which is the target of the edit-data operation. "Datastore which is the target of the edit-data operation.
If the target datastore is not writable, then the server If the target datastore is not writable, or is not
MUST return an <rpc-error> element with an <error-tag> supported by the server, then the server MUST return an
value of 'invalid-value'"; <rpc-error> element with an <error-tag> value of
'invalid-value'.";
} }
leaf default-operation { leaf default-operation {
type enumeration { type enumeration {
enum "merge" { enum "merge" {
description description
"The default operation is merge."; "The default operation is merge.";
} }
enum "replace" { enum "replace" {
description description
"The default operation is replace."; "The default operation is replace.";
skipping to change at page 12, line 46 skipping to change at page 13, line 26
description description
"Add NMDA Datastore as target."; "Add NMDA Datastore as target.";
leaf datastore { leaf datastore {
type ds:datastore-ref; type ds:datastore-ref;
description description
"Datastore to lock. "Datastore to lock.
If the lock operation is not supported by the server on the If the lock operation is not supported by the server on the
specified target datastore, then the server MUST return an specified target datastore, then the server MUST return an
<rpc-error> element with an <error-tag> value of <rpc-error> element with an <error-tag> value of
'invalid-value'"; 'invalid-value'.";
} }
} }
augment "/nc:unlock/nc:input/nc:target/nc:config-target" { augment "/nc:unlock/nc:input/nc:target/nc:config-target" {
description description
"Add NMDA Datastore as target."; "Add NMDA Datastore as target.";
leaf datastore { leaf datastore {
type ds:datastore-ref; type ds:datastore-ref;
description description
"Datastore to unlock. "Datastore to unlock.
If the unlock operation is not supported by the server on the If the unlock operation is not supported by the server on the
specified target datastore, then the server MUST return an specified target datastore, then the server MUST return an
<rpc-error> element with an <error-tag> value of <rpc-error> element with an <error-tag> value of
'invalid-value'"; 'invalid-value'.";
} }
} }
/* /*
* Augment the validate operation with a * Augment the validate operation with a
* "datastore" parameter. * "datastore" parameter.
*/ */
augment "/nc:validate/nc:input/nc:source/nc:config-source" { augment "/nc:validate/nc:input/nc:source/nc:config-source" {
description description
skipping to change at page 13, line 25 skipping to change at page 14, line 4
} }
/* /*
* Augment the validate operation with a * Augment the validate operation with a
* "datastore" parameter. * "datastore" parameter.
*/ */
augment "/nc:validate/nc:input/nc:source/nc:config-source" { augment "/nc:validate/nc:input/nc:source/nc:config-source" {
description description
"Add NMDA Datastore as source."; "Add NMDA Datastore as source.";
leaf datastore { leaf datastore {
type ds:datastore-ref; type ds:datastore-ref;
description description
"Datastore to validate. "Datastore to validate.
If the validate operation is not supported by the server on If the validate operation is not supported by the server on
the specified target datastore, then the server MUST return the specified target datastore, then the server MUST return
an <rpc-error> element with an <error-tag> value of an <rpc-error> element with an <error-tag> value of
'invalid-value'"; 'invalid-value'.";
} }
} }
} }
<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
 End of changes. 22 change blocks. 
28 lines changed or deleted 36 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/