draft-ietf-netmod-revised-datastores-04.txt		draft-ietf-netmod-revised-datastores-05.txt
	Network Working Group M. Bjorklund		Network Working Group M. Bjorklund
	Internet-Draft Tail-f Systems		Internet-Draft Tail-f Systems
	Intended status: Standards Track J. Schoenwaelder		Updates: 7950 (if approved) J. Schoenwaelder
	Expires: February 25, 2018 Jacobs University		Intended status: Standards Track Jacobs University
	P. Shafer		Expires: April 21, 2018 P. Shafer
	K. Watsen		K. Watsen
	Juniper Networks		Juniper Networks
	R. Wilton		R. Wilton
	Cisco Systems		Cisco Systems
	August 24, 2017		October 18, 2017
	Network Management Datastore Architecture		Network Management Datastore Architecture
	draft-ietf-netmod-revised-datastores-04		draft-ietf-netmod-revised-datastores-05
	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 February 25, 2018.		This Internet-Draft will expire on April 21, 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Original Model of Datastores . . . . . . . . . . . . . . 7		4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 7
	4. Architectural Model of Datastores . . . . . . . . . . . . . . 8		4.1. Original Model of Datastores . . . . . . . . . . . . . . 8
	4.1. The Startup Configuration Datastore (<startup>) . . . . . 9		5. Architectural Model of Datastores . . . . . . . . . . . . . . 9
	4.2. The Candidate Configuration Datastore (<candidate>) . . . 10		5.1. Conventional Configuration Datastores . . . . . . . . . . 10
	4.3. The Running Configuration Datastore (<running>) . . . . . 10		5.1.1. The Startup Configuration Datastore (<startup>) . . . 11
	4.4. The Intended Configuration Datastore (<intended>) . . . . 10		5.1.2. The Candidate Configuration Datastore (<candidate>) . 11
	4.5. Conventional Configuration Datastores . . . . . . . . . . 11		5.1.3. The Running Configuration Datastore (<running>) . . . 11
	4.6. Dynamic Configuration Datastores . . . . . . . . . . . . 11		5.1.4. The Intended Configuration Datastore (<intended>) . . 12
	4.7. The Operational State Datastore (<operational>) . . . . . 11		5.2. Dynamic Configuration Datastores . . . . . . . . . . . . 13
	4.7.1. Remnant Configuration . . . . . . . . . . . . . . . . 12		5.3. The Operational State Datastore (<operational>) . . . . . 13
	4.7.2. Missing Resources . . . . . . . . . . . . . . . . . . 13		5.3.1. Remnant Configuration . . . . . . . . . . . . . . . . 14
	4.7.3. System-controlled Resources . . . . . . . . . . . . . 13		5.3.2. Missing Resources . . . . . . . . . . . . . . . . . . 14
	4.7.4. Origin Metadata Annotation . . . . . . . . . . . . . 13		5.3.3. System-controlled Resources . . . . . . . . . . . . . 15
	5. Implications on YANG . . . . . . . . . . . . . . . . . . . . 15		5.3.4. Origin Metadata Annotation . . . . . . . . . . . . . 15
	5.1. XPath Context . . . . . . . . . . . . . . . . . . . . . . 15		6. Implications on YANG . . . . . . . . . . . . . . . . . . . . 16
	6. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 16		6.1. XPath Context . . . . . . . . . . . . . . . . . . . . . . 16
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21		7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 17
	7.1. Updates to the IETF XML Registry . . . . . . . . . . . . 21		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
	7.2. Updates to the YANG Module Names Registry . . . . . . . . 22		8.1. Updates to the IETF XML Registry . . . . . . . . . . . . 23
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 22		8.2. Updates to the YANG Module Names Registry . . . . . . . . 23
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22		9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
	10.1. Normative References . . . . . . . . . . . . . . . . . . 23		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
	10.2. Informative References . . . . . . . . . . . . . . . . . 23		11.1. Normative References . . . . . . . . . . . . . . . . . . 25
	Appendix A. Guidelines for Defining Datastores . . . . . . . . . 24		11.2. Informative References . . . . . . . . . . . . . . . . . 25
	A.1. Define which YANG modules can be used in the datastore . 24		Appendix A. Guidelines for Defining Datastores . . . . . . . . . 26
	A.2. Define which subset of YANG-modeled data applies . . . . 25		A.1. Define which YANG modules can be used in the datastore . 26
	A.3. Define how data is actualized . . . . . . . . . . . . . . 25		A.2. Define which subset of YANG-modeled data applies . . . . 27
	A.4. Define which protocols can be used . . . . . . . . . . . 25		A.3. Define how data is actualized . . . . . . . . . . . . . . 27
	A.5. Define YANG identities for the datastore . . . . . . . . 25		A.4. Define which protocols can be used . . . . . . . . . . . 27
	Appendix B. Ephemeral Dynamic Configuration Datastore Example . 26		A.5. Define YANG identities for the datastore . . . . . . . . 27
	Appendix C. Example Data . . . . . . . . . . . . . . . . . . . . 27		Appendix B. Ephemeral Dynamic Configuration Datastore Example . 28
	C.1. System Example . . . . . . . . . . . . . . . . . . . . . 27		Appendix C. Example Data . . . . . . . . . . . . . . . . . . . . 29
	C.2. BGP Example . . . . . . . . . . . . . . . . . . . . . . . 29		C.1. System Example . . . . . . . . . . . . . . . . . . . . . 29
	C.2.1. Datastores . . . . . . . . . . . . . . . . . . . . . 31		C.2. BGP Example . . . . . . . . . . . . . . . . . . . . . . . 32
	C.2.2. Adding a Peer . . . . . . . . . . . . . . . . . . . . 31		C.2.1. Datastores . . . . . . . . . . . . . . . . . . . . . 34
	C.2.3. Removing a Peer . . . . . . . . . . . . . . . . . . . 32		C.2.2. Adding a Peer . . . . . . . . . . . . . . . . . . . . 34
	C.3. Interface Example . . . . . . . . . . . . . . . . . . . . 33		C.2.3. Removing a Peer . . . . . . . . . . . . . . . . . . . 35
	C.3.1. Pre-provisioned Interfaces . . . . . . . . . . . . . 33		C.3. Interface Example . . . . . . . . . . . . . . . . . . . . 36
	C.3.2. System-provided Interface . . . . . . . . . . . . . . 34		C.3.1. Pre-provisioned Interfaces . . . . . . . . . . . . . 36
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35		C.3.2. System-provided Interface . . . . . . . . . . . . . . 37
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
	1. Introduction		1. Introduction
	This document provides an architectural framework for datastores as		This document provides an architectural framework for datastores as
	they are used by network management protocols such as NETCONF		they are used by network management protocols such as NETCONF
	[RFC6241], RESTCONF [RFC8040] and the YANG [RFC7950] data modeling		[RFC6241], RESTCONF [RFC8040] and the YANG [RFC7950] data modeling
	language. Datastores are a fundamental concept binding network		language. Datastores are a fundamental concept binding network
	management data models to network management protocols. Agreement on		management data models to network management protocols. Agreement on
	a common architectural model of datastores ensures that data models		a common architectural model of datastores ensures that data models
	can be written in a network management protocol agnostic way. This		can be written in a network management protocol agnostic way. This
	architectural framework identifies a set of conceptual datastores but		architectural framework identifies a set of conceptual datastores but
	it does not mandate that all network management protocols expose all		it does not mandate that all network management protocols expose all
	these conceptual datastores. This architecture is agnostic with		these conceptual datastores. This architecture is agnostic with
	regard to the encoding used by network management protocols.		regard to the encoding used by network management protocols.
	2. Terminology		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
			"OPTIONAL" in this document are to be interpreted as described in BCP
			14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
			2. Objectives
			Network management data objects can often take two different values,
			the value configured by the user or an application (configuration)
			and the value that the device is actually using (operational state).
			These two values may be different for a number of reasons, e.g.,
			system internal interactions with hardware, interaction with
			protocols or other devices, or simply the time it takes to propagate
			a configuration change to the software and hardware components of a
			system. Furthermore, configuration and operational state data
			objects may have different lifetimes.
			The original model of datastores required these data objects to be
			modeled twice in the YANG schema, as "config true" objects and as
			"config false" objects. The convention adopted by the interfaces
			data model ([RFC7223]) and the IP data model ([RFC7277]) was using
			two separate branches rooted at the root of the data tree, one branch
			for configuration data objects and one branch for operational state
			data objects.
			The duplication of definitions and the ad-hoc separation of
			operational state data from configuration data leads to a number of
			problems. Having configuration and operational state data in
			separate branches in the data model is operationally complicated and
			impacts the readability of module definitions. Furthermore, the
			relationship between the branches is not machine readable and filter
			expressions operating on configuration and on related operational
			state are different.
			With the revised architectural model of datastores defined in this
			document, the data objects are defined only once in the YANG schema
			but independent instantiations can appear in two different
			datastores, one for configured values and one for operational state
			values. This provides a more elegant and simpler solution to the
			problem.
			The revised architectural model of datastores supports additional
			datastores for systems that support more advanced processing chains
			converting configuration to operational state. For example, some
			systems support configuration that is not currently used (so called
			inactive configuration) or they support configuration templates that
			are used to expand configuration data via a common template.
			3. Terminology
	This document defines the following terminology. Some of the terms		This document defines the following terminology. Some of the terms
	are revised definitions of terms originally defined in [RFC6241] and		are revised definitions of terms originally defined in [RFC6241] and
	[RFC7950] (see also section Section 3). The revised definitions are		[RFC7950] (see also section Section 4). The revised definitions are
	semantically equivalent with the definitions found in [RFC6241] and		semantically equivalent with the definitions found in [RFC6241] and
	[RFC7950]. It is expected that the revised definitions provided in		[RFC7950]. It is expected that the revised definitions provided in
	this section will replace the definitions in [RFC6241] and [RFC7950]		this section will replace the definitions in [RFC6241] and [RFC7950]
	when these documents are revised.		when these documents are revised.
	o datastore: A conceptual place to store and access information. A		o datastore: A conceptual place to store and access information. A
	datastore might be implemented, for example, using files, a		datastore might be implemented, for example, using files, a
	database, flash memory locations, or combinations thereof. A		database, flash memory locations, or combinations thereof. A
	datastore maps to an instantiated YANG data tree.		datastore maps to an instantiated YANG data tree.
	o configuration: Data that is required to get a device from its		o configuration: Data that is required to get a device from its
	initial default state into a desired operational state. This data		initial default state into a desired operational state. This data
	is modeled in YANG using "config true" nodes. Configuration can		is modeled in YANG using "config true" nodes. Configuration can
	originate from different sources.		originate from different sources.
	o configuration datastore: A datastore holding configuration.		o configuration datastore: A datastore holding configuration.
	o running configuration datastore: A configuration datastore holding		o running configuration datastore: A configuration datastore holding
	the current configuration of the device. It may include inactive		the current configuration of the device. It may include
	configuration or template-mechanism-oriented configuration that		configuration that requires further transformations before it can
	require further expansion. This datastore is commonly referred to		be applied. This datastore is referred to as "<running>".
	as "<running>".
	o candidate configuration datastore: A configuration datastore that		o candidate configuration datastore: A configuration datastore that
	can be manipulated without impacting the device's running		can be manipulated without impacting the device's running
	configuration datastore and that can be committed to the running		configuration datastore and that can be committed to the running
	configuration datastore. This datastore is commonly referred to		configuration datastore. This datastore is referred to as
	as "<candidate>".		"<candidate>".
	o startup configuration datastore: A configuration datastore holding		o startup configuration datastore: A configuration datastore holding
	the configuration loaded by the device into the running		the configuration loaded by the device into the running
	configuration datastore when it boots. This datastore is commonly		configuration datastore when it boots. This datastore is referred
	referred to as "<startup>".		to as "<startup>".
	o intended configuration: Configuration that is intended to be used		o intended configuration: Configuration that is intended to be used
	by the device. For example, intended configuration excludes any		by the device. It represents the configuration after all
	inactive configuration and it would include configuration produced		configuration transformations to <running> have been performed and
	through the expansion of templates.		is the configuration that the system attempts to apply.
	o intended configuration datastore: A configuration datastore		o intended configuration datastore: A configuration datastore
	holding the complete intended configuration of the device. This		holding the complete intended configuration of the device. This
	datastore is commonly referred to as "<intended>".		datastore is referred to as "<intended>".
			o configuration transformation: The addition, modification or
			removal of configuration between the <running> and <intended>
			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		o conventional configuration datastore: One of the following set of
	configuration datastores: <running>, <startup>, <candidate>, and		configuration datastores: <running>, <startup>, <candidate>, and
	<intended>. These datastores share a common schema and protocol		<intended>. These datastores share a common schema, and protocol
	operations allow copying data between these datastores. The term		operations allow copying data between these datastores. The term
	"conventional" is chosen as a generic umbrella term for these		"conventional" is chosen as a generic umbrella term for these
	datastores.		datastores.
	o conventional configuration: Configuration that is stored in any of		o conventional configuration: Configuration that is stored in any of
	the conventional configuration datastores.		the conventional configuration datastores.
	o dynamic configuration datastore: A configuration datastore holding		o dynamic configuration datastore: A configuration datastore holding
	configuration obtained dynamically during the operation of a		configuration obtained dynamically during the operation of a
	device through interaction with other systems, rather than through		device through interaction with other systems, rather than through
	skipping to change at page 5, line 19 ¶		skipping to change at page 6, line 29 ¶
	o system state: The additional data on a system that is not		o system state: The additional data on a system that is not
	configuration, such as read-only status information and collected		configuration, such as read-only status information and collected
	statistics. System state is transient and modified by		statistics. System state is transient and modified by
	interactions with internal components or other systems. System		interactions with internal components or other systems. System
	state is modeled in YANG using "config false" nodes.		state is modeled in YANG using "config false" nodes.
	o operational state: The combination of applied configuration and		o operational state: The combination of applied configuration and
	system state.		system state.
	o operational state datastore: A datastore holding the complete		o operational state datastore: A datastore holding the complete
	operational state of the device. This datastore is commonly		operational state of the device. This datastore is referred to as
	referred to as "<operational>".		"<operational>".
	o origin: A metadata annotation indicating the origin of a data		o origin: A metadata annotation indicating the origin of a data
	item.		item.
	o remnant configuration: Configuration that remains part of the		o remnant configuration: Configuration that remains part of the
	applied configuration for a period of time after it has been		applied configuration for a period of time after it has been
	removed from the intended configuration or dynamic configuration.		removed from the intended configuration or dynamic configuration.
	The time period may be minimal, or may last until all resources		The time period may be minimal, or may last until all resources
	used by the newly-deleted configuration (e.g., network		used by the newly-deleted configuration (e.g., network
	connections, memory allocations, file handles) have been		connections, memory allocations, file handles) have been
	skipping to change at page 5, line 48 ¶		skipping to change at page 7, line 11 ¶
	o server: An entity that provides access to YANG-defined data to a		o server: An entity that provides access to YANG-defined data to a
	client, over some network management protocol.		client, over some network management protocol.
	o notification: A server-initiated message indicating that a certain		o notification: A server-initiated message indicating that a certain
	event has been recognized by the server.		event has been recognized by the server.
	o remote procedure call: An operation that can be invoked by a		o remote procedure call: An operation that can be invoked by a
	client on a server.		client on a server.
	3. Background		4. Background
	NETCONF [RFC6241] provides the following definitions:		NETCONF [RFC6241] provides the following definitions:
	o datastore: A conceptual place to store and access information. A		o datastore: A conceptual place to store and access information. A
	datastore might be implemented, for example, using files, a		datastore might be implemented, for example, using files, a
	database, flash memory locations, or combinations thereof.		database, flash memory locations, or combinations thereof.
	o configuration datastore: The datastore holding the complete set of		o configuration datastore: The datastore holding the complete set of
	configuration that is required to get a device from its initial		configuration that is required to get a device from its initial
	default state into a desired operational state.		default state into a desired operational state.
	skipping to change at page 6, line 44 ¶		skipping to change at page 8, line 5 ¶
	being stored in another datastore. Section 4.4 of this document then		being stored in another datastore. Section 4.4 of this document then
	concludes that at the time of the writing, modeling state as distinct		concludes that at the time of the writing, modeling state as distinct
	leafs and distinct branches is the recommended approach.		leafs and distinct branches is the recommended approach.
	Implementation experience and requests from operators		Implementation experience and requests from operators
	[I-D.ietf-netmod-opstate-reqs], [I-D.openconfig-netmod-opstate]		[I-D.ietf-netmod-opstate-reqs], [I-D.openconfig-netmod-opstate]
	indicate that the datastore model initially designed for NETCONF and		indicate that the datastore model initially designed for NETCONF and
	refined by YANG needs to be extended. In particular, the notion of		refined by YANG needs to be extended. In particular, the notion of
	intended configuration and applied configuration has developed.		intended configuration and applied configuration has developed.
	Furthermore, separating operational state from configuration in a		4.1. Original Model of Datastores
	separate branch in the data model has been found operationally
	complicated, and typically impacts the readability of module
	definitions due to overuse of groupings. The relationship between
	the branches is not machine readable and filter expressions operating
	on configuration and on related operational state are different.
	3.1. Original Model of Datastores
	The following drawing shows the original model of datastores as it is		The following drawing shows the original model of datastores as it is
	currently used by NETCONF [RFC6241]:		currently used by NETCONF [RFC6241]:
	+-------------+ +-----------+		+-------------+ +-----------+
	| <candidate> | | <startup> |		| <candidate> | | <startup> |
	| (ct, rw) |<---+ +--->| (ct, rw) |		| (ct, rw) |<---+ +--->| (ct, rw) |
	+-------------+ | | +-----------+		+-------------+ | | +-----------+
	| | | |		| | | |
	| +-----------+ |		| +-----------+ |
	skipping to change at page 7, line 48 ¶		skipping to change at page 8, line 48 ¶
	configuration is made persistent. Note that implementations may also		configuration is made persistent. Note that implementations may also
	have additional datastores that can propagate changes to <running>.		have additional datastores that can propagate changes to <running>.
	NETCONF explicitly mentions so called named datastores.		NETCONF explicitly mentions so called named datastores.
	Some observations:		Some observations:
	o Operational state has not been defined as a datastore although		o Operational state has not been defined as a datastore although
	there were proposals in the past to introduce an operational state		there were proposals in the past to introduce an operational state
	datastore.		datastore.
	o The NETCONF <get/> operation returns the content of the running		o The NETCONF <get> operation returns the contents of <running>
	configuration datastore together with the operational state. It		together with the operational state. It is therefore necessary
	is therefore necessary that "config false" data is in a different		that "config false" data is in a different branch than the "config
	branch than the "config true" data if the operational state can		true" data if the operational state can have a different lifetime
	have a different lifetime compared to configuration or if		compared to configuration or if configuration is not immediately
	configuration is not immediately or successfully applied.		or successfully applied.
	o Several implementations have proprietary mechanisms that allow		o Several implementations have proprietary mechanisms that allow
	clients to store inactive data in <running>; this inactive data is		clients to store inactive data in <running>. Inactive data is
	only exposed to clients that indicate that they support the		conceptually removed before validation.
	concept of inactive data; clients not indicating support for
	inactive data receive the content of <running> with the inactive
	data removed. Inactive data is conceptually removed before
	validation.
	o Some implementations have proprietary mechanisms that allow		o Some implementations have proprietary mechanisms that allow
	clients to define configuration templates in <running>. These		clients to define configuration templates in <running>. These
	templates are expanded automatically by the system, and the		templates are expanded automatically by the system, and the
	resulting configuration is applied internally.		resulting configuration is applied internally.
	o Some operators have reported that it is essential for them to be		o Some operators have reported that it is essential for them to be
	able to retrieve the configuration that has actually been		able to retrieve the configuration that has actually been
	successfully applied, which may be a subset or a superset of the		successfully applied, which may be a subset or a superset of the
	<running> configuration.		<running> configuration.
	4. Architectural Model of Datastores		5. Architectural Model of Datastores
	Below is a new conceptual model of datastores extending the original		Below is a new conceptual model of datastores extending the original
	model in order to reflect the experience gained with the original		model in order to reflect the experience gained with the original
	model.		model.
	+-------------+ +-----------+		+-------------+ +-----------+
	| <candidate> | | <startup> |		| <candidate> | | <startup> |
	| (ct, rw) |<---+ +--->| (ct, rw) |		| (ct, rw) |<---+ +--->| (ct, rw) |
	+-------------+ | | +-----------+		+-------------+ | | +-----------+
	| | | |		| | | |
	skipping to change at page 9, line 41 ¶		skipping to change at page 10, line 41 ¶
	v v v		v v v
	+---------------+		+---------------+
	| <operational> | <-- system state		| <operational> | <-- system state
	| (ct + cf, ro) |		| (ct + cf, ro) |
	+---------------+		+---------------+
	ct = config true; cf = config false		ct = config true; cf = config false
	rw = read-write; ro = read-only		rw = read-write; ro = read-only
	boxes denote named datastores		boxes denote named datastores
	4.1. The Startup Configuration Datastore (<startup>)		5.1. Conventional Configuration Datastores
	The startup configuration datastore (<startup>) is an optional		The conventional configuration datastores are a set of configuration
	configuration datastore holding the configuration loaded by the		datastores that share exactly the same schema, allowing data to be
	device when it boots. <startup> is only present on devices that		copied between them. The term is meant as a generic umbrella
	separate the startup configuration from the running configuration		description of these datastores. The set of datastores include:
	datastore.
			o <running>
			o <candidate>
			o <startup>
			o <intended>
			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 <copy-config> operation.
			5.1.1. The Startup Configuration Datastore (<startup>)
			The startup configuration datastore (<startup>) is a configuration
			datastore holding the configuration loaded by the device when it
			boots. <startup> is only present on devices that separate the
			startup configuration from the running configuration datastore.
	The startup configuration datastore may not be supported by all		The startup configuration datastore may not be supported by all
	protocols or implementations.		protocols or implementations.
	On devices that support non-volatile storage, the contents of		On devices that support non-volatile storage, the contents of
	<startup> will typically persist across reboots via that storage. At		<startup> will typically persist across reboots via that storage. At
	boot time, the device loads the saved startup configuration into		boot time, the device loads the saved startup configuration into
	<running>. To save a new startup configuration, data is copied to		<running>. To save a new startup configuration, data is copied to
	<startup>, either via implicit or explicit protocol operations.		<startup>, either via implicit or explicit protocol operations.
	4.2. The Candidate Configuration Datastore (<candidate>)		5.1.2. The Candidate Configuration Datastore (<candidate>)
	The candidate configuration datastore (<candidate>) is an optional		The candidate configuration datastore (<candidate>) is a
	configuration datastore that can be manipulated without impacting the		configuration datastore that can be manipulated without impacting the
	device's current configuration and that can be committed to		device's current configuration and that can be committed to
	<running>.		<running>.
	The candidate configuration datastore may not be supported by all		The candidate configuration datastore may not be supported by all
	protocols or implementations.		protocols or implementations.
	<candidate> does not typically persist across reboots, even in the		<candidate> does not typically persist across reboots, even in the
	presence of non-volatile storage. If <candidate> is stored using		presence of non-volatile storage. If <candidate> is stored using
	non-volatile storage, it should be reset at boot time to the contents		non-volatile storage, it is reset at boot time to the contents of
	of <running>.		<running>.
	4.3. The Running Configuration Datastore (<running>)		5.1.3. The Running Configuration Datastore (<running>)
	The running configuration datastore (<running>) holds the complete		The running configuration datastore (<running>) is a configuration
	current configuration on the device. It may include inactive		datastore that holds the complete current configuration on the
	configuration or template-mechanism-oriented configuration that		device. It MAY include configuration that requires further
	require further expansion.		transformation before it can be applied, e.g., inactive
			configuration, or template-mechanism-oriented configuration that
			needs further expansion. However, <running> MUST always be a valid
			configuration data tree, as defined in Section 8.1 of [RFC7950].
	If a device does not have a distinct <startup> and non-volatile is		<running> MUST be supported if the device can be configured via
	available, the device will typically use that non-volatile storage to		conventional configuration datastores.
	allow <running> to persist across reboots.
	4.4. The Intended Configuration Datastore (<intended>)		If a device does not have a distinct <startup> and non-volatile
			storage is available, the device will typically use that non-volatile
			storage to allow <running> to persist across reboots.
			5.1.4. The Intended Configuration Datastore (<intended>)
	The intended configuration datastore (<intended>) is a read-only		The intended configuration datastore (<intended>) is a read-only
	configuration datastore. It is tightly coupled to <running>. When		configuration datastore. It represents the configuration after all
	data is written to <running>, the data that is to be validated is		configuration transformations to <running> are performed (e.g.,
	also conceptually written to <intended>. Validation is performed on		template expansion, removal of inactive configuration), and is the
	the contents of <intended>.		configuration that the system attempts to apply.
			<intended> is tightly coupled to <running>. Whenever data is written
			to <running>, then <intended> MUST also be immediately updated by
			performing all necessary configuration transformations to the
			contents of <running> and then <intended> is validated.
			<intended> MAY also be updated independently of <running> if the
			effect of a configuration transformation changes, but <intended> MUST
			always be a valid configuration data tree, as defined in Section 8.1
			of [RFC7950].
	For simple implementations, <running> and <intended> are identical.		For simple implementations, <running> and <intended> are identical.
			The contents of <intended> are also related to the "config true"
			subset of <operational>, and hence a client can determine to what
			extent the intended configuration is currently in use by checking
			whether the contents of <intended> also appear in <operational>.
	<intended> does not persist across reboots; its relationship with		<intended> does not persist across reboots; its relationship with
	<running> makes that unnecessary.		<running> makes that unnecessary.
	Currently there are no standard mechanisms defined that affect		Currently there are no standard mechanisms defined that affect
	<intended> so that it would have different contents than <running>,		<intended> so that it would have different content than <running>,
	but this architecture allows for such mechanisms to be defined.		but this architecture allows for such mechanisms to be defined.
	One example of such a mechanism is support for marking nodes as		One example of such a mechanism is support for marking nodes as
	inactive in <running>. Inactive nodes are not copied to <intended>,		inactive in <running>. Inactive nodes are not copied to <intended>.
	and are thus not taken into account when validating the		A second example is support for templates, which can perform
	configuration.		transformations on the configuration from <running> to the
			configuration written to <intended>.
	Another example is support for templates. Templates are expanded
	when copied into <intended>, and the expanded result is validated.
	4.5. Conventional Configuration Datastores
	The conventional configuration datastores are a set of configuration
	datastores that share a common 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 <running>
	o <candidate>
	o <startup>
	o <intended>
	Other conventional configuration datastores may be defined in future
	documents.
	The flow of data between these datastores is depicted in section
	Section 4.
	The specific protocols may define explicit operations to copy between
	these datastores, e.g., NETCONF's <copy-config> operation.
	4.6. Dynamic Configuration Datastores		5.2. Dynamic Configuration Datastores
	The model recognizes the need for dynamic configuration datastores		The model recognizes the need for dynamic configuration datastores
	that are, by definition, not part of the persistent configuration of		that are, by definition, not part of the persistent configuration of
	a device. In some contexts, these have been termed ephemeral		a device. In some contexts, these have been termed ephemeral
	datastores since the information is ephemeral, i.e., lost upon		datastores since the information is ephemeral, i.e., lost upon
	reboot. The dynamic configuration datastores interact with the rest		reboot. The dynamic configuration datastores interact with the rest
	of the system through <operational>.		of the system through <operational>.
	4.7. The Operational State Datastore (<operational>)		5.3. The Operational State Datastore (<operational>)
	The operational state datastore (<operational>) is a read-only		The operational state datastore (<operational>) is a read-only
	datastore that consists of all "config true" and "config false" nodes		datastore that consists of all "config true" and "config false" nodes
	defined in the schema. In the original NETCONF model the operational		defined in the schema. In the original NETCONF model the operational
	state only had "config false" nodes. The reason for incorporating		state only had "config false" nodes. The reason for incorporating
	"config true" nodes here is to be able to expose all operational		"config true" nodes here is to be able to expose all operational
	settings without having to replicate definitions in the data models.		settings without having to replicate definitions in the data models.
	<operational> contains system state and all configuration actually		<operational> contains system state and all configuration actually
	used by the system. This includes all applied configuration from		used by the system. This includes all applied configuration from
	skipping to change at page 12, line 22 ¶		skipping to change at page 13, line 38 ¶
	configuration datastores.		configuration datastores.
	Requests to retrieve nodes from <operational> always return the value		Requests to retrieve nodes from <operational> always return the value
	in use if the node exists, regardless of any default value specified		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		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.		this implies that the node is not used by the device.
	The interpretation of what constitutes as being "in use" by the		The interpretation of what constitutes as being "in use" by the
	system is dependent on both the schema definition and the device		system is dependent on both the schema definition and the device
	implementation. Generally, functionality that is enabled and		implementation. Generally, functionality that is enabled and
	operational on the system would be considered as being 'in use'.		operational on the system would be considered as being "in use".
	Conversely, functionality that is neither enabled nor operational on		Conversely, functionality that is neither enabled nor operational on
	the system could be considered as not being 'in use', and hence may		the system is considered as not being "in use", and hence SHOULD be
	be omitted from <operational>.		omitted from <operational>.
	<operational> should conform to any constraints specified in the data		<operational> SHOULD conform to any constraints specified in the data
	model, but given the principal aim of returning "in use" values, it		model, but given the principal aim of returning "in use" values, it
	is possible that constraints may be violated under some		is possible that constraints MAY be violated under some
	circumstances, e.g., an abnormal value is "in use", or due to remnant		circumstances, e.g., an abnormal value is "in use", the structure of
	configuration (described below). Note, that deviations are still		a list is being modified, or due to remnant configuration (see
	used when it is known in advance that a device does not fully conform		Section 5.3.1). Note, that deviations SHOULD be used when it is
	to the <operational> schema.		known in advance that a device does not fully conform to the
			<operational> schema.
	Only semantic constraints may be violated, these are the YANG "when",		Only semantic constraints MAY be violated, these are the YANG "when",
	"must", "mandatory", "unique", "min-elements", and "max-elements"		"must", "mandatory", "unique", "min-elements", and "max-elements"
	statements.		statements; and the uniqueness of key values.
	Syntactic constraints cannot be violated, including hierarchical		Syntactic constraints MUST NOT be violated, including hierarchical
	organization, identifiers, and type-based constraints. If a node in		organization, identifiers, and type-based constraints. If a node in
	<operational> does not meet the syntactic constraints then it cannot		<operational> does not meet the syntactic constraints then it MUST
	be returned, and some other mechanism should be used to flag the		NOT be returned, and some other mechanism should be used to flag the
	error.		error.
	<operational> does not persist across reboots.		<operational> does not persist across reboots.
	4.7.1. Remnant Configuration		5.3.1. Remnant Configuration
	Changes to configuration may take time to percolate through to		Changes to configuration may take time to percolate through to
	<operational>. During this period, <operational> may contain nodes		<operational>. During this period, <operational> may contain nodes
	for both the previous and current configuration, as closely as		for both the previous and current configuration, as closely as
	possible tracking the current operation of the device. Such remnant		possible tracking the current operation of the device. Such remnant
	configuration from the previous configuration persists until the		configuration from the previous configuration persists until the
	system has released resources used by the newly-deleted configuration		system has released resources used by the newly-deleted configuration
	(e.g., network connections, memory allocations, file handles).		(e.g., network connections, memory allocations, file handles).
	Remant configuration is a common example of where the semantic		Remnant configuration is a common example of where the semantic
	constraints defined in the data model cannot be relied upon for		constraints defined in the data model cannot be relied upon for
	<operational>, since the system may have remnant configuration whose		<operational>, since the system may have remnant configuration whose
	constraints were valid with the previous configuration and that are		constraints were valid with the previous configuration and that are
	not valid with the current configuration. Since constraints on		not valid with the current configuration. Since constraints on
	"config false" nodes may refer to "config true" nodes, remnant		"config false" nodes may refer to "config true" nodes, remnant
	configuration may force the violation of those constraints.		configuration may force the violation of those constraints.
	4.7.2. Missing Resources		5.3.2. Missing Resources
	Configuration in <intended> can refer to resources that are not		Configuration in <intended> can refer to resources that are not
	available or otherwise not physically present. In these situations,		available or otherwise not physically present. In these situations,
	these parts of <intended> are not applied. The data appears in		these parts of <intended> are not applied. The data appears in
	<intended> but does not appear in <operational>.		<intended> but does not appear in <operational>.
	A typical example is an interface configuration that refers to an		A typical example is an interface configuration that refers to an
	interface that is not currently present. In such a situation, the		interface that is not currently present. In such a situation, the
	interface configuration remains in <intended> but the interface		interface configuration remains in <intended> but the interface
	configuration will not appear in <operational>.		configuration will not appear in <operational>.
	Note that configuration validity cannot depend on the current state		Note that configuration validity cannot depend on the current state
	of such resources, since that would imply the removing a resource		of such resources, since that would imply that removing a resource
	might render the configuration invalid. This is unacceptable,		might render the configuration invalid. This is unacceptable,
	especially given that rebooting such a device would fail to boot due		especially given that rebooting such a device would cause it to
	to an invalid configuration. Instead we allow configuration for		restart with an invalid configuration. Instead we allow
	missing resources to exist in <running> and <intended>, but it will		configuration for missing resources to exist in <running> and
	not appear in <operational>.		<intended>, but it will not appear in <operational>.
	4.7.3. System-controlled Resources		5.3.3. System-controlled Resources
	Sometimes resources are controlled by the device and the		Sometimes resources are controlled by the device and the
	corresponding system controlled data appear in (and disappear from)		corresponding system controlled data appears in (and disappears from)
	<operational> dynamically. If a system controlled resource has		<operational> dynamically. If a system controlled resource has
	matching configuration in <intended> when it appears, the system will		matching configuration in <intended> when it appears, the system will
	try to apply the configuration, which causes the configuration to		try to apply the configuration, which causes the configuration to
	appear in <operational> eventually (if application of the		appear in <operational> eventually (if application of the
	configuration was successful).		configuration was successful).
	4.7.4. Origin Metadata Annotation		5.3.4. Origin Metadata Annotation
	As configuration flows into <operational>, it is conceptually marked		As configuration flows into <operational>, it is conceptually marked
	with a metadata annotation ([RFC7952]) that indicates its origin.		with a metadata annotation ([RFC7952]) that indicates its origin.
	The origin applies to all configuration nodes except non-presence		The origin applies to all configuration nodes except non-presence
	containers. The "origin" metadata annotation is defined in		containers. The "origin" metadata annotation is defined in
	Section 6. The values are YANG identities. The following identities		Section 7. The values are YANG identities. The following identities
	are defined:		are defined:
	o origin: abstract base identity from which the other origin		o origin: abstract base identity from which the other origin
	identities are derived.		identities are derived.
	o intended: represents configuration provided by <intended>.		o intended: represents configuration provided by <intended>.
	o dynamic: represents configuration provided by a dynamic		o dynamic: represents configuration provided by a dynamic
	configuration datastore.		configuration datastore.
	skipping to change at page 14, line 39 ¶		skipping to change at page 16, line 9 ¶
	default origin is only used when the configuration has not been		default origin is only used when the configuration has not been
	provided by any other source.		provided by any other source.
	o unknown: represents configuration for which the system cannot		o unknown: represents configuration for which the system cannot
	identify the origin.		identify the origin.
	These identities can be further refined, e.g., there could be		These identities can be further refined, e.g., there could be
	separate identities for particular types or instances of dynamic		separate identities for particular types or instances of dynamic
	configuration datastores derived from "dynamic".		configuration datastores derived from "dynamic".
	For all configuration data nodes in <operational>, the device should		For all configuration data nodes in <operational>, the device SHOULD
	report the origin that most accurately reflects the source of the		report the origin that most accurately reflects the source of the
	configuration that is actively being used by the system.		configuration that is in use by the system.
	In cases where it could be ambiguous as to which origin should be		In cases where it could be ambiguous as to which origin should be
	used, i.e. where the same data node value has originated from		used, i.e. where the same data node value has originated from
	multiple sources, then the description statement in the YANG module		multiple sources, then the description statement in the YANG module
	should be used as guidance for choosing the appropriate origin. For		SHOULD be used as guidance for choosing the appropriate origin. For
	example:		example:
	If for a particular configuration node, the associated YANG		If for a particular configuration node, the associated YANG
	description statement indicates that a protocol negotiated value		description statement indicates that a protocol negotiated value
	overrides any configured value, then the origin would be reported as		overrides any configured value, then the origin would be reported as
	"learned", even when a learned value is the same as the configured		"learned", even when a learned value is the same as the configured
	value.		value.
	Conversely, if for a particular configuration node, the associated		Conversely, if for a particular configuration node, the associated
	YANG description statement indicates that a protocol negotiated value		YANG description statement indicates that a protocol negotiated value
	does not override an explicitly configured value, then the origin		does not override an explicitly configured value, then the origin
	would be reported as "intended" even when a learned value is the same		would be reported as "intended" even when a learned value is the same
	as the configured value.		as the configured value.
	In the case that a device cannot provide an accurate origin for a		In the case that a device cannot provide an accurate origin for a
	particular configuration data node then it should use the origin		particular configuration data node then it SHOULD use the origin
	"unknown".		"unknown".
	5. Implications on YANG		6. Implications on YANG
	5.1. XPath Context		6.1. XPath Context
			This section updates section 6.4.1 of RFC 7950.
	If a server implements the architecture defined in this document, the		If a server implements the architecture defined in this document, the
	accessible trees for some XPath contexts are refined as follows:		accessible trees for some XPath contexts are refined as follows:
	o If the XPath expression is defined in a substatement to a data		o If the XPath expression is defined in a substatement to a data
	node that represents system state, the accessible tree is all		node that represents system state, the accessible tree is all
	operational state in the server. The root node has all top-level		operational state in the server. The root node has all top-level
	data nodes in all modules as children.		data nodes in all modules as children.
	o If the XPath expression is defined in a substatement to a		o If the XPath expression is defined in a substatement to a
	skipping to change at page 16, line 8 ¶		skipping to change at page 17, line 27 ¶
	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. 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
	"IETF Network Modeling (NETMOD) Working Group";		"IETF Network Modeling (NETMOD) Working Group";
	skipping to change at page 17, line 24 ¶		skipping to change at page 18, line 43 ¶
	reference		reference
	"RFC XXXX: Network Management Datastore Architecture";		"RFC XXXX: Network Management Datastore Architecture";
	}		}
	/*		/*
	* Identities		* Identities
	*/		*/
	identity datastore {		identity datastore {
	description		description
	"Abstract base identity for datastore identities.";		"Abstract base identity for datastore identities.";
	}		}
	identity conventional {		identity conventional {
	base datastore;		base datastore;
	description		description
	"Abstract base identity for conventional configuration		"Abstract base identity for conventional configuration
	datastores.";		datastores.";
	}		}
	identity running {		identity running {
	base conventional;		base conventional;
	description		description
	"The running configuration datastore.";		"The running configuration datastore.";
	}		}
	identity candidate {		identity candidate {
	base conventional;		base conventional;
	description		description
	"The candidate configuration datastore.";		"The candidate configuration datastore.";
	}		}
	identity startup {		identity startup {
	base conventional;		base conventional;
	description		description
	"The startup configuration datastore.";		"The startup configuration datastore.";
	}		}
	identity intended {		identity intended {
	base conventional;		base conventional;
	description		description
	"The intended configuration datastore.";		"The intended configuration datastore.";
	}		}
	identity dynamic {		identity dynamic {
	base datastore;		base datastore;
	description		description
	"Abstract base identity for dynamic configuration datastores.";		"Abstract base identity for dynamic configuration datastores.";
	}		}
	identity operational {		identity operational {
	base datastore;		base datastore;
	description		description
	"The operational state datastore.";		"The operational state datastore.";
	}		}
	/*		/*
	* Type definitions		* Type definitions
	*/		*/
	typedef datastore-ref {		typedef datastore-ref {
	type identityref {		type identityref {
	base datastore;		base datastore;
	}		}
	skipping to change at page 21, line 45 ¶		skipping to change at page 23, line 15 ¶
	data node in the operational datastore. It specifies from		data node in the operational datastore. It specifies from
	where the node originated. If not specified for a given		where the node originated. If not specified for a given
	configuration data node then the origin is the same as the		configuration data node then the origin is the same as the
	origin of its parent node in the data tree. The origin for		origin of its parent node in the data tree. The origin for
	any top level configuration data nodes must be specified.";		any top level configuration data nodes must be specified.";
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	7. IANA Considerations		8. IANA Considerations
	7.1. Updates to the IETF XML Registry		8.1. Updates to the IETF XML Registry
	This document registers two URIs in the IETF XML registry [RFC3688].		This document registers two URIs in the IETF XML registry [RFC3688].
	Following the format in [RFC3688], the following registrations are		Following the format in [RFC3688], the following registrations are
	requested:		requested:
	URI: urn:ietf:params:xml:ns:yang:ietf-datastores		URI: urn:ietf:params:xml:ns:yang:ietf-datastores
	Registrant Contact: The IESG.		Registrant Contact: The IESG.
	XML: N/A, the requested URI is an XML namespace.		XML: N/A, the requested URI is an XML namespace.
	URI: urn:ietf:params:xml:ns:yang:ietf-origin		URI: urn:ietf:params:xml:ns:yang:ietf-origin
	Registrant Contact: The IESG.		Registrant Contact: The IESG.
	XML: N/A, the requested URI is an XML namespace.		XML: N/A, the requested URI is an XML namespace.
	7.2. Updates to the YANG Module Names Registry		8.2. Updates to the YANG Module Names Registry
	This document registers two YANG modules in the YANG Module Names		This document registers two YANG modules in the YANG Module Names
	registry [RFC6020]. Following the format in [RFC6020], the the		registry [RFC6020]. Following the format in [RFC6020], the the
	following registrations are requested:		following registrations are requested:
	name: ietf-datastores		name: ietf-datastores
	namespace: urn:ietf:params:xml:ns:yang:ietf-datastores		namespace: urn:ietf:params:xml:ns:yang:ietf-datastores
	prefix: ds		prefix: ds
	reference: RFC XXXX		reference: RFC XXXX
	name: ietf-origin		name: ietf-origin
	namespace: urn:ietf:params:xml:ns:yang:ietf-origin		namespace: urn:ietf:params:xml:ns:yang:ietf-origin
	prefix: or		prefix: or
	reference: RFC XXXX		reference: RFC XXXX
	8. Security Considerations		9. Security Considerations
	This document discusses an architectural model of datastores for		This document discusses an architectural model of datastores for
	network management using NETCONF/RESTCONF and YANG. It has no		network management using NETCONF/RESTCONF and YANG. It has no
	security impact on the Internet.		security impact on the Internet.
	Although this document specifies several YANG modules, these modules		Although this document specifies several YANG modules, these modules
	only define identities and meta-data, hence the "YANG module security		only define identities and meta-data, hence the "YANG module security
	guidelines" do not apply.		guidelines" do not apply.
	9. Acknowledgments		10. Acknowledgments
	This document grew out of many discussions that took place since		This document grew out of many discussions that took place since
	2010. Several Internet-Drafts ([I-D.bjorklund-netmod-operational],		2010. Several Internet-Drafts ([I-D.bjorklund-netmod-operational],
	[I-D.wilton-netmod-opstate-yang], [I-D.ietf-netmod-opstate-reqs],		[I-D.wilton-netmod-opstate-yang], [I-D.ietf-netmod-opstate-reqs],
	[I-D.kwatsen-netmod-opstate], [I-D.openconfig-netmod-opstate]) and		[I-D.kwatsen-netmod-opstate], [I-D.openconfig-netmod-opstate]) and
	[RFC6244] touched on some of the problems of the original datastore		[RFC6244] touched on some of the problems of the original datastore
	model. The following people were authors to these Internet-Drafts or		model. The following people were authors to these Internet-Drafts or
	otherwise actively involved in the discussions that led to this		otherwise actively involved in the discussions that led to this
	document:		document:
	skipping to change at page 23, line 4 ¶		skipping to change at page 24, line 23 ¶
	[I-D.wilton-netmod-opstate-yang], [I-D.ietf-netmod-opstate-reqs],		[I-D.wilton-netmod-opstate-yang], [I-D.ietf-netmod-opstate-reqs],
	[I-D.kwatsen-netmod-opstate], [I-D.openconfig-netmod-opstate]) and		[I-D.kwatsen-netmod-opstate], [I-D.openconfig-netmod-opstate]) and
	[RFC6244] touched on some of the problems of the original datastore		[RFC6244] touched on some of the problems of the original datastore
	model. The following people were authors to these Internet-Drafts or		model. The following people were authors to these Internet-Drafts or
	otherwise actively involved in the discussions that led to this		otherwise actively involved in the discussions that led to this
	document:		document:
	o Lou Berger, LabN Consulting, L.L.C., <lberger@labn.net>		o Lou Berger, LabN Consulting, L.L.C., <lberger@labn.net>
	o Andy Bierman, YumaWorks, <andy@yumaworks.com>		o Andy Bierman, YumaWorks, <andy@yumaworks.com>
	o Marcus Hines, Google, <hines@google.com>		o Marcus Hines, Google, <hines@google.com>
	o Christian Hopps, Deutsche Telekom, <chopps@chopps.org>		o Christian Hopps, Deutsche Telekom, <chopps@chopps.org>
			o Balazs Lengyel, Ericsson, <balazs.lengyel@ericsson.com>
	o Acee Lindem, Cisco Systems, <acee@cisco.com>		o Acee Lindem, Cisco Systems, <acee@cisco.com>
	o Ladislav Lhotka, CZ.NIC, <lhotka@nic.cz>		o Ladislav Lhotka, CZ.NIC, <lhotka@nic.cz>
	o Thomas Nadeau, Brocade Networks, <tnadeau@lucidvision.com>		o Thomas Nadeau, Brocade Networks, <tnadeau@lucidvision.com>
			o Tom Petch, Engineering Networks Ltd, <ietfc@btconnect.com>
	o Anees Shaikh, Google, <aashaikh@google.com>		o Anees Shaikh, Google, <aashaikh@google.com>
	o Rob Shakir, Google, <robjs@google.com>		o Rob Shakir, Google, <robjs@google.com>
			o Jason Sterne, Nokia, <jason.sterne@nokia.co>
	Juergen Schoenwaelder was partly funded by Flamingo, a Network of		Juergen Schoenwaelder was partly funded by Flamingo, a Network of
	Excellence project (ICT-318488) supported by the European Commission		Excellence project (ICT-318488) supported by the European Commission
	under its Seventh Framework Programme.		under its Seventh Framework Programme.
	10. References		11. References
			11.1. Normative References
	10.1. Normative References		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
			editor.org/info/rfc2119>.
	[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,		[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
	and A. Bierman, Ed., "Network Configuration Protocol		and A. Bierman, Ed., "Network Configuration Protocol
	(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,		(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
	<http://www.rfc-editor.org/info/rfc6241>.		<https://www.rfc-editor.org/info/rfc6241>.
	[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,
	<http://www.rfc-editor.org/info/rfc7950>.		<https://www.rfc-editor.org/info/rfc7950>.
	[RFC7952] Lhotka, L., "Defining and Using Metadata with YANG",		[RFC7952] Lhotka, L., "Defining and Using Metadata with YANG",
	RFC 7952, DOI 10.17487/RFC7952, August 2016,		RFC 7952, DOI 10.17487/RFC7952, August 2016,
	<http://www.rfc-editor.org/info/rfc7952>.		<https://www.rfc-editor.org/info/rfc7952>.
	[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF		[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
	Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,		Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
	<http://www.rfc-editor.org/info/rfc8040>.		<https://www.rfc-editor.org/info/rfc8040>.
	10.2. Informative References		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
			11.2. Informative References
	[I-D.bjorklund-netmod-operational]		[I-D.bjorklund-netmod-operational]
	Bjorklund, M. and L. Lhotka, "Operational Data in NETCONF		Bjorklund, M. and L. Lhotka, "Operational Data in NETCONF
	and YANG", draft-bjorklund-netmod-operational-00 (work in		and YANG", draft-bjorklund-netmod-operational-00 (work in
	progress), October 2012.		progress), October 2012.
	[I-D.ietf-netmod-opstate-reqs]		[I-D.ietf-netmod-opstate-reqs]
	Watsen, K. and T. Nadeau, "Terminology and Requirements		Watsen, K. and T. Nadeau, "Terminology and Requirements
	for Enhanced Handling of Operational State", draft-ietf-		for Enhanced Handling of Operational State", draft-ietf-
	netmod-opstate-reqs-04 (work in progress), January 2016.		netmod-opstate-reqs-04 (work in progress), January 2016.
	skipping to change at page 24, line 27 ¶		skipping to change at page 26, line 16 ¶
	Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling		Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling
	of Operational State Data in YANG", draft-openconfig-		of Operational State Data in YANG", draft-openconfig-
	netmod-opstate-01 (work in progress), July 2015.		netmod-opstate-01 (work in progress), July 2015.
	[I-D.wilton-netmod-opstate-yang]		[I-D.wilton-netmod-opstate-yang]
	Wilton, R., ""With-config-state" Capability for NETCONF/		Wilton, R., ""With-config-state" Capability for NETCONF/
	RESTCONF", draft-wilton-netmod-opstate-yang-02 (work in		RESTCONF", draft-wilton-netmod-opstate-yang-02 (work in
	progress), December 2015.		progress), December 2015.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	DOI 10.17487/RFC3688, January 2004,		DOI 10.17487/RFC3688, January 2004, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc3688>.		editor.org/info/rfc3688>.
	[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for		[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
	the Network Configuration Protocol (NETCONF)", RFC 6020,		the Network Configuration Protocol (NETCONF)", RFC 6020,
	DOI 10.17487/RFC6020, October 2010,		DOI 10.17487/RFC6020, October 2010, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc6020>.		editor.org/info/rfc6020>.
	[RFC6244] Shafer, P., "An Architecture for Network Management Using		[RFC6244] Shafer, P., "An Architecture for Network Management Using
	NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244, June		NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244, June
	2011, <http://www.rfc-editor.org/info/rfc6244>.		2011, <https://www.rfc-editor.org/info/rfc6244>.
			[RFC7223] Bjorklund, M., "A YANG Data Model for Interface
			Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
			<https://www.rfc-editor.org/info/rfc7223>.
			[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management",
			RFC 7277, DOI 10.17487/RFC7277, June 2014,
			<https://www.rfc-editor.org/info/rfc7277>.
	Appendix A. Guidelines for Defining Datastores		Appendix A. Guidelines for Defining Datastores
	The definition of a new datastore in this architecture should be		The definition of a new datastore in this architecture should be
	provided in a document (e.g., an RFC) purposed to the definition of		provided in a document (e.g., an RFC) purposed to the definition of
	the datastore. When it makes sense, more than one datastore may be		the datastore. When it makes sense, more than one datastore may be
	defined in the same document (e.g., when the datastores are logically		defined in the same document (e.g., when the datastores are logically
	connected). Each datastore's definition should address the points		connected). Each datastore's definition should address the points
	specified in the sections below.		specified in the sections below.
	skipping to change at page 25, line 12 ¶		skipping to change at page 27, line 10 ¶
	may constrain which data models can be used in them. If it is		may constrain which data models can be used in them. If it is
	desirable that a subset of all modules can be targeted to the		desirable that a subset of all modules can be targeted to the
	datastore, then the documentation defining the datastore must		datastore, then the documentation defining the datastore must
	indicate this.		indicate this.
	A.2. Define which subset of YANG-modeled data applies		A.2. Define which subset of YANG-modeled data applies
	By default, the data in a datastore is modeled by all YANG statements		By default, the data in a datastore is modeled by all YANG statements
	in the available YANG modules. However, it is possible to specify		in the available YANG modules. However, it is possible to specify
	criteria that YANG statements must satisfy in order to be present in		criteria that YANG statements must satisfy in order to be present in
	a datastore. For instance, maybe only "config true" nodes are		a datastore. For instance, maybe only "config true" nodes, or
	present, or "config false" nodes that also have a specific YANG		"config false" nodes that also have a specific YANG extension, are
	extension are present in the datastore.		present in the datastore.
	A.3. Define how data is actualized		A.3. Define how data is actualized
	The new datastore must specify how it interacts with other		The new datastore must specify how it interacts with other
	datastores.		datastores.
	For example, the diagram in Section 4 depicts dynamic configuration		For example, the diagram in Section 5 depicts dynamic configuration
	datastores feeding into <operational>. How this interaction occurs		datastores feeding into <operational>. How this interaction occurs
	must be defined by the particular dynamic configuration datastores.		has to be defined by the particular dynamic configuration datastores.
	In some cases, it may occur implicitly, as soon as the data is put		In some cases, it may occur implicitly, as soon as the data is put
	into the dynamic configuration datastore while, in other cases, an		into the dynamic configuration datastore while, in other cases, an
	explicit action (e.g., an RPC) may be required to trigger the		explicit action (e.g., an RPC) may be required to trigger the
	application of the datastore's data.		application of the datastore's data.
	A.4. Define which protocols can be used		A.4. Define which protocols can be used
	By default, it is assumed that both the NETCONF and RESTCONF		By default, it is assumed that both the NETCONF and RESTCONF
	protocols can be used to interact with a datastore. However, it may		protocols can be used to interact with a datastore. However, it may
	be that only a specific protocol can be used (e.g., ForCES) or that a		be that only a specific protocol can be used (e.g., ForCES) or that a
	subset of all protocol operations or capabilities are available		subset of all protocol operations or capabilities are available
	(e.g., no locking or no XPath-based filtering).		(e.g., no locking or no XPath-based filtering).
	A.5. Define YANG identities for the datastore		A.5. Define YANG identities for the datastore
	The datastore must be defined with a YANG identity that uses the		The datastore must be defined with a YANG identity that uses the
	"ds:datastore" identity or one of its derived identities as its base.		"ds:datastore" identity, or one of its derived identities, as its
	This identity is necessary so that the datastore can be referenced in		base. This identity is necessary so that the datastore can be
	protocol operations (e.g., <get-data>).		referenced in protocol operations (e.g., <get-data>).
	The datastore may also be defined with an identity that uses the		The datastore may also be defined with an identity that uses the
	"or:origin" identity or one its derived identities as its base. This		"or:origin" identity or one its derived identities as its base. This
	identity is needed if the datastore interacts with <operational> so		identity is needed if the datastore interacts with <operational> so
	that data originating from the datastore can be identified as such		that data originating from the datastore can be identified as such
	via the "origin" metadata attribute defined in Section 6.		via the "origin" metadata attribute defined in Section 7.
	An example of these guidelines in use is provided in Appendix B.		An example of these guidelines in use is provided in Appendix B.
	Appendix B. Ephemeral Dynamic Configuration Datastore Example		Appendix B. Ephemeral Dynamic Configuration Datastore Example
	The section defines documentation for an example dynamic		The section defines documentation for an example dynamic
	configuration datastore using the guidelines provided in Appendix A.		configuration datastore using the guidelines provided in Appendix A.
	While this example is very terse, it is expected to be that a		While this example is very terse, it is expected to be that a
	standalone RFC would be needed when fully expanded.		standalone RFC would be needed when fully expanded.
	This example defines a dynamic configuration datastore called		This example defines a dynamic configuration datastore called
	"ephemeral", which is loosely modeled after the work done in the I2RS		"ephemeral", which is loosely modeled after the work done in the I2RS
	working group.		working group.
	1. Name : ephemeral		+--------------+---------------------------------------------------+
	2. YANG modules : all (default)		| Name | Value |
	3. YANG data nodes : all "config true" data nodes		+--------------+---------------------------------------------------+
	4. How applied : automatic		| Name | ephemeral |
	5. Protocols : NC/RC (default)		| YANG modules | all (default) |
	6. YANG Module : (see below)		| YANG nodes | all "config true" data nodes |
			| How applied | changes automatically propagated to <operational> |
			| Protocols | NC/RC (default) |
			| YANG Module | (see below) |
			+--------------+---------------------------------------------------+
			The example "ephemeral" datastore properties
	module example-ds-ephemeral {		module example-ds-ephemeral {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:example:ds-ephemeral";		namespace "urn:example:ds-ephemeral";
	prefix eph;		prefix eph;
	import ietf-datastores {		import ietf-datastores {
	prefix ds;		prefix ds;
	}		}
	import ietf-origin {		import ietf-origin {
	skipping to change at page 28, line 22 ¶		skipping to change at page 31, line 4 ¶
	leaf ip {		leaf ip {
	type inet:ip-address;		type inet:ip-address;
	}		}
	leaf prefix-length {		leaf prefix-length {
	type uint8;		type uint8;
	}		}
	}		}
	}		}
	}		}
	}		}
	The operator has configured the host name and two interfaces, so the		The operator has configured the host name and two interfaces, so the
	contents of <intended> is:		contents of <intended> are:
	<system xmlns="urn:example:system">		<system xmlns="urn:example:system">
	<hostname>foo</hostname>		<hostname>foo</hostname>
	<interface>		<interface>
	<name>eth0</name>		<name>eth0</name>
	<auto-negotiation>		<auto-negotiation>
	<speed>1000</speed>		<speed>1000</speed>
	</auto-negotiation>		</auto-negotiation>
	<address>		<address>
	<ip>2001:db8::10</ip>		<ip>2001:db8::10</ip>
	<prefix-length>32</prefix-length>		<prefix-length>64</prefix-length>
	</address>		</address>
	</interface>		</interface>
	<interface>		<interface>
	<name>eth1</name>		<name>eth1</name>
	<address>		<address>
	<ip>2001:db8::20</ip>		<ip>2001:db8::20</ip>
	<prefix-length>32</prefix-length>		<prefix-length>64</prefix-length>
	</address>		</address>
	</interface>		</interface>
	</system>		</system>
	The system has detected that the hardware for one of the configured		The system has detected that the hardware for one of the configured
	interfaces ("eth1") is not yet present, so the configuration for that		interfaces ("eth1") is not yet present, so the configuration for that
	interface is not applied. Further, the system has received a host		interface is not applied. Further, the system has received a host
	name and an additional IP address for "eth0" over DHCP. In addition		name and an additional IP address for "eth0" over DHCP. In addition
	to a default value, a loopback interface is automatically added by		to a default value, a loopback interface is automatically added by
	the system, and the result of the "speed" auto-negotiation. All of		the system, and the result of the "speed" auto-negotiation. All of
	this is reflected in <operational>. Note how the origin metadata		this is reflected in <operational>. Note how the origin metadata
	attribute for several "config true" data nodes is inherited from		attribute for several "config true" data nodes is inherited from
	their parent data nodes.		their parent data nodes.
	skipping to change at page 31, line 13 ¶		skipping to change at page 34, line 13 ¶
	There is no separate "bgp-state" hierarchy, with the accompanying		There is no separate "bgp-state" hierarchy, with the accompanying
	repetition of containment and naming nodes. This makes the model		repetition of containment and naming nodes. This makes the model
	simpler and more readable.		simpler and more readable.
	C.2.1. Datastores		C.2.1. Datastores
	Each datastore represents differing views of these nodes. <running>		Each datastore represents differing views of these nodes. <running>
	will hold the configuration provided by the operator, for example a		will hold the configuration provided by the operator, for example a
	single BGP peer. <intended> will conceptually hold the data as		single BGP peer. <intended> will conceptually hold the data as
	validated, after the removal of data not intended for validation and		validated, after the removal of data not intended for validation and
	after any local template mechanisms are performed. <operational> will		after any local template mechanisms are performed. <operational>
	show data from <intended> as well as any "config false" nodes.		will show data from <intended> as well as any "config false" nodes.
	C.2.2. Adding a Peer		C.2.2. Adding a Peer
	If the user configures a single BGP peer, then that peer will be		If the user configures a single BGP peer, then that peer will be
	visible in both <running> and <intended>. It may also appear in		visible in both <running> and <intended>. It may also appear in
	<candidate>, if the server supports the candidate configuration		<candidate>, if the server supports the candidate configuration
	datastore. Retrieving the peer will return only the user-specified		datastore. Retrieving the peer will return only the user-specified
	values.		values.
	No time delay should exist between the appearance of the peer in		No time delay should exist between the appearance of the peer in
End of changes. 99 change blocks.
	225 lines changed or deleted		317 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/