draft-ietf-netmod-revised-datastores-08.txt		draft-ietf-netmod-revised-datastores-09.txt
	skipping to change at page 1, line 15 ¶		skipping to change at page 1, line 15 ¶
	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 23, 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
	December 20, 2017		December 20, 2017
	Network Management Datastore Architecture		Network Management Datastore Architecture
	draft-ietf-netmod-revised-datastores-08		draft-ietf-netmod-revised-datastores-09
	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. This document updates RFC 7950.		supported in the initial model. This document updates RFC 7950.
	skipping to change at page 8, line 34 ¶		skipping to change at page 8, line 34 ¶
	+-----------+		+-----------+
	|		|
	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
	Note that this diagram simplifies the model: read-only (ro) and read-		Note that this diagram simplifies the model: read-only (ro) and read-
	write (rw) is to be understood at a conceptual level. In NETCONF,		write (rw) is to be understood at a conceptual level. In NETCONF,
	for example, support for <candidate> and <startup> is optional and		for example, support for <candidate> and <startup> is optional and
	<running> does not have to be writable. Furthermore, <startup> can		<running> does not have to be writable. Furthermore, <startup> can
	only be modified by copying <running> to <startup> in the		only be modified by copying <running> to <startup> in the
	standardized NETCONF datastore editing model. The RESTCONF protocol		standardized NETCONF datastore editing model. The RESTCONF protocol
	does not expose these differences and instead provides only a		does not expose these differences and instead provides only a
	writable unified datastore, which hides whether edits are done		writable unified datastore, which hides whether edits are done
	through <candidate> or by directly modifying <running> or via some		through <candidate> or by directly modifying <running> or via some
	other implementation specific mechanism. RESTCONF also hides how		other implementation specific mechanism. RESTCONF also hides how
	skipping to change at page 10, line 16 ¶		skipping to change at page 10, line 16 ¶
	| <candidate> | | <startup> |		| <candidate> | | <startup> |
	| (ct, rw) |<---+ +--->| (ct, rw) |		| (ct, rw) |<---+ +--->| (ct, rw) |
	+-------------+ | | +-----------+		+-------------+ | | +-----------+
	| | | |		| | | |
	| +-----------+ |		| +-----------+ |
	+-------->| <running> |<--------+		+-------->| <running> |<--------+
	| (ct, rw) |		| (ct, rw) |
	+-----------+		+-----------+
	|		|
	| // configuration transformations,		| // configuration transformations,
	| // e.g., removal of "inactive"		| // e.g., removal of nodes marked as
	| // nodes, expansion of templates		| // "inactive", expansion of
			| // templates
	v		v
	+------------+		+------------+
	| <intended> | // subject to validation		| <intended> | // subject to validation
	| (ct, ro) |		| (ct, ro) |
	+------------+		+------------+
	| // changes applied, subject to		| // changes applied, subject to
	| // local factors, e.g., missing		| // local factors, e.g., missing
	| // resources, delays		| // resources, delays
	|		|
	dynamic | +-------- learned configuration		dynamic | +-------- learned configuration
	skipping to change at page 10, line 41 ¶		skipping to change at page 10, line 42 ¶
	v v v		v v v
	+---------------+		+---------------+
	| <operational> | <-- system state		| <operational> | <-- system state
	| (ct + cf, ro) |		| (ct + cf, ro) |
	+---------------+		+---------------+
	ct = config true; cf = config false		ct = config true; cf = config false
	rw = read-write; ro = read-only		rw = read-write; ro = read-only
	boxes denote named datastores		boxes denote named datastores
			Figure 2
	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. If a module does not		umbrella description of these datastores. If a module does not
	contain any configuration data nodes and it is not needed to satisfy		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		any imports, then it MAY be omitted from the datastore schema for the
	conventional configuration datastores. The set of datastores		conventional configuration datastores. The set of datastores
	include:		include:
	skipping to change at page 18, line 19 ¶		skipping to change at page 18, line 19 ¶
	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@2017-08-17.yang"		<CODE BEGINS> file "ietf-datastores@2017-12-20.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 19, line 19 ¶		skipping to change at page 19, line 19 ¶
	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).		(http://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 XXXX
	(http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself		(http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself
	for full legal notices.";		for full legal notices.";
	revision 2017-08-17 {		revision 2017-12-20 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	"RFC XXXX: Network Management Datastore Architecture";		"RFC XXXX: Network Management Datastore Architecture";
	}		}
	/*		/*
	* Identities		* Identities
	*/		*/
	skipping to change at page 20, line 44 ¶		skipping to change at page 20, line 44 ¶
	base datastore;		base datastore;
	}		}
	description		description
	"A datastore identity reference.";		"A datastore identity reference.";
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	<CODE BEGINS> file "ietf-origin@2017-08-17.yang"		<CODE BEGINS> file "ietf-origin@2017-12-20.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 48 ¶		skipping to change at page 21, line 48 ¶
	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).		(http://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 XXXX
	(http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself		(http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself
	for full legal notices.";		for full legal notices.";
	revision 2017-08-17 {		revision 2017-12-20 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	"RFC XXXX: Network Management Datastore Architecture";		"RFC XXXX: Network Management Datastore Architecture";
	}		}
	/*		/*
	* Identities		* Identities
	*/		*/
	skipping to change at page 23, line 43 ¶		skipping to change at page 23, line 43 ¶
	}		}
	/*		/*
	* 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 datastore. It specifies from		data node in the operational state datastore. It specifies
	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
	skipping to change at page 24, line 24 ¶		skipping to change at page 24, line 24 ¶
	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 the		registry [RFC6020]. Following the format in [RFC6020], the following
	following registrations are requested:		registrations are requested:
	name: ietf-datastores		name: ietf-datastores
	namespace: urn:ietf:params:xml:ns:yang:ietf-datastores		namespace: urn:ietf:params:xml:ns:yang:ietf-datastores
	prefix: ds		prefix: ds
	reference: RFC XXXX		reference: RFC XXXX
	name: ietf-origin		name: ietf-origin
	namespace: urn:ietf:params:xml:ns:yang:ietf-origin		namespace: urn:ietf:params:xml:ns:yang:ietf-origin
	prefix: or		prefix: or
	reference: RFC XXXX		reference: RFC XXXX
	skipping to change at page 32, line 9 ¶		skipping to change at page 32, line 9 ¶
	to a default value, a loopback interface is automatically added by		to a default value, a loopback interface is automatically added by
	the system, and the result of the "speed" auto-negotiation. All of		the system, and the result of the "speed" auto-negotiation. All of
	this is reflected in <operational>. Note how the origin metadata		this is reflected in <operational>. Note how the origin metadata
	attribute for several "config true" data nodes is inherited from		attribute for several "config true" data nodes is inherited from
	their parent data nodes.		their parent data nodes.
	<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:dynamic">bar</hostname>		<hostname or:origin="or:learned">bar</hostname>
	<interface or:origin="or:intended">		<interface or:origin="or:intended">
	<name>eth0</name>		<name>eth0</name>
	<auto-negotiation>		<auto-negotiation>
	<enabled or:origin="or:default">true</enabled>		<enabled or:origin="or:default">true</enabled>
	<speed>1000</speed>		<speed>1000</speed>
	</auto-negotiation>		</auto-negotiation>
	<speed>100</speed>		<speed>100</speed>
	<address>		<address>
	<ip>2001:db8::10</ip>		<ip>2001:db8::10</ip>
	<prefix-length>64</prefix-length>		<prefix-length>64</prefix-length>
	</address>		</address>
	<address or:origin="or:dynamic">		<address or:origin="or:learned">
	<ip>2001:db8::1:100</ip>		<ip>2001:db8::1:100</ip>
	<prefix-length>64</prefix-length>		<prefix-length>64</prefix-length>
	</address>		</address>
	</interface>		</interface>
	<interface or:origin="or:system">		<interface or:origin="or:system">
	<name>lo0</name>		<name>lo0</name>
	<address>		<address>
	<ip>::1</ip>		<ip>::1</ip>
	<prefix-length>128</prefix-length>		<prefix-length>128</prefix-length>
End of changes. 12 change blocks.
	13 lines changed or deleted		18 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/