< draft-ietf-netconf-subscribed-notifications-09.txt		draft-ietf-netconf-subscribed-notifications-10.txt >
	NETCONF E. Voit		NETCONF E. Voit
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Standards Track A. Clemm		Intended status: Standards Track A. Clemm
	Expires: July 28, 2018 Huawei		Expires: August 27, 2018 Huawei
	A. Gonzalez Prieto		A. Gonzalez Prieto
	VMWare		VMWare
	E. Nilsen-Nygaard		E. Nilsen-Nygaard
	A. Tripathy		A. Tripathy
	Cisco Systems		Cisco Systems
	January 24, 2018		February 23, 2018
	Custom Subscription to Event Streams		Custom Subscription to Event Streams
	draft-ietf-netconf-subscribed-notifications-09		draft-ietf-netconf-subscribed-notifications-10
	Abstract		Abstract
	This document defines capabilities and operations for the customized		This document defines capabilities and operations for the customized
	establishment of subscriptions upon a publisher's event streams.		establishment of subscriptions upon a publisher's event streams.
	Also defined are delivery mechanisms for instances of the resulting		Also defined are delivery mechanisms for instances of the resulting
	notification messages. Effectively this allows a subscriber to		notification messages. Effectively this allows a subscriber to
	request and receive a continuous, custom feed of publisher generated		request and receive a continuous, custom feed of publisher generated
	information.		information.
	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 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 July 28, 2018.		This Internet-Draft will expire on August 27, 2018.
	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 39 ¶		skipping to change at page 2, line 39 ¶
	3. YANG Data Model Trees . . . . . . . . . . . . . . . . . . . . 24		3. YANG Data Model Trees . . . . . . . . . . . . . . . . . . . . 24
	3.1. Event Streams Container . . . . . . . . . . . . . . . . . 25		3.1. Event Streams Container . . . . . . . . . . . . . . . . . 25
	3.2. Event Stream Filters Container . . . . . . . . . . . . . 25		3.2. Event Stream Filters Container . . . . . . . . . . . . . 25
	3.3. Subscriptions Container . . . . . . . . . . . . . . . . . 25		3.3. Subscriptions Container . . . . . . . . . . . . . . . . . 25
	4. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 26		4. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 26
	5. Considerations . . . . . . . . . . . . . . . . . . . . . . . 51		5. Considerations . . . . . . . . . . . . . . . . . . . . . . . 51
	5.1. Implementation Considerations . . . . . . . . . . . . . . 51		5.1. Implementation Considerations . . . . . . . . . . . . . . 51
	5.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 52		5.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 52
	5.3. Security Considerations . . . . . . . . . . . . . . . . . 52		5.3. Security Considerations . . . . . . . . . . . . . . . . . 52
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 54		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
	7.1. Normative References . . . . . . . . . . . . . . . . . . 54		7.1. Normative References . . . . . . . . . . . . . . . . . . 54
	7.2. Informative References . . . . . . . . . . . . . . . . . 55		7.2. Informative References . . . . . . . . . . . . . . . . . 54
	Appendix A. Changes between revisions . . . . . . . . . . . . . 55		Appendix A. Changes between revisions . . . . . . . . . . . . . 55
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59
	1. Introduction		1. Introduction
	This document defines capabilities and operations for the customized		This document defines capabilities and operations for the customized
	establishment of subscriptions upon system generated event streams.		establishment of subscriptions upon system generated event streams.
	Effectively this enables a "subscribe then publish" capability where		Effectively this enables a "subscribe then publish" capability where
	the customized information needs of each target receiver are		the customized information needs of each target receiver are
	understood by the publisher before subscribed event records are		understood by the publisher before subscribed event records are
	skipping to change at page 3, line 18 ¶		skipping to change at page 3, line 18 ¶
	agnostic, protocols like NETCONF [RFC6241] or RESTCONF [RFC8040] can		agnostic, protocols like NETCONF [RFC6241] or RESTCONF [RFC8040] can
	be used to configure or dynamically signal subscriptions, and there		be used to configure or dynamically signal subscriptions, and there
	are bindings defined for subscribed event record delivery for NETCONF		are bindings defined for subscribed event record delivery for NETCONF
	within [I-D.draft-ietf-netconf-netconf-event-notifications], and for		within [I-D.draft-ietf-netconf-netconf-event-notifications], and for
	HTTP2 or HTTP1.1 within [I-D.draft-ietf-netconf-restconf-notif].		HTTP2 or HTTP1.1 within [I-D.draft-ietf-netconf-restconf-notif].
	1.1. Motivation		1.1. Motivation
	There are various [RFC5277] limitations, many of which have been		There are various [RFC5277] limitations, many of which have been
	exposed in [RFC7923] which needed to be solved. Key capabilities		exposed in [RFC7923] which needed to be solved. Key capabilities
	supported by this document include:		supported by this document includes:
	o multiple subscriptions on a single transport session		o multiple subscriptions on a single transport session
	o support for dynamic and statically configured subscriptions		o support for dynamic and statically configured subscriptions
	o modification of an existing subscription		o modification of an existing subscription
	o operational counters and instrumentation		o operational counters and instrumentation
	o negotiation of subscription parameters (through the use of hints		o negotiation of subscription parameters (through the use of hints
	skipping to change at page 4, line 11 ¶		skipping to change at page 4, line 11 ¶
	Event: An occurrence of something that may be of interest. (e.g., a		Event: An occurrence of something that may be of interest. (e.g., a
	configuration change, a fault, a change in status, crossing a		configuration change, a fault, a change in status, crossing a
	threshold, or an external input to the system.)		threshold, or an external input to the system.)
	Event record: A set of information detailing an event.		Event record: A set of information detailing an event.
	NACM: NETCONF Access Control Model.		NACM: NETCONF Access Control Model.
	Notification message: A set of transport encapsulated information		Notification message: A set of transport encapsulated information
	intended for a receiver indicating that one or more event(s) have		intended for a receiver indicating that one or more event(s) have
	occurred. A notification message may bundle multiple event records.		occurred. A notification message may bundle multiple event records.
	This includes the bundling multiple, independent RFC 7950 YANG		This includes the bundling of multiple, independent RFC 7950 YANG
	notifications.		notifications.
	Publisher: An entity responsible for streaming notification messages		Publisher: An entity responsible for streaming notification messages
	per the terms of a Subscription.		per the terms of a Subscription.
	Receiver: A target to which a publisher pushes subscribed event		Receiver: A target to which a publisher pushes subscribed event
	records. For dynamic subscriptions, the receiver and subscriber are		records. For dynamic subscriptions, the receiver and subscriber are
	the same entity.		the same entity.
	Stream (also referred to as "event stream"): A continuous ordered set		Stream (also referred to as "event stream"): A continuous ordered set
	skipping to change at page 7, line 11 ¶		skipping to change at page 7, line 11 ¶
	As event records are created by a system, they may be assigned to one		As event records are created by a system, they may be assigned to one
	or more streams. The event record is distributed to subscription's		or more streams. The event record is distributed to subscription's
	receiver(s) where: (1) a subscription includes the identified stream,		receiver(s) where: (1) a subscription includes the identified stream,
	and (2) subscription filtering does not exclude the event record from		and (2) subscription filtering does not exclude the event record from
	that receiver.		that receiver.
	If access control permissions are in use to secure publisher content,		If access control permissions are in use to secure publisher content,
	then for event records to be sent to a receiver, that receiver MUST		then for event records to be sent to a receiver, that receiver MUST
	be allowed access to all the event records on the stream. If		be allowed access to all the event records on the stream. If
	subscriber permissions change during the lifecycle of a subscription,		subscriber permissions change during the lifecycle of a subscription
	then the subscription MUST be continued or terminated accordingly.		and stream access is no longer permitted, then the subscription MUST
			be terminated.
	2.2. Event Stream Filters		2.2. Event Stream Filters
	This document defines an extensible filtering mechanism. Two		This document defines an extensible filtering mechanism. Two
	optional stream filtering syntaxes supported are [XPATH] and subtree		optional stream filtering syntaxes supported are [XPATH] and subtree
	[RFC6241]. A filter always removes a complete event record; a subset		[RFC6241]. A filter always removes a complete event record; a subset
	of information is never stripped from an event record.		of information is never stripped from an event record.
	If no stream filter is provided within a subscription, all event		If no stream filter is provided within a subscription, all event
	records on a stream are to be sent.		records on a stream are to be sent.
	skipping to change at page 9, line 7 ¶		skipping to change at page 9, line 7 ¶
	Of interest in this state machine are the following:		Of interest in this state machine are the following:
	o Successful establish or modify RPCs put the subscription into an		o Successful establish or modify RPCs put the subscription into an
	active state.		active state.
	o Failed modify RPCs will leave the subscription in its previous		o Failed modify RPCs will leave the subscription in its previous
	state, with no visible change to any streaming updates.		state, with no visible change to any streaming updates.
	o A delete or kill RPC will end the subscription.		o A delete or kill RPC will end the subscription.
	o Suspend and resume state changes are driven by internal process		o The two state change notifications "subscription-suspended" and
	and prioritization. There are no direct controls over suspend and		"subscription-resumed" are shown. These are under the control of
	resume other than modifying a subscription		a publisher. There are no direct controls over suspend and resume
			other than to attempt a modification of a subscription.
	2.4.2. Establishing a Subscription		2.4.2. Establishing a Subscription
	The "establish-subscription" operation allows a subscriber to request		The "establish-subscription" operation allows a subscriber to request
	the creation of a subscription via RPC. It MUST be possible to		the creation of a subscription via RPC. It MUST be possible to
	support multiple establish subscription RPC requests made within the		support multiple establish subscription RPC requests made within the
	same transport session.		same transport session. And it MUST be possible to support the
			interleaving of RPC requests made on independent subscriptions.
	The input parameters of the operation are:		The input parameters of the operation are:
	o A stream name which identifies the targeted stream of events		o A stream name which identifies the targeted stream of events
	against which the subscription is applied.		against which the subscription is applied.
	o A stream filter which may reduce the set of event records pushed.		o A stream filter which may reduce the set of event records pushed.
	o An optional encoding for the event records pushed. Note: If no		o An optional encoding for the event records pushed. Note: If no
	encoding is included, the encoding of the RPC MUST be used.		encoding is included, the encoding of the RPC MUST be used.
	skipping to change at page 14, line 7 ¶		skipping to change at page 14, line 7 ¶
	specific errors such as those defined within this document's YANG		specific errors such as those defined within this document's YANG
	model. As a result of this mixture, how subscription errors are		model. As a result of this mixture, how subscription errors are
	encoded within an RPC error response is transport dependent.		encoded within an RPC error response is transport dependent.
	There are elements of the RPC error mechanism which are transport		There are elements of the RPC error mechanism which are transport
	independent. Specifically, references to specific identities within		independent. Specifically, references to specific identities within
	the YANG model MUST be returned as part of the error responses		the YANG model MUST be returned as part of the error responses
	resulting from failed attempts at event stream subscription.		resulting from failed attempts at event stream subscription.
	Following are valid errors per RPC:		Following are valid errors per RPC:
	establish-subscription modify-subscription		establish-subscription modify-subscription
	---------------------- -------------------		---------------------- -------------------
	dscp-unavailable filter-unsupported		dscp-unavailable filter-unsupported
	filter-unsupported insufficient-resources		filter-unsupported insufficient-resources
	history-unavailable no-such-subscription		history-unavailable no-such-subscription
	insufficient-resources		insufficient-resources
	replay-unsupported		replay-unsupported
	delete-subscription kill-subscription		delete-subscription kill-subscription
	---------------------- ----------------------		---------------------- ----------------------
	no-such-subscription no-such-subscription		no-such-subscription no-such-subscription
	There is one final set of transport independent RPC error elements		There is one final set of transport independent RPC error elements
	included in the YANG model. These are the following three yang-data		included in the YANG model. These are the following three yang-data
	structures for failed event stream subscriptions:		structures for failed event stream subscriptions:
	1. yang-data establish-subscription-error-stream: This MUST be		1. yang-data establish-subscription-error-stream: This MUST be
	returned if an RPC error reason has not been placed elsewhere		returned if an RPC error reason has not been placed elsewhere
	within the transport portion of a failed "establish-subscription"		within the transport portion of a failed "establish-subscription"
	RPC response. This MUST be sent if hints on how to overcome the		RPC response. This MUST be sent if hints on how to overcome the
	skipping to change at page 17, line 25 ¶		skipping to change at page 17, line 25 ¶
	| '----->| | '----------------------| | |		| '----->| | '----------------------| | |
	| |receiver|-(subscription-suspended)-->|receiver | |		| |receiver|-(subscription-suspended)-->|receiver | |
	|(subscription-| ACTIVE | |SUSPENDED| |		|(subscription-| ACTIVE | |SUSPENDED| |
	| modified) | |<-(subscription-resumed,----| | |		| modified) | |<-(subscription-resumed,----| | |
	| '---->'--------' subscription-modified) '---------' |		| '---->'--------' subscription-modified) '---------' |
	'----------------------------------------------------------------'		'----------------------------------------------------------------'
	Receiver state for a configured subscription		Receiver state for a configured subscription
	When a subscription first becomes valid, the operational state of		When a subscription first becomes valid, the operational state of
	each receiver is initialized to connecting. Individual are receivers		each receiver is initialized to connecting. Individual receivers are
	are moved to an active state when a "subscription-started" state		moved to an active state when a "subscription-started" state change
	change notification is successfully passed to that receiver.		notification is successfully passed to that receiver. Configured
	Configured receivers remain active if transport connectivity is not		receivers remain active if transport connectivity is not lost, and
	lost, and event records are not being dropped due to a publisher		event records are not being dropped due to a publisher buffer
	buffer overflow. A configured subscription's receiver MUST be moved		overflow. A configured subscription's receiver MUST be moved to
	to connecting if transport connectivity is lost, or if the receiver		connecting if transport connectivity is lost, or if the receiver is
	is reset via configuration operations.		reset via configuration operations.
	A configured subscription's receiver MUST be moved to a suspended		A configured subscription's receiver MUST be moved to a suspended
	state if there is transport connectivity between the publisher and		state if there is transport connectivity between the publisher and
	receiver, but notification messages are not being generated for that		receiver, but notification messages are not being generated for that
	receiver. A configured subscription receiver MUST be returned to an		receiver. A configured subscription receiver MUST be returned to an
	active state from the suspended state when notification messages are		active state from the suspended state when notification messages are
	again being generated and a receiver has successfully been sent a		again being generated and a receiver has successfully been sent a
	"subscription-resumed" or a "subscription-modified".		"subscription-resumed" or a "subscription-modified".
	Modification of a configured subscription is possible at any time. A		Modification of a configured subscription is possible at any time. A
	skipping to change at page 18, line 5 ¶		skipping to change at page 18, line 4 ¶
	"subscription-modified" state change notification will be sent to all		"subscription-modified" state change notification will be sent to all
	active receivers, immediately followed by notification messages		active receivers, immediately followed by notification messages
	conforming to the new parameters. Suspended receivers will also be		conforming to the new parameters. Suspended receivers will also be
	informed of the modification. However this notification will await		informed of the modification. However this notification will await
	the end of the suspension for that receiver.		the end of the suspension for that receiver.
	The mechanisms described above is mirrored in the RPCs and YANG		The mechanisms described above is mirrored in the RPCs and YANG
	notifications within the document. It should be noted that these		notifications within the document. It should be noted that these
	RPCs and YANG notifications have been designed to be extensible and		RPCs and YANG notifications have been designed to be extensible and
	allow subscriptions into targets other than event streams.		allow subscriptions into targets other than event streams.
	[I-D.ietf-netconf-yang-push] provides an example of such an		[I-D.ietf-netconf-yang-push] provides an example of such an
	extension.		extension.
	2.5.2. Creating a Configured Subscription		2.5.2. Creating a Configured Subscription
	Configured subscriptions are established using configuration		Configured subscriptions are established using configuration
	operations against the top-level subtree "subscription-config".		operations against the top-level "subscriptions" subtree. There are
	There are two key differences between the new RPCs defined in this		two key differences between the new RPCs defined in this document and
	document and configuration operations for subscription creation.		configuration operations for subscription creation. Firstly,
	Firstly, configuration operations install a subscription without		configuration operations install a subscription without question,
	question, while the RPCs are designed to the support negotiation and		while the RPCs are designed to the support negotiation and rejection
	rejection of requests. Secondly, while the RPCs mandate that the		of requests. Secondly, while the RPCs mandate that the subscriber
	subscriber establishing the subscription is the only receiver of the		establishing the subscription is the only receiver of the
	notification messages, configuration operations permit specifying		notification messages, configuration operations permit specifying
	receivers independent of any tracked subscriber. Because there is no		receivers independent of any tracked subscriber. Because there is no
	explicit association with an existing transport session,		explicit association with an existing transport session,
	configuration operations require additional parameters beyond those		configuration operations require additional parameters beyond those
	of dynamic subscriptions to indicate receivers, and possibly whether		of dynamic subscriptions to indicate receivers, and possibly whether
	the notification messages need to come from a specific egress		the notification messages need to come from a specific egress
	interface on the publisher.		interface on the publisher.
	After a subscription is successfully created, the publisher		After a subscription is successfully created, the publisher
	immediately sends a "subscription-started" state change notification		immediately sends a "subscription-started" state change notification
	skipping to change at page 19, line 8 ¶		skipping to change at page 19, line 8 ¶
	Note that is possible to configure replay on a configured		Note that is possible to configure replay on a configured
	subscription. This capability is to allow a configured subscription		subscription. This capability is to allow a configured subscription
	to exist on a system so that event records generated during boot can		to exist on a system so that event records generated during boot can
	be buffered and pushed as soon as the transport session is		be buffered and pushed as soon as the transport session is
	established.		established.
	2.5.3. Modifying a Configured Subscription		2.5.3. Modifying a Configured Subscription
	Configured subscriptions can be modified using configuration		Configured subscriptions can be modified using configuration
	operations against the top-level subtree "subscription-config".		operations against the top-level "subscriptions" subtree.
	If the modification involves adding receivers, added receivers are		If the modification involves adding receivers, added receivers are
	placed in the "connecting" state. If a receiver is removed, the		placed in the "connecting" state. If a receiver is removed, the
	state change notification "subscription-terminated" is sent to that		state change notification "subscription-terminated" is sent to that
	receiver if that receiver is "active" or "suspended" .		receiver if that receiver is "active" or "suspended" .
	If the modification involved changing the policies for the		If the modification involves changing the policies for the
	subscription, the publisher sends to currently active receivers a		subscription, the publisher sends to currently active receivers a
	"subscription-modified" notification. For any suspended receivers, a		"subscription-modified" notification. For any suspended receivers, a
	"subscription-modified" notification will be delayed until the		"subscription-modified" notification will be delayed until the
	receiver is resumed. (Note: in this case, the "subscription-		receiver is resumed. (Note: in this case, the "subscription-
	modified" notification informs the receiver that the subscription has		modified" notification informs the receiver that the subscription has
	been resumed, so no additional "subscription-resumed" need be sent.)		been resumed, so no additional "subscription-resumed" need be sent.)
	2.5.4. Deleting a Configured Subscription		2.5.4. Deleting a Configured Subscription
	Subscriptions can be deleted using configuration operations against		Subscriptions can be deleted using configuration operations against
	the top-level subtree "subscription-config".		the top-level "subscriptions" subtree.
	Immediately after a subscription is successfully deleted, the		Immediately after a subscription is successfully deleted, the
	publisher sends to all receivers of that subscription a state change		publisher sends to all receivers of that subscription a state change
	notification stating the subscription has ended (i.e., "subscription-		notification stating the subscription has ended (i.e., "subscription-
	terminated").		terminated").
	2.5.5. Resetting a Configured Receiver		2.5.5. Resetting a Configured Receiver
	It is possible that a configured subscription to a receiver needs to		It is possible that a configured subscription to a receiver needs to
	be reset. This re-initialization may be useful in cases where a		be reset. This re-initialization may be useful in cases where a
	skipping to change at page 19, line 49 ¶		skipping to change at page 19, line 49 ¶
	a new "subscription-started" notification will be sent.		a new "subscription-started" notification will be sent.
	2.6. Event Record Delivery		2.6. Event Record Delivery
	Whether dynamic or configured, once a subscription has been set up,		Whether dynamic or configured, once a subscription has been set up,
	the publisher streams event records via notification messages per the		the publisher streams event records via notification messages per the
	terms of the subscription. For dynamic subscriptions set up via RPC		terms of the subscription. For dynamic subscriptions set up via RPC
	operations, notification messages are sent over the session used to		operations, notification messages are sent over the session used to
	establish the subscription. For configured subscriptions,		establish the subscription. For configured subscriptions,
	notification messages are sent over the connections specified by the		notification messages are sent over the connections specified by the
	transport, plus receiver IP address and port configured.		transport, plus receiver IP address and port configured. In all
			cases, a single transport session MUST be able to support the
			interleaving of event records, RPCs, and state change notifications
			from independent subscriptions.
	A notification message is sent to a receiver when an event record is		A notification message is sent to a receiver when an event record is
	able to traverse the specified filter criteria. This notification		able to traverse the specified filter criteria. This notification
	message MUST be encoded as one-way notification element of [RFC5277],		message MUST be encoded as one-way notification element of [RFC5277],
	Section 4. The following example within [RFC7950] section 7.16.3 is		Section 4. A subscription's events MUST NOT be sent to a receiver
	an example of a compliant message:		until after a corresponding RPC response or state-change notification
			has been passed receiver indicating that events should be expected.
			The following example within [RFC7950] section 7.16.3 is an example
			of a compliant message:
	<notification		<notification
	xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">		xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
	<eventTime>2007-09-01T10:00:00Z</eventTime>		<eventTime>2007-09-01T10:00:00Z</eventTime>
	<link-failure xmlns="http://acme.example.com/system">		<link-failure xmlns="http://acme.example.com/system">
	<if-name>so-1/2/3.0</if-name>		<if-name>so-1/2/3.0</if-name>
	<if-admin-status>up</if-admin-status>		<if-admin-status>up</if-admin-status>
	<if-oper-status>down</if-oper-status>		<if-oper-status>down</if-oper-status>
	</link-failure>		</link-failure>
	</notification>		</notification>
	skipping to change at page 20, line 34 ¶		skipping to change at page 20, line 40 ¶
	event records belong to which subscription.		event records belong to which subscription.
	These drawbacks, along with other useful common headers and the		These drawbacks, along with other useful common headers and the
	ability to bundle multiple event records together is being explored		ability to bundle multiple event records together is being explored
	within [I.D.draft-ietf-netconf-notification-messages]. When the		within [I.D.draft-ietf-netconf-notification-messages]. When the
	notification-messages is supported, this document will be updated to		notification-messages is supported, this document will be updated to
	indicate support.		indicate support.
	2.7. Subscription State Notifications		2.7. Subscription State Notifications
	In addition to subscribed event records, a publisher will send		In addition to subscribed event records, a publisher MUST send
	subscription state notifications to indicate to receivers that an		subscription state notifications to indicate to receivers that an
	event related to the subscription management has occurred.		event related to the subscription management has occurred.
	Subscription state notifications are unlike other notifications which		Subscription state notifications are unlike other notifications which
	might be found in the event stream. They cannot be filtered out, and		might be found in the event stream. They cannot be filtered out, and
	they are delivered only to directly impacted receiver(s) of a		they are delivered only to directly impacted receiver(s) of a
	subscription. The identification of subscription state notifications		subscription. The identification of subscription state notifications
	is easy to separate from other notification messages through the use		is easy to separate from other notification messages through the use
	of the YANG extension "subscription-state-notif". This extension		of the YANG extension "subscription-state-notif". This extension
	tags a notification as subscription state notification.		tags a notification as subscription state notification.
	skipping to change at page 21, line 14 ¶		skipping to change at page 21, line 17 ¶
	2.7.1. subscription-started		2.7.1. subscription-started
	This notification indicates that a configured subscription has		This notification indicates that a configured subscription has
	started, and event records may be sent. Included in this state		started, and event records may be sent. Included in this state
	change notification are all the parameters of the subscription,		change notification are all the parameters of the subscription,
	except for the receiver(s) addressing information and origin		except for the receiver(s) addressing information and origin
	information indicating where notification messages will egress the		information indicating where notification messages will egress the
	publisher. Note that if a referenced filter from the "filters"		publisher. Note that if a referenced filter from the "filters"
	container has been used within the subscription, the notification		container has been used within the subscription, the notification
	will include the contents of that referenced under the "within-		will still provide the contents of that referenced filter under the
	subscription" subtree.		"within-subscription" subtree.
	Note that for dynamic subscriptions, no "subscription-started"		Note that for dynamic subscriptions, no "subscription-started"
	notifications are ever sent.		notifications are ever sent.
	+---n subscription-started {configured}?		+---n subscription-started {configured}?
	+--ro identifier subscription-id		+--ro identifier subscription-id
	+--ro protocol transport {configured}?		+--ro protocol transport {configured}?
	+--ro encoding encoding		+--ro encoding encoding
	+--ro (target)		+--ro (target)
	| +--:(stream)		| +--:(stream)
	skipping to change at page 24, line 31 ¶		skipping to change at page 24, line 35 ¶
	current state of the configured subscription.		current state of the configured subscription.
	Subscriptions that were established by RPC are removed from the list		Subscriptions that were established by RPC are removed from the list
	once they expire (reaching stop-time) or when they are terminated.		once they expire (reaching stop-time) or when they are terminated.
	Subscriptions that were established by configuration need to be		Subscriptions that were established by configuration need to be
	deleted from the configuration by a configuration editing operation		deleted from the configuration by a configuration editing operation
	even if the stop time has been passed.		even if the stop time has been passed.
	2.9. Advertisement		2.9. Advertisement
	Publishers supporting this document MUST indicate support the YANG		Publishers supporting this document MUST indicate support of the YANG
	model "ietf-subscribed-notifications" within the YANG library of the		model "ietf-subscribed-notifications" within the YANG library of the
	publisher. In addition support for optional features: "encode-xml",		publisher. In addition support for optional features: "encode-xml",
	"encode-json", "configured" "supports-vrf", and "replay" MUST also be		"encode-json", "configured" "supports-vrf", and "replay" MUST also be
	indicated if supported.		indicated if supported.
	If a publisher supports this specification but not subscriptions via		If a publisher supports this specification but not subscriptions via
	[RFC5277], the publisher MUST NOT advertise		[RFC5277], the publisher MUST NOT advertise
	"urn:ietf:params:netconf:capability:notification:1.0". Even without		"urn:ietf:params:netconf:capability:notification:1.0". Even without
	this advertisement however, the publisher MUST support the one-way		this advertisement however, the publisher MUST support the one-way
	notification element of [RFC5277] Section 4.		notification element of [RFC5277] Section 4.
	skipping to change at page 26, line 50 ¶		skipping to change at page 26, line 50 ¶
	+--ro port inet:port-number		+--ro port inet:port-number
	+--ro pushed-notifications? yang:counter64		+--ro pushed-notifications? yang:counter64
	+--ro excluded-notifications? yang:counter64		+--ro excluded-notifications? yang:counter64
	+--ro state enumeration		+--ro state enumeration
	+---x reset		+---x reset
	+--ro output		+--ro output
	+--ro time yang:date-and-time		+--ro time yang:date-and-time
	4. Data Model		4. Data Model
	<CODE BEGINS> file "ietf-subscribed-notifications@2018-01-25.yang"		<CODE BEGINS> file "ietf-subscribed-notifications@2018-02-23.yang"
	module ietf-subscribed-notifications {		module ietf-subscribed-notifications {
	yang-version 1.1;		yang-version 1.1;
	namespace		namespace
	"urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications";		"urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications";
	prefix sn;		prefix sn;
	import ietf-yang-types {		import ietf-yang-types {
	prefix yang;		prefix yang;
	}		}
	skipping to change at page 27, line 49 ¶		skipping to change at page 27, line 49 ¶
	Editor: Einar Nilsen-Nygaard		Editor: Einar Nilsen-Nygaard
	<mailto:einarnn@cisco.com>		<mailto:einarnn@cisco.com>
	Editor: Ambika Prasad Tripathy		Editor: Ambika Prasad Tripathy
	<mailto:ambtripa@cisco.com>";		<mailto:ambtripa@cisco.com>";
	description		description
	"Contains a YANG specification for subscribing to event records		"Contains a YANG specification for subscribing to event records
	and receiving matching content within notification messages.";		and receiving matching content within notification messages.";
	revision 2018-01-25 {		revision 2018-02-23 {
	description		description
	"Initial version";		"Initial version";
	reference		reference
	"draft-ietf-netconf-subscribed-notifications-09";		"draft-ietf-netconf-subscribed-notifications-10";
	}		}
	/*		/*
	* FEATURES		* FEATURES
	*/		*/
	feature encode-json {		feature encode-json {
	description		description
	"This feature indicates that JSON encoding of notification		"This feature indicates that JSON encoding of notification
	messages is supported.";		messages is supported.";
	skipping to change at page 36, line 31 ¶		skipping to change at page 36, line 31 ¶
	grouping subscription-policy-modifiable {		grouping subscription-policy-modifiable {
	description		description
	"This grouping describes all objects which may be changed		"This grouping describes all objects which may be changed
	in a subscription via an RPC.";		in a subscription via an RPC.";
	choice target {		choice target {
	mandatory true;		mandatory true;
	description		description
	"Identifies the source of information against which a		"Identifies the source of information against which a
	subscription is being applied, as well as specifics on the		subscription is being applied, as well as specifics on the
	subset of information desired from that source. This choice		subset of information desired from that source.";
	exists so that additional filter types can be added via
	augmentation.";
	case stream {		case stream {
	choice stream-filter {		choice stream-filter {
	description		description
	"An event stream filter can be applied to a subscription.		"An event stream filter can be applied to a subscription.
	That filter will come either referenced from a global list,		That filter will come either referenced from a global list,
	or be provided within the subscription itself.";		or be provided within the subscription itself.";
	case by-reference {		case by-reference {
	description		description
	"Apply a filter that has been configured separately.";		"Apply a filter that has been configured separately.";
	leaf stream-filter-ref {		leaf stream-filter-ref {
	skipping to change at page 37, line 6 ¶		skipping to change at page 37, line 4 ¶
	mandatory true;		mandatory true;
	description		description
	"References an existing stream-filter which is to		"References an existing stream-filter which is to
	be applied to stream for the subscription.";		be applied to stream for the subscription.";
	}		}
	}		}
	case within-subscription {		case within-subscription {
	description		description
	"Local definition allows a filter to have the same		"Local definition allows a filter to have the same
	lifecycle as the subscription.";		lifecycle as the subscription.";
	uses stream-filter-elements;		uses stream-filter-elements;
	}		}
	}		}
	}		}
	}		}
	leaf stop-time {		leaf stop-time {
	type yang:date-and-time;		type yang:date-and-time;
	description		description
	"Identifies a time after which notification messages for a		"Identifies a time after which notification messages for a
	subscription should not be sent. If stop-time is not present,		subscription should not be sent. If stop-time is not present,
	the notification messages will continue until the subscription		the notification messages will continue until the subscription
	is terminated. If replay-start-time exists, stop-time must be		is terminated. If replay-start-time exists, stop-time must be
	for a subsequent time. If replay-start-time doesn't exist,		for a subsequent time. If replay-start-time doesn't exist,
	stop-time must be for a future time.";		stop-time must be for a future time.";
	}		}
	}		}
	grouping subscription-policy-dynamic {		grouping subscription-policy-dynamic {
	description		description
	"This grouping describes information concerning a subscription		"This grouping describes information concerning a subscription
	which can be passed over the RPCs defined in this model.";		which can just be passed over the RPCs defined in this model.";
	leaf encoding {		leaf encoding {
	type encoding;		type encoding;
	mandatory true;		mandatory true;
	description		description
	"The type of encoding for the subscribed data.";		"The type of encoding for the subscribed data.";
	}		}
	uses subscription-policy-modifiable {		uses subscription-policy-modifiable {
	augment target/stream {		augment target/stream {
	description		description
	"Adds additional objects which can be modified by RPC.";		"Adds additional objects which can be modified by RPC.";
	skipping to change at page 52, line 11 ¶		skipping to change at page 52, line 9 ¶
	An implementation may choose to transition between active and		An implementation may choose to transition between active and
	suspended subscription states more frequently than required by this		suspended subscription states more frequently than required by this
	specification. However if a subscription is unable to marshal all		specification. However if a subscription is unable to marshal all
	intended updates into a transmittable message in multiple successive		intended updates into a transmittable message in multiple successive
	intervals, the subscription SHOULD be suspended with the reason		intervals, the subscription SHOULD be suspended with the reason
	"unsupportable-volume".		"unsupportable-volume".
	For configured subscriptions, operations are against the set of		For configured subscriptions, operations are against the set of
	receivers using the subscription identifier as a handle for that set.		receivers using the subscription identifier as a handle for that set.
	But for streaming up dates, state change notifications are local to a		But for streaming updates, state change notifications are local to a
	receiver. In this specification it is the case that receivers get no		receiver. In this specification it is the case that receivers get no
	information from the publisher about the existence of other		information from the publisher about the existence of other
	receivers. But if an operator wants to let the receivers correlate		receivers. But if an operator wants to let the receivers correlate
	results, it is useful to use the subscription identifier handle		results, it is useful to use the subscription identifier handle
	across the receivers to allow that correlation.		across the receivers to allow that correlation.
	5.2. IANA Considerations		5.2. IANA Considerations
	This document registers the following namespace URI in the "IETF XML		This document registers the following namespace URI in the "IETF XML
	Registry" [RFC3688]:		Registry" [RFC3688]:
	skipping to change at page 55, line 17 ¶		skipping to change at page 55, line 15 ¶
	[I-D.draft-ietf-netconf-netconf-event-notifications]		[I-D.draft-ietf-netconf-netconf-event-notifications]
	Clemm, Alexander., Voit, Eric., Gonzalez Prieto, Alberto.,		Clemm, Alexander., Voit, Eric., Gonzalez Prieto, Alberto.,
	Nilsen-Nygaard, E., Tripathy, A., Chisholm, S., and H.		Nilsen-Nygaard, E., Tripathy, A., Chisholm, S., and H.
	Trevino, "NETCONF support for event notifications",		Trevino, "NETCONF support for event notifications",
	October 2017, <https://datatracker.ietf.org/doc/		October 2017, <https://datatracker.ietf.org/doc/
	draft-ietf-netconf-netconf-event-notifications/>.		draft-ietf-netconf-netconf-event-notifications/>.
	[I-D.draft-ietf-netconf-restconf-notif]		[I-D.draft-ietf-netconf-restconf-notif]
	Voit, Eric., Clemm, Alexander., Tripathy, A., Nilsen-		Voit, Eric., Clemm, Alexander., Tripathy, A., Nilsen-
	Nygaard, E., and Alberto. Gonzalez Prieto, "Restconf and		Nygaard, E., and Alberto. Gonzalez Prieto, "Restconf and
	HTTP transport for event notifications", August 2016,		HTTP transport for event notifications", January 2018,
	<https://datatracker.ietf.org/doc/		<https://datatracker.ietf.org/doc/
	draft-ietf-netconf-restconf-notif/>.		draft-ietf-netconf-restconf-notif/>.
	[I-D.ietf-netconf-yang-push]		[I-D.ietf-netconf-yang-push]
	Clemm, Alexander., Voit, Eric., Gonzalez Prieto, Alberto.,		Clemm, Alexander., Voit, Eric., Gonzalez Prieto, Alberto.,
	Tripathy, A., Nilsen-Nygaard, E., Bierman, A., and B.		Tripathy, A., Nilsen-Nygaard, E., Bierman, A., and B.
	Lengyel, "YANG Datastore Subscription", December 2017,		Lengyel, "YANG Datastore Subscription", December 2017,
	<https://datatracker.ietf.org/doc/		<https://datatracker.ietf.org/doc/
	draft-ietf-netconf-yang-push/>.		draft-ietf-netconf-yang-push/>.
	skipping to change at page 55, line 52 ¶		skipping to change at page 55, line 50 ¶
	<https://www.rfc-editor.org/info/rfc7923>.		<https://www.rfc-editor.org/info/rfc7923>.
	[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>.
	Appendix A. Changes between revisions		Appendix A. Changes between revisions
	(To be removed by RFC editor prior to publication)		(To be removed by RFC editor prior to publication)
			v09 - v10
			o Typos and tweaks
	v08 - v09		v08 - v09
	o NMDA model supported. Non NMDA version at https://github.com/		o NMDA model supported. Non NMDA version at https://github.com/
	netconf-wg/rfc5277bis/		netconf-wg/rfc5277bis/
	o Error mechanism revamped to match to embedded implementations.		o Error mechanism revamped to match to embedded implementations.
	o Explicitly identified error codes relevant to each RPC/		o Explicitly identified error codes relevant to each RPC/
	Notification		Notification
	v07 - v08		v07 - v08
End of changes. 34 change blocks.
	52 lines changed or deleted		65 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/