< draft-ietf-netmod-nmda-diff-01.txt		draft-ietf-netmod-nmda-diff-02.txt >
	Network Working Group A. Clemm		Network Working Group A. Clemm
	Internet-Draft Y. Qu		Internet-Draft Y. Qu
	Intended status: Standards Track Futurewei		Intended status: Standards Track Futurewei
	Expires: November 24, 2019 J. Tantsura		Expires: January 9, 2020 J. Tantsura
	Apstra		Apstra
	A. Bierman		A. Bierman
	YumaWorks		YumaWorks
	May 23, 2019		July 8, 2019
	Comparison of NMDA datastores		Comparison of NMDA datastores
	draft-ietf-netmod-nmda-diff-01		draft-ietf-netmod-nmda-diff-02
	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 November 24, 2019.		This Internet-Draft will expire on January 9, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 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
	skipping to change at page 2, line 15 ¶		skipping to change at page 2, line 15 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9		6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 11		7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8. Possible Future Extensions . . . . . . . . . . . . . . . . . 11		8. Possible Future Extensions . . . . . . . . . . . . . . . . . 13
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	9.1. Updates to the IETF XML Registry . . . . . . . . . . . . 12		9.1. Updates to the IETF XML Registry . . . . . . . . . . . . 13
	9.2. Updates to the YANG Module Names Registry . . . . . . . . 12		9.2. Updates to the YANG Module Names Registry . . . . . . . . 14
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 13		10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
	12.1. Normative References . . . . . . . . . . . . . . . . . . 13		12.1. Normative References . . . . . . . . . . . . . . . . . . 15
	12.2. Informative References . . . . . . . . . . . . . . . . . 14		12.2. Informative References . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	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 5, line 7 ¶		skipping to change at page 5, line 7 ¶
	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.
	Those differences are encoded per YANG-Patch data model defined in		Those differences are encoded per YANG-Patch data model defined in
	RFC8072. The YANG-Patch data model is augmented to indicate the		RFC8072. The YANG-Patch data model is augmented to indicate the
	value of source datastore nodes in addition to the patch itself		value of source datastore nodes in addition to the patch itself
	that would need to be applied to the source to produce the target.		that would need to be applied to the source to produce the target.
	When the target datastore is <operational>, "origin" metadata is		When the target datastore is <operational>, "origin" metadata is
	included as part of the patch. Including origin metadata can help		included as part of the patch. Including origin metadata can help
	explain the cause of a difference, for example when a data node is		in some cases explain the cause of a difference, for example when
	part of <intended> but the origin of the same data node in		a data node is part of <intended> but the origin of the same data
	<operational> is reported as "system".		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
	skipping to change at page 5, line 49 ¶		skipping to change at page 5, line 49 ¶
	+--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?
	+--ro source-value?		+--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@2019-05-23.yang"		<CODE BEGINS> file "ietf-nmda-compare@2019-07-08.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;
	}		}
	import ietf-datastores {		import ietf-datastores {
	prefix ds;		prefix ds;
	}		}
	import ietf-yang-patch {		import ietf-yang-patch {
	prefix ypatch;		prefix ypatch;
	}		}
	import ietf-netconf {		import ietf-netconf {
	prefix nc;		prefix nc;
	}		}
	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:yqu@futurewei.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 2019-05-23 {		revision 2019-07-08 {
	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.";
	input {		input {
	leaf source {		leaf source {
	type identityref {		type identityref {
	base ds:datastore;		base ds:datastore;
	}		}
	mandatory true;		mandatory true;
	description		description
	"The source datastore to be compared.";		"The source datastore to be compared.";
	}		}
	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.";
	}		}
	choice filter-spec {		choice filter-spec {
	description		description
	"Identifies the portions of the datastores to be		"Identifies the portions of the datastores to be
	compared.";		compared.";
	anydata subtree-filter {		anydata subtree-filter {
	description		description
	"This parameter identifies the portions of the		"This parameter identifies the portions of the
	target datastore to retrieve.";		target datastore to retrieve.";
	reference "RFC 6241, Section 6.";		reference "RFC 6241, Section 6.";
	}		}
	leaf xpath-filter {		leaf xpath-filter {
	if-feature nc:xpath;		if-feature nc:xpath;
	type yang:xpath1.0;		type yang:xpath1.0;
	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 {
			choice compare-response {
			description
			"Comparison results.";
			leaf no-matches {
			type empty;
			description
			"This leaf indicates that the filter did not match
			anything and nothing was compared.";
			}
			container differences {
			description
			"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.";
			}
			}
			}
			}
			}
			}
			}
			}
			<CODE ENDS>
	}
	}
	}
	output {
	choice compare-response {
	description
	"Comparison results.";
	leaf no-matches {
	type empty;
	description
	"This leaf indicates that the filter did not match
	anything and nothing was compared.";
	}
	container differences {
	description
	"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.";
	}
	}
	}
	}
	}
	}
	}
	}
	<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 a subtree under "ospf". The subtree contains
	module [I-D.ietf-ospf-yang].		objects that are defined in a YANG data model for the management of
			OSPF defined in [I-D.ietf-ospf-yang]. The excerpt of the data model
			whose instantiation is basis of the comparison is as follows:
	RPC request:		container ospf {
			leaf enable {
			type boolean;
			}
			leaf explicit-router-id {
			type rt-types:router-id;
			}
			leaf preference {
			type uint8;
			}
			}
	<rpc message-id="101"		The contents of <intended> and <operational> datastores:
	xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
	<compare xmlns="urn:ietf:params:xml:ns:yang:ietf-nmda-compare"
	xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
	<source>ds:operational</source>
	<target>ds:intended</target>
	<xpath-filter
	xmlns:rt="urn:ietf:params:xml:ns:yang:ietf-routing"
	xmlns:ospf="urn:ietf:params:xml:ns:yang:ietf-ospf">\
	/rt:routing/rt:control-plane-protocols\
	/rt:control-plane-protocol/ospf:ospf\
	</xpath-filter>
	</compare>
	</rpc>
	RPC reply, when a difference is detected:		<ospf xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
			or:origin="or:intended">
			<enable>true</enable>
			<explicit-router-id>2.2.2.2</explicit-router-id>
			</ospf>
	<rpc-reply		<ospf xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
	xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"		or:origin="or:operational">
	message-id="101">		<enable>true</enable>
	<differences		<explicit-router-id>1.1.1.1</explicit-router-id>
	xmlns="urn:ietf:params:xml:ns:yang:ietf-nmda-compare"		<preference>200</preference>
	xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">		</ospf>
	<yang-patch>
	<patch-id>ospf router-id</patch-id>
	<comment>diff between operational and intended</comment>
	<edit>
	<edit-id>1</edit-id>
	<operation>replace</operation>
	<target>/ietf-ospf:explicit-router-id</target>
	<value>
	<ospf:explicit-router-id
	or:origin="or:system">1.1.1.1<explicit-router-id>
	</value>
	</edit>
	</yang-patch>
	</differences>
	</rpc-reply>
	RPC reply when no difference is detected:		<operational> contains one object that was not contained in
			<intended>, "preference". Another object, "explicit-router-id", has
			differences in values. A third object, "enable", is the same in both
			cases.
	<rpc-reply		RPC request to compare <operational< (source of the comparison) with
	xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"		<intended>(target of the comparison):
	message-id="101">
	<differences		<rpc message-id="101"
	xmlns="urn:ietf:params:xml:ns:yang:ietf-nmda-compare"/>		xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
	</rpc-reply>		<compare xmlns="urn:ietf:params:xml:ns:yang:ietf-nmda-compare"
			xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
			<source>ds:operational</source>
			<target>ds:intended</target>
			<xpath-filter
			xmlns:rt="urn:ietf:params:xml:ns:yang:ietf-routing"
			xmlns:ospf="urn:ietf:params:xml:ns:yang:ietf-ospf">\
			/rt:routing/rt:control-plane-protocols\
			/rt:control-plane-protocol/ospf:ospf\
			</xpath-filter>
			</compare>
			</rpc>
			RPC reply, when a difference is detected:
			<rpc-reply
			xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
			message-id="101">
			<differences
			xmlns="urn:ietf:params:xml:ns:yang:ietf-nmda-compare"
			xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
			<yang-patch>
			<patch-id>ospf router-id</patch-id>
			<comment>diff between operational and intended</comment>
			<edit>
			<edit-id>1</edit-id>
			<operation>replace</operation>
			<target>/ietf-ospf:explicit-router-id</target>
			<value>
			<ospf:explicit-router-id
			or:origin="or:system">1.1.1.1<explicit-router-id>
			</value>
			<source-value>
			<ospf:explicit-router-id
			or:origin="or:intended">2.2.2.2<explicit-router-id>
			</source-value>
			<edit-id>2</edit-id>
			<operation>create</operation>
			<target>/ietf-ospf:preference</target>
			<value>
			<ospf:preference
			or:origin="or:system">200<preference>
			</value>
			</edit>
			</yang-patch>
			</differences>
			</rpc-reply>
	The same request in RESTCONF (using JSON format):		The same request in RESTCONF (using JSON format):
	POST /restconf/operations/ietf-nmda-compare:compare HTTP/1.1		POST /restconf/operations/ietf-nmda-compare:compare HTTP/1.1
	Host: example.com		Host: example.com
	Content-Type: application/yang-data+json		Content-Type: application/yang-data+json
	Accept: application/yang-data+json		Accept: application/yang-data+json
	{ "ietf-nmda-compare:input" {		{ "ietf-nmda-compare:input" {
	"source" : "ietf-datastores:operational",		"source" : "ietf-datastores:operational",
	"target" : "ietf-datastores:intended".		"target" : "ietf-datastores:intended".
	"xpath-filter" : \		"xpath-filter" : \
	"/ietf-routing:routing/control-plane-protocols\		"/ietf-routing:routing/control-plane-protocols\
	/control-plane-protocol/ietf-ospf:ospf"		/control-plane-protocol/ietf-ospf:ospf"
			}
	}		}
	}
	The same response in RESTCONF (using JSON format):		The same response in RESTCONF (using JSON format):
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Date: Thu, 26 Jan 2017 20:56:30 GMT		Date: Thu, 26 Jan 2019 20:56:30 GMT
	Server: example-server		Server: example-server
	Content-Type: application/yang-data+json		Content-Type: application/yang-data+json
	{ "ietf-nmda-compare:output" : {		{ "ietf-nmda-compare:output" : {
	"differences" : {		"differences" : {
	"ietf-yang-patch:yang-patch" : {		"ietf-yang-patch:yang-patch" : {
	"patch-id" : "ospf router-id",		"patch-id" : "ospf router-id",
	"comment" : "diff between operational and intended",		"comment" : "diff between operational and intended",
	"edit" : [		"edit" : [
	{		{
	"edit-id" : "1",		"edit-id" : "1",
	"operation" : "replace",		"operation" : "replace",
	"target" : "/ietf-ospf:explicit-router-id",		"target" : "/ietf-ospf:explicit-router-id",
	"value" : {		"value" : {
	"ietf-ospf:explicit-router-id" : "1.1.1.1"		"ietf-ospf:explicit-router-id" : "1.1.1.1"
	"@ietf-ospf:explicit-router-id" : {		"@ietf-ospf:explicit-router-id" : {
	"ietf-origin:origin" : "ietf-origin:system"		"ietf-origin:origin" : "ietf-origin:system"
	}		}
	}		"source-value" : {
	}		"ietf-ospf:explicit-router-id" : "2.2.2.2"
	]		"@ietf-ospf:explicit-router-id" : {
	}		"ietf-origin:origin" : "ietf-origin:intended"
	}		}
	}		"edit-id" : "2",
	}		"operation" : "create",
			"target" : "/ietf-ospf:preference",
			"value" : {
			"ietf-ospf:preference" : "200"
			"@ietf-ospf:preference" : {
			"ietf-origin:origin" : "ietf-origin:system"
			}
			}
			]
			}
			}
			}
			}
	7. Open Issues		7. Open Issues
	Currently, origin metadata is included in RPC output per default in		Currently, origin metadata is included in RPC output per default in
	comparisons that involve <operational>. It is conceivable to		comparisons that involve <operational>. It is conceivable to
	introduce an input parameter that controls whether origin metadata		introduce an input parameter that controls whether this origin
	should in fact be included.		metadata should in fact be included.
	Currently the comparison filter is defined using subtree and XPath as		Currently the comparison filter is defined using subtree and XPath as
	in NETCONF[RFC6241]. It is not clear whether there is a requirement		in NETCONF[RFC6241]. It is not clear whether there is a requirement
	to allow for the definition of filters that relate instead to target		to allow for the definition of filters that relate instead to target
	resources per RESTCONF [RFC7950].		resources per RESTCONF [RFC7950].
	8. Possible Future Extensions		8. Possible Future Extensions
	It is conceivable to extend the compare operation with a number of		It is conceivable to extend the compare operation with a number of
	possible additional features in the future.		possible additional features in the future.
	skipping to change at page 13, line 7 ¶		skipping to change at page 14, line 21 ¶
	name: ietf-nmda-compare		name: ietf-nmda-compare
	namespace: urn:ietf:params:xml:ns:yang:ietf-nmda-compare		namespace: urn:ietf:params:xml:ns:yang:ietf-nmda-compare
	prefix: cp		prefix: cp
	reference: RFC XXXX		reference: RFC XXXX
	10. Security Considerations		10. Security Considerations
	Comparing discrepancies between datastores requires a certain amount		The YANG module specified in this document defines a schema for data
	of processing resources at the server. An attacker could attempt to		that is designed to be accessed via network management protocols such
			as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
			is the secure transport layer, and the mandatory-to-implement secure
			transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
			is HTTPS, and the mandatory-to-implement secure transport is TLS
			[RFC8446].
			The NETCONF access control model [RFC8341] provides the means to
			restrict access for particular NETCONF or RESTCONF users to a
			preconfigured subset of all available NETCONF or RESTCONF protocol
			operations and content.
			The RPC operation defined in this YANG module, "compare", may be
			considered sensitive or vulnerable in some network environments. It
			is thus important to control access to this operation. This is the
			sensitivity/vulnerability of RPC operation "compare":
			Comparing datastores for differences requires a certain amount of
			processing resources at the server. An attacker could attempt to
	attack a server by making a high volume of comparison requests.		attack a server by making a high volume of comparison requests.
	Server implementations can guard against such scenarios in several		Server implementations can guard against such scenarios in several
	ways. For one, they can implement NACM in order to require proper		ways. For one, they can implement the NETCONF access control model
	authorization for requests to be made. Second, server		in order to require proper authorization for requests to be made.
	implementations can limit the number of requests that they serve in		Second, server implementations can limit the number of requests that
	any one time interval, potentially rejecting requests made at a		they serve to a client in any one time interval, rejecting requests
	higher frequency than the implementation can reasonably sustain.		made at a 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.		feedback and suggestions.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	skipping to change at page 13, line 41 ¶		skipping to change at page 15, line 29 ¶
	[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,		DOI 10.17487/RFC3688, January 2004,
	<https://www.rfc-editor.org/info/rfc3688>.		<https://www.rfc-editor.org/info/rfc3688>.
	[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>.
			[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
			Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
			<https://www.rfc-editor.org/info/rfc6242>.
	[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>.
	[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>.
	[RFC8072] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Patch		[RFC8072] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Patch
	Media Type", RFC 8072, DOI 10.17487/RFC8072, February		Media Type", RFC 8072, DOI 10.17487/RFC8072, February
	2017, <https://www.rfc-editor.org/info/rfc8072>.		2017, <https://www.rfc-editor.org/info/rfc8072>.
	[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>.
	[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",		[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
	BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,		BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
	<https://www.rfc-editor.org/info/rfc8340>.		<https://www.rfc-editor.org/info/rfc8340>.
			[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
			Access Control Model", STD 91, RFC 8341,
			DOI 10.17487/RFC8341, March 2018,
			<https://www.rfc-editor.org/info/rfc8341>.
	[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>.
			[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
			Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
			<https://www.rfc-editor.org/info/rfc8446>.
	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-21 (work in progress), January 2019.		yang-23 (work in progress), July 2019.
	Authors' Addresses		Authors' Addresses
	Alexander Clemm		Alexander Clemm
	Futurewei		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
End of changes. 38 change blocks.
	243 lines changed or deleted		325 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/