draft-ietf-netmod-revised-datastores-06.txt   draft-ietf-netmod-revised-datastores-07.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: May 3, 2018 P. Shafer Expires: June 2, 2018 P. Shafer
K. Watsen K. Watsen
Juniper Networks Juniper Networks
R. Wilton R. Wilton
Cisco Systems Cisco Systems
October 30, 2017 November 29, 2017
Network Management Datastore Architecture Network Management Datastore Architecture
draft-ietf-netmod-revised-datastores-06 draft-ietf-netmod-revised-datastores-07
Abstract Abstract
Datastores are a fundamental concept binding the data models written Datastores are a fundamental concept binding the data models written
in the YANG data modeling language to network management protocols in the YANG data modeling language to network management protocols
such as NETCONF and RESTCONF. This document defines an architectural such as NETCONF and RESTCONF. This document defines an architectural
framework for datastores based on the experience gained with the framework for datastores based on the experience gained with the
initial simpler model, addressing requirements that were not well initial simpler model, addressing requirements that were not well
supported in the initial model. supported in the initial model.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 May 3, 2018. This Internet-Draft will expire on June 2, 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 33 skipping to change at page 2, line 33
5.1.3. The Running Configuration Datastore (<running>) . . . 11 5.1.3. The Running Configuration Datastore (<running>) . . . 11
5.1.4. The Intended Configuration Datastore (<intended>) . . 12 5.1.4. The Intended Configuration Datastore (<intended>) . . 12
5.2. Dynamic Configuration Datastores . . . . . . . . . . . . 13 5.2. Dynamic Configuration Datastores . . . . . . . . . . . . 13
5.3. The Operational State Datastore (<operational>) . . . . . 13 5.3. The Operational State Datastore (<operational>) . . . . . 13
5.3.1. Remnant Configuration . . . . . . . . . . . . . . . . 14 5.3.1. Remnant Configuration . . . . . . . . . . . . . . . . 14
5.3.2. Missing Resources . . . . . . . . . . . . . . . . . . 14 5.3.2. Missing Resources . . . . . . . . . . . . . . . . . . 14
5.3.3. System-controlled Resources . . . . . . . . . . . . . 15 5.3.3. System-controlled Resources . . . . . . . . . . . . . 15
5.3.4. Origin Metadata Annotation . . . . . . . . . . . . . 15 5.3.4. Origin Metadata Annotation . . . . . . . . . . . . . 15
6. Implications on YANG . . . . . . . . . . . . . . . . . . . . 16 6. Implications on YANG . . . . . . . . . . . . . . . . . . . . 16
6.1. XPath Context . . . . . . . . . . . . . . . . . . . . . . 16 6.1. XPath Context . . . . . . . . . . . . . . . . . . . . . . 16
7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 17 6.2. Invocation of Actions and RPCs . . . . . . . . . . . . . 17
7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8.1. Updates to the IETF XML Registry . . . . . . . . . . . . 23 8.1. Updates to the IETF XML Registry . . . . . . . . . . . . 23
8.2. Updates to the YANG Module Names Registry . . . . . . . . 23 8.2. Updates to the YANG Module Names Registry . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Guidelines for Defining Datastores . . . . . . . . . 26 Appendix A. Guidelines for Defining Datastores . . . . . . . . . 27
A.1. Define which YANG modules can be used in the datastore . 27 A.1. Define which YANG modules can be used in the datastore . 27
A.2. Define which subset of YANG-modeled data applies . . . . 27 A.2. Define which subset of YANG-modeled data applies . . . . 27
A.3. Define how data is actualized . . . . . . . . . . . . . . 27 A.3. Define how data is actualized . . . . . . . . . . . . . . 27
A.4. Define which protocols can be used . . . . . . . . . . . 27 A.4. Define which protocols can be used . . . . . . . . . . . 28
A.5. Define YANG identities for the datastore . . . . . . . . 27 A.5. Define YANG identities for the datastore . . . . . . . . 28
Appendix B. Ephemeral Dynamic Configuration Datastore Example . 28 Appendix B. Ephemeral Dynamic Configuration Datastore Example . 28
Appendix C. Example Data . . . . . . . . . . . . . . . . . . . . 29 Appendix C. Example Data . . . . . . . . . . . . . . . . . . . . 29
C.1. System Example . . . . . . . . . . . . . . . . . . . . . 29 C.1. System Example . . . . . . . . . . . . . . . . . . . . . 29
C.2. BGP Example . . . . . . . . . . . . . . . . . . . . . . . 32 C.2. BGP Example . . . . . . . . . . . . . . . . . . . . . . . 32
C.2.1. Datastores . . . . . . . . . . . . . . . . . . . . . 34 C.2.1. Datastores . . . . . . . . . . . . . . . . . . . . . 34
C.2.2. Adding a Peer . . . . . . . . . . . . . . . . . . . . 34 C.2.2. Adding a Peer . . . . . . . . . . . . . . . . . . . . 34
C.2.3. Removing a Peer . . . . . . . . . . . . . . . . . . . 35 C.2.3. Removing a Peer . . . . . . . . . . . . . . . . . . . 35
C.3. Interface Example . . . . . . . . . . . . . . . . . . . . 36 C.3. Interface Example . . . . . . . . . . . . . . . . . . . . 36
C.3.1. Pre-provisioned Interfaces . . . . . . . . . . . . . 36 C.3.1. Pre-provisioned Interfaces . . . . . . . . . . . . . 36
C.3.2. System-provided Interface . . . . . . . . . . . . . . 37 C.3.2. System-provided Interface . . . . . . . . . . . . . . 37
skipping to change at page 17, line 37 skipping to change at page 17, line 37
o If the XPath expression is defined in a substatement to an o If the XPath expression is defined in a substatement to an
"output" statement in an "rpc" or "action" statement, the "output" statement in an "rpc" or "action" statement, the
accessible tree is the RPC or action operation instance and all accessible tree is the RPC or action operation instance and all
operational state in the server. The root node has top-level data operational state in the server. The root node has top-level data
nodes in all modules as children. Additionally, for an RPC, the nodes in all modules as children. Additionally, for an RPC, the
root node also has the node representing the RPC operation being root node also has the node representing the RPC operation being
defined as a child. The node representing the operation being defined as a child. The node representing the operation being
defined has the operation's output parameters as children. defined has the operation's output parameters as children.
6.2. Invocation of Actions and RPCs
This section updates section 7.15 of RFC 7950.
Actions are always invoked in the context of the operational state
datastore. The node for which the action is invoked MUST exist in
the operational state datastore.
Note that this document does not constrain the result of invoking an
RPC or action in any way. For example, an RPC might be defined to
modify the contents of some datastore.
7. YANG Modules 7. YANG Modules
<CODE BEGINS> file "ietf-datastores@2017-08-17.yang" <CODE BEGINS> file "ietf-datastores@2017-08-17.yang"
module ietf-datastores { module ietf-datastores {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-datastores"; namespace "urn:ietf:params:xml:ns:yang:ietf-datastores";
prefix ds; prefix ds;
organization organization
skipping to change at page 33, line 15 skipping to change at page 33, line 15
container bgp { container bgp {
leaf local-as { leaf local-as {
type uint32; type uint32;
} }
leaf peer-as { leaf peer-as {
type uint32; type uint32;
} }
list peer { list peer {
key name; key name;
leaf name { leaf name {
type ipaddress; type inet:ip-address;
} }
leaf local-as { leaf local-as {
type uint32; type uint32;
description description
".... Defaults to ../local-as"; ".... Defaults to ../local-as";
} }
leaf peer-as { leaf peer-as {
type uint32; type uint32;
description description
"... Defaults to ../peer-as"; "... Defaults to ../peer-as";
 End of changes. 10 change blocks. 
11 lines changed or deleted 24 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/