draft-ietf-netconf-https-notif-02.txt   draft-ietf-netconf-https-notif-03.txt 
NETCONF M. Jethanandani NETCONF M. Jethanandani
Internet-Draft VMware Internet-Draft Kloud Services
Intended status: Standards Track K. Watsen Intended status: Standards Track K. Watsen
Expires: September 10, 2020 Watsen Networks Expires: January 10, 2021 Watsen Networks
March 9, 2020 July 9, 2020
An HTTPS-based Transport for Configured Subscriptions An HTTPS-based Transport for Configured Subscriptions
draft-ietf-netconf-https-notif-02 draft-ietf-netconf-https-notif-03
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 in RFC 8639. The use of HTTPS configured subscription, as defined in RFC 8639. The use of HTTPS
maximizes transport-level interoperability, while allowing for maximizes transport-level interoperability, while allowing for
encoding selection from text, e.g. XML or JSON, to binary. encoding selection from text, e.g. XML or JSON, to binary.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 September 10, 2020. This Internet-Draft will expire on January 10, 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
skipping to change at page 2, line 11 skipping to change at page 2, line 11
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
1.1. Applicability Statement . . . . . . . . . . . . . . . . . 3 1.1. Applicability Statement . . . . . . . . . . . . . . . . . 3
1.2. Note to RFC Editor . . . . . . . . . . . . . . . . . . . 3 1.2. Note to RFC Editor . . . . . . . . . . . . . . . . . . . 3
1.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.4.1. Subscribed Notifications . . . . . . . . . . . . . . 3 1.4.1. Subscribed Notifications . . . . . . . . . . . . . . 4
2. Learning Receiver Capabilities . . . . . . . . . . . . . . . 4 1.5. Receiver and Publisher Interaction . . . . . . . . . . . 4
2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4 1.5.1. Pipelining of messages . . . . . . . . . . . . . . . 4
2.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Learning Receiver Capabilities . . . . . . . . . . . . . . . 7
3. YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. YANG module . . . . . . . . . . . . . . . . . . . . . . . 6 3. The "ietf-sub-notif-recv-list" Module . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 3.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 3.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. URI Registration . . . . . . . . . . . . . . . . . . . . 11 4. The "ietf-https-notif" Module . . . . . . . . . . . . . . . . 10
5.2. YANG Module Name Registration . . . . . . . . . . . . . . 11 4.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 10
5.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. YANG module . . . . . . . . . . . . . . . . . . . . . . . 11
5.3.1. Media Type "application/ietf-https-notif-cap+xml . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5.3.2. Media Type "application/ietf-https-notif-cap+json . . 12 6. Receiving Event Notifications . . . . . . . . . . . . . . . . 14
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6.1. HTTPS Configured Subscription . . . . . . . . . . . . . . 14 7.1. URI Registration . . . . . . . . . . . . . . . . . . . . 15
6.2. Bundled Message . . . . . . . . . . . . . . . . . . . . . 16 7.2. YANG Module Name Registration . . . . . . . . . . . . . . 15
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 7.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 7.3.1. Media Type "application/ietf-https-notif-cap+xml . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.3.2. Media Type "application/ietf-https-notif-cap+json . . 17
9.1. Normative references . . . . . . . . . . . . . . . . . . 17 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.2. Informative references . . . . . . . . . . . . . . . . . 19 8.1. Subscribed Notification based Configuration . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 8.2. Non Subscribed Notification based Configuration . . . . . 20
8.3. Bundled Message . . . . . . . . . . . . . . . . . . . . . 23
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
11. Normative references . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
Subscription to YANG Notifications [RFC8639] defines a YANG data Subscription to YANG Notifications [RFC8639] defines a YANG data
module for configuring subscribed notifications. It defines a module for configuring subscribed notifications. It defines a
"subscriptions" container that contains a list of receivers, but it "subscriptions" container that contains a list of receivers, but it
defers the configuration and management of those receivers to other defers the configuration and management of those receivers to other
documents. This document defines a YANG 1.1 [RFC7950] data module documents. This document defines two YANG 1.1 [RFC7950] data
for configuring and managing HTTPS based receivers for the modules, one for augmenting the Subscription to YANG Notifications
notifications. Configured subscriptions enable a server, acting as a [RFC8639] to add a transport type, and another for configuring and
publisher of notifications, to proactively push notifications to managing HTTPS based receivers for the notifications.
external receivers without the receivers needing to first connect to
the server, as is the case with dynamic subscriptions.
This document describes how to enable the transmission of YANG The first module allows for different transports to be configured for
modeled notifications, in the configured encoding (i.e., XML, JSON) the same receiver instance. The second module describes how to
over HTTPS. Notifications are delivered in the form of a HTTPS POST. enable the transmission of YANG modeled notifications, in the
The use of HTTPS maximizes transport-level interoperability, while configured encoding (i.e., XML, JSON) over HTTPS. Notifications are
the encoding selection pivots between implementation simplicity (XML, delivered in the form of a HTTPS POST. The use of HTTPS maximizes
JSON) and throughput (text versus binary). transport-level interoperability, while the encoding selection pivots
between implementation simplicity (XML, JSON) and throughput (text
versus binary).
Configured subscriptions enable a server, acting as a publisher of
notifications, to proactively push notifications to external
receivers without the receivers needing to first connect to the
server, as is the case with dynamic subscriptions.
1.1. Applicability Statement 1.1. Applicability Statement
While the YANG module has been defined as an augmentation of While the YANG modules have been defined as an augmentation of
Subscription to YANG Notifications [RFC8639], the notification method Subscription to YANG Notifications [RFC8639], the notification method
defined in this document MAY be used outside of Subscription to YANG defined in this document MAY be used outside of Subscription to YANG
Notifications [RFC8639] by using the grouping defined in the model. Notifications [RFC8639] by using some of the definitions from this
module along with the grouping defined in Groupings for HTTP Clients
and Servers [I-D.ietf-netconf-http-client-server]. For an example on
how that can be done, see Section 8.2.
1.2. Note to RFC Editor 1.2. 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.
2020-03-09 with the actual date of the publication of this document. 2020-07-10 with the actual date of the publication of this document.
1.3. Abbreviations 1.3. Abbreviations
+---------+--------------------------------------+ +---------+--------------------------------------+
| Acronym | Expansion | | Acronym | Expansion |
+---------+--------------------------------------+ +---------+--------------------------------------+
| HTTP | Hyper Text Transport Protocol | | HTTP | Hyper Text Transport Protocol |
| | | | | |
| HTTPS | Hyper Text Transport Protocol Secure | | HTTPS | Hyper Text Transport Protocol Secure |
| | | | | |
skipping to change at page 4, line 7 skipping to change at page 4, line 20
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.4.1. Subscribed Notifications 1.4.1. Subscribed Notifications
The following terms are defined in Subscription to YANG Notifications The following terms are defined in Subscription to YANG Notifications
[RFC8639]. [RFC8639].
o Subscribed Notifications o Subscribed Notifications
1.5. 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.5.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. Learning Receiver Capabilities 2. Learning Receiver Capabilities
2.1. Introduction 2.1. Introduction
To learn the capabilities of the receiver, the publisher can issue a To learn the capabilities of the receiver, the publisher can issue a
HTTPS GET request with Accept-Type set to application/ietf-https- HTTPS GET request with Accept-Type set to application/ietf-https-
notif-cap+xml or application/ietf-https-notif-cap+json, with latter notif-cap+xml or application/ietf-https-notif-cap+json, with latter
as the mandatory to implement, and the default in case the type is as the mandatory to implement, and the default in case the type is
not specified. If the receiver supports capabilities such as binary not specified. If the receiver supports capabilities such as binary
encoding of data, it can return that as a capability in a response. encoding of data, it can return that as a capability in a response.
skipping to change at page 5, line 5 skipping to change at page 8, line 5
Cache-Control: no-cache Cache-Control: no-cache
Content-Type: application/ietf-https-notif-cap+xml Content-Type: application/ietf-https-notif-cap+xml
Content-Length: nnn Content-Length: nnn
<receiver-capabilities> <receiver-capabilities>
<receiver-capability> <receiver-capability>
<urn:ietf:params:https-config:capability:binary-encoding:1.0> <urn:ietf:params:https-config:capability:binary-encoding:1.0>
</receiver-capability> </receiver-capability>
</receiver-capabilities> </receiver-capabilities>
3. YANG module 3. The "ietf-sub-notif-recv-list" Module
3.1. Overview
The YANG module is a definition of a set of receivers that are 3.1. Data Model Overview
interested in the notifications published by the publisher. The
module contains the TCP, TLS and HTTPS parameters that are needed to
communicate with the receiver. The module augments the Subscription
to YANG Notifications [RFC8639] receiver container to create a
reference to a receiver defined by the YANG module. As mentioned
earlier, it uses 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. This YANG module augments ietf-subscribed-notifications module to
define a choice of transport types that other modules such as the
ietf-https-notif module can use to define a transport specific
receiver.
module: ietf-https-notif module: ietf-sub-notif-recv-list
augment /sn:subscriptions: augment /sn:subscriptions:
+--rw https-receivers +--rw receiver-instances
+--rw https-receiver* [name] +--rw receiver-instance* [name]
+--rw name string +--rw name string
+--rw tcp-params +--rw (transport-type)
| +--rw remote-address inet:host
| +--rw remote-port? inet:port-number
| +--rw local-address? inet:ip-address
| +--rw local-port? inet:port-number
| +--rw keepalives!
| ...
+--rw tls-params
| +--rw client-identity
| | ...
| +--rw server-authentication
| | ...
| +--rw hello-params {tls-client-hello-params-config}?
| | ...
| +--rw keepalives! {tls-client-keepalives}?
| ...
+--rw http-params
| +--rw protocol-version? enumeration
| +--rw client-identity
| | ...
| +--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? leafref +--rw receiver-instance-ref? leafref
3.2. YANG module
The YANG module imports Common YANG Data Types [RFC6991], A YANG Data
Model for SNMP Configuration [RFC7407], and Subscription to YANG
Notifications [RFC8639].
The YANG module is shown below. 3.2. YANG Module
<CODE BEGINS> file "ietf-https-notif@2020-03-09.yang" <CODE BEGINS> file "ietf-sub-notif-recv-list@2020-07-10.yang"
module ietf-https-notif { module ietf-sub-notif-recv-list {
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-sub-notif-recv-list";
prefix "hn"; prefix "snrl";
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
"I-D.ietf-netconf-subscribed-notifications";
}
import ietf-x509-cert-to-name {
prefix x509c2n;
reference reference
"RFC 7407: A YANG Data Model for SNMP Configuration"; "I-D.ietf-netconf-subscribed-notifications";
}
import ietf-tcp-client {
prefix tcpc;
}
import ietf-tls-client {
prefix tlsc;
}
import ietf-http-client {
prefix httpc;
} }
organization organization
"IETF NETCONF Working Group"; "IETF NETCONF Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/netconf> "WG Web: <http://tools.ietf.org/wg/netconf>
WG List: <netconf@ietf.org> WG List: <netconf@ietf.org>
Authors: Mahesh Jethanandani (mjethanandani at gmail dot com) Authors: Mahesh Jethanandani (mjethanandani at gmail dot com)
Kent Watsen (kent plus ietf at watsen dot net)"; Kent Watsen (kent plus ietf at watsen dot net)";
description description
"YANG module for configuring HTTPS base configuration. "YANG module for augmenting Subscribed Notifications to add
a transport type.
Copyright (c) 2018 IETF Trust and the persons identified as Copyright (c) 2018 IETF Trust and the persons identified as
the document authors. All rights reserved. the document authors. All rights reserved.
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.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as 'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here."; they appear in all capitals, as shown here.";
revision "2020-03-09" { revision "2020-07-10" {
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 { augment "/sn:subscriptions" {
base sn:transport; container receiver-instances {
description
"HTTPS transport for notifications.";
}
grouping https-receivers {
description
"Grouping for HTTPS based receivers such that it can be
implemented outside the constructs of a Subscription to YANG
Notification [RFC8639] module.";
container https-receivers {
description description
"HTTPS based notifications."; "A container for all instances of receivers.";
list https-receiver { list receiver-instance {
key "name"; key "name";
leaf name { leaf name {
type string; type string;
description description
"A name that uniquely identifies this receiver."; "An arbitrary but unique name for this receiver instance.";
}
container tcp-params {
uses tcpc:tcp-client-grouping;
description
"TCP client parameters.";
}
container tls-params {
uses tlsc:tls-client-grouping;
description
"TLS client parameters.";
}
container http-params {
description
"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 { choice transport-type {
mandatory true;
description description
"Specifies mechanism for identifying the receiver. The "Choice of different types of transports used to send
publisher MUST NOT include any content in a notification notifications.";
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."; "A list of all receiver instances.";
} }
} }
}
augment "/sn:subscriptions" {
description description
"Augment the subscirbed notification module to add in the "Augment the subscriptions container to define the transport
receivers container."; type.";
uses https-receivers;
} }
augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" { augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {
leaf receiver-ref { leaf receiver-instance-ref {
type leafref { type leafref {
path "/sn:subscriptions/hn:https-receivers/hn:https-receiver/" + path "/sn:subscriptions/snrl:receiver-instances/" +
"hn:name"; "snrl:receiver-instance/snrl:name";
} }
description description
"Reference to a receiver."; "Reference to a receiver instance.";
} }
description description
"Augment the subscriptions container to define the receiver."; "Augment the subscriptions container to define an optional
reference to a receiver instance.";
} }
} }
<CODE ENDS> <CODE ENDS>
4. Security Considerations 4. The "ietf-https-notif" Module
4.1. Data Model Overview
This YANG module is a definition of a set of receivers that are
interested in the notifications published by the publisher. The
module contains the TCP, TLS and HTTPS parameters that are needed to
communicate with the receiver. The module augments the ietf-sub-
notif-recv-list module to define a transport specific receiver. As
mentioned earlier, it uses POST method to deliver the notification.
The attribute 'path' defines the 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 as part of 'receiver-identity'.
An abridged tree diagram representing the module is shown below.
module: ietf-https-notif
augment /sn:subscriptions/snrl:receiver-instances
/snrl:receiver-instance/snrl:transport-type:
+--:(https)
+--rw https-receiver
+--rw (transport)
| +--:(tcp) {tcp-supported,not httpc:tcp-supported}?
| | ...
| +--:(tls) {tls-supported}?
| ...
+--rw receiver-identity
+--rw cert-maps
...
4.2. YANG module
The YANG module imports Common YANG Data Types [RFC6991], A YANG Data
Model for SNMP Configuration [RFC7407], JSON Encoding of Data Modeled
with YANG [RFC7951], and Subscription to YANG Notifications
[RFC8639].
The YANG module is shown below.
<CODE BEGINS> file "ietf-https-notif@2020-07-10.yang"
module ietf-https-notif {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-https-notif";
prefix "hn";
import ietf-subscribed-notifications {
prefix sn;
reference
"I-D.ietf-netconf-subscribed-notifications";
}
import ietf-http-client {
prefix httpc;
reference
"I-D.ietf-netconf-http-client-server";
}
import ietf-sub-notif-recv-list {
prefix snrl;
reference
"RFC XXXX, YANG Data Module for HTTPS Notifications.";
}
import ietf-x509-cert-to-name {
prefix x509c2n;
reference
"RFC 7407: YANG Data Model for SNMP Configuration.";
}
organization
"IETF NETCONF Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/netconf>
WG List: <netconf@ietf.org>
Authors: Mahesh Jethanandani (mjethanandani at gmail dot com)
Kent Watsen (kent plus ietf at watsen dot net)";
description
"YANG module for configuring HTTPS base configuration.
Copyright (c) 2018 IETF Trust and the persons identified as
the document authors. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.";
revision "2020-07-10" {
description
"Initial Version.";
reference
"RFC XXXX, YANG Data Module for HTTPS Notifications.";
}
identity https {
base sn:transport;
description
"HTTPS transport for notifications.";
}
augment "/sn:subscriptions/snrl:receiver-instances/" +
"snrl:receiver-instance/snrl:transport-type" {
case https {
container https-receiver {
description
"HTTPS receiver for notification";
uses httpc:http-client-stack-grouping {
refine "transport/tcp" {
// create the logical impossibility of enabling "tcp"
// transport
if-feature "not httpc:tcp-supported";
}
augment "transport/tls/tls/http-client-parameters" {
leaf path {
type string;
description
"Relative URI to the target resource.";
}
description
"Augmentation to add a path to the target resource.";
}
}
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
"Augment the transport-type choice to define this transport.";
}
}
<CODE ENDS>
5. 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
[RFC8446]. The NETCONF Access Control Model (NACM) [RFC8341] [RFC8446]. The NETCONF Access Control Model (NACM) [RFC8341]
provides the means to restrict access for particular NETCONF or provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or
skipping to change at page 11, line 12 skipping to change at page 14, line 44
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, get-config, or important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data notification) to these data nodes. These are the subtrees and data
nodes and their sensitivity/vulnerability: nodes and their sensitivity/vulnerability:
Some of the RPC operations in this YANG module may be considered Some of the RPC operations 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 access to these operations. These are the important to control access to these operations. These are the
operations and their sensitivity/vulnerability: operations and their sensitivity/vulnerability:
5. IANA Considerations 6. Receiving Event Notifications
This document registers one URI, one YANG module and two Media Types. Encoding notifications for the HTTPS notifications is the same as the
encoding notifications as defined in RESTCONF [RFC8040] Section 6.4,
with the following changes. Instead of saying that for JSON-encoding
purposes, the module name for "notification" element will be "ietf-
restconf, it will say that for JSON-encoding purposes, the module
name for "notification" element will be "ietf-https-notif".
5.1. URI Registration With those changes, the SSE event notification encoded JSON example
that would be sent over the HTTPS notif transport would appear as
follows:
data: {
data: "ietf-https-notif:notification" : {
data: "eventTime" : "2013-12-21T00:01:00Z",
data: "example-mod:event" : {
data: "event-class" : "fault",
data: "reporting-entity" : { "card" : "Ethernet0" },
data: "severity" : "major"
data: }
data: }
data: }
7. IANA Considerations
This document registers two URI, two YANG module and two Media Types.
7.1. URI Registration
in the IETF XML registry [RFC3688]. Following the format in RFC in the IETF XML registry [RFC3688]. Following the format in RFC
3688, the following registration is requested to be made: 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
URI: urn:ietf:params:xml:ns:yang:ietf-sub-notif-recv-list
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.
5.2. YANG Module Name Registration 7.2. YANG Module Name Registration
This document registers one 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.3. Media Types name: ietf-sub-recv-list
namespace: urn:ietf:params:xml:ns:yang:ietf-sub-notif-recv-list
prefix: snrl
reference: RFC XXXX
5.3.1. Media Type "application/ietf-https-notif-cap+xml 7.3. Media Types
7.3.1. Media Type "application/ietf-https-notif-cap+xml
Type name: application Type name: application
Subtype name: ietf-https-notif-cap+xml Subtype name: ietf-https-notif-cap+xml
Required parameters: None Required parameters: None
Optional parameters: None Optional parameters: None
Encoding considerations: Encoding considerations:
skipping to change at page 12, line 36 skipping to change at page 17, line 4
Deprecated alias names for this type: N/A Deprecated alias names for this type: N/A
Magic number(s): N/A Magic number(s): N/A
File extension(s): None File extension(s): None
Macintosh file type code(s): "TEXT" Macintosh file type code(s): "TEXT"
Person & email address to contact for further information: Person & email address to contact for further information:
See Author's Address section of RFC XXXX. See Author's Address section of RFC XXXX.
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: See Author's Address section of RFC XXXX Author: See Author's Address section of RFC XXXX
Change controller: Change controller:
Internet Engineering Task Force (mailto:iesg@ietf.org) Internet Engineering Task Force (mailto:iesg@ietf.org)
Provisional registration? (standards tree only): no Provisional registration? (standards tree only): no
5.3.2. Media Type "application/ietf-https-notif-cap+json 7.3.2. Media Type "application/ietf-https-notif-cap+json
Type name: application Type name: application
Subtype name: ietf-https-notif-cap+json Subtype name: ietf-https-notif-cap+json
Required parameters: None Required parameters: None
Optional parameters: None Optional parameters: None
Encoding considerations: Encoding considerations:
8-bit Each conceptual YANG data node is encoded according to the XML 8-bit Each conceptual YANG data node is encoded according to the XML
Encoding Rules and Canonical Format for the specific YANG data node Encoding Rules and Canonical Format for the specific YANG data node
type defined in JSON Encoding of Data Modeled with YANG [RFC7951]. type defined in JSON Encoding of Data Modeled with YANG [RFC7951].
Security considerations: Security considerations:
Security considerations related to the generation and consumption of Security considerations related to the generation and consumption of
RESTCONF messages are discussed in Section NN of RFC XXXX. RESTCONF messages are discussed in Section NN of RFC XXXX.
skipping to change at page 14, line 4 skipping to change at page 18, line 20
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: See Author's Address section of RFC XXXX Author: See Author's Address section of RFC XXXX
Change controller: Change controller:
Internet Engineering Task Force (mailto:iesg@ietf.org) Internet Engineering Task Force (mailto:iesg@ietf.org)
Provisional registration? (standards tree only): no Provisional registration? (standards tree only): no
6. Examples
This section tries to show some examples in how the model can be 8. Examples
used.
6.1. HTTPS Configured Subscription This section shows some examples in how the module can be used.
8.1. Subscribed Notification based Configuration
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">
<subscriptions <subscriptions
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notificatio\ xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notificatio\
ns"> ns">
<https-receivers <receiver-instances
xmlns="urn:ietf:params:xml:ns:yang:ietf-https-notif" xmlns="urn:ietf:params:xml:ns:yang:ietf-sub-notif-recv-list">
xmlns:x509c2n="urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-name">\ <receiver-instance>
<https-receiver>
<name>foo</name> <name>foo</name>
<tcp-params> <https-receiver
<remote-address>my-receiver.my-domain.com</remote-address> xmlns="urn:ietf:params:xml:ns:yang:ietf-https-notif"
<remote-port>443</remote-port> xmlns:x509c2n="urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-na\
</tcp-params> me">
<tls-params> <tls>
<server-authentication> <tcp-client-parameters>
<ca-certs>explicitly-trusted-server-ca-certs</ca-certs> <remote-address>my-receiver.my-domain.com</remote-address>
<server-certs>explicitly-trusted-server-certs</server-certs> <remote-port>443</remote-port>
</server-authentication> </tcp-client-parameters>
</tls-params> <tls-client-parameters>
<http-params> <server-authentication>
<client-identity> <ca-certs>explicitly-trusted-server-ca-certs</ca-certs>
<basic> <server-certs>explicitly-trusted-server-certs</server-certs>
<user-id>my-name</user-id> </server-authentication>
<password>my-password</password> </tls-client-parameters>
</basic> <http-client-parameters>
</client-identity> <client-identity>
<path>/some/path</path> <basic>
</http-params> <user-id>my-name</user-id>
<receiver-identity> <password>my-password</password>
<cert-maps> </basic>
<cert-to-name> </client-identity>
<id>1</id> <path>/some/path</path>
<fingerprint>11:0A:05:11:00</fingerprint> </http-client-parameters>
<map-type>x509c2n:san-any</map-type> </tls>
</cert-to-name> <receiver-identity>
</cert-maps> <cert-maps>
</receiver-identity> <cert-to-name>
</https-receiver> <id>1</id>
</https-receivers> <fingerprint>11:0A:05:11:00</fingerprint>
<map-type>x509c2n:san-any</map-type>
</cert-to-name>
</cert-maps>
</receiver-identity>
</https-receiver>
</receiver-instance>
</receiver-instances>
<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>
<receiver-ref <receiver-instance-ref
xmlns="urn:ietf:params:xml:ns:yang:ietf-https-notif">foo</rec\ xmlns="urn:ietf:params:xml:ns:yang:ietf-sub-notif-recv-list">\
eiver-ref> foo</receiver-instance-ref>
</receiver> </receiver>
</receivers> </receivers>
</subscription> </subscription>
</subscriptions> </subscriptions>
<truststore xmlns="urn:ietf:params:xml:ns:yang:ietf-truststore"> <truststore xmlns="urn:ietf:params:xml:ns:yang:ietf-truststore">
<certificates> <certificates>
<name>explicitly-trusted-server-certs</name> <name>explicitly-trusted-server-certs</name>
<description> <description>
Specific server authentication certificates for explicitly Specific server authentication certificates for explicitly
skipping to change at page 16, line 4 skipping to change at page 20, line 25
Trust anchors (i.e. CA certs) that are used to authenticate Trust anchors (i.e. CA certs) that are used to authenticate
server connections. Servers are authenticated if their server connections. Servers are authenticated if their
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>
</config>
8.2. Non Subscribed Notification based Configuration
In the case that it is desired to use HTTPS notif outside of
Subscribed Notifications, there would have to be a module to define
the configuration for where and how to send the notification, such as
the following:
[note: '\' line wrapping for formatting only]
module example-custom-module {
yang-version 1.1;
namespace "http://example.com/example-custom-module";
prefix "custom";
import ietf-http-client {
prefix httpc;
reference
"I-D.ietf-netconf-http-client-server";
}
organization
"Example, Inc.";
contact
"Support at example.com";
description
"Example of module not using Subscribed Notifications module.";
revision "2020-07-10" {
description
"Initial Version.";
reference
"RFC XXXX, YANG Data Module for HTTPS Notifications.";
}
container example-module {
description
"Example of using HTTPS notif without having to
implement Subscribed Notifications.";
container https-receivers {
description
"A container of all HTTPS notif receivers.";
list https-receiver {
key "name";
leaf name {
type string;
description
"A unique name for the https notif receiver.";
}
uses httpc:http-client-stack-grouping {
refine "transport/tcp" {
// create the logical impossibility of enabling "tcp"
// transport
if-feature "not httpc:tcp-supported";
}
augment "transport/tls/tls/http-client-parameters" {
leaf path {
type string;
description
"Relative URI to the target resource.";
}
description
"Augmentation to add a path to the target resource.";
}
}
description
"Just include the grouping from ietf-http-client to
realize the 'HTTPS stack'.";
}
}
}
}
This example shows how a HTTPS client can be configured to send
notifications to a receiver at address 192.0.2.1, port 443, a 'path',
with server certificates, and the corresponding trust store that is
used to authenticate a connection.
[note: '\' line wrapping for formatting only]
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<example-module
xmlns="http://example.com/example-custom-module">
<https-receivers>
<https-receiver>
<name>foo</name>
<tls>
<tcp-client-parameters>
<remote-address>my-receiver.my-domain.com</remote-address>
<remote-port>443</remote-port>
</tcp-client-parameters>
<tls-client-parameters>
<server-authentication>
<ca-certs>explicitly-trusted-server-ca-certs</ca-certs>
<server-certs>explicitly-trusted-server-certs</server-certs>
</server-authentication>
</tls-client-parameters>
<http-client-parameters>
<client-identity>
<basic>
<user-id>my-name</user-id>
<password>my-password</password>
</basic>
</client-identity>
<path>/some/path</path>
</http-client-parameters>
</tls>
</https-receiver>
</https-receivers>
</example-module>
<truststore xmlns="urn:ietf:params:xml:ns:yang:ietf-truststore">
<certificates>
<name>explicitly-trusted-server-certs</name>
<description>
Specific server authentication certificates for explicitly
trusted servers. These are needed for server certificates
that are not signed by a pinned CA.
</description>
<certificate>
<name>Fred Flintstone</name>
<cert>base64encodedvalue==</cert>
</certificate>
</certificates>
<certificates>
<name>explicitly-trusted-server-ca-certs</name>
<description>
Trust anchors (i.e. CA certs) that are used to authenticate
server connections. Servers are authenticated if their
certificate has a chain of trust to one of these CA
certificates.
</description>
<certificate>
<name>ca.example.com</name>
<cert>base64encodedvalue==</cert>
</certificate>
</certificates>
</truststore> </truststore>
</config> </config>
6.2. Bundled Message 8.3. Bundled Message
In the case of "bundled-message" as defined in Notification Message In the case of "bundled-message" as defined in Notification Message
Headers and Bundles [I-D.ietf-netconf-notification-messages], Headers and Bundles [I-D.ietf-netconf-notification-messages],
something that this module supports, the flow of messages would look something that this module supports, the flow of messages would look
something like this. something like this.
------------- -------------- ------------- --------------
| Publisher | | Receiver | | Publisher | | Receiver |
------------- -------------- ------------- --------------
Establish TCP ------> Establish TCP ------>
skipping to change at page 17, line 41 skipping to change at page 25, line 41
HTTP/1.1 204 No Content HTTP/1.1 204 No Content
Date: Fri, 03 Mar 2019 12:35:00 GMT Date: Fri, 03 Mar 2019 12:35:00 GMT
Server: my-receiver.my-domain.com Server: my-receiver.my-domain.com
HTTP/1.1 204 No Content HTTP/1.1 204 No Content
Date: Fri, 03 Mar 2019 12:35:00 GMT Date: Fri, 03 Mar 2019 12:35:00 GMT
Server: my-receiver.my-domain.com Server: my-receiver.my-domain.com
HTTP/1.1 204 No Content HTTP/1.1 204 No Content
Date: Fri, 03 Mar 2019 12:35:01 GMT Date: Fri, 03 Mar 2019 12:35:01 GMT
Server: my-receiver.my-domain.com Server: my-receiver.my-domain.com
7. Contributors 9. Contributors
8. Acknowledgements 10. Acknowledgements
9. References 11. Normative references
9.1. Normative references [I-D.ietf-netconf-http-client-server]
Watsen, K., "YANG Groupings for HTTP Clients and HTTP
Servers", draft-ietf-netconf-http-client-server-04 (work
in progress), July 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.
[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>.
skipping to change at page 19, line 23 skipping to change at page 27, line 31
[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>.
[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>.
9.2. Informative references
[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>.
Authors' Addresses Authors' Addresses
Mahesh Jethanandani Mahesh Jethanandani
VMware Kloud Services
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. 68 change blocks. 
265 lines changed or deleted 602 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/