< draft-ietf-netconf-https-notif-00.txt		draft-ietf-netconf-https-notif-01.txt >
	NETCONF M. Jethanandani		NETCONF M. Jethanandani
	Internet-Draft VMware		Internet-Draft VMware
	Intended status: Standards Track K. Watsen		Intended status: Standards Track K. Watsen
	Expires: March 20, 2020 Watsen Networks		Expires: May 2, 2020 Watsen Networks
	September 17, 2019		October 30, 2019
	An HTTPS-based Transport for Configured Subscriptions		An HTTPS-based Transport for Configured Subscriptions
	draft-ietf-netconf-https-notif-00		draft-ietf-netconf-https-notif-01
	Abstract		Abstract
	This document defines a YANG data module for configuring HTTPS based		This document defines a YANG data module for configuring HTTPS based
	configured subscription, as defined I-D.ietf-netconf-subscribed-		configured subscription, as defined in Subscribed Notifications
	notifications. The use of HTTPS maximizes transport-level		(RFC8639). The use of HTTPS maximizes transport-level
	interoperability, while allowing for encoding selection from text,		interoperability, while allowing for encoding selection from text,
	e.g. XML or JSON, to binary.		e.g. XML or JSON, to binary.
	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.
	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 March 20, 2020.		This Internet-Draft will expire on May 2, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 14 ¶		skipping to change at page 2, line 14 ¶
	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
	1.1. Note to RFC Editor . . . . . . . . . . . . . . . . . . . 3		1.1. Note to RFC Editor . . . . . . . . . . . . . . . . . . . 3
	1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3		1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
	1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	1.3.1. Subscribed Notifications . . . . . . . . . . . . . . 3		1.3.1. Subscribed Notifications . . . . . . . . . . . . . . 3
	2. YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 3		1.4. Receiver and Publisher Interaction . . . . . . . . . . . 3
	2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3		1.4.1. Pipelining of messages . . . . . . . . . . . . . . . 4
	2.2. YANG module . . . . . . . . . . . . . . . . . . . . . . . 4		2. YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Security Considerations . . . . . . . . . . . . . . . . . . . 7		2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		2.2. YANG module . . . . . . . . . . . . . . . . . . . . . . . 7
	4.1. URI Registration . . . . . . . . . . . . . . . . . . . . 7		3. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	4.2. YANG Module Name Registration . . . . . . . . . . . . . . 8		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8		4.1. URI Registration . . . . . . . . . . . . . . . . . . . . 11
	5.1. HTTPS Configured Subscription . . . . . . . . . . . . . . 8		4.2. YANG Module Name Registration . . . . . . . . . . . . . . 12
	6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10		5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10		5.1. HTTPS Configured Subscription . . . . . . . . . . . . . . 12
	8. Normative references . . . . . . . . . . . . . . . . . . . . 10		6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
			8. Normative references . . . . . . . . . . . . . . . . . . . . 14
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	Subscribed Notifications [I-D.ietf-netconf-subscribed-notifications]		Subscribed Notifications [RFC8639] defines a YANG data module for
	defines a YANG data module for configuring subscribed notifications.		configuring subscribed notifications. It even defines a
	It even defines a subscriptions container that contains a list of		subscriptions container that contains a list of receivers. But it
	receivers. But it defers the configuration and management of those		defers the configuration and management of those receivers to other
	receivers to other documents. This document defines a YANG [RFC7950]		documents. This document defines a YANG [RFC7950] data module for
	data module for configuring and managing HTTPS based receivers for		configuring and managing HTTPS based receivers for the notifications.
	the notifications. Such a configured receiver can be a third party		Such a configured receiver can be a third party collector, collecting
	collector, collecting events on behalf of receivers that want to co-		events on behalf of receivers that want to correlate events from
	relate events from different publishers. Configured subscriptions		different publishers. Configured subscriptions enable a server,
	enable a server, acting as a publisher of notifications, to		acting as a publisher of notifications, to proactively push
	proactively push notifications to external receivers without the		notifications to external receivers without the receivers needing to
	receivers needing to first connect to the server, as is the case with		first connect to the server, as is the case with dynamic
	dynamic subscriptions.		subscriptions.
	This document describes how to enable the transmission of YANG		This document describes how to enable the transmission of YANG
	modeled notifications, in the configured encoding (i.e., XML, JSON)		modeled notifications, in the configured encoding (i.e., XML, JSON)
	over HTTPS. The use of HTTPS maximizes transport-level		over HTTPS. It comes in the form of a HTTPS POST. The use of HTTPS
	interoperability, while the encoding selection pivots between		maximizes transport-level interoperability, while the encoding
	implementation simplicity (XML, JSON) and throughput (text versus		selection pivots between implementation simplicity (XML, JSON) and
	binary).		throughput (text versus binary).
	1.1. Note to RFC Editor		1.1. Note to RFC Editor
	This document uses several placeholder values throughout the		This document uses several placeholder values throughout the
	document. Please replace them as follows and remove this section		document. Please replace them as follows and remove this section
	before publication.		before publication.
	RFC XXXX, where XXXX is the number assigned to this document at the		RFC XXXX, where XXXX is the number assigned to this document at the
	time of publication.		time of publication.
	2019-09-17 with the actual date of the publication of this document.		2019-10-30 with the actual date of the publication of this document.
	1.2. Abbreviations		1.2. Abbreviations
	+---------+-------------------------------+		+---------+-------------------------------+
	| Acronym | Expansion |		| Acronym | Expansion |
	+---------+-------------------------------+		+---------+-------------------------------+
	| HTTP | Hyper Text Transport Protocol |		| HTTP | Hyper Text Transport Protocol |
	| | |		| | |
	| TCP | Transmission Control Protocol |		| TCP | Transmission Control Protocol |
	| | |		| | |
	| TLS | Transport Layer Security |		| TLS | Transport Layer Security |
	+---------+-------------------------------+		+---------+-------------------------------+
	1.3. Terminology		1.3. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 RFC2119 [RFC2119] RFC8174 [RFC8174] when, and only when, they		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	appear in all capitals, as shown here.		capitals, as shown here.
	1.3.1. Subscribed Notifications		1.3.1. Subscribed Notifications
	The following terms are defined in Subscribed Notifications		The following terms are defined in Subscribed Notifications
	[I-D.ietf-netconf-subscribed-notifications].		[RFC8639].
	o Subscribed Notifications		o Subscribed Notifications
			1.4. Receiver and Publisher Interaction
			The interaction between the receiver and the publisher can be of type
			"pipelining" or send multiple notifications as part of a "bundled-
			message", as defined in Notification Message Headers and Bundles
			[I-D.ietf-netconf-notification-messages]
			1.4.1. Pipelining of messages
			In the case of "pipelining", the flow of messages would look
			something like this.
			------------- --------------
			| Publisher | | Receiver |
			------------- --------------
			Establish TCP ------>
			Establish TLS ------>
			Send HTTPS POST message
			with YANG defined ------>
			notification #1
			Send HTTPS POST message
			with YANG defined ------>
			notification #2
			Send 204 (No Content)
			<------ for notification #1
			Send 204 (No Content)
			<------ for notification #2
			Send HTTPS POST message
			with YANG defined ------->
			notification #3
			Send 204 (No Content)
			<------ for notification #3
			The content of the exchange would look something like this.
			Request:
			POST /some/path HTTP/1.1
			Host: my-receiver.my-domain.com
			Content-Type: application/yang-data+xml
			<notification
			xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
			<eventTime>2019-03-22T12:35:00Z</eventTime>
			<foo xmlns="https://example.com/my-foobar-module">
			...
			</foo>
			</notification>
			<notification
			xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
			<eventTime>2019-03-22T12:35:00Z</eventTime>
			<bar xmlns="https://example.com/my-foobar-module">
			...
			</bar>
			</notification>
			<notification
			xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
			<eventTime>2019-03-22T12:35:01Z</eventTime>
			<baz xmlns="https://example.com/my-foobar-module">
			...
			</baz>
			</notification>
			Response:
			HTTP/1.1 204 No Content
			Date: Fri, 03 Mar 2019 12:35:00 GMT
			Server: my-receiver.my-domain.com
			HTTP/1.1 204 No Content
			Date: Fri, 03 Mar 2019 12:35:00 GMT
			Server: my-receiver.my-domain.com
			HTTP/1.1 204 No Content
			Date: Fri, 03 Mar 2019 12:35:01 GMT
			Server: my-receiver.my-domain.com
	2. YANG module		2. YANG module
	2.1. Overview		2.1. Overview
	The YANG module is a definition of a set of receivers that are		The YANG module is a definition of a set of receivers that are
	interested in the notifications published by the publisher. The		interested in the notifications published by the publisher. The
	module contains the TCP, TLS and HTTPS parameters that are needed to		module contains the TCP, TLS and HTTPS parameters that are needed to
	communicate with the receiver. The module augments the Subscribed		communicate with the receiver. The module augments the Subscribed
	Notifications [I-D.ietf-netconf-subscribed-notifications] receiver		Notifications [RFC8639] receiver container to create a reference to a
	container to create a reference to a receiver defined by the YANG		receiver defined by the YANG module. As mentioned earlier, it uses
	module.		POST method to deliver the notification. The attribute 'path'
			defines the absolute path for the resource on the receiver, as
			defined by 'path-absolute' in URI Generic Syntax [RFC3986]. The
			user-id used by Network Configuration Access Control Model [RFC8341],
			is that of the receiver and is derived from the certificate presented
			by the receiver.
	An abridged tree diagram representing the module is shown below.		An abridged tree diagram representing the module is shown below.
	module: ietf-https-notif		module: ietf-https-notif
	+--rw receivers		+--rw receivers
	+--rw receiver* [name]		+--rw receiver* [name]
	+--rw name string		+--rw name string
	+--rw tcp-params		+--rw tcp-params
	| +--rw remote-address inet:host		| +--rw remote-address inet:host
	| +--rw remote-port? inet:port-number		| +--rw remote-port? inet:port-number
	| +--rw local-address? inet:ip-address		| +--rw local-address? inet:ip-address
	| +--rw local-port? inet:port-number		| +--rw local-port? inet:port-number
	| +--rw keepalives!		| +--rw keepalives!
	| ...		| ...
	+--rw tls-params		+--rw tls-params
	| +--rw client-identity		| +--rw client-identity
	| | ...		| | ...
	| +--rw server-authentication		| +--rw server-authentication
	| | ...		| | ...
	| +--rw hello-params {tls-client-hello-params-config}?		| +--rw hello-params {tls-client-hello-params-config}?
	| | ...		| | ...
	| +--rw keepalives! {tls-client-keepalives}?		| +--rw keepalives! {tls-client-keepalives}?
	| ...		| ...
	+--rw http-params		+--rw http-params
	+--rw protocol-version? enumeration		| +--rw protocol-version? enumeration
	+--rw client-identity		| +--rw client-identity
	| ...		| | ...
	+--rw proxy-server! {proxy-connect}?		| +--rw proxy-server! {proxy-connect}?
			| | ...
			| +--rw path? inet:uri
			+--rw receiver-identity
			+--rw cert-maps
	...		...
	augment /sn:subscriptions/sn:subscription/sn:receivers/sn:receiver:		augment /sn:subscriptions/sn:subscription/sn:receivers/sn:receiver:
	+--rw receiver-ref? -> /receivers/receiver/name		+--rw receiver-ref? -> /receivers/receiver/name
	2.2. YANG module		2.2. YANG module
	The YANG module is shown below.		The YANG module imports Common YANG Data Types [RFC6991], A YANG Data
			Model for SNMP Configuration [RFC7407], and Subscription to YANG
			Notifcations [RFC8639].
	<CODE BEGINS> file "ietf-https-notif@2019-09-17.yang"		<CODE BEGINS> file "ietf-https-notif@2019-10-30.yang"
	module ietf-https-notif {		module ietf-https-notif {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-https-notif";		namespace "urn:ietf:params:xml:ns:yang:ietf-https-notif";
	prefix "hsn";		prefix "hsn";
			import ietf-inet-types {
			prefix inet;
			reference
			"RFC 6991: Common YANG Data Types.";
			}
	import ietf-subscribed-notifications {		import ietf-subscribed-notifications {
	prefix sn;		prefix sn;
	reference		reference
	"I-D.ietf-netconf-subscribed-notifications";		"I-D.ietf-netconf-subscribed-notifications";
	}		}
			import ietf-x509-cert-to-name {
			prefix x509c2n;
			reference
			"RFC 7407: A YANG Data Model for SNMP Configuration";
			}
	import ietf-tcp-client {		import ietf-tcp-client {
	prefix tcpc;		prefix tcpc;
	}		}
	import ietf-tls-client {		import ietf-tls-client {
	prefix tlsc;		prefix tlsc;
	}		}
	import ietf-http-client {		import ietf-http-client {
	prefix httpc;		prefix httpc;
	skipping to change at page 5, line 44 ¶		skipping to change at page 9, line 9 ¶
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject		without modification, is permitted pursuant to, and subject
	to the license terms contained in, the Simplified BSD		to the license terms contained in, the Simplified BSD
	License set forth in Section 4.c of the IETF Trust's Legal		License set forth in Section 4.c of the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX; see		This version of this YANG module is part of RFC XXXX; see
	the RFC itself for full legal notices.";		the RFC itself for full legal notices.";
	revision "2019-09-17" {		revision "2019-10-30" {
	description		description
	"Initial Version.";		"Initial Version.";
	reference		reference
	"RFC XXXX, YANG Data Module for HTTPS Notifications.";		"RFC XXXX, YANG Data Module for HTTPS Notifications.";
	}		}
	identity https {		identity https {
	base sn:transport;		base sn:transport;
	description		description
	"HTTPS transport for notifications.";		"HTTPS transport for notifications.";
	skipping to change at page 6, line 26 ¶		skipping to change at page 9, line 39 ¶
	"A name that uniquely identifies this receiver.";		"A name that uniquely identifies this receiver.";
	}		}
	container tcp-params {		container tcp-params {
	uses tcpc:tcp-client-grouping;		uses tcpc:tcp-client-grouping;
	description		description
	"TCP client parameters.";		"TCP client parameters.";
	}		}
	container tls-params {		container tls-params {
	uses tlsc:tls-client-grouping;
	description		description
	"TLS client parameters.";		"TLS client parameters.";
			uses tlsc:tls-client-grouping;
	}		}
	container http-params {		container http-params {
	uses httpc:http-client-grouping;
	description		description
	"HTTP client parameters.";		"HTTP client parameters.";
			uses httpc:http-client-grouping;
			leaf path {
			type inet:uri;
			description
			"The absolute path for the resource on the remote
			HTTPS server. The absolute path as specified in
			RFC 3986 as 'path-absolute'.";
			reference
			"RFC 3986: URI Generic Syntax.";
			}
			}
			container receiver-identity {
			description
			"Specifies mechanism for identifying the receiver. The
			publisher MUST NOT include any content in a notification
			that the user is not authorized to view.";
			container cert-maps {
			uses x509c2n:cert-to-name;
			description
			"The cert-maps container is used by a TLS-based HTTP
			server to map the HTTPS client's presented X.509
			certificate to a 'local' username. If no matching and
			valid cert-to-name list entry is found, the publisher
			MUST close the connection, and MUST NOT
			not send any notifications over it.";
			reference
			"RFC 7407: A YANG Data Model for SNMP Configuration.";
			}
	}		}
	description		description
	"All receivers interested in this notification.";		"All receivers interested in this notification.";
	}		}
	description		description
	"HTTPS based notifications.";		"HTTPS based notifications.";
	}		}
	augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {		augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {
	leaf receiver-ref {		leaf receiver-ref {
	skipping to change at page 8, line 4 ¶		skipping to change at page 11, line 48 ¶
	4. IANA Considerations		4. IANA Considerations
	This document registers one URI and one YANG module.		This document registers one URI and one YANG module.
	4.1. URI Registration		4.1. URI Registration
	in the IETF XML registry [RFC3688] [RFC3688]. Following the format		in the IETF XML registry [RFC3688] [RFC3688]. Following the format
	in RFC 3688, the following registration is requested to be made:		in RFC 3688, the following registration is requested to be made:
	URI: urn:ietf:params:xml:ns:yang:ietf-http-notif		URI: urn:ietf:params:xml:ns:yang:ietf-http-notif
	Registrant Contact: The IESG. XML: N/A, the requested URI is an XML		Registrant Contact: The IESG. XML: N/A, the requested URI is an XML
	namespace.		namespace.
	4.2. YANG Module Name Registration		4.2. YANG Module Name Registration
	This document registers three YANG module in the YANG Module Names		This document registers one YANG module in the YANG Module Names
	registry YANG [RFC6020].		registry YANG [RFC6020].
	name: ietf-https-notif		name: ietf-https-notif
	namespace: urn:ietf:params:xml:ns:yang:ietf-https-notif		namespace: urn:ietf:params:xml:ns:yang:ietf-https-notif
	prefix: hn		prefix: hn
	reference: RFC XXXX		reference: RFC XXXX
	5. Examples		5. Examples
	This section tries to show some examples in how the model can be		This section tries to show some examples in how the model can be
	used.		used.
	5.1. HTTPS Configured Subscription		5.1. HTTPS Configured Subscription
	This example shows how a HTTPS client can be configured to send		This example shows how a HTTPS client can be configured to send
	notifications to a receiver at address 192.0.2.1, port 443 with		notifications to a receiver at address 192.0.2.1, port 443, a 'path',
	server certificates, and the corresponding trust store that is used		with server certificates, and the corresponding trust store that is
	to authenticate a connection.		used to authenticate a connection.
	[note: '\' line wrapping for formatting only]		[note: '\' line wrapping for formatting only]
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">		<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
	<receivers		<receivers
	xmlns="urn:ietf:params:xml:ns:yang:ietf-https-notif">		xmlns="urn:ietf:params:xml:ns:yang:ietf-https-notif"
			xmlns:x509c2n="urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-n\
			ame">
	<receiver>		<receiver>
	<name>foo</name>		<name>foo</name>
	<tcp-params>		<tcp-params>
	<remote-address>192.0.2.1</remote-address>		<remote-address>my-receiver.my-domain.com</remote-address>
	<remote-port>443</remote-port>		<remote-port>443</remote-port>
	<local-address>192.0.3.1</local-address>
	<local-port>63001</local-port>
	</tcp-params>		</tcp-params>
	<tls-params>		<tls-params>
	<server-authentication>		<server-authentication>
	<ca-certs>explicitly-trusted-server-ca-certs</ca-certs>		<ca-certs>explicitly-trusted-server-ca-certs</ca-certs>
	<server-certs>explicitly-trusted-server-certs</server-ce\		<server-certs>explicitly-trusted-server-certs</server-ce\
	rts>		rts>
	</server-authentication>		</server-authentication>
	</tls-params>		</tls-params>
			<http-params>
			<client-identity>
			<basic>
			<user-id>my-name</user-id>
			<password>my-password</password>
			</basic>
			</client-identity>
			<path>/some/path</path>
			</http-params>
			<receiver-identity>
			<cert-maps>
			<cert-to-name>
			<id>1</id>
			<fingerprint>11:0A:05:11:00</fingerprint>
			<map-type>x509c2n:san-any</map-type>
			</cert-to-name>
			</cert-maps>
			</receiver-identity>
	</receiver>		</receiver>
	</receivers>		</receivers>
	<subscriptions		<subscriptions
	xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notificatio\		xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notificatio\
	ns">		ns">
	<subscription>		<subscription>
	<id>6666</id>		<id>6666</id>
	<stream-subtree-filter>foo</stream-subtree-filter>		<stream-subtree-filter>foo</stream-subtree-filter>
	<stream>some-stream</stream>		<stream>some-stream</stream>
	<receivers>		<receivers>
	<receiver>		<receiver>
	<name>my-receiver</name>		<name>my-receiver</name>
	skipping to change at page 10, line 4 ¶		skipping to change at page 14, line 19 ¶
	certificate has a chain of trust to one of these CA		certificate has a chain of trust to one of these CA
	certificates.		certificates.
	</description>		</description>
	<certificate>		<certificate>
	<name>ca.example.com</name>		<name>ca.example.com</name>
	<cert>base64encodedvalue==</cert>		<cert>base64encodedvalue==</cert>
	</certificate>		</certificate>
	</certificates>		</certificates>
	</truststore>		</truststore>
	</config>		</config>
	6. Contributors		6. Contributors
	7. Acknowledgements		7. Acknowledgements
	8. Normative references		8. Normative references
	[I-D.ietf-netconf-subscribed-notifications]		[I-D.ietf-netconf-notification-messages]
	Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and		Voit, E., Birkholz, H., Bierman, A., Clemm, A., and T.
	A. Tripathy, "Subscription to YANG Event Notifications",		Jenkins, "Notification Message Headers and Bundles",
	draft-ietf-netconf-subscribed-notifications-26 (work in		draft-ietf-netconf-notification-messages-07 (work in
	progress), May 2019.		progress), August 2019.
	[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>.
			[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
			Resource Identifier (URI): Generic Syntax", STD 66,
			RFC 3986, DOI 10.17487/RFC3986, January 2005,
			<https://www.rfc-editor.org/info/rfc3986>.
	[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for		[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
	the Network Configuration Protocol (NETCONF)", RFC 6020,		the Network Configuration Protocol (NETCONF)", RFC 6020,
	DOI 10.17487/RFC6020, October 2010,		DOI 10.17487/RFC6020, October 2010,
	<https://www.rfc-editor.org/info/rfc6020>.		<https://www.rfc-editor.org/info/rfc6020>.
	[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,		[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
	and A. Bierman, Ed., "Network Configuration Protocol		and A. Bierman, Ed., "Network Configuration Protocol
	(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,		(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
	<https://www.rfc-editor.org/info/rfc6241>.		<https://www.rfc-editor.org/info/rfc6241>.
	[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure		[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
	Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,		Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
	<https://www.rfc-editor.org/info/rfc6242>.		<https://www.rfc-editor.org/info/rfc6242>.
			[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
			RFC 6991, DOI 10.17487/RFC6991, July 2013,
			<https://www.rfc-editor.org/info/rfc6991>.
			[RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for
			SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407,
			December 2014, <https://www.rfc-editor.org/info/rfc7407>.
	[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",		[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
	RFC 7950, DOI 10.17487/RFC7950, August 2016,		RFC 7950, DOI 10.17487/RFC7950, August 2016,
	<https://www.rfc-editor.org/info/rfc7950>.		<https://www.rfc-editor.org/info/rfc7950>.
	[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF		[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
	Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,		Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
	<https://www.rfc-editor.org/info/rfc8040>.		<https://www.rfc-editor.org/info/rfc8040>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	skipping to change at page 11, line 14 ¶		skipping to change at page 15, line 43 ¶
	[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration		[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
	Access Control Model", STD 91, RFC 8341,		Access Control Model", STD 91, RFC 8341,
	DOI 10.17487/RFC8341, March 2018,		DOI 10.17487/RFC8341, March 2018,
	<https://www.rfc-editor.org/info/rfc8341>.		<https://www.rfc-editor.org/info/rfc8341>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
	Authors' Addresses		[RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
			E., and A. Tripathy, "Subscription to YANG Notifications",
			RFC 8639, DOI 10.17487/RFC8639, September 2019,
			<https://www.rfc-editor.org/info/rfc8639>.
			Authors' Addresses
	Mahesh Jethanandani		Mahesh Jethanandani
	VMware		VMware
	Email: mjethanandani@gmail.com		Email: mjethanandani@gmail.com
	Kent Watsen		Kent Watsen
	Watsen Networks		Watsen Networks
	USA		USA
	Email: kent+ietf@watsen.net		Email: kent+ietf@watsen.net
End of changes. 37 change blocks.
	67 lines changed or deleted		249 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/