draft-ietf-netconf-nmda-netconf-00.txt   draft-ietf-netconf-nmda-netconf-01.txt 
Network Working Group M. Bjorklund Network Working Group M. Bjorklund
Internet-Draft Tail-f Systems Internet-Draft Tail-f Systems
Updates: 7950 (if approved) J. Schoenwaelder Updates: 7950 (if approved) J. Schoenwaelder
Intended status: Standards Track Jacobs University Intended status: Standards Track Jacobs University
Expires: April 14, 2018 P. Shafer Expires: May 3, 2018 P. Shafer
K. Watsen K. Watsen
Juniper Networks Juniper Networks
R. Wilton R. Wilton
Cisco Systems Cisco Systems
October 11, 2017 October 30, 2017
NETCONF Model for NMDA NETCONF Model for NMDA
draft-ietf-netconf-nmda-netconf-00 draft-ietf-netconf-nmda-netconf-01
Abstract Abstract
The "Network Management Datastore Architecture" (NMDA) improves on The "Network Management Datastore Architecture" (NMDA) improves on
NETCONF by adding new features to give more accurate handling of NETCONF by adding new features to give more accurate handling of
configuration and operational data. These include ability to inspect configuration and operational data. These include ability to inspect
the current operational values of configuration data, allowing the current operational values of configuration data, allowing
clients to use identical paths for retrieving the configured values clients to use identical paths for retrieving the configured values
and the operational values. These new features require additional and the operational values. These new features require additional
operations in network management applications such as NETCONF. This operations in network management applications such as NETCONF. This
draft details those new operations. document details those new operations.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 14, 2018. This Internet-Draft will expire on May 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. The NMDA Model for NETCONF . . . . . . . . . . . . . . . . . 3 2. The NMDA Model for NETCONF . . . . . . . . . . . . . . . . . 3
2.1. Operations . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Operations . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1. The <get-data> Operation . . . . . . . . . . . . . . 3 2.1.1. The <get-data> Operation . . . . . . . . . . . . . . 3
2.1.2. The <edit-data> Operation . . . . . . . . . . . . . . 4 2.1.2. The <edit-data> Operation . . . . . . . . . . . . . . 4
2.2. Augmentations to the Base NETCONF Model . . . . . . . . . 4 2.2. Augmentations to the Base NETCONF Model . . . . . . . . . 5
2.3. RPCs and Actions . . . . . . . . . . . . . . . . . . . . 5 2.3. RPCs and Actions . . . . . . . . . . . . . . . . . . . . 5
2.4. YANG Library Capability . . . . . . . . . . . . . . . . . 5 2.4. YANG Library Capability . . . . . . . . . . . . . . . . . 5
3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Informative References . . . . . . . . . . . . . . . . . . . 11 6. Informative References . . . . . . . . . . . . . . . . . . . 12
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
This document provides a YANG model that adds NETCONF ([RFC6241]) This document provides a YANG model that adds NETCONF ([RFC6241])
support for the "Network Management Datastore Architecture" (NMDA) support for the "Network Management Datastore Architecture" (NMDA)
[I-D.ietf-netmod-revised-datastores]. NMDA defines a framework for [I-D.ietf-netmod-revised-datastores]. NMDA defines a framework for
datastores, a fundamental concept binding network management data datastores, a fundamental concept binding network management data
models to network management protocols, enabling data models to be models to network management protocols, enabling data models to be
written in a network management protocol agnostic way. NETCONF written in a network management protocol agnostic way. NETCONF
skipping to change at page 3, line 28 skipping to change at page 3, line 28
2. The NMDA Model for NETCONF 2. The NMDA Model for NETCONF
This section describes the changes needed for NMDA support. These This section describes the changes needed for NMDA support. These
changes are contained in a new YANG ([RFC7950]) model changes are contained in a new YANG ([RFC7950]) model
"ietf-netconf-datastores". "ietf-netconf-datastores".
These changes include the use of source and target parameters based These changes include the use of source and target parameters based
on the "datastore" identity defined in the "ietf-datastores" from on the "datastore" identity defined in the "ietf-datastores" from
[I-D.ietf-netmod-revised-datastores]. The use of identities allows [I-D.ietf-netmod-revised-datastores]. The use of identities allows
future expansion in a way that the choice-based strategy from the future expansion in a way that the choice-based strategy from the
original operations (e.g. <get-config>, <edit-config>) do not. original operations (e.g., <get-config>, <edit-config>) do not.
2.1. Operations 2.1. Operations
Support for the NMDA includes two new operations defined in this Support for the NMDA includes two new operations defined in this
document. document.
2.1.1. The <get-data> Operation 2.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, but adds flexibility in naming the target datastore. operation, but adds flexibility in naming the source datastore.
The "source" parameter indicates the datastore which is the source of The "source" parameter indicates the datastore which is the source of
the data to be retrieved. This is a datastore identity. 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 and XPath filtering. for subtree filtering and XPath filtering.
Additional filters are defined to retrieve only "config true" nodes Additional filters are defined to retrieve only "config true" nodes
or nodes matching a given "origin" value. or nodes matching a given "origin" value.
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.
2.1.1.1. Origin Attribute 2.1.1.1. Origin Metadata Attribute
The "get-data" operation adds a new boolean parameter named The <get-data> operation adds a new parameter named "with-origin",
"with-origin", which requests that the server returns the "origin" which if present, requests that the server includes "origin" metadata
information as detailed in the NMDA. This parameter is only valid anotations in its response, as detailed in the NMDA. This parameter
for <operational> and any datastores with identities derived from the is only valid for <operational> and any datastores with identities
"operational" identity. derived from the "operational" identity. Otherwise, if an invalid
datastore is specified then an <rpc-error> element is returned with
an <error-tag> value of "invalid-value". "origin" metadata
annotations are not included unless a client explicitly requesteds
them.
Data from <operational> can come from multiple sources. The server Data from <operational> can come from multiple sources. The server
should return the most accurate value for the "origin" attribute as should return the most accurate value for the "origin" metadata
possible, indicating the source of the operational value. annotation as possible, indicating the source of the operational
value, as specified in section 5.3.4 of the NMDA.
When encoding the origin attribute for a hierarchy of returned nodes, When encoding the origin metadata annotation for a hierarchy of
the origin attribute may be omitted when the value matches that of returned nodes, the annotation may be omitted for a child node when
the parent node. the value matches that of the parent node (as described in ietf-
origin@2017-08-17). [RFC Editor, please check published revision
date.]
The "with-origin" parameter is optional to support. It is identified
with the URI:
urn:ietf:params:netconf:capability:with-origin:1.0
2.1.2. The <edit-data> Operation 2.1.2. The <edit-data> Operation
The <edit-data> operation changes the contents of a specific The <edit-data> operation changes the contents of a specific
datastore, similar to the <edit-config> operation, but with datastore, similar to the <edit-config> operation, but with
additional flexibility in naming the target datastore. additional flexibility in naming the target datastore.
The "target" 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 "edit-content" parameter from "edit-config" it is modified to The "edit-content" parameter from "edit-config" it is modified to
allow use "type anydata" for configuration content, rather than the allow use "type anydata" for configuration content, rather than the
"edit-config"'s use of "type anyxml". "edit-config"'s use of "type anyxml".
The "default-operation" parameter mirrors the parameter of the The "default-operation" parameter mirrors the parameter of the
"edit-config" operation. <edit-config> operation.
2.2. Augmentations to the Base NETCONF Model 2.2. Augmentations to the Base NETCONF Model
Several of the operations defined in the base NETCONF data model Several of the operations defined in the base NETCONF data model
(ietf-netconf@2011-06-01.yang) will continue to be used under the (ietf-netconf@2011-06-01.yang) will continue to be used under the
NMDA. The <lock>, <unlock>, and <validate> operations are augmented NMDA. The <lock>, <unlock>, and <validate> operations are augmented
with a new "datastore" leaf can indicate a desired NMDA datastore. with a new "datastore" leaf can indicate a desired NMDA datastore.
Only writable datastores can be locked. Only writable datastores can be locked.
2.3. RPCs and Actions 2.3. RPCs and Actions
RPC operations and actions can be defined in YANG modules. The RPC operations and actions can be defined in YANG modules. The
evaluation context for constraints and references in operation and evaluation context for constraints and references in RPC operations
actions is <operational>. and actions is <operational>, as specified in the NMDA.
2.4. YANG Library Capability 2.4. YANG Library Capability
RFC Ed.: Update 201X-XX-XX below with correct date. RFC Ed.: Update 201X-XX-XX below with correct date.
Support for NMDA requires the server to implement at least revision Support for NMDA requires the server to implement at least revision
201X-XX-XX of the "ietf-yang-library" module defined in 201X-XX-XX of the "ietf-yang-library" module defined in
[I-D.nmdsdt-netconf-rfc7895bis]. The server MUST advertise the [I-D.nmdsdt-netconf-rfc7895bis]. The server MUST advertise the
following capability in the <hello> message (line breaks and following capability in the <hello> message (line breaks and
whitespaces are used for formatting reasons only): whitespaces are used for formatting reasons only):
skipping to change at page 7, line 36 skipping to change at page 7, line 48
} }
description description
"An NMDA datastore."; "An NMDA datastore.";
reference "RFC XXXX: Network Management Datastore Architecture"; reference "RFC XXXX: Network Management Datastore Architecture";
} }
rpc get-data { rpc get-data {
description description
"Retrieve data from an NMDA datastore."; "Retrieve data from an NMDA datastore.";
input { input {
leaf source { leaf datastore {
type ncds:datastore; type ncds:datastore;
mandatory true; mandatory true;
description description
"Datastore from which to retrieve data."; "Datastore from which to retrieve data.";
} }
choice filter-spec { choice filter-spec {
description description
"The content filter specification for this request."; "The content filter specification for this request.";
skipping to change at page 8, line 40 skipping to change at page 8, line 51
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 the given filter value.";
} }
} }
leaf with-origin { leaf with-origin {
when 'derived-from-or-self(../source, "or:operational")'; when 'derived-from-or-self(../datastore, "or:operational")';
if-feature origin; if-feature origin;
type boolean; type empty;
default false;
description description
"If this parameter is 'true', 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;
} }
output { output {
anydata data { anydata data {
description description
"Copy of the source datastore subset which matched "Copy of the source datastore subset which matched
skipping to change at page 9, line 18 skipping to change at page 9, line 29
container indicates that the request did not container indicates that the request did not
produce any results."; produce any results.";
} }
} }
} }
rpc edit-data { rpc edit-data {
description description
"Edit data in an NMDA datastore."; "Edit data in an NMDA datastore.";
input { input {
leaf target { leaf datastore {
type ncds:datastore; type ncds:datastore;
description description
"Datastore which data affects."; "Datastore which data affects.";
} }
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.";
} }
skipping to change at page 11, line 42 skipping to change at page 12, line 10
5. Security Considerations 5. Security Considerations
This document has no security considerations. This document has no security considerations.
6. Informative References 6. Informative References
[I-D.ietf-netmod-revised-datastores] [I-D.ietf-netmod-revised-datastores]
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore and R. Wilton, "Network Management Datastore
Architecture", draft-ietf-netmod-revised-datastores-04 Architecture", draft-ietf-netmod-revised-datastores-05
(work in progress), August 2017. (work in progress), October 2017.
[I-D.nmdsdt-netconf-rfc7895bis] [I-D.nmdsdt-netconf-rfc7895bis]
Bierman, A., Bjorklund, M., and K. Watsen, "YANG Library", Bierman, A., Bjorklund, M., and K. Watsen, "YANG Library",
draft-nmdsdt-netconf-rfc7895bis-01 (work in progress), draft-nmdsdt-netconf-rfc7895bis-01 (work in progress),
July 2017. July 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
skipping to change at page 12, line 27 skipping to change at page 12, line 40
<https://www.rfc-editor.org/info/rfc6243>. <https://www.rfc-editor.org/info/rfc6243>.
[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>.
Appendix A. Examples
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
 End of changes. 25 change blocks. 
38 lines changed or deleted 46 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/