--- 1/draft-ietf-netmod-revised-datastores-05.txt 2017-10-30 11:13:48.140614694 -0700 +++ 2/draft-ietf-netmod-revised-datastores-06.txt 2017-10-30 11:13:48.208616311 -0700 @@ -1,24 +1,24 @@ Network Working Group M. Bjorklund Internet-Draft Tail-f Systems Updates: 7950 (if approved) J. Schoenwaelder Intended status: Standards Track Jacobs University -Expires: April 21, 2018 P. Shafer +Expires: May 3, 2018 P. Shafer K. Watsen Juniper Networks R. Wilton Cisco Systems - October 18, 2017 + October 30, 2017 Network Management Datastore Architecture - draft-ietf-netmod-revised-datastores-05 + draft-ietf-netmod-revised-datastores-06 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. @@ -30,21 +30,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 21, 2018. + This Internet-Draft will expire on May 3, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -72,27 +72,27 @@ 5.3.1. Remnant Configuration . . . . . . . . . . . . . . . . 14 5.3.2. Missing Resources . . . . . . . . . . . . . . . . . . 14 5.3.3. System-controlled Resources . . . . . . . . . . . . . 15 5.3.4. Origin Metadata Annotation . . . . . . . . . . . . . 15 6. Implications on YANG . . . . . . . . . . . . . . . . . . . . 16 6.1. XPath Context . . . . . . . . . . . . . . . . . . . . . . 16 7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8.1. Updates to the IETF XML Registry . . . . . . . . . . . . 23 8.2. Updates to the YANG Module Names Registry . . . . . . . . 23 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . 25 Appendix A. Guidelines for Defining Datastores . . . . . . . . . 26 - A.1. Define which YANG modules can be used in the datastore . 26 + 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.3. Define how data is actualized . . . . . . . . . . . . . . 27 A.4. Define which protocols can be used . . . . . . . . . . . 27 A.5. Define YANG identities for the datastore . . . . . . . . 27 Appendix B. Ephemeral Dynamic Configuration Datastore Example . 28 Appendix C. Example Data . . . . . . . . . . . . . . . . . . . . 29 C.1. System Example . . . . . . . . . . . . . . . . . . . . . 29 C.2. BGP Example . . . . . . . . . . . . . . . . . . . . . . . 32 C.2.1. Datastores . . . . . . . . . . . . . . . . . . . . . 34 C.2.2. Adding a Peer . . . . . . . . . . . . . . . . . . . . 34 @@ -173,20 +173,27 @@ semantically equivalent with the definitions found in [RFC6241] and [RFC7950]. It is expected that the revised definitions provided in this section will replace the definitions in [RFC6241] and [RFC7950] when these documents are revised. o datastore: A conceptual place to store and access information. A datastore might be implemented, for example, using files, a database, flash memory locations, or combinations thereof. A datastore maps to an instantiated YANG data tree. + o schema node: A node in the schema tree. The formal definition is + in RFC 7950. + + o datastore schema: The combined set of schema nodes for all modules + supported by a particular datastore, taking into consideration any + deviations and enabled features for that datastore. + o configuration: Data that is required to get a device from its initial default state into a desired operational state. This data is modeled in YANG using "config true" nodes. Configuration can originate from different sources. o configuration datastore: A datastore holding configuration. o running configuration datastore: A configuration datastore holding the current configuration of the device. It may include configuration that requires further transformations before it can @@ -213,24 +220,24 @@ datastore is referred to as "". o configuration transformation: The addition, modification or removal of configuration between the and datastores. Examples of configuration transformations include the removal of inactive configuration and the configuration produced through the expansion of templates. o conventional configuration datastore: One of the following set of configuration datastores: , , , and - . These datastores share a common schema, and protocol - operations allow copying data between these datastores. The term - "conventional" is chosen as a generic umbrella term for these - datastores. + . These datastores share a common datastore schema, and + protocol operations allow copying data between these datastores. + The term "conventional" is chosen as a generic umbrella term for + these datastores. o conventional configuration: Configuration that is stored in any of the conventional configuration datastores. o dynamic configuration datastore: A configuration datastore holding configuration obtained dynamically during the operation of a device through interaction with other systems, rather than through one of the conventional configuration datastores. o dynamic configuration: Configuration obtained via a dynamic @@ -434,29 +441,30 @@ | (ct + cf, ro) | +---------------+ ct = config true; cf = config false rw = read-write; ro = read-only boxes denote named datastores 5.1. Conventional Configuration Datastores The conventional configuration datastores are a set of configuration - datastores that share exactly the same schema, allowing data to be - copied between them. The term is meant as a generic umbrella - description of these datastores. The set of datastores include: + 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. The set of datastores + include: o o - o + o Other conventional configuration datastores may be defined in future documents. The flow of data between these datastores is depicted in Section 5. The specific protocols may define explicit operations to copy between these datastores, e.g., NETCONF defines the operation. @@ -552,32 +560,38 @@ that are, by definition, not part of the persistent configuration of a device. In some contexts, these have been termed ephemeral datastores since the information is ephemeral, i.e., lost upon reboot. The dynamic configuration datastores interact with the rest of the system through . 5.3. The Operational State Datastore () The operational state datastore () is a read-only datastore that consists of all "config true" and "config false" nodes - defined in the schema. In the original NETCONF model the operational - state only had "config false" nodes. The reason for incorporating - "config true" nodes here is to be able to expose all operational - settings without having to replicate definitions in the data models. + defined in the datastore's schema. In the original NETCONF model the + operational state only had "config false" nodes. The reason for + incorporating "config true" nodes here is to be able to expose all + operational settings without having to replicate definitions in the + data models. contains system state and all configuration actually used by the system. This includes all applied configuration from , learned configuration, system-provided configuration, and default values defined by any supported data models. In addition, also contains applied configuration from dynamic configuration datastores. + The datastore schema for MUST be a superset of the + combined datastore schema used in all configuration datastores except + that YANG nodes supported in a configuration datastore MAY be omitted + from if a server is not able to accurately report them. + Requests to retrieve nodes from always return the value in use if the node exists, regardless of any default value specified in the YANG module. If no value is returned for a given node, then this implies that the node is not used by the device. The interpretation of what constitutes as being "in use" by the system is dependent on both the schema definition and the device implementation. Generally, functionality that is enabled and operational on the system would be considered as being "in use". Conversely, functionality that is neither enabled nor operational on