draft-ietf-netconf-distributed-notif-00.txt		draft-ietf-netconf-distributed-notif-01.txt
	NETCONF T. Zhou		NETCONF T. Zhou
	Internet-Draft G. Zheng		Internet-Draft G. Zheng
	Intended status: Standards Track Huawei		Intended status: Standards Track Huawei
	Expires: April 6, 2021 E. Voit		Expires: May 6, 2021 E. Voit
	Cisco Systems		Cisco Systems
	T. Graf		T. Graf
	Swisscom		Swisscom
	P. Francois		P. Francois
	INSA-Lyon		INSA-Lyon
	October 3, 2020		November 02, 2020
	Subscription to Distributed Notifications		Subscription to Distributed Notifications
	draft-ietf-netconf-distributed-notif-00		draft-ietf-netconf-distributed-notif-01
	Abstract		Abstract
	This documents describes extensions to the YANG notifications		This documents describes extensions to the YANG notifications
	subscription to allow metrics being published directly from		subscription to allow metrics being published directly from
	processors on line cards to target receivers, while subscription is		processors on line cards to target receivers, while subscription is
	still maintained at the route processor in a distributed forwarding		still maintained at the route processor in a distributed forwarding
	system.		system.
	Requirements Language		Requirements Language
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 6, 2021.		This Internet-Draft will expire on May 6, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4		3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Subscription Decomposition . . . . . . . . . . . . . . . . . 6		4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
	5. Publication Composition . . . . . . . . . . . . . . . . . . . 6		5. Subscription Decomposition . . . . . . . . . . . . . . . . . 6
	6. Subscription State Change Notifications . . . . . . . . . . . 7		6. Publication Composition . . . . . . . . . . . . . . . . . . . 6
	7. Publisher Configurations . . . . . . . . . . . . . . . . . . 7		7. Subscription State Change Notifications . . . . . . . . . . . 7
	8. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . . . 7		8. Publisher Configurations . . . . . . . . . . . . . . . . . . 7
	9. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 7		9. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		10. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 8
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 10		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11		12. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11		13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
	14.1. Normative References . . . . . . . . . . . . . . . . . . 11		15. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	14.2. Informative References . . . . . . . . . . . . . . . . . 12		15.1. Normative References . . . . . . . . . . . . . . . . . . 11
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 12		15.2. Informative References . . . . . . . . . . . . . . . . . 12
	A.1. Dynamic Subscription . . . . . . . . . . . . . . . . . . 12		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13
	A.2. Configured Subscription . . . . . . . . . . . . . . . . . 16		A.1. Dynamic Subscription . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18		A.2. Configured Subscription . . . . . . . . . . . . . . . . . 17
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	The mechanism to support a subscription to a continuous and		The mechanism to support a subscription to a continuous and
	customized stream of updates from a YANG datastore is defined in		customized stream of updates from a YANG datastore is defined in
	[RFC8639] and [RFC8641]. Requirements for Subscription to YANG		[RFC8639] and [RFC8641]. Requirements for Subscription to YANG
	Datastores are defined in [RFC7923]		Datastores are defined in [RFC7923]
	By streaming data from publishers to receivers, much better		By streaming data from publishers to receivers, much better
	performance and fine-grained sampling can be achieved than with		performance and fine-grained sampling can be achieved than with
	skipping to change at page 4, line 5 ¶		skipping to change at page 4, line 5 ¶
	Component Capability: is the subscription capability that each		Component Capability: is the subscription capability that each
	Publisher can expose to the Subscriber.		Publisher can expose to the Subscriber.
	Master: is the Publisher that interacts with the Subscriber to deal		Master: is the Publisher that interacts with the Subscriber to deal
	with the Global Subscription. It decomposes the Global Subscription		with the Global Subscription. It decomposes the Global Subscription
	to multiple Component Subscriptions and interacts with the Agents.		to multiple Component Subscriptions and interacts with the Agents.
	Agent: is the Publisher that interacts with the Master to deal with		Agent: is the Publisher that interacts with the Master to deal with
	the Component Subscription and pushing the data to the collector.		the Component Subscription and pushing the data to the collector.
	3. Solution Overview		Observation Domain: An Observation Domain is the largest set of
			Observation Points for which metrics can be collected by a metering
			process. For example, a router line card may be an Observation
			Domain if it is composed of several interfaces, each of which is an
			Observation Point. In the YANG notification messages it generates,
			the Observation Domain includes its Observation Domain ID, which is
			unique per publisher process. That way, the collecting process can
			identify the specific Observation Domain from the publisher that
			sends the YANG notification messages. Every Observation Point is
			associated with an Observation Domain.
			Observation Domain ID: A 32-bit identifier of the Observation Domain
			that is locally unique to the publisher process. The publisher
			process uses the Observation Domain ID to uniquely identify to the
			collecting process the Observation Domain that meters the metrics.
			Receivers SHOULD use the transport session and the Observation Domain
			ID field to separate different publisher streams originating from the
			same publisher.
			3. Motivation
			Lost and corrupt YANG notification messages need to be recognized at
			the receiver to ensure data integrity even when multiple publisher
			processes publishing from the same transport session.
			To preserve data integrity down to the publisher process, the
			Observation Domain ID in the transport message header of the YANG
			notification message is introduced. In case of UDP transport, this
			is described in Section 3.2 of UDP based transport
			[I-D.ietf-netconf-udp-notif].
			4. Solution Overview
	Figure 2 below shows the distributed data export framework.		Figure 2 below shows the distributed data export framework.
	A collector usually includes two components,		A collector usually includes two components,
	o the Subscriber generates the subscription instructions to express		o the Subscriber generates the subscription instructions to express
	what and how the collector want to receive the data;		what and how the collector want to receive the data;
	o the Receiver is the target for the data publication.		o the Receiver is the target for the data publication.
	skipping to change at page 6, line 5 ¶		skipping to change at page 6, line 16 ¶
	o The Agents announce the status of their Component Subscriptions to		o The Agents announce the status of their Component Subscriptions to
	the Master. The status of the overall subscription is maintained		the Master. The status of the overall subscription is maintained
	by the Master. The Master is responsible for notifying the		by the Master. The Master is responsible for notifying the
	subscriber in case of problems with the Component Subscriptions.		subscriber in case of problems with the Component Subscriptions.
	The technical mechanisms or protocols used for the coordination of		The technical mechanisms or protocols used for the coordination of
	operational information between Master and Agent is out-of-scope of		operational information between Master and Agent is out-of-scope of
	this document.		this document.
	4. Subscription Decomposition		5. Subscription Decomposition
	The Collector can only subscribe to the Master. This requires the		The Collector can only subscribe to the Master. This requires the
	Master to:		Master to:
	1. expose the Global Capability that can be served by multiple		1. expose the Global Capability that can be served by multiple
	Publisher Agents;		Publisher Agents;
	2. disassemble the Global Subscription to multiple Component		2. disassemble the Global Subscription to multiple Component
	Subscriptions, and distribute them to the Publisher Agents of the		Subscriptions, and distribute them to the Publisher Agents of the
	corresponding metric sources so that they not overlap;		corresponding metric sources so that they not overlap;
	skipping to change at page 6, line 29 ¶		skipping to change at page 6, line 40 ¶
	And the Agent to:		And the Agent to:
	o Inherit the Global Subscription properties from Publisher Master		o Inherit the Global Subscription properties from Publisher Master
	for its Component Subscription;		for its Component Subscription;
	o share the same life-cycle as the Global Subscription;		o share the same life-cycle as the Global Subscription;
	o share the same Subscription ID as the Global Subscription.		o share the same Subscription ID as the Global Subscription.
	5. Publication Composition		6. Publication Composition
	The Publisher Agent collects data and encapsulates the packets per		The Publisher Agent collects data and encapsulates the packets per
	Component Subscription. The format and structure of the data records		Component Subscription. The format and structure of the data records
	are defined by the YANG schema, so that the decomposition at the		are defined by the YANG schema, so that the decomposition at the
	Receiver can benefit from the structured and hierarchical data		Receiver can benefit from the structured and hierarchical data
	records.		records.
	The Receiver is able to associate the YANG data records with		The Receiver is able to associate the YANG data records with
	Subscription ID [RFC8639] to the subscribed subscription and with		Subscription ID [RFC8639] to the subscribed subscription and with
	Message Generator ID [I-D.ietf-netconf-notification-messages] to one		Message Observation Domain ID
	of the Publisher Agents software processes to enable message		[I-D.ietf-netconf-notification-messages] to one of the Publisher
	integrity.		Agents software processes to enable message integrity.
	For the dynamic subscription, the output of the "establish-		For the dynamic subscription, the output of the "establish-
	subscription" RPC defined in [RFC8639] MUST include a list of Message		subscription" RPC defined in [RFC8639] MUST include a list of Message
	Generator IDs to indicate how the Global Subscription is decomposed		Observation Domain IDs to indicate how the Global Subscription is
	into several Component Subscriptions.		decomposed into several Component Subscriptions.
	The "subscription-started" and "subscription-modified" notification		The "subscription-started" and "subscription-modified" notification
	defined in [RFC8639] MUST also include a list of Message Generator		defined in [RFC8639] MUST also include a list of Message Observation
	IDs to notify the current Publishers for the corresponding Global		Domain IDs to notify the current Publishers for the corresponding
	Subscription.		Global Subscription.
	6. Subscription State Change Notifications		7. Subscription State Change Notifications
	In addition to sending event records to Receivers, the Master MUST		In addition to sending event records to Receivers, the Master MUST
	also send subscription state change notifications [RFC8639] when		also send subscription state change notifications [RFC8639] when
	events related to subscription management have occurred. All the		events related to subscription management have occurred. All the
	subscription state change notifications MUST be delivered by the		subscription state change notifications MUST be delivered by the
	Master.		Master.
	When the subscription decomposition result changed, the		When the subscription decomposition result changed, the
	"subscription-modified" notification MUST be sent to indicate the new		"subscription-modified" notification MUST be sent to indicate the new
	list of Publishers.		list of Publishers.
	7. Publisher Configurations		8. Publisher Configurations
	This document assumes that all Publisher Agents are preconfigured to		This document assumes that all Publisher Agents are preconfigured to
	push data. The actual working Publisher Agents are selected based on		push data. The actual working Publisher Agents are selected based on
	the subscription decomposition result.		the subscription decomposition result.
	All Publisher Agents share the same source IP address for data		All Publisher Agents share the same source IP address for data
	export. For connectionless data transport such as UDP based		export. For connectionless data transport such as UDP based
	transport [I-D.unyte-netconf-udp-notif] the same Layer 4 source port		transport [I-D.ietf-netconf-udp-notif] the same Layer 4 source port
	for data export can be used. For connection based data transport		for data export can be used. For connection based data transport
	such as HTTPS based transport [I-D.ietf-netconf-https-notif], each		such as HTTPS based transport [I-D.ietf-netconf-https-notif], each
	Publisher Agent MUST be able to acknowledge packet retrieval from		Publisher Agent MUST be able to acknowledge packet retrieval from
	Receivers, and therefore requires a dedicated Layer 4 source port per		Receivers, and therefore requires a dedicated Layer 4 source port per
	software process.		software process.
	The specific configuration on transports is described in the		The specific configuration on transports is described in the
	resposible documents.		resposible documents.
	8. YANG Tree		9. YANG Tree
	module: ietf-distributed-notifications		module: ietf-distributed-notifications
	augment /sn:subscriptions/sn:subscription:		augment /sn:subscriptions/sn:subscription:
	+--ro message-generator-id* string		+--ro message-observation-domain-id* string
	augment /sn:subscription-started:		augment /sn:subscription-started:
	+--ro message-generator-id* string		+--ro message-observation-domain-id* string
	augment /sn:subscription-modified:		augment /sn:subscription-modified:
	+--ro message-generator-id* string		+--ro message-observation-domain-id* string
	augment /sn:establish-subscription/sn:output:		augment /sn:establish-subscription/sn:output:
	+--ro message-generator-id* string		+--ro message-observation-domain-id* string
	9. YANG Module		10. YANG Module
	<CODE BEGINS> file "ietf-distributed-notifications@2020-05-09.yang"		<CODE BEGINS> file "ietf-distributed-notifications@2020-05-09.yang"
	module ietf-distributed-notif {		module ietf-distributed-notif {
	yang-version 1.1;		yang-version 1.1;
	namespace		namespace
	"urn:ietf:params:xml:ns:yang:ietf-distributed-notifications";		"urn:ietf:params:xml:ns:yang:ietf-distributed-notifications";
	prefix mso;		prefix mso;
	import ietf-subscribed-notifications {		import ietf-subscribed-notifications {
	prefix sn;		prefix sn;
	}		}
	skipping to change at page 8, line 45 ¶		skipping to change at page 9, line 15 ¶
	This version of this YANG module is part of RFC XXXX; see the		This version of this YANG module is part of RFC XXXX; see the
	RFC itself for full legal notices.";		RFC itself for full legal notices.";
	revision 2020-05-09 {		revision 2020-05-09 {
	description		description
	"Initial version";		"Initial version";
	reference		reference
	"RFC XXXX: Subscription to Distributed Notifications";		"RFC XXXX: Subscription to Distributed Notifications";
	}		}
	grouping message-generator-ids {		grouping message-observation-domain-ids {
	description		description
	"Provides a reusable list of message-generator-ids.";		"Provides a reusable list of message-observation-domain-ids.";
	leaf-list message-generator-id {		leaf-list message-observation-domain-id {
	type string;		type string;
	config false;		config false;
	ordered-by user;		ordered-by user;
	description		description
	"Software process which created the message (e.g.,		"Software process which created the message (e.g.,
	processor 1 on linecard 1). This field is		processor 1 on linecard 1). This field is
	used to notify the collector the working originator.";		used to notify the collector the working originator.";
	}		}
	}		}
	augment "/sn:subscriptions/sn:subscription" {		augment "/sn:subscriptions/sn:subscription" {
	description		description
	"This augmentation allows the message generators to be		"This augmentation allows the message
	exposed for a subscription.";		Observation Domain ID to be exposed for a subscription.";
	uses message-generator-ids;		uses message-observation-domain-ids;
	}		}
	augment "/sn:subscription-started" {		augment "/sn:subscription-started" {
	description		description
	"This augmentation allows MSO specific parameters to be		"This augmentation allows MSO specific parameters to be
	exposed for a subscription.";		exposed for a subscription.";
	uses message-generator-ids;		uses message-observation-domain-ids;
	}		}
	augment "/sn:subscription-modified" {		augment "/sn:subscription-modified" {
	description		description
	"This augmentation allows MSO specific parameters to be		"This augmentation allows MSO specific parameters to be
	exposed for a subscription.";		exposed for a subscription.";
	uses message-generator-ids;		uses message-observation-domain-ids;
	}		}
	augment "/sn:establish-subscription/sn:output" {		augment "/sn:establish-subscription/sn:output" {
	description		description
	"This augmentation allows MSO specific parameters to be		"This augmentation allows MSO specific parameters to be
	exposed for a subscription.";		exposed for a subscription.";
	uses message-generator-ids;		uses message-observation-domain-ids;
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	10. IANA Considerations		11. 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]:
	URI: urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications		URI: urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications
	Registrant Contact: The IESG.		Registrant Contact: The IESG.
	XML: N/A; the requested URI is an XML namespace.		XML: N/A; the requested URI is an XML namespace.
	skipping to change at page 10, line 23 ¶		skipping to change at page 10, line 37 ¶
	Name: ietf-subscribed-notifications		Name: ietf-subscribed-notifications
	Namespace: urn:ietf:params:xml:ns:yang:ietf-subscribed-		Namespace: urn:ietf:params:xml:ns:yang:ietf-subscribed-
	notifications		notifications
	Prefix: mso		Prefix: mso
	Reference: RFC XXXX		Reference: RFC XXXX
	11. Security Considerations		12. Security Considerations
	The YANG module specified in this document defines a schema for data		The YANG module specified in this document defines a schema for data
	that is designed to be accessed via network management protocols such		that is designed to be accessed via network management protocols such
	as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer		as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
	is the secure transport layer, and the mandatory-to-implement secure		is the secure transport layer, and the mandatory-to-implement secure
	transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer		transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
	is HTTPS, and the mandatory-to-implement secure transport is TLS		is HTTPS, and the mandatory-to-implement secure transport is TLS
	[RFC5246].		[RFC5246].
	The NETCONF Access Control Model (NACM) [RFC6536] provides the means		The NETCONF Access Control Model (NACM) [RFC6536] provides the means
	to restrict access for particular NETCONF or RESTCONF users to a		to restrict access for particular NETCONF or RESTCONF users to a
	preconfigured subset of all available NETCONF or RESTCONF protocol		preconfigured subset of all available NETCONF or RESTCONF protocol
	operations and content.		operations and content.
	The new data nodes introduced in this YANG module may be considered		The new data nodes introduced in this YANG module may be considered
	sensitive or vulnerable in some network environments. It is thus		sensitive or vulnerable in some network environments. It is thus
	important to control read access (e.g., via get-config or		important to control read access (e.g., via get-config or
	notification) to this data nodes. These are the subtrees and data		notification) to this data nodes. These are the subtrees and data
	nodes and their sensitivity/vulnerability:		nodes and their sensitivity/vulnerability:
	o /subscriptions/subscription/message-generator-ids		o /subscriptions/subscription/message-observation-domain-ids
	The entries in the two lists above will show where subscribed		The entries in the two lists above will show where subscribed
	resources might be located on the publishers. Access control MUST be		resources might be located on the publishers. Access control MUST be
	set so that only someone with proper access permissions has the		set so that only someone with proper access permissions has the
	ability to access this resource.		ability to access this resource.
	Other Security Considerations is the same as those discussed in YANG-		Other Security Considerations is the same as those discussed in YANG-
	Push [RFC8641].		Push [RFC8641].
	12. Contributors		13. Contributors
	Alexander Clemm		Alexander Clemm
	Futurewai		Futurewai
	2330 Central Expressway		2330 Central Expressway
	Santa Clara		Santa Clara
	California		California
	United States of America		United States of America
	Email: ludwig@clemm.org		Email: ludwig@clemm.org
	13. Acknowledgements		14. Acknowledgements
	We thank Kent Watsen, Mahesh Jethanandani, Martin Bjorklund, Tim		We thank Kent Watsen, Mahesh Jethanandani, Martin Bjorklund, Tim
	Carey and Qin Wu for their constructive suggestions for improving		Carey and Qin Wu for their constructive suggestions for improving
	this document.		this document.
	14. References		15. References
	14.1. Normative References		15.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[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>.
	skipping to change at page 12, line 23 ¶		skipping to change at page 12, line 42 ¶
	[RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,		[RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
	E., and A. Tripathy, "Subscription to YANG Notifications",		E., and A. Tripathy, "Subscription to YANG Notifications",
	RFC 8639, DOI 10.17487/RFC8639, September 2019,		RFC 8639, DOI 10.17487/RFC8639, September 2019,
	<https://www.rfc-editor.org/info/rfc8639>.		<https://www.rfc-editor.org/info/rfc8639>.
	[RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications		[RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications
	for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,		for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
	September 2019, <https://www.rfc-editor.org/info/rfc8641>.		September 2019, <https://www.rfc-editor.org/info/rfc8641>.
	14.2. Informative References		15.2. Informative References
	[I-D.ietf-netconf-https-notif]		[I-D.ietf-netconf-https-notif]
	Jethanandani, M. and K. Watsen, "An HTTPS-based Transport		Jethanandani, M. and K. Watsen, "An HTTPS-based Transport
	for Configured Subscriptions", draft-ietf-netconf-https-		for Configured Subscriptions", draft-ietf-netconf-https-
	notif-04 (work in progress), July 2020.		notif-05 (work in progress), October 2020.
	[I-D.ietf-netconf-notification-messages]		[I-D.ietf-netconf-notification-messages]
	Voit, E., Jenkins, T., Birkholz, H., Bierman, A., and A.		Voit, E., Jenkins, T., Birkholz, H., Bierman, A., and A.
	Clemm, "Notification Message Headers and Bundles", draft-		Clemm, "Notification Message Headers and Bundles", draft-
	ietf-netconf-notification-messages-08 (work in progress),		ietf-netconf-notification-messages-08 (work in progress),
	November 2019.		November 2019.
	[I-D.unyte-netconf-udp-notif]		[I-D.ietf-netconf-udp-notif]
	Zhou, T., Zheng, G., Lucente, P., Graf, T., and P.		Zhou, T., Zheng, G., Lucente, P., Graf, T., and P.
	Francois, "UDP-based Transport for Configured		Francois, "UDP-based Transport for Configured
	Subscriptions", draft-unyte-netconf-udp-notif-00 (work in		Subscriptions", draft-ietf-netconf-udp-notif-01 (work in
	progress), July 2020.		progress), July 2020.
	Appendix A. Examples		Appendix A. Examples
	This appendix is non-normative.		This appendix is non-normative.
	A.1. Dynamic Subscription		A.1. Dynamic Subscription
	Figure 3 shows a typical dynamic subscription to the device with		Figure 3 shows a typical dynamic subscription to the device with
	distributed data export capability.		distributed data export capability.
	+-------------+ +-------------+ +-------------+		+-------------+ +-------------+ +-------------+
	| Subscriber/ | | Publisher | | Publisher |		| Subscriber/ | | Publisher | | Publisher |
	| Receiver | | (Master) | | (Agent) |		| Receiver | | (Master) | | (Agent) |
	+-------------+ +------+------+ +------+------+		+-------------+ +------+------+ +------+------+
	| | |		| | |
	| establish-subscription | |		| establish-subscription | |
	+------------------------------>+ component |		+------------------------------>+ component |
	| | subscription |		| | subscription |
	| RPC Reply: OK, id #22 +-------------->+		| RPC Reply: OK, id #22 +-------------->+
	| message generator ID [#1, #2] | |		| Observation Domain ID [#1,#2] | |
	+<------------------------------+ |		+<------------------------------+ |
	| | |		| | |
	| notif-mesg, id #22 | |		| notif-mesg, id #22 | |
	| message generator ID #1 | |		| Observation Domain ID #1 | |
	+<------------------------------+ |		+<------------------------------+ |
	| | |		| | |
	| notif-mesg, id#22 | |		| notif-mesg, id#22 | |
	| message generator ID #2 | |		| Observation Domain ID #2 | |
	+<----------------------------------------------+		+<----------------------------------------------+
	| | |		| | |
	| modify-subscription (id#22) | |		| modify-subscription (id#22) | |
	+------------------------------>+ component |		+------------------------------>+ component |
	| | subscription |		| | subscription |
	| RPC Reply: OK, id #22 +-------------->+		| RPC Reply: OK, id #22 +-------------->+
	+<------------------------------+ |		+<------------------------------+ |
	| | |		| | |
	| subscription-modified, id#22 | |		| subscription-modified, id#22 | |
	| message generator ID [#1] | |		| Observation Domain ID [#1] | |
	+<------------------------------+ |		+<------------------------------+ |
	| | |		| | |
	| notif-mesg, id #22 | |		| notif-mesg, id #22 | |
	| message generator ID #1 | |		| Observation Domain ID #1 | |
	+<------------------------------+ |		+<------------------------------+ |
	| | |		| | |
	| | |		| | |
	+ + +		+ + +
	Fig. 3 Call Flow for Dynamic Subscription		Fig. 3 Call Flow for Dynamic Subscription
	A "establish-subscription" RPC request as per [RFC8641] is sent to		A "establish-subscription" RPC request as per [RFC8641] is sent to
	the Master with a successful response. An example of using NETCONF:		the Master with a successful response. An example of using NETCONF:
	skipping to change at page 14, line 29 ¶		skipping to change at page 15, line 29 ¶
	<yp:period>500</yp:period>		<yp:period>500</yp:period>
	</yp:periodic>		</yp:periodic>
	</establish-subscription>		</establish-subscription>
	</netconf:rpc>		</netconf:rpc>
	Fig. 4 "establish-subscription" Request		Fig. 4 "establish-subscription" Request
	As the device is able to fully satisfy the request, the request is		As the device is able to fully satisfy the request, the request is
	given a subscription ID of 22. The response as in Figure 5 indicates		given a subscription ID of 22. The response as in Figure 5 indicates
	that the subscription is decomposed into two component subscriptions		that the subscription is decomposed into two component subscriptions
	which will be published by two message generators: #1 and #2.		which will be published by two message Observation Domain ID: #1 and
			#2.
	<rpc-reply message-id="101"		<rpc-reply message-id="101"
	xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">		xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
	<id		<id
	xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">		xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
	22		22
	</id>		</id>
	<message-generator-id		<message-observation-domain-id
	xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications>		xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications>
	1		1
	</message-generator-id>		</message-observation-domain-id>
	<message-generator-id		<message-observation-domain-id
	xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications>		xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications>
	2		2
	</message-generator-id>		</message-observation-domain-id>
	</rpc-reply>		</rpc-reply>
	Fig. 5 "establish-subscription" Positive RPC Response		Fig. 5 "establish-subscription" Positive RPC Response
	Then, both Publishers send notifications with the corresponding piece		Then, both Publishers send notifications with the corresponding piece
	of data to the Receiver.		of data to the Receiver.
	The subscriber may invoke the "modify-subscription" RPC for a		The subscriber may invoke the "modify-subscription" RPC for a
	subscription it previously established. The RPC has no difference to		subscription it previously established. The RPC has no difference to
	the single publisher case as in [RFC8641]. Figure 6 provides an		the single publisher case as in [RFC8641]. Figure 6 provides an
	skipping to change at page 15, line 38 ¶		skipping to change at page 16, line 38 ¶
	</yp:periodic>		</yp:periodic>
	</modify-subscription>		</modify-subscription>
	</rpc>		</rpc>
	Fig. 6 "modify-subscription" Request		Fig. 6 "modify-subscription" Request
	If the modification is successfully accepted, the "subscription-		If the modification is successfully accepted, the "subscription-
	modified" subscription state notification is sent to the subscriber		modified" subscription state notification is sent to the subscriber
	by the Master. The notification, Figure 7 for example, indicates the		by the Master. The notification, Figure 7 for example, indicates the
	modified subscription is decomposed into one component subscription		modified subscription is decomposed into one component subscription
	which will be published by message generator #1.		which will be published by message Observation Domain #1.
	<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">		<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
	<eventTime>2007-09-01T10:00:00Z</eventTime>		<eventTime>2007-09-01T10:00:00Z</eventTime>
	<subscription-modified		<subscription-modified
	xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"		xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
	xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">		xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">
	<id>22</id>		<id>22</id>
	<yp:datastore		<yp:datastore
	xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">		xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
	ds:operational		ds:operational
	</yp:datastore>		</yp:datastore>
	<yp:datastore-xpath-filter		<yp:datastore-xpath-filter
	xmlns:ex="https://example.com/sample-data/1.0">		xmlns:ex="https://example.com/sample-data/1.0">
	/ex:bar		/ex:bar
	</yp:datastore-xpath-filter>		</yp:datastore-xpath-filter>
	<yp:periodic>		<yp:periodic>
	<yp:period>250</yp:period>		<yp:period>250</yp:period>
	</yp:periodic>		</yp:periodic>
	<message-generator-id		<message-observation-domain-id
	xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notificationss>		xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notificationss>
	1		1
	</message-generator-id>		</message-observation-domain-id>
	</subscription-modified>		</subscription-modified>
	</notification>		</notification>
	Fig. 7 "subscription-modified" Subscription State Notification		Fig. 7 "subscription-modified" Subscription State Notification
	A.2. Configured Subscription		A.2. Configured Subscription
	Figure 8 shows a typical configured subscription to the device with		Figure 8 shows a typical configured subscription to the device with
	distributed data export capability.		distributed data export capability.
	+-------------+ +-------------+ +-------------+		+-------------+ +-------------+ +-------------+
	| Receiver | | Publisher | | Publisher |		| Receiver | | Publisher | | Publisher |
	| | | (Master) | | (Agent) |		| | | (Master) | | (Agent) |
	+------+------+ +------+------+ +------+------+		+------+------+ +------+------+ +------+------+
	| | |		| | |
	| subscription-started, id#39 | |		| subscription-started, id#39 | |
	| message generator ID [#1, #2] | |		| Observation Domain ID [#1,#2] | |
	+<------------------------------+ |		+<------------------------------+ |
	| | |		| | |
	| notif-mesg, id#39 | |		| notif-mesg, id#39 | |
	| message generator ID #1 | |		| Observation Domain ID #1 | |
	+<------------------------------+ |		+<------------------------------+ |
	| | |		| | |
	| notif-mesg, id#39 | |		| notif-mesg, id#39 | |
	| message generator ID #2 | |		| Observation Domain ID #2 | |
	+<----------------------------------------------+		+<----------------------------------------------+
	| | |		| | |
	| | |		| | |
	| | |		| | |
	Fig. 8 Call Flow for Configured Subscription		Fig. 8 Call Flow for Configured Subscription
	Before starting to push data, the "subscription-started" subscription		Before starting to push data, the "subscription-started" subscription
	state notification is sent to the Receiver. The following example		state notification is sent to the Receiver. The following example
	assumes the NETCONF transport has already established. The		assumes the NETCONF transport has already established. The
	notification indicates that the configured subscription is decomposed		notification indicates that the configured subscription is decomposed
	into two component subscriptions which will be published by two		into two component subscriptions which will be published by two
	message generators: #1 and #2.		message Observation Domain: #1 and #2.
	<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">		<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
	<eventTime>2007-09-01T10:00:00Z</eventTime>		<eventTime>2007-09-01T10:00:00Z</eventTime>
	<subscription-started		<subscription-started
	xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"		xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
	xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">		xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">
	<identifier>39</identifier>		<identifier>39</identifier>
	<yp:datastore		<yp:datastore
	xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">		xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
	ds:operational		ds:operational
	</yp:datastore>		</yp:datastore>
	<yp:datastore-xpath-filter		<yp:datastore-xpath-filter
	xmlns:ex="https://example.com/sample-data/1.0">		xmlns:ex="https://example.com/sample-data/1.0">
	/ex:foo		/ex:foo
	</yp:datastore-xpath-filter>		</yp:datastore-xpath-filter>
	<yp:periodic>		<yp:periodic>
	<yp:period>250</yp:period>		<yp:period>250</yp:period>
	</yp:periodic>		</yp:periodic>
	<message-generator-id		<message-observation-domain-id
	xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications>		xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications>
	1		1
	</message-generator-id>		</message-observation-domain-id>
	<message-generator-id		<message-observation-domain-id
	xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications>		xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications>
	2		2
	</message-generator-id>		</message-observation-domain-id>
	</subscription-started>		</subscription-started>
	</notification>		</notification>
	Fig. 9 "subscription-started" Subscription State Notification		Fig. 9 "subscription-started" Subscription State Notification
	Then, both Publishers send notifications with the corresponding data		Then, both Publishers send notifications with the corresponding data
	record to the Receiver.		record to the Receiver.
	Authors' Addresses		Authors' Addresses
End of changes. 59 change blocks.
	85 lines changed or deleted		116 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/