draft-ietf-netmod-revised-datastores-07.txt		draft-ietf-netmod-revised-datastores-08.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: June 2, 2018 P. Shafer		Expires: June 23, 2018 P. Shafer
	K. Watsen		K. Watsen
	Juniper Networks		Juniper Networks
	R. Wilton		R. Wilton
	Cisco Systems		Cisco Systems
	November 29, 2017		December 20, 2017
	Network Management Datastore Architecture		Network Management Datastore Architecture
	draft-ietf-netmod-revised-datastores-07		draft-ietf-netmod-revised-datastores-08
	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. This document updates RFC 7950.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 June 2, 2018.		This Internet-Draft will expire on June 23, 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 23 ¶		skipping to change at page 2, line 23 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 7		4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 7
	4.1. Original Model of Datastores . . . . . . . . . . . . . . 8		4.1. Original Model of Datastores . . . . . . . . . . . . . . 8
	5. Architectural Model of Datastores . . . . . . . . . . . . . . 9		5. Architectural Model of Datastores . . . . . . . . . . . . . . 9
	5.1. Conventional Configuration Datastores . . . . . . . . . . 10		5.1. Conventional Configuration Datastores . . . . . . . . . . 10
	5.1.1. The Startup Configuration Datastore (<startup>) . . . 11		5.1.1. The Startup Configuration Datastore (<startup>) . . . 11
	5.1.2. The Candidate Configuration Datastore (<candidate>) . 11		5.1.2. The Candidate Configuration Datastore (<candidate>) . 11
	5.1.3. The Running Configuration Datastore (<running>) . . . 11		5.1.3. The Running Configuration Datastore (<running>) . . . 12
	5.1.4. The Intended Configuration Datastore (<intended>) . . 12		5.1.4. The Intended Configuration Datastore (<intended>) . . 12
	5.2. Dynamic Configuration Datastores . . . . . . . . . . . . 13		5.2. Dynamic Configuration Datastores . . . . . . . . . . . . 13
	5.3. The Operational State Datastore (<operational>) . . . . . 13		5.3. The Operational State Datastore (<operational>) . . . . . 13
	5.3.1. Remnant Configuration . . . . . . . . . . . . . . . . 14		5.3.1. Remnant Configuration . . . . . . . . . . . . . . . . 14
	5.3.2. Missing Resources . . . . . . . . . . . . . . . . . . 14		5.3.2. Missing Resources . . . . . . . . . . . . . . . . . . 15
	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 . . . . . . . . . . . . . . . . . . . . 17
	6.1. XPath Context . . . . . . . . . . . . . . . . . . . . . . 16		6.1. XPath Context . . . . . . . . . . . . . . . . . . . . . . 17
	6.2. Invocation of Actions and RPCs . . . . . . . . . . . . . 17		6.2. Invocation of Actions and RPCs . . . . . . . . . . . . . 18
	7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 18		7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 18
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
	8.1. Updates to the IETF XML Registry . . . . . . . . . . . . 23		8.1. Updates to the IETF XML Registry . . . . . . . . . . . . 24
	8.2. Updates to the YANG Module Names Registry . . . . . . . . 24		8.2. Updates to the YANG Module Names Registry . . . . . . . . 24
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 24		9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
	11.1. Normative References . . . . . . . . . . . . . . . . . . 25		11.1. Normative References . . . . . . . . . . . . . . . . . . 25
	11.2. Informative References . . . . . . . . . . . . . . . . . 26		11.2. Informative References . . . . . . . . . . . . . . . . . 26
	Appendix A. Guidelines for Defining Datastores . . . . . . . . . 27		Appendix A. Guidelines for Defining Datastores . . . . . . . . . 27
	A.1. Define which YANG modules can be used in the datastore . 27		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 . . . . . . . . . . . 28		A.4. Define which protocols can be used . . . . . . . . . . . 28
	A.5. Define YANG identities for the datastore . . . . . . . . 28		A.5. Define YANG identities for the datastore . . . . . . . . 28
	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 . . . . . . . . . . . . . . . . . . . . . 30
	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
	C.2.3. Removing a Peer . . . . . . . . . . . . . . . . . . . 35		C.2.3. Removing a Peer . . . . . . . . . . . . . . . . . . . 35
	C.3. Interface Example . . . . . . . . . . . . . . . . . . . . 36		C.3. Interface Example . . . . . . . . . . . . . . . . . . . . 36
	C.3.1. Pre-provisioned Interfaces . . . . . . . . . . . . . 36		C.3.1. Pre-provisioned Interfaces . . . . . . . . . . . . . 36
	C.3.2. System-provided Interface . . . . . . . . . . . . . . 37		C.3.2. System-provided Interface . . . . . . . . . . . . . . 37
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
	1. Introduction		1. Introduction
	skipping to change at page 10, line 46 ¶		skipping to change at page 10, line 46 ¶
	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 datastore schema, allowing		datastores that share exactly the same datastore schema, allowing
	data to be copied between them. The term is meant as a generic		data to be copied between them. The term is meant as a generic
	umbrella description of these datastores. The set of datastores		umbrella description of these datastores. If a module does not
			contain any configuration data nodes and it is not needed to satisfy
			any imports, then it MAY be omitted from the datastore schema for the
			conventional configuration datastores. The set of datastores
	include:		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
	skipping to change at page 13, line 16 ¶		skipping to change at page 13, line 20 ¶
	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
			from the datastore schema used for conventional configuration
			datastores. If a module does not contain any configuration data
			nodes and it is not needed to satisfy any imports, then it MAY be
			omitted from the datastore schema for the dynamic configuration
			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 the
	operational state only had "config false" nodes. The reason for		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 except
	that YANG nodes supported in a configuration datastore MAY be omitted		that configuration data nodes supported in a configuration datastore
	from <operational> if a server is not able to accurately report them.		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".
	skipping to change at page 25, line 33 ¶		skipping to change at page 25, line 43 ¶
	Juergen Schoenwaelder was partly funded by Flamingo, a Network of		Juergen Schoenwaelder was partly funded by Flamingo, a Network of
	Excellence project (ICT-318488) supported by the European Commission		Excellence project (ICT-318488) supported by the European Commission
	under its Seventh Framework Programme.		under its Seventh Framework Programme.
	11. References		11. References
	11.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,		Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
	DOI 10.17487/RFC2119, March 1997, <https://www.rfc-		RFC2119, March 1997, <https://www.rfc-editor.org/info/
	editor.org/info/rfc2119>.		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,		RFC 7950, DOI 10.17487/RFC7950, August 2016,
	<https://www.rfc-editor.org/info/rfc7950>.		<https://www.rfc-editor.org/info/rfc7950>.
	[RFC7952] Lhotka, L., "Defining and Using Metadata with YANG",		[RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", RFC
	RFC 7952, DOI 10.17487/RFC7952, August 2016,		7952, DOI 10.17487/RFC7952, August 2016, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc7952>.		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 RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	11.2. Informative References		11.2. Informative References
	skipping to change at page 27, line 9 ¶		skipping to change at page 27, line 18 ¶
	editor.org/info/rfc6020>.		editor.org/info/rfc6020>.
	[RFC6244] Shafer, P., "An Architecture for Network Management Using		[RFC6244] Shafer, P., "An Architecture for Network Management Using
	NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244, June		NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244, June
	2011, <https://www.rfc-editor.org/info/rfc6244>.		2011, <https://www.rfc-editor.org/info/rfc6244>.
	[RFC7223] Bjorklund, M., "A YANG Data Model for Interface		[RFC7223] Bjorklund, M., "A YANG Data Model for Interface
	Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,		Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
	<https://www.rfc-editor.org/info/rfc7223>.		<https://www.rfc-editor.org/info/rfc7223>.
	[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management",		[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", RFC
	RFC 7277, DOI 10.17487/RFC7277, June 2014,		7277, DOI 10.17487/RFC7277, June 2014, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc7277>.		editor.org/info/rfc7277>.
	Appendix A. Guidelines for Defining Datastores		Appendix A. Guidelines for Defining Datastores
	The definition of a new datastore in this architecture should be		The definition of a new datastore in this architecture should be
	provided in a document (e.g., an RFC) purposed to the definition of		provided in a document (e.g., an RFC) purposed to the definition of
	the datastore. When it makes sense, more than one datastore may be		the datastore. When it makes sense, more than one datastore may be
	defined in the same document (e.g., when the datastores are logically		defined in the same document (e.g., when the datastores are logically
	connected). Each datastore's definition should address the points		connected). Each datastore's definition should address the points
	specified in the sections below.		specified in the sections below.
End of changes. 18 change blocks.
	26 lines changed or deleted		37 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/