--- 1/draft-ietf-netmod-revised-datastores-08.txt 2017-12-21 11:13:22.923193205 -0800 +++ 2/draft-ietf-netmod-revised-datastores-09.txt 2017-12-21 11:13:22.995194927 -0800 @@ -4,21 +4,21 @@ Updates: 7950 (if approved) J. Schoenwaelder Intended status: Standards Track Jacobs University Expires: June 23, 2018 P. Shafer K. Watsen Juniper Networks R. Wilton Cisco Systems December 20, 2017 Network Management Datastore Architecture - draft-ietf-netmod-revised-datastores-08 + draft-ietf-netmod-revised-datastores-09 Abstract Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as NETCONF and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950. @@ -356,20 +356,22 @@ +-----------+ | v operational state <--- control plane (cf, ro) ct = config true; cf = config false rw = read-write; ro = read-only boxes denote datastores + Figure 1 + Note that this diagram simplifies the model: read-only (ro) and read- write (rw) is to be understood at a conceptual level. In NETCONF, for example, support for and is optional and does not have to be writable. Furthermore, can only be modified by copying to in the standardized NETCONF datastore editing model. The RESTCONF protocol does not expose these differences and instead provides only a writable unified datastore, which hides whether edits are done through or by directly modifying or via some other implementation specific mechanism. RESTCONF also hides how @@ -414,22 +416,23 @@ | | | | | (ct, rw) |<---+ +--->| (ct, rw) | +-------------+ | | +-----------+ | | | | | +-----------+ | +-------->| |<--------+ | (ct, rw) | +-----------+ | | // configuration transformations, - | // e.g., removal of "inactive" - | // nodes, expansion of templates + | // e.g., removal of nodes marked as + | // "inactive", expansion of + | // templates v +------------+ | | // subject to validation | (ct, ro) | +------------+ | // changes applied, subject to | // local factors, e.g., missing | // resources, delays | dynamic | +-------- learned configuration @@ -439,20 +442,22 @@ v v v +---------------+ | | <-- system state | (ct + cf, ro) | +---------------+ ct = config true; cf = config false rw = read-write; ro = read-only boxes denote named datastores + Figure 2 + 5.1. Conventional Configuration Datastores The conventional configuration datastores are a set of configuration datastores that share exactly the same datastore schema, allowing data to be copied between them. The term is meant as a generic umbrella description of these datastores. If a module does not contain any configuration data nodes and it is not needed to satisfy any imports, then it MAY be omitted from the datastore schema for the conventional configuration datastores. The set of datastores include: @@ -793,21 +799,21 @@ 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 - file "ietf-datastores@2017-08-17.yang" + file "ietf-datastores@2017-12-20.yang" module ietf-datastores { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-datastores"; prefix ds; organization "IETF Network Modeling (NETMOD) Working Group"; contact @@ -842,21 +848,21 @@ without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself for full legal notices."; - revision 2017-08-17 { + revision 2017-12-20 { description "Initial revision."; reference "RFC XXXX: Network Management Datastore Architecture"; } /* * Identities */ @@ -916,21 +922,21 @@ base datastore; } description "A datastore identity reference."; } } - file "ietf-origin@2017-08-17.yang" + file "ietf-origin@2017-12-20.yang" module ietf-origin { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-origin"; prefix or; import ietf-yang-metadata { prefix md; } @@ -968,21 +974,21 @@ without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself for full legal notices."; - revision 2017-08-17 { + revision 2017-12-20 { description "Initial revision."; reference "RFC XXXX: Network Management Datastore Architecture"; } /* * Identities */ @@ -1059,22 +1065,22 @@ } /* * Metadata annotations */ md:annotation origin { type origin-ref; description "The 'origin' annotation can be present on any configuration - data node in the operational datastore. It specifies from - where the node originated. If not specified for a given + data node in the operational state datastore. It specifies + from where the node originated. If not specified for a given configuration data node then the origin is the same as the origin of its parent node in the data tree. The origin for any top level configuration data nodes must be specified."; } } 8. IANA Considerations @@ -1088,22 +1094,22 @@ Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-origin Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. 8.2. Updates to the YANG Module Names Registry This document registers two YANG modules in the YANG Module Names - registry [RFC6020]. Following the format in [RFC6020], the the - following registrations are requested: + registry [RFC6020]. Following the format in [RFC6020], the following + registrations are requested: name: ietf-datastores namespace: urn:ietf:params:xml:ns:yang:ietf-datastores prefix: ds reference: RFC XXXX name: ietf-origin namespace: urn:ietf:params:xml:ns:yang:ietf-origin prefix: or reference: RFC XXXX @@ -1452,34 +1458,34 @@ to a default value, a loopback interface is automatically added by the system, and the result of the "speed" auto-negotiation. All of this is reflected in . Note how the origin metadata attribute for several "config true" data nodes is inherited from their parent data nodes. - bar + bar eth0 true 1000 100
2001:db8::10 64
-
+
2001:db8::1:100 64
lo0
::1 128