draft-ietf-netmod-revised-datastores-10.txt		rfc8342.txt
	Network Working Group M. Bjorklund		Internet Engineering Task Force (IETF) M. Bjorklund
	Internet-Draft Tail-f Systems		Request for Comments: 8342 Tail-f Systems
	Updates: 7950 (if approved) J. Schoenwaelder		Updates: 7950 J. Schoenwaelder
	Intended status: Standards Track Jacobs University		Category: Standards Track Jacobs University
	Expires: July 17, 2018 P. Shafer		ISSN: 2070-1721 P. Shafer
	K. Watsen		K. Watsen
	Juniper Networks		Juniper Networks
	R. Wilton		R. Wilton
	Cisco Systems		Cisco Systems
	January 13, 2018		March 2018
	Network Management Datastore Architecture		Network Management Datastore Architecture (NMDA)
	draft-ietf-netmod-revised-datastores-10
	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 the Network Configuration Protocol (NETCONF) and RESTCONF.
	framework for datastores based on the experience gained with the		This document defines an architectural framework for datastores based
	initial simpler model, addressing requirements that were not well		on the experience gained with the initial simpler model, addressing
	supported in the initial model. This document updates RFC 7950.		requirements that were not well supported in the initial model. This
			document updates RFC 7950.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	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		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on July 17, 2018.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc8342.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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		(https://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. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Objectives ......................................................4
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Terminology .....................................................5
	4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 7		4. Background ......................................................8
	4.1. Original Model of Datastores . . . . . . . . . . . . . . 8		4.1. Original Model of Datastores ...............................9
	5. Architectural Model of Datastores . . . . . . . . . . . . . . 9		5. Architectural Model of Datastores ..............................11
	5.1. Conventional Configuration Datastores . . . . . . . . . . 10		5.1. Conventional Configuration Datastores .....................12
	5.1.1. The Startup Configuration Datastore (<startup>) . . . 11		5.1.1. The Startup Configuration Datastore (<startup>) ....12
	5.1.2. The Candidate Configuration Datastore (<candidate>) . 11		5.1.2. The Candidate Configuration Datastore
	5.1.3. The Running Configuration Datastore (<running>) . . . 12		(<candidate>) ......................................13
	5.1.4. The Intended Configuration Datastore (<intended>) . . 12		5.1.3. The Running Configuration Datastore (<running>) ....13
	5.2. Dynamic Configuration Datastores . . . . . . . . . . . . 13		5.1.4. The Intended Configuration Datastore (<intended>) ..13
	5.3. The Operational State Datastore (<operational>) . . . . . 13		5.2. Dynamic Configuration Datastores ..........................14
	5.3.1. Remnant Configuration . . . . . . . . . . . . . . . . 14		5.3. The Operational State Datastore (<operational>) ...........14
	5.3.2. Missing Resources . . . . . . . . . . . . . . . . . . 15		5.3.1. Remnant Configuration ..............................16
	5.3.3. System-controlled Resources . . . . . . . . . . . . . 15		5.3.2. Missing Resources ..................................16
	5.3.4. Origin Metadata Annotation . . . . . . . . . . . . . 15		5.3.3. System-Controlled Resources ........................16
	6. Implications on YANG . . . . . . . . . . . . . . . . . . . . 17		5.3.4. Origin Metadata Annotation .........................17
	6.1. XPath Context . . . . . . . . . . . . . . . . . . . . . . 17		6. Implications on YANG ...........................................18
	6.2. Invocation of Actions and RPCs . . . . . . . . . . . . . 18		6.1. XPath Context .............................................18
	7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 18		6.2. Invocation of Actions and RPCs ............................19
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		7. YANG Modules ...................................................20
	8.1. Updates to the IETF XML Registry . . . . . . . . . . . . 24		8. IANA Considerations ............................................26
	8.2. Updates to the YANG Module Names Registry . . . . . . . . 24		8.1. Updates to the IETF XML Registry ..........................26
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 24		8.2. Updates to the YANG Module Names Registry .................27
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25		9. Security Considerations ........................................27
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25		10. References ....................................................28
	11.1. Normative References . . . . . . . . . . . . . . . . . . 26		10.1. Normative References .....................................28
	11.2. Informative References . . . . . . . . . . . . . . . . . 26		10.2. Informative References ...................................29
	Appendix A. Guidelines for Defining Datastores . . . . . . . . . 27
	A.1. Define which YANG modules can be used in the datastore . 27		Appendix A. Guidelines for Defining Datastores ....................31
	A.2. Define which subset of YANG-modeled data applies . . . . 28		A.1. Define Which YANG Modules Can Be Used in the Datastore .....31
	A.3. Define how data is actualized . . . . . . . . . . . . . . 28		A.2. Define Which Subset of YANG-Modeled Data Applies ...........31
	A.4. Define which protocols can be used . . . . . . . . . . . 28		A.3. Define How Data Is Actualized ..............................31
	A.5. Define YANG identities for the datastore . . . . . . . . 28		A.4. Define Which Protocols Can Be Used .........................31
	Appendix B. Ephemeral Dynamic Configuration Datastore Example . 29		A.5. Define YANG Identities for the Datastore ...................32
	Appendix C. Example Data . . . . . . . . . . . . . . . . . . . . 30		Appendix B. Example of an Ephemeral Dynamic Configuration
	C.1. System Example . . . . . . . . . . . . . . . . . . . . . 30		Datastore .............................................32
	C.2. BGP Example . . . . . . . . . . . . . . . . . . . . . . . 33		Appendix C. Example Data ..........................................33
	C.2.1. Datastores . . . . . . . . . . . . . . . . . . . . . 35		C.1. System Example .............................................34
	C.2.2. Adding a Peer . . . . . . . . . . . . . . . . . . . . 35		C.2. BGP Example ................................................37
	C.2.3. Removing a Peer . . . . . . . . . . . . . . . . . . . 36		C.2.1. Datastores .............................................38
	C.3. Interface Example . . . . . . . . . . . . . . . . . . . . 37		C.2.2. Adding a Peer ..........................................38
	C.3.1. Pre-provisioned Interfaces . . . . . . . . . . . . . 37		C.2.3. Removing a Peer ........................................39
	C.3.2. System-provided Interface . . . . . . . . . . . . . . 38		C.3. Interface Example ..........................................40
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39		C.3.1. Pre-provisioned Interfaces .............................41
			C.3.2. System-Provided Interface ..............................42
			Acknowledgments ...................................................43
			Authors' Addresses ................................................44
	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 the Network
	[RFC6241], RESTCONF [RFC8040] and the YANG [RFC7950] data modeling		Configuration Protocol (NETCONF) [RFC6241], RESTCONF [RFC8040], and
	language. Datastores are a fundamental concept binding network		the YANG data modeling language [RFC7950]. Datastores are a
	management data models to network management protocols. Agreement on		fundamental concept binding network management data models to network
	a common architectural model of datastores ensures that data models		management protocols. Agreement on a common architectural model of
	can be written in a network management protocol agnostic way. This		datastores ensures that data models can be written in a way that is
	architectural framework identifies a set of conceptual datastores but		network management protocol agnostic. This architectural framework
	it does not mandate that all network management protocols expose all		identifies a set of conceptual datastores, but it does not mandate
	these conceptual datastores. This architecture is agnostic with		that all network management protocols expose all these conceptual
	regard to the encoding used by network management protocols.		datastores. This architecture is agnostic with regard to the
			encoding used by network management protocols.
	This document updates RFC 7950 by refining the definition of the		This document updates RFC 7950 by refining the definition of the
	accessible tree for some XPath context (see Section 6.1) and the		accessible tree for some XML Path Language (XPath) context (see
	invocation context of operations (see Section 6.2).		Section 6.1) and the invocation context of operations (see
			Section 6.2).
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2. Objectives		2. Objectives
	Network management data objects can often take two different values,		Network management data objects can often take two different values:
	the value configured by the user or an application (configuration)		the value configured by the user or an application (configuration)
	and the value that the device is actually using (operational state).		and the value that the device is actually using (operational state).
	These two values may be different for a number of reasons, e.g.,		These two values may be different for a number of reasons, e.g.,
	system internal interactions with hardware, interaction with		system internal interactions with hardware, interaction with
	protocols or other devices, or simply the time it takes to propagate		protocols or other devices, or simply the time it takes to propagate
	a configuration change to the software and hardware components of a		a configuration change to the software and hardware components of a
	system. Furthermore, configuration and operational state data		system. Furthermore, configuration and operational state data
	objects may have different lifetimes.		objects may have different lifetimes.
	The original model of datastores required these data objects to be		The original model of datastores required these data objects to be
	modeled twice in the YANG schema, as "config true" objects and as		modeled twice in the YANG schema -- as "config true" objects and as
	"config false" objects. The convention adopted by the interfaces		"config false" objects. The convention adopted by the interfaces
	data model ([RFC7223]) and the IP data model ([RFC7277]) was using		data model [RFC8343] and the IP data model [RFC8344] was to use two
	two separate branches rooted at the root of the data tree, one branch		separate branches rooted at the root of the data tree: one branch for
	for configuration data objects and one branch for operational state		configuration data objects and one branch for operational state data
	data objects.		objects.
	The duplication of definitions and the ad-hoc separation of		The duplication of definitions and the ad hoc separation of
	operational state data from configuration data leads to a number of		operational state data from configuration data lead to a number of
	problems. Having configuration and operational state data in		problems. Having configuration and operational state data in
	separate branches in the data model is operationally complicated and		separate branches in the data model is operationally complicated and
	impacts the readability of module definitions. Furthermore, the		impacts the readability of module definitions. Furthermore, the
	relationship between the branches is not machine readable and filter		relationship between the branches is not machine readable, and filter
	expressions operating on configuration and on related operational		expressions operating on configuration and on related operational
	state are different.		state are different.
	With the revised architectural model of datastores defined in this		With the revised architectural model of datastores defined in this
	document, the data objects are defined only once in the YANG schema		document, the data objects are defined only once in the YANG schema
	but independent instantiations can appear in different datastores,		but independent instantiations can appear in different datastores,
	e.g., one for a configured value and another for an operationally		e.g., one for a configured value and another for an operationally
	used value. This provides a more elegant and simpler solution to the		used value. This provides a more elegant and simpler solution to the
	problem.		problem.
	The revised architectural model of datastores supports additional		The revised architectural model of datastores supports additional
	datastores for systems that support more advanced processing chains		datastores for systems that support more advanced processing chains
	converting configuration to operational state. For example, some		converting configuration to operational state. For example, some
	systems support configuration that is not currently used (so called		systems support configuration that is not currently used (so-called
	inactive configuration) or they support configuration templates that		"inactive configuration") or they support configuration templates
	are used to expand configuration data via a common template.		that are used to expand configuration data via a common template.
	3. Terminology		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 4). The revised definitions are		[RFC7950] (see also Section 4). The revised definitions are
	semantically equivalent with the definitions found in [RFC6241] and		semantically equivalent to 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 schema node: A node in the schema tree. The formal definition is		o schema node: A node in the schema tree. The formal definition is
	in RFC 7950.		provided in RFC 7950.
	o datastore schema: The combined set of schema nodes for all modules		o datastore schema: The combined set of schema nodes for all modules
	supported by a particular datastore, taking into consideration any		supported by a particular datastore, taking into consideration any
	deviations and enabled features for that datastore.		deviations and enabled features for that datastore.
	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.
	skipping to change at page 5, line 41 ¶		skipping to change at page 6, line 14 ¶
	o intended configuration: Configuration that is intended to be used		o intended configuration: Configuration that is intended to be used
	by the device. It represents the configuration after all		by the device. It represents the configuration after all
	configuration transformations to <running> have been performed and		configuration transformations to <running> have been performed and
	is the configuration that the system attempts to apply.		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 referred to as "<intended>".		datastore is referred to as "<intended>".
	o configuration transformation: The addition, modification or		o configuration transformation: The addition, modification, or
	removal of configuration between the <running> and <intended>		removal of configuration between the <running> and <intended>
	datastores. Examples of configuration transformations include the		datastores. Examples of configuration transformations include the
	removal of inactive configuration and the configuration produced		removal of inactive configuration and the configuration produced
	through the expansion of templates.		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 datastore schema, and		<intended>. These datastores share a common datastore schema, and
	protocol operations allow copying data between these datastores.		protocol operations allow copying data between these datastores.
	The term "conventional" is chosen as a generic umbrella term for		The term "conventional" is chosen as a generic umbrella term for
	skipping to change at page 6, line 28 ¶		skipping to change at page 6, line 50 ¶
	conventional nor dynamic configuration.		conventional nor dynamic configuration.
	o system configuration: Configuration that is supplied by the device		o system configuration: Configuration that is supplied by the device
	itself.		itself.
	o default configuration: Configuration that is not explicitly		o default configuration: Configuration that is not explicitly
	provided but for which a value defined in the data model is used.		provided but for which a value defined in the data model is used.
	o applied configuration: Configuration that is actively in use by a		o applied configuration: Configuration that is actively in use by a
	device. Applied configuration originates from conventional,		device. Applied configuration originates from conventional,
	dynamic, learned, system and default configuration.		dynamic, learned, system, and default configuration.
	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 referred to as		operational state of the device. This datastore is 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
	item.		data 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
	deallocated.		deallocated.
	The following additional terms are not datastore specific but		The following additional terms are not datastore specific, but they
	commonly used and thus defined here as well:		are commonly used and are thus defined here as well:
	o client: An entity that can access YANG-defined data on a server,		o client: An entity that can access YANG-defined data on a server,
	over some network management protocol.		over some network management protocol.
	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.
	skipping to change at page 7, line 33 ¶		skipping to change at page 8, line 18 ¶
	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.
	YANG 1.1 [RFC7950] provides the following refinements when NETCONF is		YANG 1.1 [RFC7950] provides the following refinements when NETCONF is
	used with YANG (which is the usual case but note that NETCONF was		used with YANG (which is the usual case, but note that NETCONF was
	defined before YANG existed):		defined before YANG existed):
	o datastore: When modeled with YANG, a datastore is realized as an		o datastore: When modeled with YANG, a datastore is realized as an
	instantiated data tree.		instantiated data tree.
	o configuration datastore: When modeled with YANG, a configuration		o configuration datastore: When modeled with YANG, a configuration
	datastore is realized as an instantiated data tree with		datastore is realized as an instantiated data tree with
	configuration.		configuration.
	[RFC6244] defined operational state data as follows:		[RFC6244] defined operational state data as follows:
	o Operational state data is a set of data that has been obtained by		o Operational state data is a set of data that has been obtained by
	the system at runtime and influences the system's behavior similar		the system at runtime and influences the system's behavior similar
	to configuration data. In contrast to configuration data,		to configuration data. In contrast to configuration data,
	operational state is transient and modified by interactions with		operational state is transient and modified by interactions with
	internal components or other systems via specialized protocols.		internal components or other systems via specialized protocols.
	Section 4.3.3 of [RFC6244] discusses operational state and among		Section 4.3.3 of [RFC6244] discusses operational state and mentions,
	other things mentions the option to consider operational state as		among other things, the option to consider operational state as being
	being stored in another datastore. Section 4.4 of [RFC6244] then		stored in another datastore. Section 4.4 of [RFC6244] then concludes
	concludes that at the time of the writing, modeling state as distinct		that, at the time of its writing, modeling state as distinct leafs
	leafs and distinct branches is the recommended approach.		and distinct branches is the recommended approach.
	Implementation experience and requests from operators		Implementation experience and requests from operators [OpState-Reqs]
	[I-D.ietf-netmod-opstate-reqs], [I-D.openconfig-netmod-opstate]		[OpState-Modeling] indicate that the datastore model initially
	indicate that the datastore model initially designed for NETCONF and		designed for NETCONF and refined by YANG needs to be extended. In
	refined by YANG needs to be extended. In particular, the notion of		particular, the notion of intended configuration and applied
	intended configuration and applied configuration has developed.		configuration has developed.
	4.1. Original Model of Datastores		4.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) |
	+-------------+ | | +-----------+		+-------------+ | | +-----------+
	| | | |		| | | |
	| +-----------+ |		| +-----------+ |
	+-------->| <running> |<--------+		+-------->| <running> |<--------+
	| (ct, rw) |		| (ct, rw) |
	+-----------+		+-----------+
	|		|
	v		v
	operational state <--- control plane		operational state <--- control plane
	(cf, ro)		(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 datastores		boxes denote datastores
	Figure 1		Figure 1
	Note that this diagram simplifies the model: read-only (ro) and read-		Note that this diagram simplifies the model: "read-only" (ro) and
	write (rw) is to be understood at a conceptual level. In NETCONF,		"read-write" (rw) are to be understood from the client's perspective,
	for example, support for <candidate> and <startup> is optional and		at a conceptual level. In NETCONF, for example, support for
	<running> does not have to be writable. Furthermore, <startup> can		<candidate> and <startup> is optional, and <running> does not have to
	only be modified by copying <running> to <startup> in the		be writable. Furthermore, <startup> can only be modified by copying
	standardized NETCONF datastore editing model. The RESTCONF protocol		<running> to <startup> in the standardized NETCONF datastore editing
	does not expose these differences and instead provides only a		model. The RESTCONF protocol does not expose these differences and
	writable unified datastore, which hides whether edits are done		instead provides only a writable unified datastore, which hides
	through <candidate> or by directly modifying <running> or via some		whether edits are done through <candidate>, by directly modifying
	other implementation specific mechanism. RESTCONF also hides how		<running>, or via some other implementation-specific mechanism.
	configuration is made persistent. Note that implementations may also		RESTCONF also hides how configuration is made persistent. Note that
	have additional datastores that can propagate changes to <running>.		implementations may also have additional datastores that can
	NETCONF explicitly mentions so called named datastores.		propagate changes to <running>. 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 contents of <running>		o The NETCONF <get> operation returns the contents of <running>
	together with the operational state. It is therefore necessary		together with the operational state. It is therefore necessary
	that "config false" data is in a different branch than the "config		that "config false" data be in a different branch than the
	true" data if the operational state can have a different lifetime		"config true" data if the operational state can have a different
	compared to configuration or if configuration is not immediately		lifetime compared to configuration or if configuration is not
	or successfully applied.		immediately 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>. Inactive data is		clients to store inactive data in <running>. Inactive data is
	conceptually removed before validation.		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.
	5. 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) |
	+-------------+ | | +-----------+		+-------------+ | | +-----------+
	| | | |		| | | |
	| +-----------+ |		| +-----------+ |
	+-------->| <running> |<--------+		+-------->| <running> |<--------+
	skipping to change at page 11, line 37 ¶		skipping to change at page 12, line 46 ¶
	boots. <startup> is only present on devices that separate the		boots. <startup> is only present on devices that separate the
	startup configuration from the running configuration datastore.		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> via either implicit or explicit protocol operations.
	5.1.2. The Candidate Configuration Datastore (<candidate>)		5.1.2. The Candidate Configuration Datastore (<candidate>)
	The candidate configuration datastore (<candidate>) is a		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.
	skipping to change at page 12, line 29 ¶		skipping to change at page 13, line 42 ¶
	If a device does not have a distinct <startup> and non-volatile		If a device does not have a distinct <startup> and non-volatile
	storage is available, the device will typically use that non-volatile		storage is available, the device will typically use that non-volatile
	storage to allow <running> to persist across reboots.		storage to allow <running> to persist across reboots.
	5.1.4. The Intended Configuration Datastore (<intended>)		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 represents the configuration after all		configuration datastore. It represents the configuration after all
	configuration transformations to <running> are performed (e.g.,		configuration transformations to <running> are performed (e.g.,
	template expansion, removal of inactive configuration), and is the		template expansion, removal of inactive configuration) and is the
	configuration that the system attempts to apply.		configuration that the system attempts to apply.
	<intended> is tightly coupled to <running>. Whenever data is written		<intended> is tightly coupled to <running>. Whenever data is written
	to <running>, then <intended> MUST also be immediately updated by		to <running>, the server MUST also immediately update and validate
	performing all necessary configuration transformations to the		<intended>.
	contents of <running> and then <intended> is validated.
	<intended> MAY also be updated independently of <running> if the		<intended> MAY also be updated independently of <running> if the
	effect of a configuration transformation changes, but <intended> MUST		effect of a configuration transformation changes, but <intended> MUST
	always be a valid configuration data tree, as defined in Section 8.1		always be a valid configuration data tree, as defined in Section 8.1
	of [RFC7950].		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"		The contents of <intended> are also related to the "config true"
	subset of <operational>, and hence a client can determine to what		subset of <operational>; hence, a client can determine to what extent
	extent the intended configuration is currently in use by checking		the intended configuration is currently in use by checking to see
	whether the contents of <intended> also appear in <operational>.		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 content 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>.
	A second example is support for templates, which can perform		A second example is support for templates, which can perform
	transformations on the configuration from <running> to the		transformations on the configuration from <running> to the
	configuration written to <intended>.		configuration written to <intended>.
	5.2. 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>.
	The datastore schema for a dynamic configuration datastore MAY differ		The datastore schema for a dynamic configuration datastore MAY differ
	from the datastore schema used for conventional configuration		from the datastore schema used for conventional configuration
	datastores. If a module does not contain any configuration data		datastores. If a module does not contain any configuration data
	nodes and it is not needed to satisfy any imports, then it MAY be		nodes and it is not needed to satisfy any imports, then it MAY be
	omitted from the datastore schema for the dynamic configuration		omitted from the datastore schema for the dynamic configuration
	datastore.		datastore.
	5.3. 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 datastore's schema. In the original NETCONF model the		defined in the datastore's schema. In the original NETCONF model,
	operational state only had "config false" nodes. The reason for		the operational state only had "config false" nodes. The reason for
	incorporating "config true" nodes here is to be able to expose all		incorporating "config true" nodes here is to be able to expose all
	operational settings without having to replicate definitions in the		operational settings without having to replicate definitions in the
	data models.		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
	<intended>, learned configuration, system-provided configuration, and		<intended>, learned configuration, system-provided configuration, and
	default values defined by any supported data models. In addition,		default values defined by any supported data models. In addition,
	<operational> also contains applied configuration from dynamic		<operational> also contains applied configuration from dynamic
	configuration datastores.		configuration datastores.
	The datastore schema for <operational> MUST be a superset of the		The datastore schema for <operational> MUST be a superset of the
	combined datastore schema used in all configuration datastores except		combined datastore schema used in all configuration datastores,
	that configuration data nodes supported in a configuration datastore		except that configuration data nodes supported in a configuration
	MAY be omitted from <operational> if a server is not able to		datastore MAY be omitted from <operational> if a server is not able
	accurately report them.		to accurately report them.
	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 being "in use" by the system
	system is dependent on both the schema definition and the device		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 to be "in use".
	Conversely, functionality that is neither enabled nor operational on		Conversely, functionality that is neither enabled nor operational on
	the system is considered as not being "in use", and hence SHOULD be		the system is considered not to be "in use"; hence, it SHOULD 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
	circumstances, e.g., an abnormal value is "in use", the structure of		(e.g., an abnormal value is "in use", the structure of a list is
	a list is being modified, or due to remnant configuration (see		being modified, or remnant configuration (see Section 5.3.1) still
	Section 5.3.1). Note, that deviations SHOULD be used when it is		exists). Note that deviations SHOULD be used when it is known in
	known in advance that a device does not fully conform to the		advance that a device does not fully conform to the <operational>
	<operational> schema.		schema.
	Only semantic constraints MAY be violated, these are the YANG "when",		Only semantic constraints MAY be violated. These are the YANG
	"must", "mandatory", "unique", "min-elements", and "max-elements"		"when", "must", "mandatory", "unique", "min-elements", and
	statements; and the uniqueness of key values.		"max-elements" statements; and the uniqueness of key values.
	Syntactic constraints MUST NOT 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 MUST		<operational> does not meet the syntactic constraints, then it
	NOT be returned, and some other mechanism should be used to flag the		MUST NOT be returned, and some other mechanism should be used to flag
	error.		the error.
	<operational> does not persist across reboots.		<operational> does not persist across reboots.
	5.3.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).
	Remnant 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.
	skipping to change at page 15, line 24 ¶		skipping to change at page 16, line 39 ¶
	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 that 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 cause it to		especially given that rebooting such a device would cause it to
	restart with an invalid configuration. Instead we allow		restart with an invalid configuration. Instead, we allow
	configuration for missing resources to exist in <running> and		configuration for missing resources to exist in <running> and
	<intended>, but it will not appear in <operational>.		<intended>, but it will not appear in <operational>.
	5.3.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 appears in (and disappears 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; this 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).
	5.3.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
	The origin applies to all configuration nodes except non-presence		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 7. 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.
	o system: represents configuration provided by the system itself.		o system: represents configuration provided by the system itself.
	Examples of system configuration include applied configuration for		Examples of system configuration include applied configuration for
	an always existing loopback interface, or interface configuration		an always-existing loopback interface, or interface configuration
	that is auto-created due to the hardware currently present in the		that is auto-created due to the hardware currently present in the
	device.		device.
	o learned: represents configuration that has been learned via		o learned: represents configuration that has been learned via
	protocol interactions with other systems, including protocols such		protocol interactions with other systems, including such protocols
	as link-layer negotiations, routing protocols, DHCP, etc.		as link-layer negotiations, routing protocols, and DHCP.
	o default: represents configuration using a default value specified		o default: represents configuration using a default value specified
	in the data model, using either values in the "default" statement		in the data model, using either values in the "default" statement
	or any values described in the "description" statement. The		or any values described in the "description" statement. The
	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 in use 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, 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
	does not override an explicitly configured value, then the origin		value does not override an explicitly configured value, then the
	would be reported as "intended" even when a learned value is the same		origin would be reported as "intended", even when a learned value is
	as the configured value.		the same 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, it SHOULD use the origin
	"unknown".		"unknown".
	6. Implications on YANG		6. Implications on YANG
	6.1. XPath Context		6.1. XPath Context
	This section updates section 6.4.1 of RFC 7950.		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 18, line 7 ¶		skipping to change at page 19, line 25 ¶
	"output" statement in an "rpc" or "action" statement, the		"output" statement in an "rpc" or "action" statement, the
	accessible tree is the RPC or action operation instance and all		accessible tree is the RPC or action operation instance and all
	operational state in the server. The root node has top-level data		operational state in the server. The root node has top-level data
	nodes in all modules as children. Additionally, for an RPC, the		nodes in all modules as children. Additionally, for an RPC, the
	root node also has the node representing the RPC operation being		root node also has the node representing the RPC operation being
	defined as a child. The node representing the operation being		defined as a child. The node representing the operation being
	defined has the operation's output parameters as children.		defined has the operation's output parameters as children.
	6.2. Invocation of Actions and RPCs		6.2. Invocation of Actions and RPCs
	This section updates section 7.15 of RFC 7950.		This section updates Section 7.15 of RFC 7950.
	Actions are always invoked in the context of the operational state		Actions are always invoked in the context of the operational state
	datastore. The node for which the action is invoked MUST exist in		datastore. The node for which the action is invoked MUST exist in
	the operational state datastore.		the operational state datastore.
	Note that this document does not constrain the result of invoking an		Note that this document does not constrain the result of invoking an
	RPC or action in any way. For example, an RPC might be defined to		RPC or action in any way. For example, an RPC might be defined to
	modify the contents of some datastore.		modify the contents of some datastore.
	7. YANG Modules		7. YANG Modules
	<CODE BEGINS> file "ietf-datastores@2018-01-11.yang"		<CODE BEGINS> file "ietf-datastores@2018-02-14.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";
	contact		contact
	skipping to change at page 18, line 50 ¶		skipping to change at page 20, line 38 ¶
	Author: Phil Shafer		Author: Phil Shafer
	<mailto:phil@juniper.net>		<mailto:phil@juniper.net>
	Author: Kent Watsen		Author: Kent Watsen
	<mailto:kwatsen@juniper.net>		<mailto:kwatsen@juniper.net>
	Author: Rob Wilton		Author: Rob Wilton
	<rwilton@cisco.com>";		<rwilton@cisco.com>";
	description		description
	"This YANG module defines two sets of identities for datastores.		"This YANG module defines a set of identities for identifying
	The first identifies the datastores themselves, the second		datastores.
	identifies datastore properties.
	Copyright (c) 2018 IETF Trust and the persons identified as		Copyright (c) 2018 IETF Trust and the persons identified as
	authors of the code. All rights reserved.		authors of the code. All rights reserved.
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject to		without modification, is permitted pursuant to, and subject to
	the license terms contained in, the Simplified BSD License set		the license terms contained in, the Simplified BSD License set
	forth in Section 4.c of the IETF Trust's Legal Provisions		forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents		Relating to IETF Documents
	(http://trustee.ietf.org/license-info).		(https://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX		This version of this YANG module is part of RFC 8342
	(http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself		(https://www.rfc-editor.org/info/rfc8342); see the RFC itself
	for full legal notices.";		for full legal notices.";
	revision 2018-01-11 {		revision 2018-02-14 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	"RFC XXXX: Network Management Datastore Architecture";		"RFC 8342: Network Management Datastore Architecture (NMDA)";
	}		}
	/*		/*
	* Identities		* Identities
	*/		*/
	identity datastore {		identity datastore {
	description		description
	"Abstract base identity for datastore identities.";		"Abstract base identity for datastore identities.";
	}		}
	skipping to change at page 20, line 39 ¶		skipping to change at page 22, line 33 ¶
	* Type definitions		* Type definitions
	*/		*/
	typedef datastore-ref {		typedef datastore-ref {
	type identityref {		type identityref {
	base datastore;		base datastore;
	}		}
	description		description
	"A datastore identity reference.";		"A datastore identity reference.";
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
			<CODE BEGINS> file "ietf-origin@2018-02-14.yang"
	<CODE BEGINS> file "ietf-origin@2018-01-11.yang"
	module ietf-origin {		module ietf-origin {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-origin";		namespace "urn:ietf:params:xml:ns:yang:ietf-origin";
	prefix or;		prefix or;
	import ietf-yang-metadata {		import ietf-yang-metadata {
	prefix md;		prefix md;
	}		}
	skipping to change at page 21, line 31 ¶		skipping to change at page 23, line 39 ¶
	Author: Phil Shafer		Author: Phil Shafer
	<mailto:phil@juniper.net>		<mailto:phil@juniper.net>
	Author: Kent Watsen		Author: Kent Watsen
	<mailto:kwatsen@juniper.net>		<mailto:kwatsen@juniper.net>
	Author: Rob Wilton		Author: Rob Wilton
	<rwilton@cisco.com>";		<rwilton@cisco.com>";
	description		description
	"This YANG module defines an 'origin' metadata annotation, and a		"This YANG module defines an 'origin' metadata annotation and a
	set of identities for the origin value.		set of identities for the origin value.
	Copyright (c) 2018 IETF Trust and the persons identified as		Copyright (c) 2018 IETF Trust and the persons identified as
	authors of the code. All rights reserved.		authors of the code. All rights reserved.
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject to		without modification, is permitted pursuant to, and subject to
	the license terms contained in, the Simplified BSD License set		the license terms contained in, the Simplified BSD License set
	forth in Section 4.c of the IETF Trust's Legal Provisions		forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents		Relating to IETF Documents
	(http://trustee.ietf.org/license-info).		(https://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX		This version of this YANG module is part of RFC 8342
	(http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself		(https://www.rfc-editor.org/info/rfc8342); see the RFC itself
	for full legal notices.";		for full legal notices.";
	revision 2018-01-11 {		revision 2018-02-14 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	"RFC XXXX: Network Management Datastore Architecture";		"RFC 8342: Network Management Datastore Architecture (NMDA)";
	}		}
	/*		/*
	* Identities		* Identities
	*/		*/
	identity origin {		identity origin {
	description		description
	"Abstract base identity for the origin annotation.";		"Abstract base identity for the origin annotation.";
	}		}
	identity intended {		identity intended {
	base origin;		base origin;
	description		description
	"Denotes configuration from the intended configuration		"Denotes configuration from the intended configuration
	datastore";		datastore.";
	}		}
	identity dynamic {		identity dynamic {
	base origin;		base origin;
	description		description
	"Denotes configuration from a dynamic configuration		"Denotes configuration from a dynamic configuration
	datastore.";		datastore.";
	}		}
	identity system {		identity system {
	base origin;		base origin;
	description		description
	"Denotes configuration originated by the system itself.		"Denotes configuration originated by the system itself.
	Examples of system configuration include applied configuration		Examples of system configuration include applied configuration
	for an always existing loopback interface, or interface		for an always-existing loopback interface, or interface
	configuration that is auto-created due to the hardware		configuration that is auto-created due to the hardware
	currently present in the device.";		currently present in the device.";
	}		}
	identity learned {		identity learned {
	base origin;		base origin;
	description		description
	"Denotes configuration learned from protocol interactions with		"Denotes configuration learned from protocol interactions with
	other devices, instead of via either the intended		other devices, instead of via either the intended
	configuration datastore or any dynamic configuration		configuration datastore or any dynamic configuration
	datastore.		datastore.
	Examples of protocols that provide learned configuration		Examples of protocols that provide learned configuration
	include link-layer negotiations, routing protocols, and		include link-layer negotiations, routing protocols, and
	skipping to change at page 23, line 4 ¶		skipping to change at page 25, line 15 ¶
	base origin;		base origin;
	description		description
	"Denotes configuration learned from protocol interactions with		"Denotes configuration learned from protocol interactions with
	other devices, instead of via either the intended		other devices, instead of via either the intended
	configuration datastore or any dynamic configuration		configuration datastore or any dynamic configuration
	datastore.		datastore.
	Examples of protocols that provide learned configuration		Examples of protocols that provide learned configuration
	include link-layer negotiations, routing protocols, and		include link-layer negotiations, routing protocols, and
	DHCP.";		DHCP.";
	}		}
	identity default {		identity default {
	base origin;		base origin;
	description		description
	"Denotes configuration that does not have an configured or		"Denotes configuration that does not have a configured or
	learned value, but has a default value in use. Covers both		learned value but has a default value in use. Covers both
	values defined in a 'default' statement, and values defined		values defined in a 'default' statement and values defined
	via an explanation in a 'description' statement.";		via an explanation in a 'description' statement.";
	}		}
	identity unknown {		identity unknown {
	base origin;		base origin;
	description		description
	"Denotes configuration for which the system cannot identify the		"Denotes configuration for which the system cannot identify the
	origin.";		origin.";
	}		}
	skipping to change at page 23, line 45 ¶		skipping to change at page 26, line 14 ¶
	/*		/*
	* Metadata annotations		* Metadata annotations
	*/		*/
	md:annotation origin {		md:annotation origin {
	type origin-ref;		type origin-ref;
	description		description
	"The 'origin' annotation can be present on any configuration		"The 'origin' annotation can be present on any configuration
	data node in the operational state datastore. It specifies		data node in the operational state datastore. It specifies
	from where the node originated. If not specified for a given		from 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>
	8. IANA Considerations		8. IANA Considerations
	8.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"
	Following the format in [RFC3688], the following registrations are		[RFC3688]. Following the format in [RFC3688], the following
	requested:		registrations have been made:
	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.
	8.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 following		registry [RFC6020]. Following the format in [RFC6020], the following
	registrations are requested:		registrations have been made:
	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 8342
	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 8342
	9. 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 a metadata annotation, hence the "YANG		only define identities and a metadata annotation; hence, the "YANG
	module security guidelines" do not apply.		module security guidelines" [YANG-SEC] do not apply.
	The origin metadata annotation exposes the origin of values in the		The origin metadata annotation exposes the origin of values in the
	applied configuration. Origin information may provide hints that		applied configuration. Origin information may provide hints that
	certain control plane protocols are active on a device. Since origin		certain control-plane protocols are active on a device. Since origin
	information is tied to applied configuration values, it is only		information is tied to applied configuration values, it is only
	accessible to clients that have the permissions to read the applied		accessible to clients that have the permissions to read the applied
	configuration values. Security administrators should consider the		configuration values. Security administrators should consider the
	sensitivity of origin information while defining access control		sensitivity of origin information while defining access control
	rules.		rules.
	10. Acknowledgments		10. References
	This document grew out of many discussions that took place since
	2010. Several Internet-Drafts ([I-D.bjorklund-netmod-operational],
	[I-D.wilton-netmod-opstate-yang], [I-D.ietf-netmod-opstate-reqs],
	[I-D.kwatsen-netmod-opstate], [I-D.openconfig-netmod-opstate]) and
	[RFC6244] touched on some of the problems of the original datastore
	model. 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, L.L.C., <lberger@labn.net>
	o Andy Bierman, YumaWorks, <andy@yumaworks.com>
	o Marcus Hines, Google, <hines@google.com>
	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 Ladislav Lhotka, CZ.NIC, <lhotka@nic.cz>
	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 Rob Shakir, Google, <robjs@google.com>
	o Jason Sterne, Nokia, <jason.sterne@nokia.co>
	Juergen Schoenwaelder was partly funded by Flamingo, a Network of
	Excellence project (ICT-318488) supported by the European Commission
	under its Seventh Framework Programme.
	11. References		10.1. Normative References
	11.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/		Requirement Levels", BCP 14, RFC 2119,
	RFC2119, March 1997, <https://www.rfc-editor.org/info/		DOI 10.17487/RFC2119, March 1997,
	rfc2119>.		<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,
	<https://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, <https://www		RFC 7950, DOI 10.17487/RFC7950, August 2016,
	.rfc-editor.org/info/rfc7950>.		<https://www.rfc-editor.org/info/rfc7950>.
	[RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", RFC		[RFC7952] Lhotka, L., "Defining and Using Metadata with YANG",
	7952, DOI 10.17487/RFC7952, August 2016, <https://www.rfc-		RFC 7952, DOI 10.17487/RFC7952, August 2016,
	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,
	<https://www.rfc-editor.org/info/rfc8040>.		<https://www.rfc-editor.org/info/rfc8040>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		RFC 2119 Key Words", BCP 14, RFC 8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		DOI 10.17487/RFC8174, May 2017,
			<https://www.rfc-editor.org/info/rfc8174>.
	11.2. Informative References		[W3C.REC-xml-20081126]
			Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
			F. Yergeau, "Extensible Markup Language (XML) 1.0
			(Fifth Edition)", World Wide Web Consortium Recommendation
			REC-xml-20081126, November 2008,
			<https://www.w3.org/TR/2008/REC-xml-20081126>.
	[I-D.bjorklund-netmod-operational]		10.2. Informative References
	Bjorklund, M. and L. Lhotka, "Operational Data in NETCONF
	and YANG", draft-bjorklund-netmod-operational-00 (work in
	progress), October 2012.
	[I-D.ietf-netmod-opstate-reqs]		[NETMOD-Operational]
	Watsen, K. and T. Nadeau, "Terminology and Requirements		Bjorklund, M. and L. Lhotka, "Operational Data in NETCONF
	for Enhanced Handling of Operational State", draft-ietf-		and YANG", Work in Progress, draft-bjorklund-netmod-
	netmod-opstate-reqs-04 (work in progress), January 2016.		operational-00, October 2012.
	[I-D.kwatsen-netmod-opstate]		[OpState-Enhance]
	Watsen, K., Bierman, A., Bjorklund, M., and J.		Watsen, K., Bierman, A., Bjorklund, M., and J.
	Schoenwaelder, "Operational State Enhancements for YANG,		Schoenwaelder, "Operational State Enhancements for YANG,
	NETCONF, and RESTCONF", draft-kwatsen-netmod-opstate-02		NETCONF, and RESTCONF", Work in Progress, draft-kwatsen-
	(work in progress), February 2016.		netmod-opstate-02, February 2016.
	[I-D.openconfig-netmod-opstate]		[OpState-Modeling]
	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", Work in Progress,
	netmod-opstate-01 (work in progress), July 2015.		draft-openconfig-netmod-opstate-01, July 2015.
	[I-D.wilton-netmod-opstate-yang]		[OpState-Reqs]
	Wilton, R., ""With-config-state" Capability for NETCONF/		Watsen, K. and T. Nadeau, "Terminology and Requirements
	RESTCONF", draft-wilton-netmod-opstate-yang-02 (work in		for Enhanced Handling of Operational State", Work in
	progress), December 2015.		Progress, draft-ietf-netmod-opstate-reqs-04, January 2016.
	[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, <https://www.rfc-		DOI 10.17487/RFC3688, January 2004,
	editor.org/info/rfc3688>.		<https://www.rfc-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, <https://www.rfc-		DOI 10.17487/RFC6020, October 2010,
	editor.org/info/rfc6020>.		<https://www.rfc-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,
	2011, <https://www.rfc-editor.org/info/rfc6244>.		June 2011, <https://www.rfc-editor.org/info/rfc6244>.
	[RFC7223] Bjorklund, M., "A YANG Data Model for Interface		[RFC8343] Bjorklund, M., "A YANG Data Model for Interface
	Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,		Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
	<https://www.rfc-editor.org/info/rfc7223>.		<https://www.rfc-editor.org/info/rfc8343>.
	[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", RFC		[RFC8344] Bjorklund, M., "A YANG Data Model for IP Management",
	7277, DOI 10.17487/RFC7277, June 2014, <https://www.rfc-		RFC 8344, DOI 10.17487/RFC8344, March 2018,
	editor.org/info/rfc7277>.		<https://www.rfc-editor.org/info/rfc8344>.
			[With-config-state]
			Wilton, R., ""With-config-state" Capability for
			NETCONF/RESTCONF", Work in Progress, draft-wilton-netmod-
			opstate-yang-02, December 2015.
			[YANG-SEC] IETF, "YANG Security Guidelines", <https://trac.ietf.org/
			trac/ops/wiki/yang-security-guidelines>.
	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 for defining the
	the datastore. When it makes sense, more than one datastore may be		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 subsections below.
	A.1. Define which YANG modules can be used in the datastore		A.1. Define Which YANG Modules Can Be Used in the Datastore
	Not all YANG modules may be used in all datastores. Some datastores		Not all YANG modules may be used in all datastores. Some datastores
	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, or		a datastore. For instance, maybe only "config true" nodes, or
	"config false" nodes that also have a specific YANG extension, are		"config false" nodes that also have a specific YANG 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 5 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
	has to 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., Forwarding and
	subset of all protocol operations or capabilities are available		Control Element Separation (ForCES)) or that a subset of all protocol
	(e.g., no locking or no XPath-based filtering).		operations or capabilities are available (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		"ds:datastore" identity, or one of its derived identities, as its
	base. This identity is necessary so that the datastore can be		base. This identity is necessary, so that the datastore can be
	referenced in 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 of its derived identities, as its base.
	identity is needed if the datastore interacts with <operational> so		This identity is needed if the datastore interacts with
	that data originating from the datastore can be identified as such		<operational>, so that data originating from the datastore can be
	via the "origin" metadata attribute defined in Section 7.		identified as such 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. Example of an Ephemeral Dynamic Configuration Datastore
	The section defines documentation for an example dynamic		This 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		For brevity, only a terse example is provided; it is expected that a
	standalone RFC would be needed when fully expanded.		standalone RFC would be written when this type of scenario is fully
			considered.
	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.
	+--------------+---------------------------------------------------+		+--------------------+----------------------------------------------+
	| Name | Value |		| Name | Value |
	+--------------+---------------------------------------------------+		+--------------------+----------------------------------------------+
	| Name | ephemeral |		| Name | ephemeral |
	| YANG modules | all (default) |		| | |
	| YANG nodes | all "config true" data nodes |		| YANG modules | all (default) |
	| How applied | changes automatically propagated to <operational> |		| | |
	| Protocols | NC/RC (default) |		| YANG nodes | all "config true" data nodes |
	| YANG Module | (see below) |		| | |
	+--------------+---------------------------------------------------+		| How applied | changes automatically propagated to |
			| | <operational> |
			| | |
			| Protocols | NETCONF/RESTCONF (default) |
			| | |
			| Defining YANG | "example-ds-ephemeral" |
			| module | |
			+--------------------+----------------------------------------------+
	The example "ephemeral" datastore properties		Properties of the Example "ephemeral" Datastore
	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 30, line 40 ¶		skipping to change at page 33, line 40 ¶
	}		}
	}		}
	Appendix C. Example Data		Appendix C. Example Data
	The use of datastores is complex, and many of the subtle effects are		The use of datastores is complex, and many of the subtle effects are
	more easily presented using examples. This section presents a series		more easily presented using examples. This section presents a series
	of example data models with some sample contents of the various		of example data models with some sample contents of the various
	datastores.		datastores.
			The XML [W3C.REC-xml-20081126] snippets that follow are provided as
			examples only.
	C.1. System Example		C.1. System Example
	In this example, the following fictional module is used:		In this example, the following fictional module is used:
	module example-system {		module example-system {
	yang-version 1.1;		yang-version 1.1;
	namespace urn:example:system;		namespace urn:example:system;
	prefix sys;		prefix sys;
	import ietf-inet-types {		import ietf-inet-types {
	skipping to change at page 31, line 25 ¶		skipping to change at page 34, line 39 ¶
	container auto-negotiation {		container auto-negotiation {
	leaf enabled {		leaf enabled {
	type boolean;		type boolean;
	default true;		default true;
	}		}
	leaf speed {		leaf speed {
	type uint32;		type uint32;
	units mbps;		units mbps;
	description		description
	"The advertised speed, in mbps.";		"The advertised speed, in Mbps.";
	}		}
	}		}
	leaf speed {		leaf speed {
	type uint32;		type uint32;
	units mbps;		units mbps;
	config false;		config false;
	description		description
	"The speed of the interface, in mbps.";		"The speed of the interface, in Mbps.";
	}		}
	list address {		list address {
	key ip;		key ip;
	leaf ip {		leaf ip {
	type inet:ip-address;		type inet:ip-address;
	}		}
	leaf prefix-length {		leaf prefix-length {
	type uint8;		type uint8;
	}		}
	}		}
	skipping to change at page 32, line 4 ¶		skipping to change at page 35, line 17 ¶
	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 hostname and two interfaces, so the
	contents of <intended> are:		contents of <intended> are:
	<system xmlns="urn:example:system">		<system xmlns="urn:example:system">
	<hostname>foo.example.com</hostname>		<hostname>foo.example.com</hostname>
	<interface>		<interface>
	<name>eth0</name>		<name>eth0</name>
	<auto-negotiation>		<auto-negotiation>
	<speed>1000</speed>		<speed>1000</speed>
	skipping to change at page 32, line 34 ¶		skipping to change at page 35, line 48 ¶
	<address>		<address>
	<ip>2001:db8::20</ip>		<ip>2001:db8::20</ip>
	<prefix-length>64</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
	name and an additional IP address for "eth0" over DHCP. In addition		hostname and an additional IP address for "eth0" over DHCP. In
	to a default value, a loopback interface is automatically added by		addition to filling in the default value for the auto-negotiation
	the system, and the result of the "speed" auto-negotiation. All of		enabled leaf, a loopback interface entry is also automatically
	this is reflected in <operational>. Note how the origin metadata		instantiated by the system. All of this is reflected in
	attribute for several "config true" data nodes is inherited from		<operational>. Note how the "origin" metadata attribute for several
	their parent data nodes.		"config true" data nodes is inherited from their parent data nodes.
	<system		<system
	xmlns="urn:example:system"		xmlns="urn:example:system"
	xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">		xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
	<hostname or:origin="or:learned">bar.example.com</hostname>		<hostname or:origin="or:learned">bar.example.com</hostname>
	<interface or:origin="or:intended">		<interface or:origin="or:intended">
	<name>eth0</name>		<name>eth0</name>
	<auto-negotiation>		<auto-negotiation>
	skipping to change at page 34, line 20 ¶		skipping to change at page 37, line 24 ¶
	type uint32;		type uint32;
	}		}
	list peer {		list peer {
	key name;		key name;
	leaf name {		leaf name {
	type inet:ip-address;		type inet:ip-address;
	}		}
	leaf local-as {		leaf local-as {
	type uint32;		type uint32;
	description		description
	".... Defaults to ../local-as";		"... Defaults to ../local-as.";
	}		}
	leaf peer-as {		leaf peer-as {
	type uint32;		type uint32;
	description		description
	"... Defaults to ../peer-as";		"... Defaults to ../peer-as.";
	}		}
	leaf local-port {		leaf local-port {
	type inet:port;		type inet:port;
	}		}
	leaf remote-port {		leaf remote-port {
	type inet:port;		type inet:port;
	default 179;		default 179;
	}		}
	leaf state {		leaf state {
	config false;		config false;
	skipping to change at page 35, line 10 ¶		skipping to change at page 38, line 14 ¶
	The model also follows the pattern of fully integrating state		The model also follows the pattern of fully integrating state
	("config false") nodes with configuration ("config true") nodes.		("config false") nodes with configuration ("config true") nodes.
	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,
	single BGP peer. <intended> will conceptually hold the data as		a 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>		after any local template mechanisms are performed. <operational>
	will 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
	<running> and <intended>.		<running> and <intended>.
	In this scenario, we've added the following to <running>:		In this scenario, we've added the following to <running>:
	<bgp>		<bgp>
	<local-as>64501</local-as>		<local-as>64501</local-as>
	<peer-as>64502</peer-as>		<peer-as>64502</peer-as>
	<peer>		<peer>
	<name>2001:db8::2:3</name>		<name>2001:db8::2:3</name>
	</peer>		</peer>
	</bgp>		</bgp>
	C.2.2.1. <operational>		C.2.2.1. <operational>
	The operational datastore will contain the fully expanded peer data,		The operational datastore will contain the fully expanded peer data,
	including "config false" nodes. In our example, this means the		including "config false" nodes. In our example, this means that the
	"state" node will appear.		"state" node will appear.
	In addition, <operational> will contain the "currently in use" values		In addition, <operational> will contain the "currently in use" values
	for all nodes. This means that local-as and peer-as will be		for all nodes. This means that local-as and peer-as will be
	populated even if they are not given values in <intended>. The value		populated even if they are not given values in <intended>. The value
	of bgp/local-as will be used if bgp/peer/local-as is not provided;		of bgp/local-as will be used if bgp/peer/local-as is not provided;
	bgp/peer-as and bgp/peer/peer-as will have the same relationship. In		bgp/peer-as and bgp/peer/peer-as will have the same relationship. In
	the operational view, this means that every peer will have values for		the operational view, this means that every peer will have values for
	their local-as and peer-as, even if those values are not explicitly		their local-as and peer-as, even if those values are not explicitly
	configured but are provided by bgp/local-as and bgp/peer-as.		configured but are provided by bgp/local-as and bgp/peer-as.
	skipping to change at page 36, line 15 ¶		skipping to change at page 39, line 18 ¶
	Each BGP peer has a TCP connection associated with it, using the		Each BGP peer has a TCP connection associated with it, using the
	values of local-port and remote-port from <intended>. If those		values of local-port and remote-port from <intended>. If those
	values are not supplied, the system will select values. When the		values are not supplied, the system will select values. When the
	connection is established, <operational> will contain the current		connection is established, <operational> will contain the current
	values for the local-port and remote-port nodes regardless of the		values for the local-port and remote-port nodes regardless of the
	origin. If the system has chosen the values, the "origin" attribute		origin. If the system has chosen the values, the "origin" attribute
	will be set to "system". Before the connection is established, one		will be set to "system". Before the connection is established, one
	or both of the nodes may not appear, since the system may not yet		or both of the nodes may not appear, since the system may not yet
	have their values.		have their values.
	<bgp or:origin="or:intended">		<bgp xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
			or:origin="or:intended">
	<local-as>64501</local-as>		<local-as>64501</local-as>
	<peer-as>64502</peer-as>		<peer-as>64502</peer-as>
	<peer>		<peer>
	<name>2001:db8::2:3</name>		<name>2001:db8::2:3</name>
	<local-as or:origin="or:default">64501</local-as>		<local-as or:origin="or:default">64501</local-as>
	<peer-as or:origin="or:default">64502</peer-as>		<peer-as or:origin="or:default">64502</peer-as>
	<local-port or:origin="or:system">60794</local-port>		<local-port or:origin="or:system">60794</local-port>
	<remote-port or:origin="or:default">179</remote-port>		<remote-port or:origin="or:default">179</remote-port>
	<state>established</state>		<state>established</state>
	</peer>		</peer>
	skipping to change at page 37, line 5 ¶		skipping to change at page 40, line 5 ¶
	operation of the device.		operation of the device.
	Consider the scenario where a client removes a BGP peer. When a peer		Consider the scenario where a client removes a BGP peer. When a peer
	is removed, the operational state will continue to reflect the		is removed, the operational state will continue to reflect the
	existence of that peer until the peer's resources are released,		existence of that peer until the peer's resources are released,
	including closing the peer's connection. During this period, the		including closing the peer's connection. During this period, the
	current data values will continue to be visible in <operational>,		current data values will continue to be visible in <operational>,
	with the "origin" attribute set to indicate the origin of the		with the "origin" attribute set to indicate the origin of the
	original data.		original data.
	<bgp or:origin="or:intended">		<bgp xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
			or:origin="or:intended">
	<local-as>64501</local-as>		<local-as>64501</local-as>
	<peer-as>64502</peer-as>		<peer-as>64502</peer-as>
	<peer>		<peer>
	<name>2001:db8::2:3</name>		<name>2001:db8::2:3</name>
	<local-as or:origin="or:default">64501</local-as>		<local-as or:origin="or:default">64501</local-as>
	<peer-as or:origin="or:default">64502</peer-as>		<peer-as or:origin="or:default">64502</peer-as>
	<local-port or:origin="or:system">60794</local-port>		<local-port or:origin="or:system">60794</local-port>
	<remote-port or:origin="or:default">179</remote-port>		<remote-port or:origin="or:default">179</remote-port>
	<state>closing</state>		<state>closing</state>
	</peer>		</peer>
	skipping to change at page 38, line 24 ¶		skipping to change at page 41, line 32 ¶
	</interfaces>		</interfaces>
	Since the interface does not exist, this data does not appear in		Since the interface does not exist, this data does not appear in
	<operational>.		<operational>.
	When a FRU containing this interface is inserted, the system will		When a FRU containing this interface is inserted, the system will
	detect it and process the associated configuration. <operational>		detect it and process the associated configuration. <operational>
	will contain the data from <intended>, as well as nodes added by the		will contain the data from <intended>, as well as nodes added by the
	system, such as the current value of the interface's MTU.		system, such as the current value of the interface's MTU.
	<interfaces or:origin="or:intended">		<interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
			or:origin="or:intended">
	<interface>		<interface>
	<name>et-0/0/0</name>		<name>et-0/0/0</name>
	<description>Test interface</description>		<description>Test interface</description>
	<mtu or:origin="or:system">1500</mtu>		<mtu or:origin="or:system">1500</mtu>
	</interface>		</interface>
	</interfaces>		</interfaces>
	If the FRU is removed, the interface data is removed from		If the FRU is removed, the interface data is removed from
	<operational>.		<operational>.
	C.3.2. System-provided Interface		C.3.2. System-Provided Interface
	Imagine if the system provides a loopback interface (named "lo0")		Imagine that the system provides a loopback interface (named "lo0")
	with a default ip-address of "127.0.0.1" and a default ip-address of		with a default IPv4 address of "127.0.0.1" and a default IPv6 address
	"::1". The system will only provide configuration for this interface		of "::1". The system will only provide configuration for this
	if there is no data for it in <intended>.		interface if there is no data for it in <intended>.
	When no configuration for "lo0" appears in <intended>, then		When no configuration for "lo0" appears in <intended>, <operational>
	<operational> will show the system-provided data:		will show the system-provided data:
	<interfaces or:origin="or:intended">		<interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
			or:origin="or:intended">
	<interface or:origin="or:system">		<interface or:origin="or:system">
	<name>lo0</name>		<name>lo0</name>
	<ip-address>127.0.0.1</ip-address>		<ip-address>127.0.0.1</ip-address>
	<ip-address>::1</ip-address>		<ip-address>::1</ip-address>
	</interface>		</interface>
	</interfaces>		</interfaces>
	When configuration for "lo0" does appear in <intended>, then		When configuration for "lo0" does appear in <intended>, <operational>
	<operational> will show that data with the origin set to "intended".		will show that data with the origin set to "intended". If the
	If the "ip-address" is not provided, then the system-provided value		"ip-address" is not provided, then the system-provided value will
	will appear as follows:		appear as follows:
	<interfaces or:origin="or:intended">		<interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
			or:origin="or:intended">
	<interface>		<interface>
	<name>lo0</name>		<name>lo0</name>
	<description>loopback</description>		<description>loopback</description>
	<ip-address or:origin="or:system">127.0.0.1</ip-address>		<ip-address or:origin="or:system">127.0.0.1</ip-address>
	<ip-address>::1</ip-address>		<ip-address>::1</ip-address>
	</interface>		</interface>
	</interfaces>		</interfaces>
			Acknowledgments
			This document grew out of many discussions that took place since
			2010. Several documents ([NETMOD-Operational] [With-config-state]
			[OpState-Reqs] [OpState-Enhance] [OpState-Modeling], as well as
			[RFC6244]), touched on some of the problems of the original datastore
			model. The following people were authors of these works in progress
			or were otherwise actively involved in the discussions that led to
			this document:
			o Lou Berger, LabN Consulting, L.L.C., <lberger@labn.net>
			o Andy Bierman, YumaWorks, <andy@yumaworks.com>
			o Marcus Hines, Google, <hines@google.com>
			o Christian Hopps, Deutsche Telekom, <chopps@chopps.org>
			o Balazs Lengyel, Ericsson, <balazs.lengyel@ericsson.com>
			o Ladislav Lhotka, CZ.NIC, <lhotka@nic.cz>
			o Acee Lindem, Cisco Systems, <acee@cisco.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 Rob Shakir, Google, <robjs@google.com>
			o Jason Sterne, Nokia, <jason.sterne@nokia.com>
			Juergen Schoenwaelder was partly funded by Flamingo, a Network of
			Excellence project (ICT-318488) supported by the European Commission
			under its Seventh Framework Programme.
	Authors' Addresses		Authors' Addresses
	Martin Bjorklund		Martin Bjorklund
	Tail-f Systems		Tail-f Systems
	Email: mbj@tail-f.com		Email: mbj@tail-f.com
	Juergen Schoenwaelder		Juergen Schoenwaelder
	Jacobs University		Jacobs University
End of changes. 148 change blocks.
	397 lines changed or deleted		423 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/