< draft-ietf-netmod-nmda-diff-00.txt		draft-ietf-netmod-nmda-diff-01.txt >
	Network Working Group A. Clemm		Network Working Group A. Clemm
	Internet-Draft Y. Qu		Internet-Draft Y. Qu
	Intended status: Standards Track Huawei		Intended status: Standards Track Futurewei
	Expires: April 24, 2019 J. Tantsura		Expires: November 24, 2019 J. Tantsura
	Nuage Networks		Apstra
	A. Bierman		A. Bierman
	YumaWorks		YumaWorks
	October 21, 2018		May 23, 2019
	Comparison of NMDA datastores		Comparison of NMDA datastores
	draft-ietf-netmod-nmda-diff-00		draft-ietf-netmod-nmda-diff-01
	Abstract		Abstract
	This document defines an RPC operation to compare management		This document defines an RPC operation to compare management
	datastores that comply with the NMDA architecture.		datastores that comply with the NMDA architecture.
	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.
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 24, 2019.		This Internet-Draft will expire on November 24, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	(https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3		3. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3
	4. Data Model Overview . . . . . . . . . . . . . . . . . . . . . 4		4. Data Model Overview . . . . . . . . . . . . . . . . . . . . . 4
	5. YANG Data Model . . . . . . . . . . . . . . . . . . . . . . . 5		5. YANG Data Model . . . . . . . . . . . . . . . . . . . . . . . 5
	6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8		6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 10		7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 11
	8. Possible Future Extensions . . . . . . . . . . . . . . . . . 10		8. Possible Future Extensions . . . . . . . . . . . . . . . . . 11
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	9.1. Updates to the IETF XML Registry . . . . . . . . . . . . 11		9.1. Updates to the IETF XML Registry . . . . . . . . . . . . 12
	9.2. Updates to the YANG Module Names Registry . . . . . . . . 11		9.2. Updates to the YANG Module Names Registry . . . . . . . . 12
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 12		10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	12.1. Normative References . . . . . . . . . . . . . . . . . . 12		12.1. Normative References . . . . . . . . . . . . . . . . . . 13
	12.2. Informative References . . . . . . . . . . . . . . . . . 13		12.2. Informative References . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	The revised Network Management Datastore Architecture (NMDA)		The revised Network Management Datastore Architecture (NMDA)
	[RFC8342] introduces a set of new datastores that each hold YANG-		[RFC8342] introduces a set of new datastores that each hold YANG-
	defined data [RFC7950] and represent a different "viewpoint" on the		defined data [RFC7950] and represent a different "viewpoint" on the
	data that is maintained by a server. New YANG datastores that are		data that is maintained by a server. New YANG datastores that are
	introduced include <intended>, which contains validated configuration		introduced include <intended>, which contains validated configuration
	data that a client application intends to be in effect, and		data that a client application intends to be in effect, and
	<operational>, which contains at least conceptually operational state		<operational>, which contains at least conceptually operational state
	skipping to change at page 4, line 48 ¶		skipping to change at page 4, line 48 ¶
	applied to exclude data from the comparison that does not pertain		applied to exclude data from the comparison that does not pertain
	to both datastores: if the same schema node is not present in both		to both datastores: if the same schema node is not present in both
	datastores, then all instances of that schema node and all its		datastores, then all instances of that schema node and all its
	descendants are excluded from the comparison. This allows client		descendants are excluded from the comparison. This allows client
	applications to focus on the differences that constitute true		applications to focus on the differences that constitute true
	mismatches of instance data without needing to specify more		mismatches of instance data without needing to specify more
	complex filter constructs.		complex filter constructs.
	The operation provides the following output parameter:		The operation provides the following output parameter:
	o differences: This parameter contains the list of differences,		o differences: This parameter contains the list of differences.
	encoded per RFC8072, i.e. specifying which patches would need to		Those differences are encoded per YANG-Patch data model defined in
	be applied to the source to produce the target. When the target		RFC8072. The YANG-Patch data model is augmented to indicate the
	datastore is <operational>, "origin" metadata is included as part		value of source datastore nodes in addition to the patch itself
	of the patch. Including origin metadata can help explain the		that would need to be applied to the source to produce the target.
	cause of a difference, for example when a data node is part of
	<intended> but the origin of the same data node in <operational>		When the target datastore is <operational>, "origin" metadata is
	is reported as "system".		included as part of the patch. Including origin metadata can help
			explain the cause of a difference, for example when a data node is
			part of <intended> but the origin of the same data node in
			<operational> is reported as "system".
	The data model is defined in the ietf-nmda-compare YANG module. Its		The data model is defined in the ietf-nmda-compare YANG module. Its
	structure is shown in the following figure. The notation syntax		structure is shown in the following figure. The notation syntax
	follows [RFC8340].		follows [RFC8340].
	module: ietf-nmda-compare		module: ietf-nmda-compare
			rpcs:
	rpcs:		+---x compare
	+---x compare		+---w input
	+---w input		| +---w source identityref
	| +---w source identityref		| +---w target identityref
	| +---w target identityref		| +---w all? empty
	| +---w all? empty		| +---w (filter-spec)?
	| +---w (filter-spec)?		| +--:(subtree-filter)
	| +--:(subtree-filter)		| | +---w subtree-filter?
	| | +---w subtree-filter? <anydata>		| +--:(xpath-filter)
	| +--:(xpath-filter)		| +---w xpath-filter? yang:xpath1.0 {nc:xpath}?
	| +---w xpath-filter? yang:xpath1.0 {nc:xpath}?		+--ro output
	+--ro output		+--ro (compare-response)?
	+--ro (compare-response)?		+--:(no-matches)
	+--:(no-matches)		| +--ro no-matches? empty
	| +--ro no-matches? empty		+--:(differences)
	+--:(differences)		+--ro differences
	+--ro differences		+--ro yang-patch
	+--ro yang-patch		+--ro patch-id string
	+--ro patch-id string		+--ro comment? string
	+--ro comment? string		+--ro edit* [edit-id]
	+--ro edit* [edit-id]		+--ro edit-id string
	+--ro edit-id string		+--ro operation enumeration
	+--ro operation enumeration		+--ro target target-resource-offset
	+--ro target target-resource-offset		+--ro point? target-resource-offset
	+--ro point? target-resource-offset		+--ro where? enumeration
	+--ro where? enumeration		+--ro value?
	+--ro value? <anydata>		+--ro source-value?
	Structure of ietf-nmda-compare		Structure of ietf-nmda-compare
	5. YANG Data Model		5. YANG Data Model
	<CODE BEGINS> file "ietf-nmda-compare@2018-10-21.yang"		<CODE BEGINS> file "ietf-nmda-compare@2019-05-23.yang"
	module ietf-nmda-compare {		module ietf-nmda-compare {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-nmda-compare";		namespace "urn:ietf:params:xml:ns:yang:ietf-nmda-compare";
	prefix cp;		prefix cp;
	import ietf-yang-types {		import ietf-yang-types {
	prefix yang;		prefix yang;
	}		}
	skipping to change at page 6, line 30 ¶		skipping to change at page 6, line 30 ¶
	organization "IETF";		organization "IETF";
	contact		contact
	"WG Web: <http://tools.ietf.org/wg/netconf/>		"WG Web: <http://tools.ietf.org/wg/netconf/>
	WG List: <mailto:netconf@ietf.org>		WG List: <mailto:netconf@ietf.org>
	Author: Alexander Clemm		Author: Alexander Clemm
	<mailto:ludwig@clemm.org>		<mailto:ludwig@clemm.org>
	Author: Yingzhen Qu		Author: Yingzhen Qu
	<mailto:yingzhen.qu@huawei.com>		<mailto:yqu@futurewei.com>
	Author: Jeff Tantsura		Author: Jeff Tantsura
	<mailto:jefftant.ietf@gmail.com>		<mailto:jefftant.ietf@gmail.com>
	Author: Andy Bierman		Author: Andy Bierman
	<mailto:andy@yumaworks.com>";		<mailto:andy@yumaworks.com>";
	description		description
	"The YANG data model defines a new operation, <compare>, that		"The YANG data model defines a new operation, <compare>, that
	can be used to compare NMDA datastores.";		can be used to compare NMDA datastores.";
	revision 2018-10-21 {		revision 2019-05-23 {
	description		description
	"Initial revision";		"Initial revision";
	reference		reference
	"RFC XXXX: Comparison of NMDA datastores";		"RFC XXXX: Comparison of NMDA datastores";
	}		}
	/* RPC */		/* RPC */
	rpc compare {		rpc compare {
	description		description
	"NMDA compare operation.";		"NMDA compare operation.";
	skipping to change at page 7, line 23 ¶		skipping to change at page 7, line 23 ¶
	}		}
	leaf target {		leaf target {
	type identityref {		type identityref {
	base ds:datastore;		base ds:datastore;
	}		}
	mandatory true;		mandatory true;
	description		description
	"The target datastore to be compared.";		"The target datastore to be compared.";
	}		}
	leaf all {		leaf all {
	type empty;		type empty;
	description		description
	"When this leaf is provided, all data nodes are compared,		"When this leaf is provided, all data nodes are compared,
	whether their schema node pertains to both datastores or		whether their schema node pertains to both datastores or
	not. When this leaf is omitted, a prefiltering step is		not. When this leaf is omitted, a prefiltering step is
	automatically applied that excludes data nodes from the		automatically applied that excludes data nodes from the
	comparison that can occur in only one datastore but not		comparison that can occur in only one datastore but not
	the other. Specifically, if one of the datastores		the other. Specifically, if one of the datastores
	(source or target) contains only configuration data and		(source or target) contains only configuration data and
	the other datastore is <operational>, data nodes for		the other datastore is <operational>, data nodes for
	which config is false are excluded from the comparison.";		which config is false are excluded from the comparison.";
	skipping to change at page 8, line 10 ¶		skipping to change at page 8, line 10 ¶
	description		description
	"This parameter contains an XPath expression		"This parameter contains an XPath expression
	identifying the portions of the target		identifying the portions of the target
	datastore to retrieve.";		datastore to retrieve.";
	}		}
	}		}
	}		}
	output {		output {
	choice compare-response {		choice compare-response {
			description
			"Comparison results.";
	leaf no-matches {		leaf no-matches {
	type empty;		type empty;
	description		description
	"This leaf indicates that the filter did not match anything		"This leaf indicates that the filter did not match
	and nothing was compared.";		anything and nothing was compared.";
	}		}
	container differences {		container differences {
	uses ypatch:yang-patch;
	description		description
	"The list of differences, encoded per RFC8072.";		"The list of differences, encoded per RFC8072 with an
			augmentation to include source values where
			applicable.";
			uses ypatch:yang-patch {
			augment "yang-patch/edit" {
			description
			"Provide the value of the source of the patch,
			respectively of the comparison, in addition to
			the target value, where applicable.";
			anydata source-value {
			when "../operation = 'delete'"
			+ "or ../operation = 'merge'"
			+ "or ../operation = 'move'"
			+ "or ../operation = 'replace'"
			+ "or ../operation = 'remove'";
			description
			"The anydata 'value' is only used for 'delete',
			'move', 'merge', 'replace', and 'remove'
			operations.";
			}
			}
			}
	}		}
	description
	"Comparision results.";
	}		}
	}		}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	6. Example		6. Example
	The following example compares the difference between <operational>		The following example compares the difference between <operational>
	and <intended> for object "explicit-router-id", as defined in data		and <intended> for object "explicit-router-id", as defined in data
	module [I-D.ietf-ospf-yang].		module [I-D.ietf-ospf-yang].
	RPC request:		RPC request:
	<rpc message-id="101"		<rpc message-id="101"
	xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">		xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
	skipping to change at page 12, line 21 ¶		skipping to change at page 13, line 21 ¶
	ways. For one, they can implement NACM in order to require proper		ways. For one, they can implement NACM in order to require proper
	authorization for requests to be made. Second, server		authorization for requests to be made. Second, server
	implementations can limit the number of requests that they serve in		implementations can limit the number of requests that they serve in
	any one time interval, potentially rejecting requests made at a		any one time interval, potentially rejecting requests made at a
	higher frequency than the implementation can reasonably sustain.		higher frequency than the implementation can reasonably sustain.
	11. Acknowledgments		11. Acknowledgments
	We thank Rob Wilton, Martin Bjorklund, Mahesh Jethanandani, Lou		We thank Rob Wilton, Martin Bjorklund, Mahesh Jethanandani, Lou
	Berger, Kent Watsen, Phil Shafer, Ladislav Lhotka for valuable		Berger, Kent Watsen, Phil Shafer, Ladislav Lhotka for valuable
	feedback and suggestions on an earlier revision of this document.		feedback and suggestions.
	12. References		12. References
	12.1. Normative References		12.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/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 13, line 23 ¶		skipping to change at page 14, line 23 ¶
	[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,		[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
	and R. Wilton, "Network Management Datastore Architecture		and R. Wilton, "Network Management Datastore Architecture
	(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,		(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
	<https://www.rfc-editor.org/info/rfc8342>.		<https://www.rfc-editor.org/info/rfc8342>.
	12.2. Informative References		12.2. Informative References
	[I-D.ietf-ospf-yang]		[I-D.ietf-ospf-yang]
	Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem,		Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem,
	"YANG Data Model for OSPF Protocol", draft-ietf-ospf-		"YANG Data Model for OSPF Protocol", draft-ietf-ospf-
	yang-17 (work in progress), September 2018.		yang-21 (work in progress), January 2019.
	Authors' Addresses		Authors' Addresses
	Alexander Clemm		Alexander Clemm
	Huawei		Futurewei
	2330 Central Expressway		2330 Central Expressway
	Santa Clara, CA 95050		Santa Clara, CA 95050
	USA		USA
	Email: ludwig@clemm.org		Email: ludwig@clemm.org
	Yingzhen Qu		Yingzhen Qu
	Huawei		Futurewei
	2330 Central Expressway		2330 Central Expressway
	Santa Clara, CA 95050		Santa Clara, CA 95050
	USA		USA
	Email: yingzhen.qu@huawei.com		Email: yqu@futurewei.com
	Jeff Tantsura		Jeff Tantsura
	Nuage Networks		Apstra
	Email: jefftant.ietf@gmail.com		Email: jefftant.ietf@gmail.com
	Andy Bierman		Andy Bierman
	YumaWorks		YumaWorks
	Email: andy@yumaworks.com		Email: andy@yumaworks.com
End of changes. 24 change blocks.
	72 lines changed or deleted		94 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/