Internet Engineering Task Force R. Wilton, Ed. Internet-Draft Cisco Systems Intended status: Standards Track June 3, 2016 Expires: December 5, 2016 Refined YANG datastores draft-wilton-netmod-refined-datastores-00 Abstract The existing definition of YANG datastores supported by NETCONF only provides a loose definition of the running datastore, and no formal definition of any datastore that represents the operational state of a device. This document defines a refined datastore model with new concrete and abstract datastores to allow devices to provide a clean separation between the operator's intended configuration of a device and the actual running operational state of a device. It provides a similiar, but alternative, datastore framework to the one described in draft-schoenw-netmod-revised-datastores. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 December 5, 2016. Copyright Notice Copyright (c) 2016 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 carefully, as they describe your rights and restrictions with respect Wilton Expires December 5, 2016 [Page 1] Internet-Draft Refined YANG Datastores June 2016 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Overview of a refined model of datastores . . . . . . . . . . 3 5. Definition of all datastores . . . . . . . . . . . . . . . . 6 5.1. Candidate Datastore (Optional) . . . . . . . . . . . . . 6 5.2. Startup Datastore . . . . . . . . . . . . . . . . . . . . 6 5.3. Running Configuration Datastore (Abstract) . . . . . . . 6 5.3.1. Support by non-opstate aware devices . . . . . . . . 6 5.3.2. Support by opstate aware devices . . . . . . . . . . 7 5.4. Persistent Configuration Datastore . . . . . . . . . . . 7 5.5. Ephemeral Configuration Datastore (Optional) . . . . . . 7 5.6. Intended Configuration Datastore (Abstract) . . . . . . . 8 5.7. Operational State Datastore . . . . . . . . . . . . . . . 8 5.8. Applied Configuration Datastore (Abstract) . . . . . . . 9 5.9. System Controlled Configuration Datastore (Abstract) . . 10 5.10. System State Datastore (Abstract) . . . . . . . . . . . . 10 6. Discussion points . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Missing resources . . . . . . . . . . . . . . . . . . . . 11 6.2. System controlled resources . . . . . . . . . . . . . . . 11 6.3. Auto-configured or auto-negotiated values . . . . . . . . 11 6.4. Operational State with Different Origins . . . . . . . . 12 7. Implications of the Refined Datastore Model . . . . . . . . . 12 7.1. Implications for opstate unaware clients . . . . . . . . 12 7.1.1. Upgradeability . . . . . . . . . . . . . . . . . . . 13 7.2. Implications for opstate aware clients . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction This document defines a similar, but alternative architectural datastore framework to draft-schoenw-netmod-revised-datastores [I-D.schoenw-netmod-revised-datastores]. This purpose of this document is to make it easier to compare the models and approaches being described in the two different drafts. The reader is advised Wilton Expires December 5, 2016 [Page 2] Internet-Draft Refined YANG Datastores June 2016 to also read draft-schoenw-netmod-revised-datastores [I-D.schoenw-netmod-revised-datastores] which provides a good background on why a refined NETCONF/YANG datastore model is needed. 2. Objectives The key aims of this definition of datastores are: to keep the existing definition of the running-configuration completely unchanged to provide a viable upgrade path for existing NETCONF/RESTCONF servers to minimize the number datastores (and amount of data) that need to be explicitly managed by external management agents to make explicit the meaning of the contents in each of the datastores and how they relate to each other This draft does not formally address the active/inactive configuration functionality described in draft-schoenw-netmod- revised-datastores [I-D.schoenw-netmod-revised-datastores]. If supporting this functionality is required, then it is envisaged that this would be a separate optional datastore that exists between the persistent configuration datastore and the ephemeral configuration datastore. 3. Definitions The following terms are defined: opstate aware device - a device that exposes a clean separation between intended and applied configuration opstate unaware device - a device that does not expose a clean separation between intended and applied configuration 4. Overview of a refined model of datastores The following diagram illustrates how the datastores (except running) defined in this document relate to each other: Wilton Expires December 5, 2016 [Page 3] Internet-Draft Refined YANG Datastores June 2016 +-------------+ +-----------+ | | | | | (ct, rw) |<---+ +--->| (ct, rw) | +-------------+ | | +-----------+ | | | | | +---------------+ | +-------->| |<-----+ | (ct, rw) | // subject to validation +---------------+ | v +---------------+ | | | (ct, rw) | +---------------+ | v +---------------+ | | // subject to validation | (ct, ro) | +---------------+ | v +---------------------+ | +---------------+ | | | | <--- actual cfg in effect | | (ct, ro) | | | +---------------+ | | | | | v | Operational | +---------------+ | State ==> | | | <--- System created config Datastore | | (ct, ro) | | | +---------------+ | | | | | v | | +-----------------+ | | | | <--- Config false nodes | | (cf, ro) | | | +-----------------+ | +---------------------+ This document defines seven additional datastores beyond the three (candidate, startup, running) that are defined in existing RFCs! Many of these newly defined datastores are regarded as being entirely abstract datastores, and even opstate aware devices are not required to explicitly handle get requests (or YANG push notifications) on these named abstract datastores. One of the main reasons for Wilton Expires December 5, 2016 [Page 4] Internet-Draft Refined YANG Datastores June 2016 defining these abstract datastores is to give a precise definition of the meaning of the configuration and operational data on a device, and potentially allow management agents to make queries between the different datastores (e.g. to determine if any intended configuration hasn't actually been applied, or perhaps conversely which parts of the applied configuration do not match the intended configuration). The ten datastores can be summarized as thus: 1. candidate ds - represents candidate configuration, unchanged from existing implementations 2. startup ds - represents startup configuration, unchanged from existing implementations 3. running configuration ds (abstract) - represents the combined persistent, ephemeral, intended and applied datastores, logically equivalent to the existing definition 4. persistent configuration ds - represents operator provided configuration that is written to the startup datastore and is recovered after device reboot 5. ephemeral configuration ds (optional) - represents operator provided transient configuration that is discarded after device reboot 6. intended configuration ds (abstract) - represents the combined (i.e. persistent and ephemeral) desired configuration of the device 7. operational state ds - a combined datastore that represents all of the operational state of the device (i.e. applied config, system controlled config & system state). 8. applied configuration ds (abstract) - represents the actual applied configuration of the device 9. system controlled configuration ds (abstract) - represents any system created/managed configuration on the device 10. system state ds (abstract) - represents all of the non- configuration operational state of the device Only the system state datastore holds config=false nodes. All other datastores defined above only hold config=true YANG schema nodes, and are represented by the same YANG schema files. Wilton Expires December 5, 2016 [Page 5] Internet-Draft Refined YANG Datastores June 2016 5. Definition of all datastores 5.1. Candidate Datastore (Optional) Holds candidate configuration. The definition is unchanged from existing RFCs. 5.2. Startup Datastore Holds the saved configuration that is used by the device after reboot. The definition is unchanged from existing RFCs. 5.3. Running Configuration Datastore (Abstract) This document does not try to redefine the running configuration datastore, it aims to retain its existing (loose) definition. Some implementations regard the running configuration as solely the configuration provided by the operator to the device. Other implementations regard it as something akin to the applied configuration datastore, where, on a system without ephemeral configuration, after a configuration commit has completed, the running configuration matches the configuration provided by the operator. In the refined datastore model described in this draft, the running configuration datastore can be considered as being logically split into the persistent, ephemeral, intended, and applied configuration datastores as illustrated in the diagram below. ---- Persistent configuration ds / ----- Ephemeral configuration ds Running configuration ds | ----- Intended configuration ds \ ---- Applied configuration ds 5.3.1. Support by non-opstate aware devices On a non-opstate aware device, the running configuration datastore is supported exactly as it is today by the existing NETCONF/YANG RFCs Wilton Expires December 5, 2016 [Page 6] Internet-Draft Refined YANG Datastores June 2016 5.3.2. Support by opstate aware devices For an opstate aware device, the running configuration datastore is supported as an abstract datastore. It maintain backwards compatibility, config writes to the running configuration datastore are treated as writes to the persistent configuration datastore. Config reads (e.g. get-config) from the running configuration datastore are treated as reads from the applied configuration datastore. NETCONF get requests (or equivalent) are treated as a read on the operational state datastore. 5.4. Persistent Configuration Datastore The Persistent Configuration Datastore represents the configuration provided by the operator, that is expected to be persisted over device reboot. Writes to the persistent configuration are validated to ensure that the configuration is well formed and valid, and if so, is persisted over device reboot. The persistent configuration datastore interacts with both the candidate and startup datastores (as per the running configuration datastore on a non opstate aware device). This datastore is only written by the operator. The default behavior for get requests (or YANG push notifications) on this datastore is to return the configuration exactly as provided by the operator (i.e. including any explicitly configured default values and excluding any implicit YANG default values). 5.5. Ephemeral Configuration Datastore (Optional) This document does not intend to formally define an Ephemeral Configuration Datastore. In particular, it must be noted that the ephemeral configuration datastore described here does not match that described in version -09 of draft-ietf-i2rs-ephemeral-state [I-D.ietf-i2rs-ephemeral-state]. Instead, it describes conceptually how such a datastore (restricted to configuration only) might fit into a conceptual refined datastore model. An Ephemeral Configuration Datastore may optionally be supported to hold any configuration that must not persist over device reboot. This datastore could be regarded as a pane of glass overlay on the persistent configuration datastore, allowing nodes in the ephemeral configuration to override, or depend on, nodes in the persistent configuration if required. This datastore is only written by the operator. Wilton Expires December 5, 2016 [Page 7] Internet-Draft Refined YANG Datastores June 2016 The default behavior for get requests (or YANG push notifications) on the ephemeral configuration datastore is to return the configuration exactly as written by the operator to the ephemeral datastore (i.e. including any explicitly configured default values and excluding any implicit default values). Multiple layers of ephemeral configuration in the ephemeral datastore could be supported. 5.6. Intended Configuration Datastore (Abstract) The Intended Configuration datastore abstractly represents the net combination of the persistent configuration datastore overlaid with the optional ephemeral configuration datastore. It represents the entire combined configuration that the operator intends for the device. This datastore is read only. It is optional as to whether the device allows the intended configuration to be directly read (or notified) as a labelled, user visible, datastore; or possibly the contents of the intended configuration datastore may only be made available as YANG meta-data annotations on one of the other datastores. If get requests (or YANG push notifications) are supported on the intended configuration datastore then the handling of default values would be consistent with both the persistent and ephemeral configuration datastores (as described previously), i.e. the explicit operator configuration is returned. 5.7. Operational State Datastore The Operational State datastore represents all of the operational state of the device. This includes the applied configuration, any system controlled configuration, and all of the system state (i.e. config=false nodes). Logically, the operational state datastore can be considered as being split into the applied configuration, system controlled configuration, and system state datastores as illustrated in the following diagram: ---- Applied configuration ds / Operational state ds |----- System controlled configuration ds \ ---- System state ds Wilton Expires December 5, 2016 [Page 8] Internet-Draft Refined YANG Datastores June 2016 This datastore is read only. Performing a read of the operational state datastore returns the applied configuration overlaid with system controlled configuration and system state datastores. The default behavior for get requests (or YANG push notifications) on the operational state datastore is to explicitly return all values in effect in the system (including any values that are implicitly set by a YANG schema default). A default NETCONF GET request can be regarded as a GET request against the operational state datastore. It should also be noted that with the exception of system controlled configuration, that if the system has converged and the configuration has been applied then a GET request for an opstate aware device and a non opstate aware device return exactly the same data. This provides backwards compatibility and an upgrade path from existing NETCONF servers. 5.8. Applied Configuration Datastore (Abstract) The Applied Configuration datastore is the abstract subset of the operational state datastore that represents the actual configuration that has been applied and is in effect on the device. For a well behaved device, after a config write operation has completed successfully the notional contents of the applied configuration datastore matches the intended configuration datastore. Being an abstract datastore that is part of the operational state datastore it is read-only. The contents of this datastore must be made available as part of the applied configuration datastore. It is optional as to whether the device allows the applied configuration datastore to be directly read (or notified via YANG Push) as a labelled, user visible, datastore; or possibly the contents of the applied configuration datastore may only be made available as YANG meta-data annotations on one of the other datastores (e.g. persistent, intended, or operational-state datastore). If supported, the default behavior for get requests (or YANG push notifications) on this datastore is to explicitly return all values in effect in the system (including any values that are implicitly set by a YANG schema default). Wilton Expires December 5, 2016 [Page 9] Internet-Draft Refined YANG Datastores June 2016 5.9. System Controlled Configuration Datastore (Abstract) The System Controlled Configuration Datastore is the abstract subset of the operational state datastore that represents all configuration nodes that are created by the system independently of the intended configuration. E.g. system created interfaces that hadn't been configured by the operator would logically exist in the system controlled configuration datastore whether or not they also exists in the applied configuration datastore. This datastore uses the same YANG schema of config=true as for the intended or applied configuration datastores. Logically, nodes may exist in both the applied configuration and system controlled configuration datastores (e.g. if a system created interface had been configured). Being an abstract datastore that is part of the operational state datastore it is read-only. The contents of this datastore must be made available as part of the applied configuration datastore. It is optional as to whether the device allows the applied configuration datastore to be directly read (or notified via YANG Push) as a labelled, user visible, datastore; or possibly the contents of the applied configuration datastore may only be made available as YANG meta-data annotations on the operational-state datastore. If supported, the default behavior for get requests (or YANG push notifications) on this datastore is to explicitly return all values in effect in the system (including any values that are implicit due to a YANG schema default). 5.10. System State Datastore (Abstract) The System State Abstract Datastore is the abstract subset of the operational state datastore that represents all of the operational state derived from configuration or other system defined values, and is represented by config=false nodes in the YANG schema. Entries in this datastore can rely on the existence of entries in the applied configuration and system controlled configuration datastores, thus allowing disjoint config vs state lists to be merged together into a single list. Being an abstract datastore that is part of the operational state datastore it is read-only. Wilton Expires December 5, 2016 [Page 10] Internet-Draft Refined YANG Datastores June 2016 The contents of this datastore must be made available as part of the operational state datastore. It is optional as to whether the device also allows this datastore to be directly read (or notified) as a labelled, operator visible, datastore. If supported, the default behavior for get requests (or YANG push notifications) on this datastore is to explicitly return all values in effect in the system (including any values that are implicit due to a YANG schema default). 6. Discussion points 6.1. Missing resources Configuration that cannot be applied because the system resources are missing (or have been exhausted) would logically exist in the intended configuration datastore but not the applied configuration datastore. 6.2. System controlled resources System controlled resources (i.e. those resources that would exist in the system regardless of configuration) always exist in the system controlled configuration datastore. They may also exist in the applied configuration datastore if they have also been configured (and the configuration successfully applied to the device). 6.3. Auto-configured or auto-negotiated values The applied configuration datastore only represents the configuration that is applied. Generally, separate config false leaves in the system state datastore are used to represent the operational state of the device. In the specific case that the operational value is (i) directly controlled by configuration, (ii) has exactly the same schema value space as the corresponding configuration leaf, and (iii) if configured, the operational value of the system must be the same as the applied configuration then no separate config false leaf is needed. This optimization is valid because the system state datastore leaf value would always have exactly the same lifetime and value as the corresponding configuration leaf in the applied configuration datastore. Wilton Expires December 5, 2016 [Page 11] Internet-Draft Refined YANG Datastores June 2016 6.4. Operational State with Different Origins The definition of the operational state datastore is designed to allow config false leaves to depend on either explicitly configured entities (in the applied configuration datastore) or system created entries (in the system controlled configuration) datastore. This definition facilitates the merging of separate configuration and state parts of YANG models into the same container/lists if desired. An example are IP addresses of an interface that can originate from configuration, from DHCP, or may be dynamically auto-configured. In this case, the operational state datastore would contain all IP addresses. The explicitly configured addresses would logically exist in the applied configuration datastore. Addresses learned through DHCP or dynamically configured would logically exist in the system controlled configuration datastore. Enhanced get/notification requests with YANG metadata annotations could be used to amend the reply/notification with metadata information to indicate which datastore the entries logically exist in. 7. Implications of the Refined Datastore Model 7.1. Implications for opstate unaware clients This sections describes the implications for all opstate unaware clients, which includes all existing standards compliant NETCONF/ RESTCONF clients. One of the key aims of the refined datastore model described in this draft is to minimize the impact on existing (or opstate unaware) NETCONF/RESTCONF clients and devices. The assumption of this model is that for an opstate unaware device, the persistent configuration, intended configuration and applied configuration datastores all hold exactly the same values. This is also why they are collectively labelled as the abstract running configuration datastore). Hence, for opstate unaware clients the key change is that NETCONF/ RESTCONF get requests now only returns the state from the operational-state datastore rather than returning the running configuration datastore plus all config=false nodes. This means that there are two specific changes to how get requests are handled compared to how they would be handled by existing NETCONF/RESTCONF devices: 1. System created configuration entries would be included in any new YANG models that have been designed to allow configuration and state to be held in a single combined list. Given that existing YANG models are all specifically designed to avoid this scenario, Wilton Expires December 5, 2016 [Page 12] Internet-Draft Refined YANG Datastores June 2016 this change would only affect new YANG models. No existing YANG models would be affected by this change. 2. This draft proposes different standard default handling semantics for the operational state datastore. Hence, unless the client requested otherwise, the device would be recommended to explicitly return all default values in a get request (or YANG push notification). This is exactly the same behavior as the 'report-all' retrieval mode described in With-defaults Capability for NETCONF [RFC6243]. The other potential impact is the recommendation that the standard default handling semantics for the persistent configure datastore (which is what would be returned for a get-config request against the abstract running configuration datastore) is that the exact configuration written by the client should be returned. This is exactly the same behavior as the 'explicit' retrieval mode described in With-defaults Capability for NETCONF [RFC6243]. 7.1.1. Upgradeability The solution described in this document is intended to provide a viable upgrade path from an opstate unaware server to one that is opstate aware. I.e. it is feasible for an existing NETCONF/RESTCONF server to declare itself as being trivially opstate aware (treating applied configuration as the same as intended configuration) and over time refine the data it returns to provide more accurate applied configuration state. 7.2. Implications for opstate aware clients This sections describes the implications for all opstate aware clients. Although this draft references a total of ten datastores, the expectation is that devices will only expose a subset as explicit named datastores. Of course, devices could also expose them all as formal externally visible datastores if desired. In particular, depending on the protocol semantics, an opstate aware device would be expected to support the following datastores/ requests: o Startup configuration ds - (already supported in NETCONF, implicit in RESTCONF) o Persistent configuration ds - edit-config and get-config requests only (added to NETCONF, implicit in RESTCONF) Wilton Expires December 5, 2016 [Page 13] Internet-Draft Refined YANG Datastores June 2016 o Intended configuration ds - get-config requests only, handled as a transparent reference to the persistent configuration ds if ephemeral config datastore is not supported (added to NETCONF, optionally added to RESTCONF) o Operational state ds - get request only (added to NETCONF, optionally added to RESTCONF) o Candidate configuration ds - optional (already supported in NETCONF, implicit in RESTCONF) o Running configuration ds - for backwards compatibility. edit- config/get-config requests are directed to the persistent datastore, get requests are directed to the operational state datastore (already supported in NETCONF, implicit in RESTCONF) Support for operations on the following datastores would be optional: o Ephemeral configuration ds - get-config requests only o Applied configuration ds - get requests only o System controlled configuration ds - get requests only o System state datastore - get requests only Some of the nodes in these datastores rely on the structure and existance of nodes in the preceding datastores to be valid. Hence, get requests and YANG notifications would have to include sufficient parent nodes (and list keys) to represent a valid YANG data tree. Rather that explicitly supporting and requiring management of all of these separate datastores, it is envisaged that optional YANG Metadata could be used to provide extra annotations to a subset of the datastores, allowing key additional information to be provided. A full solution is outside the scope of this draft, but it is envisaged that such annotations could be: o Persistent config datastore, with any nodes that are not also in the applied configuration datastore annotated (possibly along with the reason why they are not applied). o Intended config datastore, with any nodes that are not also in the applied configuration datastore annotated (possibly along with the reason why they are not applied). Wilton Expires December 5, 2016 [Page 14] Internet-Draft Refined YANG Datastores June 2016 o Operational state datastore, with any applied configuration ds nodes that do not also match intended configuration ds annotated, and also any system created configuration ds nodes annotated. 8. Acknowledgements This document is not solely the authors own work, but instead represents one view from the discussions to find a consensual solution to the operational state problem. It takes ideas from many people and uses parts of solutions described in various internet drafts listed below. In particular, this document is an alternative to the revised datastore model described in draft-schoenw-netmod- revised-datastores [I-D.schoenw-netmod-revised-datastores], and reuses some of the structure and text from that document. Work from the following internet drafts have helped form the basis of the datastore solution described in this draft: o draft-bjorklund-netmod-operational [I-D.bjorklund-netmod-operational] o draft-ietf-netmod-opstate-reqs [I-D.ietf-netmod-opstate-reqs] o draft-kwatsen-netmod-opstate [I-D.kwatsen-netmod-opstate] o draft-openconfig-netmod-opstate [I-D.openconfig-netmod-opstate] o draft-schoenw-netmod-revised-datastores [I-D.schoenw-netmod-revised-datastores] o draft-wilton-netmod-opstate-yang [I-D.wilton-netmod-opstate-yang] o draft-ietf-i2rs-ephemeral-state [I-D.ietf-i2rs-ephemeral-state] The following people were authors to these Internet-Drafts or otherwise actively involved in the discussions that led to this document: o Lou Berger, Labn Consulting, o Andy Biermann, YumaWorks, o Martin Bjorklund, Tail-f Systems, o Susan Hares, Huawei, o Jeff Haas, Juniper Networks, Wilton Expires December 5, 2016 [Page 15] Internet-Draft Refined YANG Datastores June 2016 o Marcus Hines, Google, o Christian Hopps, Cisco Systems, o Acee Lindem, Cisco Systems, o Ladislav Lhotka, CZ.NIC, o Thomas Nadeau, Brocade Networks, o Juergen Schoenwaelder, Jacobs University Bremen o Anees Shaikh, Google, o Rob Shakir, Jive Communications, o Kent Watsen, Juniper Networks, 9. IANA Considerations None 10. Security Considerations This document discusses a conceptual model of datastores for network management using NETCONF/RESTCONF and YANG. It has no security impact on the Internet. 11. References 11.1. Normative References [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6243] Bierman, A. and B. Lengyel, "With-defaults Capability for NETCONF", RFC 6243, DOI 10.17487/RFC6243, June 2011, . 11.2. Informative References [I-D.bjorklund-netmod-operational] Bjorklund, M. and L. Lhotka, "Operational Data in NETCONF and YANG", draft-bjorklund-netmod-operational-00 (work in progress), October 2012. Wilton Expires December 5, 2016 [Page 16] Internet-Draft Refined YANG Datastores June 2016 [I-D.ietf-i2rs-ephemeral-state] Haas, J. and S. Hares, "I2RS Ephemeral State Requirements", draft-ietf-i2rs-ephemeral-state-09 (work in progress), May 2016. [I-D.ietf-netmod-opstate-reqs] Watsen, K. and T. Nadeau, "Terminology and Requirements for Enhanced Handling of Operational State", draft-ietf- netmod-opstate-reqs-04 (work in progress), January 2016. [I-D.kwatsen-netmod-opstate] Watsen, K., Bierman, A., Bjorklund, M., and J. Schoenwaelder, "Operational State Enhancements for YANG, NETCONF, and RESTCONF", draft-kwatsen-netmod-opstate-02 (work in progress), February 2016. [I-D.openconfig-netmod-opstate] Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling of Operational State Data in YANG", draft-openconfig- netmod-opstate-01 (work in progress), July 2015. [I-D.schoenw-netmod-revised-datastores] Schoenwaelder, J., "A Revised Conceptual Model for YANG Datastores", draft-schoenw-netmod-revised-datastores-00 (work in progress), May 2016. [I-D.wilton-netmod-opstate-yang] Wilton, R., ""With-config-state" Capability for NETCONF/ RESTCONF", draft-wilton-netmod-opstate-yang-02 (work in progress), December 2015. [RFC6244] Shafer, P., "An Architecture for Network Management Using NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244, June 2011, . Author's Address Robert Wilton (editor) Cisco Systems Email: rwilton@cisco.com Wilton Expires December 5, 2016 [Page 17]