draft-ietf-netmod-revised-datastores-05.txt		draft-ietf-netmod-revised-datastores-06.txt
	Network Working Group M. Bjorklund		Network Working Group M. Bjorklund
	Internet-Draft Tail-f Systems		Internet-Draft Tail-f Systems
	Updates: 7950 (if approved) J. Schoenwaelder		Updates: 7950 (if approved) J. Schoenwaelder
	Intended status: Standards Track Jacobs University		Intended status: Standards Track Jacobs University
	Expires: April 21, 2018 P. Shafer		Expires: May 3, 2018 P. Shafer
	K. Watsen		K. Watsen
	Juniper Networks		Juniper Networks
	R. Wilton		R. Wilton
	Cisco Systems		Cisco Systems
	October 18, 2017		October 30, 2017
	Network Management Datastore Architecture		Network Management Datastore Architecture
	draft-ietf-netmod-revised-datastores-05		draft-ietf-netmod-revised-datastores-06
	Abstract		Abstract
	Datastores are a fundamental concept binding the data models written		Datastores are a fundamental concept binding the data models written
	in the YANG data modeling language to network management protocols		in the YANG data modeling language to network management protocols
	such as NETCONF and RESTCONF. This document defines an architectural		such as NETCONF and RESTCONF. This document defines an architectural
	framework for datastores based on the experience gained with the		framework for datastores based on the experience gained with the
	initial simpler model, addressing requirements that were not well		initial simpler model, addressing requirements that were not well
	supported in the initial model.		supported in the initial model.
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 21, 2018.		This Internet-Draft will expire on May 3, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 37 ¶		skipping to change at page 2, line 37 ¶
	5.3.1. Remnant Configuration . . . . . . . . . . . . . . . . 14		5.3.1. Remnant Configuration . . . . . . . . . . . . . . . . 14
	5.3.2. Missing Resources . . . . . . . . . . . . . . . . . . 14		5.3.2. Missing Resources . . . . . . . . . . . . . . . . . . 14
	5.3.3. System-controlled Resources . . . . . . . . . . . . . 15		5.3.3. System-controlled Resources . . . . . . . . . . . . . 15
	5.3.4. Origin Metadata Annotation . . . . . . . . . . . . . 15		5.3.4. Origin Metadata Annotation . . . . . . . . . . . . . 15
	6. Implications on YANG . . . . . . . . . . . . . . . . . . . . 16		6. Implications on YANG . . . . . . . . . . . . . . . . . . . . 16
	6.1. XPath Context . . . . . . . . . . . . . . . . . . . . . . 16		6.1. XPath Context . . . . . . . . . . . . . . . . . . . . . . 16
	7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 17		7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 17
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
	8.1. Updates to the IETF XML Registry . . . . . . . . . . . . 23		8.1. Updates to the IETF XML Registry . . . . . . . . . . . . 23
	8.2. Updates to the YANG Module Names Registry . . . . . . . . 23		8.2. Updates to the YANG Module Names Registry . . . . . . . . 23
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 23		9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
	11.1. Normative References . . . . . . . . . . . . . . . . . . 25		11.1. Normative References . . . . . . . . . . . . . . . . . . 25
	11.2. Informative References . . . . . . . . . . . . . . . . . 25		11.2. Informative References . . . . . . . . . . . . . . . . . 25
	Appendix A. Guidelines for Defining Datastores . . . . . . . . . 26		Appendix A. Guidelines for Defining Datastores . . . . . . . . . 26
	A.1. Define which YANG modules can be used in the datastore . 26		A.1. Define which YANG modules can be used in the datastore . 27
	A.2. Define which subset of YANG-modeled data applies . . . . 27		A.2. Define which subset of YANG-modeled data applies . . . . 27
	A.3. Define how data is actualized . . . . . . . . . . . . . . 27		A.3. Define how data is actualized . . . . . . . . . . . . . . 27
	A.4. Define which protocols can be used . . . . . . . . . . . 27		A.4. Define which protocols can be used . . . . . . . . . . . 27
	A.5. Define YANG identities for the datastore . . . . . . . . 27		A.5. Define YANG identities for the datastore . . . . . . . . 27
	Appendix B. Ephemeral Dynamic Configuration Datastore Example . 28		Appendix B. Ephemeral Dynamic Configuration Datastore Example . 28
	Appendix C. Example Data . . . . . . . . . . . . . . . . . . . . 29		Appendix C. Example Data . . . . . . . . . . . . . . . . . . . . 29
	C.1. System Example . . . . . . . . . . . . . . . . . . . . . 29		C.1. System Example . . . . . . . . . . . . . . . . . . . . . 29
	C.2. BGP Example . . . . . . . . . . . . . . . . . . . . . . . 32		C.2. BGP Example . . . . . . . . . . . . . . . . . . . . . . . 32
	C.2.1. Datastores . . . . . . . . . . . . . . . . . . . . . 34		C.2.1. Datastores . . . . . . . . . . . . . . . . . . . . . 34
	C.2.2. Adding a Peer . . . . . . . . . . . . . . . . . . . . 34		C.2.2. Adding a Peer . . . . . . . . . . . . . . . . . . . . 34
	skipping to change at page 4, line 43 ¶		skipping to change at page 4, line 43 ¶
	semantically equivalent with the definitions found in [RFC6241] and		semantically equivalent with the definitions found in [RFC6241] and
	[RFC7950]. It is expected that the revised definitions provided in		[RFC7950]. It is expected that the revised definitions provided in
	this section will replace the definitions in [RFC6241] and [RFC7950]		this section will replace the definitions in [RFC6241] and [RFC7950]
	when these documents are revised.		when these documents are revised.
	o datastore: A conceptual place to store and access information. A		o datastore: A conceptual place to store and access information. A
	datastore might be implemented, for example, using files, a		datastore might be implemented, for example, using files, a
	database, flash memory locations, or combinations thereof. A		database, flash memory locations, or combinations thereof. A
	datastore maps to an instantiated YANG data tree.		datastore maps to an instantiated YANG data tree.
			o schema node: A node in the schema tree. The formal definition is
			in RFC 7950.
			o datastore schema: The combined set of schema nodes for all modules
			supported by a particular datastore, taking into consideration any
			deviations and enabled features for that datastore.
	o configuration: Data that is required to get a device from its		o configuration: Data that is required to get a device from its
	initial default state into a desired operational state. This data		initial default state into a desired operational state. This data
	is modeled in YANG using "config true" nodes. Configuration can		is modeled in YANG using "config true" nodes. Configuration can
	originate from different sources.		originate from different sources.
	o configuration datastore: A datastore holding configuration.		o configuration datastore: A datastore holding configuration.
	o running configuration datastore: A configuration datastore holding		o running configuration datastore: A configuration datastore holding
	the current configuration of the device. It may include		the current configuration of the device. It may include
	configuration that requires further transformations before it can		configuration that requires further transformations before it can
	skipping to change at page 5, line 35 ¶		skipping to change at page 5, line 42 ¶
	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 schema, and protocol		<intended>. These datastores share a common datastore schema, and
	operations allow copying data between these datastores. The term		protocol operations allow copying data between these datastores.
	"conventional" is chosen as a generic umbrella term for these		The term "conventional" is chosen as a generic umbrella term for
	datastores.		these datastores.
	o conventional configuration: Configuration that is stored in any of		o conventional configuration: Configuration that is stored in any of
	the conventional configuration datastores.		the conventional configuration datastores.
	o dynamic configuration datastore: A configuration datastore holding		o dynamic configuration datastore: A configuration datastore holding
	configuration obtained dynamically during the operation of a		configuration obtained dynamically during the operation of a
	device through interaction with other systems, rather than through		device through interaction with other systems, rather than through
	one of the conventional configuration datastores.		one of the conventional configuration datastores.
	o dynamic configuration: Configuration obtained via a dynamic		o dynamic configuration: Configuration obtained via a dynamic
	skipping to change at page 10, line 44 ¶		skipping to change at page 10, line 44 ¶
	| (ct + cf, ro) |		| (ct + cf, ro) |
	+---------------+		+---------------+
	ct = config true; cf = config false		ct = config true; cf = config false
	rw = read-write; ro = read-only		rw = read-write; ro = read-only
	boxes denote named datastores		boxes denote named datastores
	5.1. Conventional Configuration Datastores		5.1. Conventional Configuration Datastores
	The conventional configuration datastores are a set of configuration		The conventional configuration datastores are a set of configuration
	datastores that share exactly the same schema, allowing data to be		datastores that share exactly the same datastore schema, allowing
	copied between them. The term is meant as a generic umbrella		data to be copied between them. The term is meant as a generic
	description of these datastores. The set of datastores include:		umbrella description of these datastores. The set of datastores
			include:
	o <running>		o <running>
	o <candidate>		o <candidate>
	o <startup>		o <startup>
	o <intended>		o <intended>
	Other conventional configuration datastores may be defined in future		Other conventional configuration datastores may be defined in future
	documents.		documents.
	The flow of data between these datastores is depicted in Section 5.		The flow of data between these datastores is depicted in Section 5.
	The specific protocols may define explicit operations to copy between		The specific protocols may define explicit operations to copy between
	these datastores, e.g., NETCONF defines the <copy-config> operation.		these datastores, e.g., NETCONF defines the <copy-config> operation.
	skipping to change at page 13, line 18 ¶		skipping to change at page 13, line 20 ¶
	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>.
	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 schema. In the original NETCONF model the operational		defined in the datastore's schema. In the original NETCONF model the
	state only had "config false" nodes. The reason for incorporating		operational state only had "config false" nodes. The reason for
	"config true" nodes here is to be able to expose all operational		incorporating "config true" nodes here is to be able to expose all
	settings without having to replicate definitions in the data models.		operational settings without having to replicate definitions in the
			data models.
	<operational> contains system state and all configuration actually		<operational> contains system state and all configuration actually
	used by the system. This includes all applied configuration from		used by the system. This includes all applied configuration from
	<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
			combined datastore schema used in all configuration datastores except
			that YANG nodes supported in a configuration datastore MAY be omitted
			from <operational> if a server is not able 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 as being "in use" by the
	system is dependent on both the schema definition and the device		system is dependent on both the schema definition and the device
	implementation. Generally, functionality that is enabled and		implementation. Generally, functionality that is enabled and
	operational on the system would be considered as being "in use".		operational on the system would be considered as being "in use".
	Conversely, functionality that is neither enabled nor operational on		Conversely, functionality that is neither enabled nor operational on
End of changes. 14 change blocks.
	19 lines changed or deleted		33 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/