draft-ietf-netconf-nmda-netconf-03.txt   draft-ietf-netconf-nmda-netconf-04.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: August 9, 2018 P. Shafer Expires: September 2, 2018 P. Shafer
K. Watsen K. Watsen
Juniper Networks Juniper Networks
R. Wilton R. Wilton
Cisco Systems Cisco Systems
February 5, 2018 March 1, 2018
NETCONF Extensions to Support the Network Management Datastore NETCONF Extensions to Support the Network Management Datastore
Architecture Architecture
draft-ietf-netconf-nmda-netconf-03 draft-ietf-netconf-nmda-netconf-04
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 August 9, 2018. This Internet-Draft will expire on September 2, 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 29 skipping to change at page 2, line 29
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 . . . . . . . . . . . . . . 8
3.2. Augmentations to NETCONF Operations . . . . . . . . . . . 7 3.2. Augmentations to NETCONF Operations . . . . . . . . . . . 9
4. NETCONF Datastores YANG Module . . . . . . . . . . . . . . . 7 4. NETCONF Datastores YANG Module . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . 15 7.1. Normative References . . . . . . . . . . . . . . . . . . 19
7.2. Informative References . . . . . . . . . . . . . . . . . 16 7.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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
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 5, line 5 skipping to change at page 5, line 5
to the <get-config> and <edit-config> operations but they can work on to the <get-config> and <edit-config> operations but they can work on
an extensible set of datastores. an extensible set of datastores.
3.1.1. The <get-data> Operation 3.1.1. The <get-data> Operation
The <get-data> operation retrieves data from a specific NMDA The <get-data> operation retrieves data from a specific NMDA
datastore. This operation is similar to NETCONF's <get-config> datastore. This operation is similar to NETCONF's <get-config>
operation defined in [RFC6241], but it adds the flexibility to select operation defined in [RFC6241], but it adds the flexibility to select
the source datastore. the source datastore.
+---x get-data +---x get-data
+---w input +---w input
| +---w datastore ds:datastore-ref | +---w datastore ds:datastore-ref
| +---w (filter-spec)? | +--(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}? | +--(origin-filters)? {origin}?
| +---w max-depth? union | | +--:(origin-filter)
| +---w with-origin? empty {origin}? | | | +---w origin-filter* or:origin-ref
| +---w with-defaults? with-defaults-mode | | +--:(negated-origin-filter)
+--ro output | | +---w negated-origin-filter* or:origin-ref
+--ro data? <anydata> | +---w max-depth? union
| +---w with-origin? empty {origin}?
| +---w with-defaults? with-defaults-mode
+--ro output
+--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.
select nodes matching any of a set of given "origin" values.
The "origin-filter" parameter, which can be present multiple times,
selects nodes matching any of the given values. The
"negated-origin-filter", which can be present multiple times, selects
nodes that do not match all given values. 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.
The <get-data> operation also supports the "with-defaults" parameter 3.1.1.1. With-defaults interactions
as defined in [RFC6243]. The supported values follow the constraints
given by the "with-defaults" capability.
The "with-defaults" parameter does not apply when interacting with an If the "with-defaults" capability is supported by the server, then
operational datastore. This means that all "in use" values, as the "with-defaults" parameter, defined in [RFC6243], is supported for
defined in [I-D.ietf-netmod-revised-datastores] section 5.3, are <get-data> operations that target conventional configuration
returned from the operational state datastore, even if a node happens datastores.
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 Section 4).
3.1.1.1. Origin Metadata Attribute The "with-defaults" parameter is optional to support for <get-data>
operations that target <operational>. The associated capability to
indicate a server's support is identified with the URI:
urn:ietf:params:netconf:capability:with-operational-defaults:1.0
If the "with-defaults" parameter is supported for <get-data>
operations on <operational>, then all retrieval modes specified in
either the 'basic-mode' or 'also-supported' parameters of the
"with-defaults" capability are permitted. The behavior of the
"with-defaults" parameter for <operational> is defined as below:
o If no "with-defaults" parameter is specified, or if it is set to
"explicit", "report-all", or "report-all-tagged", then the "in
use" values, as defined in [I-D.ietf-netmod-revised-datastores]
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 set to "report-all-tagged", any
values that match the schema default are tagged with additional
metadata, as described in [RFC6243] section 3.4.
o If the "with-defaults" parameter is set to "trim", all "in use"
values are returned, except that the output is filtered to exclude
any values that match the default defined in the YANG schema.
Support for "with-defaults" in <get-data> operations on any datastore
not defined in [I-D.ietf-netmod-revised-datastores] SHOULD be defined
by the specification for the datastore.
3.1.1.2. Origin Metadata Attribute
The <get-data> operation defines a parameter named "with-origin", The <get-data> operation defines a parameter named "with-origin",
which if present, requests that the server includes "origin" metadata which if present, requests that the server includes "origin" metadata
anotations in its response, as detailed in the NMDA. This parameter annotations in its response, as detailed in the NMDA. This parameter
is only valid for the operational state datastore and any datastores is only valid for the operational state datastore and any datastores
with identities derived from the "operational" identity. Otherwise, with identities derived from the "operational" identity. Otherwise,
if an invalid datastore is specified then an error is returned, as if an invalid datastore is specified then an error is returned, as
specified in "ietf-netconf-nmda" (see Section 4). Note that "origin" specified in "ietf-netconf-nmda" (see Section 4). Note that "origin"
metadata annotations are not included in a response unless a client metadata annotations are not included in a response unless a client
explicitly requests them. explicitly requests them.
Data in the operational state datastore can come from multiple Data in the operational state datastore can come from multiple
sources. The server should return the most accurate value for the sources. The server should return the most accurate value for the
"origin" metadata annotation as possible, indicating the source of "origin" metadata annotation as possible, indicating the source of
the operational value, as specified in Section 5.3.4 of the operational value, as specified in Section 5.3.4 of
[I-D.ietf-netmod-revised-datastores]. [I-D.ietf-netmod-revised-datastores].
When encoding the origin metadata annotation for a hierarchy of When encoding the origin metadata annotation for a hierarchy of
returned nodes, the annotation may be omitted for a child node when returned nodes, the annotation may be omitted for a child node when
the value matches that of the parent node, as described in the the value matches that of the parent node, as described in the
"ietf-origin" YANG module [I-D.ietf-netmod-revised-datastores]. "ietf-origin" YANG module [I-D.ietf-netmod-revised-datastores].
The "with-origin" parameter is optional to support. It is identified The "with-origin" parameter is optional to support. It is identified
with the URI: with the feature "origin".
urn:ietf:params:netconf:capability:with-origin:1.0 3.1.1.3. Example: Retrieving an entire subtree from <running>
The following example shows the <get-data> version of the
<get-config> example shown in Section 7.1 of [RFC6241].
<rpc message-id="101"
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">
<datastore>ds:running</datastore>
<subtree-filter>
<top xmlns="http://example.com/schema/1.2/config">
<users/>
</top>
</subtree-filter>
</get-data>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda">
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>root</name>
<type>superuser</type>
<full-name>Charlie Root</full-name>
<company-info>
<dept>1</dept>
<id>1</id>
</company-info>
</user>
<!-- additional <user> elements appear here... -->
</users>
</top>
</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
+---w input +---w input
+---w datastore? ds:datastore-ref +---w datastore ds:datastore-ref
+---w default-operation? enumeration +---w default-operation? enumeration
+---w (edit-content) +--(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 is a copy of the
"default-operation" parameter of the <edit-config> operation. "default-operation" parameter of the <edit-config> operation.
The "edit-content" choice mirrors the "edit-content" choice of the The "edit-content" choice mirrors the "edit-content" choice of the
<edit-config> operation. Note, however, that the "config" element in <edit-config> operation. Note, however, that the "config" element in
the "edit-content" choice of <edit-data> uses "anydata" (introduced the "edit-content" choice of <edit-data> uses "anydata" (introduced
in YANG 1.1) while the "config" element in the "edit-content" choice in YANG 1.1) while the "config" element in the "edit-content" choice
of <edit-config> used "anyxml". 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. operation. The error behaviour of <edit-data> corresponds to the
"error-option" "rollback-on-error".
If the "with-defaults" capability is supported by the server, the
semantics of editing modes is the same as for <edit-config>, as
described in section 4.5.2 of [RFC6243].
Semantics for "with-defaults" in <edit-data> operations on any non
conventional configuration datastores SHOULD be defined by the
specification for the datastore.
3.1.2.1. Example: Setting a leaf of an interface in <running>
The following example shows the <edit-data> version of the first
<edit-config> example in Section 7.2 of [RFC6241], setting the MTU to
1500 on an interface named "Ethernet0/0" in the running configuration
datastore.
<rpc message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
<datastore>ds:running</datastore>
<config>
<top xmlns="http://example.com/schema/1.2/config">
<interface>
<name>Ethernet0/0</name>
<mtu>1500</mtu>
</interface>
</top>
</config>
</edit-data>
</rpc>
<rpc-reply message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
The other <edit-config> examples shown in Section 7.2 can be
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
"ietf-netconf" [RFC6241] may be used with new datastores. Hence, the "ietf-netconf" [RFC6241] may be used with new datastores. Hence, the
<lock>, <unlock>, and <validate> operations are augmented with a new <lock>, <unlock>, and <validate> operations are augmented with a new
"datastore" leaf that can select the desired datastore. If a <lock>, "datastore" leaf that can select the desired datastore. If a <lock>,
<unlock>, or <validate> operation is not supported on a particular <unlock>, or <validate> operation is not supported on a particular
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).
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-02-05.yang" <CODE BEGINS> file "ietf-netconf-nmda@2018-02-28.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;
} reference "RFC 6991: Common YANG Data Types.";
import ietf-inet-types { }
prefix inet; import ietf-inet-types {
} prefix inet;
import ietf-datastores { reference "RFC 6991: Common YANG Data Types.";
prefix ds; }
} import ietf-datastores {
import ietf-origin { prefix ds;
prefix or; // RFC Ed.: update the reference below with the actual RFC number
} reference "RFC XXXX: Network Management Datastore Architecture.";
import ietf-netconf { }
prefix nc; import ietf-origin {
} prefix or;
import ietf-netconf-with-defaults { // RFC Ed.: update the reference below with the actual RFC number
prefix ncwd; reference "RFC XXXX: Network Management Datastore Architecture.";
} }
import ietf-netconf {
prefix nc;
reference "RFC 6241: Network Configuration Protocol (NETCONF)";
}
import ietf-netconf-with-defaults {
prefix ncwd;
reference "RFC 6243: With-defaults Capability for NETCONF.";
}
organization organization
"IETF NETCONF Working Group"; "IETF NETCONF Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/netconf/> "WG Web: <https://datatracker.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org> WG List: <mailto:netconf@ietf.org>
Author: Martin Bjorklund Author: Martin Bjorklund
<mailto:mbj@tail-f.com> <mailto:mbj@tail-f.com>
Author: Juergen Schoenwaelder Author: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de> <mailto:j.schoenwaelder@jacobs-university.de>
Author: Phil Shafer Author: Phil Shafer
<mailto:phil@juniper.net> <mailto:phil@juniper.net>
Author: Kent Watsen Author: Kent Watsen
<mailto:kwatsen@juniper.net> <mailto:kwatsen@juniper.net>
Author: Rob Wilton Author: Rob Wilton
<rwilton@cisco.com>"; <rwilton@cisco.com>";
description description
"This YANG module defines a set of NETCONF operations to support "This YANG module defines a set of NETCONF operations to support
the Network Management Datastore Architecture (NMDA). the Network Management Datastore Architecture (NMDA).
Copyright (c) 2018 IETF Trust and the persons identified as Copyright (c) 2018 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject 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-02-05 { // RFC Ed.: update the date below with the date of RFC publication
description // and remove this note.
"Initial revision."; // RFC Ed.: replace XXXX with actual RFC number and remove this
reference // note.
"RFC XXXX: NETCONF Extensions to Support the Network Management revision 2018-02-28 {
Datastore Architecture"; description
} "Initial revision.";
reference
"RFC XXXX: NETCONF Extensions to Support the Network Management
Datastore Architecture";
}
feature origin { feature origin {
description description
"Indicates that the server supports the 'origin' annotation."; "Indicates that the server supports the 'origin' annotation.";
reference reference
"RFC XXXX: Network Management Datastore Architecture"; "RFC XXXX: Network Management Datastore Architecture";
} }
rpc get-data { feature with-defaults {
description description
"Retrieve data from an NMDA datastore. The content returned "NETCONF :with-defaults capability; If the server advertises
by get-data must satisfy all filters, i.e., the filter the :with-defaults capability for a session, then this
criteria are logically ANDed. feature must also be enabled for that session. Otherwise,
this feature must not be enabled.";
reference
"RFC 6243: With-defaults Capability for NETCONF, section 4; and
RFC XXXX: NETCONF Extensions to Support the Network Management
Datastore Architecture, section 3.1.1.1.";
}
The 'with-origin' parameter is only valid for an operational rpc get-data {
datastore. If 'with-origin' is used with an invalid datastore, description
then the server MUST return an <rpc-error> element with an "Retrieve data from an NMDA datastore. The content returned
<error-tag> value of 'invalid-value'. by get-data must satisfy all filters, i.e., the filter
criteria are logically ANDed.
The 'with-defaults' parameter does not apply to operational The 'with-origin' parameter is only valid for an operational
datastores. If the 'with-defaults' parameter is present in a datastore. If 'with-origin' is used with an invalid datastore,
request to an operational datastore, then the server MUST then the server MUST return an <rpc-error> element with an
return an <rpc-error> element with an <error-tag> value of <error-tag> value of 'invalid-value'.
'invalid-value'.";
input {
leaf datastore {
type ds:datastore-ref;
mandatory true;
description
"Datastore from which to retrieve data.
If the datastore is not supported by the server, then the The 'with-defaults' parameter only applies to the operational
server MUST return an <rpc-error> element with an datastore if the NETCONF :with-defaults and
<error-tag> value of 'invalid-value'."; :with-operational-defaults capabilities are both advertised.
} If the 'with-defaults' parameter is present in a request for
which it is not supported, then the server MUST return an
<rpc-error> element with an <error-tag> value of
'invalid-value'.";
input {
leaf datastore {
type ds:datastore-ref;
mandatory true;
description
"Datastore from which to retrieve data.
choice filter-spec { If the datastore is not supported by the server, then the
description server MUST return an <rpc-error> element with an
"The content filter specification for this request."; <error-tag> value of 'invalid-value'.";
}
anydata subtree-filter { choice filter-spec {
description description
"This parameter identifies the portions of the "The content filter specification for this request.";
target datastore to retrieve.";
reference
"RFC 6241: Network Configuration Protocol, Section 6.";
}
leaf xpath-filter {
if-feature nc:xpath;
type yang:xpath1.0;
description
"This parameter contains an XPath expression identifying
the portions of the target datastore to retrieve.
If the expression returns a node-set, all nodes in the anydata subtree-filter {
node-set are selected by the filter. Otherwise, if the description
expression does not return a node-set, then the get-data "This parameter identifies the portions of the
operation fails. target datastore to retrieve.";
reference
"RFC 6241: Network Configuration Protocol, Section 6.";
}
leaf xpath-filter {
if-feature nc:xpath;
type yang:xpath1.0;
description
"This parameter contains an XPath expression identifying
the portions of the target datastore to retrieve.
The expression is evaluated in the following XPath If the expression returns a node-set, all nodes in the
context: node-set are selected by the filter. Otherwise, if the
expression does not return a node-set, then the get-data
operation fails.
o The set of namespace declarations are those in The expression is evaluated in the following XPath
scope on the 'xpath-filter' leaf element. context:
o The set of variable bindings is empty. o The set of namespace declarations are those in
scope on the 'xpath-filter' leaf element.
o The function library is the core function library, o The set of variable bindings is empty.
and the XPath functions defined in section 10 in
RFC 7950.
o The context node is the root node of the target o The function library is the core function library,
datastore."; and the XPath functions defined in section 10 in
} RFC 7950.
}
leaf config-filter { o The context node is the root node of the target
type boolean; datastore.";
description }
"Filter for nodes with the given value for their }
'config' property.";
}
leaf-list origin-filter {
when 'derived-from-or-self(../datastore, "ds:operational")';
if-feature origin;
type identityref {
base or:origin;
}
description
"Filter based on 'origin' annotation. A node matches the
filter if its 'origin' annotation is derived from or
equal to any of the given filter values.";
}
leaf max-depth { leaf config-filter {
type union { type boolean;
type uint16 { description
range "1..65535"; "Filter for nodes with the given value for their
} 'config' property.";
type enumeration { }
enum "unbounded"; choice origin-filters {
} when 'derived-from-or-self(datastore, "ds:operational")';
} if-feature origin;
default "unbounded"; description
description "Filters based on the 'origin' annotation.";
"For each node selected by the filter, this parameter
selects how many conceptual sub-tree levels should be
returned in the reply. If the depth is 1, the reply
includes just the selected nodes but no children. If the
depth is 'unbounded', all descendant nodes are included.";
}
leaf with-origin { leaf-list origin-filter {
when 'derived-from-or-self(../datastore, "ds:operational")'; type or:origin-ref;
if-feature origin; description
type empty; "Filter based on the 'origin' annotation. A node matches
description the filter if its 'origin' annotation is derived from or
"If this parameter is present, the server will return equal to any of the given filter values.";
the 'origin' annotation for the nodes that has one."; }
} leaf-list negated-origin-filter {
type or:origin-ref;
description
"Filter based on the 'origin' annotation. A node matches
the filter if its 'origin' annotation is not derived
from and not equal to all of the given filter values.";
}
}
uses ncwd:with-defaults-parameters; leaf max-depth {
type union {
type uint16 {
range "1..65535";
}
type enumeration {
enum "unbounded";
}
}
default "unbounded";
description
"For each node selected by the filter, this parameter
selects how many conceptual sub-tree levels should be
returned in the reply. If the depth is 1, the reply
includes just the selected nodes but no children. If the
depth is 'unbounded', all descendant nodes are included.";
}
} leaf with-origin {
when 'derived-from-or-self(../datastore, "ds:operational")';
if-feature origin;
type empty;
description
"If this parameter is present, the server will return
the 'origin' annotation for the nodes that has one.";
}
output { uses ncwd:with-defaults-parameters {
anydata data { if-feature with-defaults;
description }
"Copy of the source datastore subset which matched }
the filter criteria (if any). An empty data
container indicates that the request did not
produce any results.";
}
}
} output {
anydata data {
description
"Copy of the source datastore subset which matched
the filter criteria (if any). An empty data
container indicates that the request did not
produce any results.";
}
}
}
rpc edit-data { rpc edit-data {
description description
"Edit data in an NMDA datastore."; "Edit data in an NMDA datastore.
input {
leaf datastore {
type ds:datastore-ref;
description
"Datastore which is the target of the edit-data operation.
If the target datastore is not writable, or is not If an error condition occurs such that an error severity
supported by the server, then the server MUST return an <rpc-error> element is generated, the server will stop
<rpc-error> element with an <error-tag> value of processing the <edit-data> operation and restore the
'invalid-value'."; specified configuration to its complete state at
} the start of this <edit-data> operation.";
leaf default-operation { input {
type enumeration { leaf datastore {
enum "merge" { type ds:datastore-ref;
description mandatory true;
"The default operation is merge."; description
} "Datastore which is the target of the edit-data operation.
enum "replace" {
description
"The default operation is replace.";
}
enum "none" {
description
"There is no default operation.";
}
}
default "merge";
description
"The default operation to use.";
}
choice edit-content {
mandatory true;
description
"The content for the edit operation.";
anydata config { If the target datastore is not writable, or is not
description supported by the server, then the server MUST return an
"Inline config content."; <rpc-error> element with an <error-tag> value of
} 'invalid-value'.";
leaf url { }
if-feature nc:url; leaf default-operation {
type inet:uri; type enumeration {
description enum "merge" {
"URL based config content."; description
} "The default operation is merge.";
} }
} enum "replace" {
} description
"The default operation is replace.";
}
enum "none" {
description
"There is no default operation.";
}
}
default "merge";
description
"The default operation to use.";
/* }
* Augment the lock and unlock operations with a choice edit-content {
* "datastore" parameter. mandatory true;
*/ description
"The content for the edit operation.";
augment "/nc:lock/nc:input/nc:target/nc:config-target" { anydata config {
description description
"Add NMDA Datastore as target."; "Inline config content.";
leaf datastore { }
type ds:datastore-ref; leaf url {
description if-feature nc:url;
"Datastore to lock. type inet:uri;
description
"URL based config content.";
}
}
}
}
If the lock operation is not supported by the server on the /*
specified target datastore, then the server MUST return an * Augment the lock and unlock operations with a
<rpc-error> element with an <error-tag> value of * "datastore" parameter.
'invalid-value'."; */
}
}
augment "/nc:unlock/nc:input/nc:target/nc:config-target" {
description
"Add NMDA Datastore as target.";
leaf datastore {
type ds:datastore-ref;
description
"Datastore to unlock.
If the unlock operation is not supported by the server on the augment "/nc:lock/nc:input/nc:target/nc:config-target" {
specified target datastore, then the server MUST return an description
<rpc-error> element with an <error-tag> value of "Add NMDA Datastore as target.";
'invalid-value'."; leaf datastore {
} type ds:datastore-ref;
} description
"Datastore to lock.
/* The lock operation is only supported on writable datastores.
* Augment the validate operation with a
* "datastore" parameter.
*/
augment "/nc:validate/nc:input/nc:source/nc:config-source" { If the lock operation is not supported by the server on the
description specified target datastore, then the server MUST return an
"Add NMDA Datastore as source."; <rpc-error> element with an <error-tag> value of
'invalid-value'.";
}
}
augment "/nc:unlock/nc:input/nc:target/nc:config-target" {
description
"Add NMDA Datastore as target.";
leaf datastore {
type ds:datastore-ref;
description
"Datastore to unlock.
leaf datastore { The unlock operation is only supported on writable
type ds:datastore-ref; datastores.
description
"Datastore to validate.
If the validate operation is not supported by the server on If the unlock 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'.";
}
}
} /*
} * Augment the validate operation with a
} * "datastore" parameter.
*/
augment "/nc:validate/nc:input/nc:source/nc:config-source" {
description
"Add NMDA Datastore as source.";
leaf datastore {
type ds:datastore-ref;
description
"Datastore to validate.
The validate operation is supported only on configuration
datastores.
If the validate operation is not supported by the server on
the specified target datastore, then the server MUST return
an <rpc-error> element with an <error-tag> value of
'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
"Network Configuration Protocol (NETCONF) Capability URNs" registry: "Network Configuration Protocol (NETCONF) Capability URNs" registry:
Index Capability Identifier Index
------------- --------------------------------------------------- Capability Identifier
:yang-library urn:ietf:params:netconf:capability:yang-library:1.1 ---------------------
:with-origin urn:ietf:params:netconf:capability:with-origin:1.0 :yang-library
urn:ietf:params:netconf:capability:yang-library:1.1
:with-operational-defaults
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
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
This document registers a YANG module in the "YANG Module Names" This document registers a YANG module in the "YANG Module Names"
registry [RFC6020]. registry [RFC6020].
name: ietf-netconf-nmda name: ietf-netconf-nmda
namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-nmda namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-nmda
prefix: ncds prefix: ncds
reference: RFC XXXX reference: RFC XXXX
6. Security Considerations 6. Security Considerations
skipping to change at page 15, line 22 skipping to change at page 19, line 4
The network configuration access control model The network configuration access control model
[I-D.ietf-netconf-rfc6536bis] provides the means to restrict access [I-D.ietf-netconf-rfc6536bis] provides the means to restrict access
for particular NETCONF users to a preconfigured subset of all for particular NETCONF users to a preconfigured subset of all
available NETCONF protocol operations and content. available NETCONF protocol operations and content.
The security considerations for the base NETCONF protocol operations The security considerations for the base NETCONF protocol operations
(see Section 9 of [RFC6241]) apply to the new NETCONF <get-data> and (see Section 9 of [RFC6241]) apply to the new NETCONF <get-data> and
<edit-data> operations defined in this document. <edit-data> operations defined in this document.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-netconf-rfc6536bis] [I-D.ietf-netconf-rfc6536bis]
Bierman, A. and M. Bjorklund, "Network Configuration Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Module", draft-ietf-netconf-rfc6536bis-09 Access Control Module", draft-ietf-netconf-rfc6536bis-09
(work in progress), December 2017. (work in progress), December 2017.
[I-D.ietf-netconf-rfc7895bis] [I-D.ietf-netconf-rfc7895bis]
Bierman, A., Bjorklund, M., and K. Watsen, "YANG Library", Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K.,
draft-ietf-netconf-rfc7895bis-02 (work in progress), and R. Wilton, "YANG Library", draft-ietf-netconf-
October 2017. rfc7895bis-05 (work in progress), February 2018.
[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-10 Architecture", draft-ietf-netmod-revised-datastores-10
(work in progress), January 2018. (work in progress), January 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, DOI 10.17487/
RFC2119, March 1997, <https://www.rfc-editor.org/info/ RFC2119, March 1997, <https://www.rfc-editor.org/info/
skipping to change at page 16, line 39 skipping to change at page 20, line 17
<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>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-netmod-yang-tree-diagrams] [I-D.ietf-netmod-yang-tree-diagrams]
Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-
ietf-netmod-yang-tree-diagrams-04 (work in progress), ietf-netmod-yang-tree-diagrams-06 (work in progress),
December 2017. February 2018.
Authors' Addresses Authors' Addresses
Martin Bjorklund Martin Bjorklund
Tail-f Systems Tail-f Systems
Email: mbj@tail-f.com Email: mbj@tail-f.com
Juergen Schoenwaelder Juergen Schoenwaelder
Jacobs University Jacobs University
Email: j.schoenwaelder@jacobs-university.de Email: j.schoenwaelder@jacobs-university.de
Phil Shafer Phil Shafer
Juniper Networks Juniper Networks
Email: phil@juniper.net Email: phil@juniper.net
 End of changes. 69 change blocks. 
340 lines changed or deleted 504 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/