< draft-ietf-netconf-restconf-notif-09.txt		draft-ietf-netconf-restconf-notif-10.txt >
	NETCONF E. Voit		NETCONF E. Voit
	Internet-Draft R. Rahman		Internet-Draft R. Rahman
	Intended status: Standards Track E. Nilsen-Nygaard		Intended status: Standards Track E. Nilsen-Nygaard
	Expires: April 22, 2019 Cisco Systems		Expires: May 8, 2019 Cisco Systems
	A. Clemm		A. Clemm
	Huawei		Huawei
	A. Bierman		A. Bierman
	YumaWorks		YumaWorks
	October 19, 2018		November 4, 2018
	Dynamic subscription to YANG Events and Datastores over RESTCONF		Dynamic subscription to YANG Events and Datastores over RESTCONF
	draft-ietf-netconf-restconf-notif-09		draft-ietf-netconf-restconf-notif-10
	Abstract		Abstract
	This document provides a RESTCONF binding to the dynamic subscription		This document provides a RESTCONF binding to the dynamic subscription
	capability of both subscribed notifications and YANG-Push.		capability of both subscribed notifications and YANG-Push.
	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 36 ¶		skipping to change at page 1, line 36 ¶
	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 22, 2019.		This Internet-Draft will expire on May 8, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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 19 ¶		skipping to change at page 2, line 19 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Dynamic Subscriptions . . . . . . . . . . . . . . . . . . . . 3		3. Dynamic Subscriptions . . . . . . . . . . . . . . . . . . . . 3
	3.1. Transport Connectivity . . . . . . . . . . . . . . . . . 4		3.1. Transport Connectivity . . . . . . . . . . . . . . . . . 4
	3.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 4		3.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.3. RESTCONF RPCs and HTTP Status Codes . . . . . . . . . . . 4		3.3. RESTCONF RPCs and HTTP Status Codes . . . . . . . . . . . 4
	3.4. Call Flow for Server-Sent Events (SSE) . . . . . . . . . 6		3.4. Call Flow for Server-Sent Events (SSE) . . . . . . . . . 6
	4. QoS Treatment . . . . . . . . . . . . . . . . . . . . . . . . 8		4. QoS Treatment . . . . . . . . . . . . . . . . . . . . . . . . 8
	5. Notification Messages . . . . . . . . . . . . . . . . . . . . 8		5. Notification Messages . . . . . . . . . . . . . . . . . . . . 8
	6. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . . . 8		6. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	7. YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 8		7. YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 9
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 11		9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	11.1. Normative References . . . . . . . . . . . . . . . . . . 11		11.1. Normative References . . . . . . . . . . . . . . . . . . 12
	11.2. Informative References . . . . . . . . . . . . . . . . . 13		11.2. Informative References . . . . . . . . . . . . . . . . . 13
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14
	A.1. Dynamic Subscriptions . . . . . . . . . . . . . . . . . . 14		A.1. Dynamic Subscriptions . . . . . . . . . . . . . . . . . . 14
	A.1.1. Establishing Dynamic Subscriptions . . . . . . . . . 14		A.1.1. Establishing Dynamic Subscriptions . . . . . . . . . 14
	A.1.2. Modifying Dynamic Subscriptions . . . . . . . . . . . 17		A.1.2. Modifying Dynamic Subscriptions . . . . . . . . . . . 17
	A.1.3. Deleting Dynamic Subscriptions . . . . . . . . . . . 18		A.1.3. Deleting Dynamic Subscriptions . . . . . . . . . . . 18
	A.2. Subscription State Notifications . . . . . . . . . . . . 19		A.2. Subscription State Notifications . . . . . . . . . . . . 19
	A.2.1. subscription-modified . . . . . . . . . . . . . . . . 19		A.2.1. subscription-modified . . . . . . . . . . . . . . . . 19
	A.2.2. subscription-completed, subscription-resumed, and		A.2.2. subscription-completed, subscription-resumed, and
	replay-complete . . . . . . . . . . . . . . . . . . . 20		replay-complete . . . . . . . . . . . . . . . . . . . 20
	skipping to change at page 5, line 27 ¶		skipping to change at page 5, line 27 ¶
	Appendix A.1, for datastore subscriptions. The tag to use depends		Appendix A.1, for datastore subscriptions. The tag to use depends
	on the RPC for which the error occurred. Viable errors for		on the RPC for which the error occurred. Viable errors for
	different RPCs are as follows:		different RPCs are as follows:
	RPC select an identity with a base		RPC select an identity with a base
	---------------------- ------------------------------		---------------------- ------------------------------
	establish-subscription establish-subscription-error		establish-subscription establish-subscription-error
	modify-subscription modify-subscription-error		modify-subscription modify-subscription-error
	delete-subscription delete-subscription-error		delete-subscription delete-subscription-error
	kill-subscription kill-subscription-error		kill-subscription kill-subscription-error
	resynch-subscription resynch-subscription-error		resync-subscription resync-subscription-error
	Each error identity will be inserted as the "error-app-tag" using		Each error identity will be inserted as the "error-app-tag" using
	JSON encoding following the form <modulename>:<identityname>. An		JSON encoding following the form <modulename>:<identityname>. An
	example of such as valid encoding would be "ietf-subscribed-		example of such as valid encoding would be "ietf-subscribed-
	notifications:no-such-subscription".		notifications:no-such-subscription".
	In case of error responses to an "establish-subscription" or "modify-		In case of error responses to an "establish-subscription" or "modify-
	subscription" request there is the option of including an "error-		subscription" request there is the option of including an "error-
	info" node. This node may contain hints for parameter settings that		info" node. This node may contain hints for parameter settings that
	might lead to successful RPC requests in the future. Following are		might lead to successful RPC requests in the future. Following are
	skipping to change at page 6, line 21 ¶		skipping to change at page 6, line 21 ¶
	---------------------- ------------------------------------		---------------------- ------------------------------------
	target: event stream modify-subscription-stream-error-info		target: event stream modify-subscription-stream-error-info
	target: datastore modify-subscription-datastore-error-info		target: datastore modify-subscription-datastore-error-info
	The yang-data included within "error-info" SHOULD NOT include the		The yang-data included within "error-info" SHOULD NOT include the
	optional leaf "error-reason", as such a leaf would be redundant		optional leaf "error-reason", as such a leaf would be redundant
	with information that is already placed within the		with information that is already placed within the
	"error-app-tag".		"error-app-tag".
	In case of an rpc error as a result of a "delete-subscription", a		In case of an rpc error as a result of a "delete-subscription", a
	"kill-subscription", or a "resynch-subscription" request, no		"kill-subscription", or a "resync-subscription" request, no
	"error-info" needs to be included, as the "subscription-id" is		"error-info" needs to be included, as the "subscription-id" is
	the only RPC input parameter and no hints regarding this RPC input		the only RPC input parameter and no hints regarding this RPC input
	parameters need to be provided.		parameters need to be provided.
	Note that "error-path" [RFC8040] does not need to be included with		Note that "error-path" [RFC8040] does not need to be included with
	the "rpc-error" element, as subscription errors are generally		the "rpc-error" element, as subscription errors are generally
	associated with the choice of RPC input parameters.		associated with the choice of RPC input parameters.
	3.4. Call Flow for Server-Sent Events (SSE)		3.4. Call Flow for Server-Sent Events (SSE)
	skipping to change at page 8, line 5 ¶		skipping to change at page 8, line 5 ¶
	o Subscription RPCs MUST NOT use the connection currently providing		o Subscription RPCs MUST NOT use the connection currently providing
	notification messages for that subscription.		notification messages for that subscription.
	o In addition to an RPC response for a "modify-subscription" RPC		o In addition to an RPC response for a "modify-subscription" RPC
	traveling over (a), a "subscription-modified" state change		traveling over (a), a "subscription-modified" state change
	notification must be sent within (b). This allows the receiver to		notification must be sent within (b). This allows the receiver to
	know exactly when the new terms of the subscription have been		know exactly when the new terms of the subscription have been
	applied to the notification messages. See arrow (c).		applied to the notification messages. See arrow (c).
			o RPCs modify-subscription, resync-subscription and delete-
			subscription can only be done by the same RESTCONF username
			[RFC8040] who did the establish-subscription, or by a RESTCONF
			username with the required administrative permissions. The latter
			also has access to the kill-subscription RPC.
	A publisher MUST terminate a subscription in the following cases:		A publisher MUST terminate a subscription in the following cases:
	o Receipt of a "delete-subscription" or a "kill-subscription" RPC		o Receipt of a "delete-subscription" or a "kill-subscription" RPC
	for that subscription.		for that subscription.
	o Loss of TLS heartbeat		o Loss of TLS heartbeat
	A publisher MAY terminate a subscription at any time as stated in		A publisher MAY terminate a subscription at any time as stated in
	[I-D.draft-ietf-netconf-subscribed-notifications] Section 1.3		[I-D.draft-ietf-netconf-subscribed-notifications] Section 1.3
	skipping to change at page 22, line 43 ¶		skipping to change at page 22, line 43 ¶
	}		}
	Figure 17		Figure 17
	For more examples of subtree filters, see [RFC6241], section 6.4.		For more examples of subtree filters, see [RFC6241], section 6.4.
	Appendix B. Changes between revisions		Appendix B. Changes between revisions
	(To be removed by RFC editor prior to publication)		(To be removed by RFC editor prior to publication)
			v09 - v10
			o Fixed typo for resync.
			o Added text wrt RPC permissions and RESTCONF username.
	v08 - v09		v08 - v09
	o Addressed comments received during WGLC.		o Addressed comments received during WGLC.
	v07 - v08		v07 - v08
	o Aligned with RESTCONF mechanism.		o Aligned with RESTCONF mechanism.
	o YANG model: removed augment of subscription-started, added		o YANG model: removed augment of subscription-started, added
	restconf transport.		restconf transport.
End of changes. 10 change blocks.
	9 lines changed or deleted		21 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/