draft-ietf-i2rs-pub-sub-requirements-08.txt		draft-ietf-i2rs-pub-sub-requirements-09.txt
	Interface to the Routing System (i2rs) E. Voit		Interface to the Routing System (i2rs) E. Voit
	Internet-Draft A. Clemm		Internet-Draft A. Clemm
	Intended status: Informational A. Gonzalez Prieto		Intended status: Informational A. Gonzalez Prieto
	Expires: November 14, 2016 Cisco Systems		Expires: November 18, 2016 Cisco Systems
	May 13, 2016		May 17, 2016
	Requirements for Subscription to YANG Datastores		Requirements for Subscription to YANG Datastores
	draft-ietf-i2rs-pub-sub-requirements-08		draft-ietf-i2rs-pub-sub-requirements-09
	Abstract		Abstract
	This document provides requirements for a service that allows client		This document provides requirements for a service that allows client
	applications to subscribe to updates of a YANG datastore. Based on		applications to subscribe to updates of a YANG datastore. Based on
	criteria negotiated as part of a subscription, updates will be pushed		criteria negotiated as part of a subscription, updates will be pushed
	to targeted recipients. Such a capability eliminates the need for		to targeted recipients. Such a capability eliminates the need for
	periodic polling of YANG datastores by applications and fills a		periodic polling of YANG datastores by applications and fills a
	functional gap in existing YANG transports (i.e., Netconf and		functional gap in existing YANG transports (i.e., Netconf and
	Restconf). Such a service can be summarized as a "pub/sub" service		Restconf). Such a service can be summarized as a "pub/sub" service
	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 November 14, 2016.		This Internet-Draft will expire on November 18, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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 9, line 34 ¶		skipping to change at page 9, line 34 ¶
	o Any Filters associated with a subtree subscription		o Any Filters associated with a subtree subscription
	A Subscription Service SHOULD be able to negotiate QoS criteria for a		A Subscription Service SHOULD be able to negotiate QoS criteria for a
	Subscription. Examples of Subscription QoS criteria may include		Subscription. Examples of Subscription QoS criteria may include
	reliability of the Subscription Service, reaction time between a		reliability of the Subscription Service, reaction time between a
	monitored YANG subtree/object change and a corresponding notification		monitored YANG subtree/object change and a corresponding notification
	push, and the Subscription Service's ability to support certain		push, and the Subscription Service's ability to support certain
	levels of object liveliness.		levels of object liveliness.
	In cases where a Subscription Request cannot be fulfilled, the		In cases where a Subscription Request cannot be fulfilled due to
	Subscription Service MUST include in its decline a set of criteria		insufficient platform resources, the Subscription Service SHOULD
	that would have been acceptable when the Subscription Request was		include within its decline hints on criteria that would have been
	made. For example, if periodic updates were requested with too short		acceptable when the Subscription Request was made. For example, if
	update intervals for the specified data set, an alternative		periodic updates were requested with too short update intervals for
	acceptable interval period might be returned from the Publisher. If		the specified data set, an alternative acceptable interval period
	on-change updates were requested with too-aggressive a dampening		might be returned from the Publisher. If on-change updates were
	period, then an acceptable dampening period may be returned, or		requested with too-aggressive a dampening period, then an acceptable
	alternatively an indication that only periodic updates are supported		dampening period may be returned, or alternatively an indication that
	for the requested object(s).		only periodic updates are supported for the requested object(s).
	4.2.3. Update Distribution		4.2.3. Update Distribution
	For "on-change" updates, the Subscription Service MUST only send		For "on-change" updates, the Subscription Service MUST only send
	deltas to the object data for which a change occurred. [Otherwise		deltas to the object data for which a change occurred. [Otherwise
	the subscriber might not know what has actually undergone change.]		the subscriber might not know what has actually undergone change.]
	The updates for each object MUST include an indication whether it was		The updates for each object MUST include an indication whether it was
	removed, added, or changed.		removed, added, or changed.
	When a Subscription Service is not able to send updates per its		When a Subscription Service is not able to send updates per its
	skipping to change at page 11, line 12 ¶		skipping to change at page 11, line 12 ¶
	It MUST be possible for Receivers to associate the update with a		It MUST be possible for Receivers to associate the update with a
	specific Subscription.		specific Subscription.
	In the case of connection-oriented transport, when a transport		In the case of connection-oriented transport, when a transport
	connection drops, the associated Subscription SHOULD be terminated.		connection drops, the associated Subscription SHOULD be terminated.
	It is up the Subscriber to request a new Subscription.		It is up the Subscriber to request a new Subscription.
	4.2.5. Security Requirements		4.2.5. Security Requirements
	Some uses of this Subscription Service will push privacy-sensitive		Some uses of this Subscription Service will push privacy-sensitive
	updates and metadata. Good deployment practices will bind this		updates and metadata. For privacy-sensitive deployments,
	generated information within secure, encrypted transport layer		subscription information MUST be bound within secure, encrypted
	mechanisms. For example if NETCONF is used as transport, then		transport layer mechanisms. For example if NETCONF is used as
	[RFC5539] would be a valid option to secure the transported		transport, then [RFC5539] would be a valid option to secure the
	information. The Subscription Service can also be used with emerging		transported information. The Subscription Service can also be used
	deployment contexts as well. As an example, deployments based on		with emerging privacy-sensitive deployment contexts as well. As an
	[i2rs-usecase] can apply these requirements in conjunction with those		example, deployments based on [i2rs-usecase] would apply these
	documented within [i2rs-protocol-security] to secure ephemeral state		requirements in conjunction with those documented within
	information being pushed from a Network Element.		[i2rs-environment-security] and [i2rs-protocol-security] to secure
			ephemeral state information being pushed from a Network Element.
	As part of the Subscription establishment, there MUST be mutual		As part of the Subscription establishment, mutual authentication MUST
	authentication between the Subscriber and the Subscription Service.		be used between the Subscriber and the Subscription Service.
	When there are multiple Subscribers, it SHOULD be possible to provide		Subscribers MUST NOT be able to pose as the original Subscription
	cryptographic authentication in such a way that no Subscriber can		Service.
	pose as the original Subscription Service.
	Versioning of any subscription protocols MUST be supported so that		Versioning of any subscription protocols MUST be supported so that
	the capabilities and behaviors expected of specific technology		the capabilities and behaviors expected of specific technology
	implementations can be exposed.		implementations can be exposed.
	A Subscription could be used to attempt to retrieve information to		A Subscription could be used to attempt to retrieve information to
	which a client has no authorized access. Therefore it is important		which a client has no authorized access. Therefore it is important
	that data pushed based on Subscriptions is authorized in the same way		that data pushed based on Subscriptions is authorized in the same way
	that regular data retrieval operations are authorized. Data being		that regular data retrieval operations are authorized. Data being
	pushed to a client MUST be filtered accordingly, just like if the		pushed to a client MUST be filtered accordingly, just like if the
	data were being retrieved on-demand. For Unicast transports, the		data were being retrieved on-demand. For Unicast transports, the
	NETCONF Authorization Control Model applies.		NETCONF Authorization Control Model applies.
	Additions or changes within a subscribed subtree structure MUST be		Additions or changes within a subscribed subtree structure MUST be
	validated against authorization methods before Subscription Updates		validated against authorization methods before Subscription Updates
	including new subtree information are pushed.		including new subtree information are pushed.
	A loss of authenticated access to subtree or node SHOULD be		A loss of authenticated access to target subtree or node SHOULD be
	communicated to the Subscriber.		communicated to the Subscriber.
			For any encrypted information exchanges, commensurate strength
			security mechanisms MUST be available and SHOULD be used. This
			includes all stages of the Subscription and update push process.
	Subscription requests, including requests to create, terminate,		Subscription requests, including requests to create, terminate,
	suspend, and resume Subscriptions MUST be properly authorized.		suspend, and resume Subscriptions MUST be properly authorized.
	When the Subscriber and Receiver are different, the Receiver MUST be		When the Subscriber and Receiver are different, the Receiver MUST be
	able to terminate any Subscription to it where objects are being		able to terminate any Subscription to it where objects are being
	delivered over a Unicast transport.		delivered over a Unicast transport.
	A Subscription Service SHOULD decline a Subscription Request if it is		A Subscription Service SHOULD decline a Subscription Request if it is
	likely to deplete its resources. It is preferable to decline a		likely to deplete its resources. It is preferable to decline a
	Subscription when originally requested, rather than having to		Subscription when originally requested, rather than having to
	skipping to change at page 16, line 16 ¶		skipping to change at page 16, line 16 ¶
	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,
	<http://www.rfc-editor.org/info/rfc6241>.		<http://www.rfc-editor.org/info/rfc6241>.
	[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/		[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
	BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February		BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
	2012, <http://www.rfc-editor.org/info/rfc6513>.		2012, <http://www.rfc-editor.org/info/rfc6513>.
	8.2. Informative References		8.2. Informative References
			[i2rs-environment-security]
			Migault, D., Halpern, J., and S. Hares, "I2RS Environment
			Security Requirements", April 2016,
			<https://datatracker.ietf.org/doc/draft-ietf-i2rs-
			security-environment-reqs/>.
	[i2rs-protocol-security]		[i2rs-protocol-security]
	Hares, S., Migault, D., and J. Halpern, "I2RS Security		Hares, S., Migault, D., and J. Halpern, "I2RS Security
	Related Requirements", May 2016,		Related Requirements", May 2016,
	<https://datatracker.ietf.org/doc/draft-ietf-i2rs-		<https://datatracker.ietf.org/doc/draft-ietf-i2rs-
	protocol-security-requirements/>.		protocol-security-requirements/>.
	[i2rs-usecase]		[i2rs-usecase]
	Hares, S. and M. Chen, "Summary of I2RS Use Case		Hares, S. and M. Chen, "Summary of I2RS Use Case
	Requirements", March 2016,		Requirements", March 2016,
	<https://datatracker.ietf.org/doc/draft-ietf-i2rs-usecase-		<https://datatracker.ietf.org/doc/draft-ietf-i2rs-usecase-
End of changes. 10 change blocks.
	29 lines changed or deleted		39 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/