draft-ietf-netconf-https-notif-06.txt   draft-ietf-netconf-https-notif-07.txt 
NETCONF M. Jethanandani NETCONF M. Jethanandani
Internet-Draft Kloud Services Internet-Draft Kloud Services
Intended status: Standards Track K. Watsen Intended status: Standards Track K. Watsen
Expires: May 20, 2021 Watsen Networks Expires: August 6, 2021 Watsen Networks
November 16, 2020 February 2, 2021
An HTTPS-based Transport for Configured Subscriptions An HTTPS-based Transport for Configured Subscriptions
draft-ietf-netconf-https-notif-06 draft-ietf-netconf-https-notif-07
Abstract Abstract
This document defines a YANG data module for configuring HTTPS based This document defines both a protocol for sending notifications over
configured subscription, as defined in RFC 8639. The use of HTTPS HTTPS as well as extensions to the data model for configured
maximizes transport-level interoperability, while allowing for subscriptions defined in RFC 8639. It also presents an example
encoding selection from text, e.g. XML or JSON, to binary. module for configuration without using the data model defined in RFC
8639.
This document requires that the publisher is a "server" (e.g., a
NETCONF or RESTCONF server), but does not assume that the receiver is
a server.
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 May 20, 2021. This Internet-Draft will expire on August 6, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.4.1. Subscribed Notifications . . . . . . . . . . . . . . 4 1.4.1. Subscribed Notifications . . . . . . . . . . . . . . 4
1.5. Receiver and Publisher Interaction . . . . . . . . . . . 4 2. Overview of Publisher to Receiver Interaction . . . . . . . . 4
1.5.1. Pipelining of messages . . . . . . . . . . . . . . . 4 3. Discovering a Receiver's Capabilities . . . . . . . . . . . . 5
2. Learning Receiver Capabilities . . . . . . . . . . . . . . . 7 3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Request . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Response . . . . . . . . . . . . . . . . . . . . . . . . 6
3. The "ietf-sub-notif-recv-list" Module . . . . . . . . . . . . 8 3.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 8 4. Sending Event Notifications . . . . . . . . . . . . . . . . . 7
3.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. The "ietf-https-notif" Module . . . . . . . . . . . . . . . . 10 4.2. Response . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 10 4.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. YANG module . . . . . . . . . . . . . . . . . . . . . . . 11 5. The "ietf-subscribed-notif-receivers" Module . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 9
6. Receiving Event Notifications . . . . . . . . . . . . . . . . 15 5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. The "ietf-https-notif-transport" Module . . . . . . . . . . . 12
7.1. URI Registration . . . . . . . . . . . . . . . . . . . . 15 6.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 12
7.2. YANG Module Name Registration . . . . . . . . . . . . . . 15 6.2. YANG module . . . . . . . . . . . . . . . . . . . . . . . 13
7.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7.3.1. Media Type "application/ietf-https-notif-cap+xml . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7.3.2. Media Type "application/ietf-https-notif-cap+json . . 17 8.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 18
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.2. The "YANG Module Names" Registry . . . . . . . . . . . . 18
8.1. Subscribed Notification based Configuration . . . . . . . 18 8.3. The "Capabilities for HTTPS Notification Receivers"
8.2. Non Subscribed Notification based Configuration . . . . . 20 Registry . . . . . . . . . . . . . . . . . . . . . . . . 18
8.3. Bundled Message . . . . . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 9.1. Normative references . . . . . . . . . . . . . . . . . . 19
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 9.2. Informative references . . . . . . . . . . . . . . . . . 21
11. Normative references . . . . . . . . . . . . . . . . . . . . 25 Appendix A. Configuration Examples . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 A.1. Using Subscribed Notifications (RFC 8639) . . . . . . . . 22
A.2. Not Using Subscribed Notifications . . . . . . . . . . . 24
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
Subscription to YANG Notifications [RFC8639] defines a YANG data This document defines a protocol for sending notifications over
module for configuring subscribed notifications. It defines a HTTPS. Using HTTPS maximizes transport-level interoperability, while
"subscriptions" container that contains a list of receivers, but it allowing for a variety of encoding options. This document defines
defers the configuration and management of those receivers to other support for JSON and XML; future efforts may define support for other
documents. This document defines two YANG 1.1 [RFC7950] data encodings (e.g., binary).
modules, one for augmenting the Subscription to YANG Notifications
[RFC8639] to add a transport type, and another for configuring and
managing HTTPS based receivers for the notifications.
The first module allows for different transports to be configured for This document also defines two YANG 1.1 [RFC7950] modules that extend
the same receiver instance. The second module describes how to the data model defined in Subscription to YANG Notifications
enable the transmission of YANG modeled notifications, in the [RFC8639], enabling the configuration of HTTPS-based receivers.
configured encoding (i.e., XML, JSON) over HTTPS. Notifications are
delivered in the form of a HTTPS POST. The use of HTTPS maximizes An example module illustrating the configuration of a publisher not
transport-level interoperability, while the encoding selection pivots using the data model defined in RFC 8639 is also provided.
between implementation simplicity (XML, JSON) and throughput (text
versus binary).
Configured subscriptions enable a server, acting as a publisher of Configured subscriptions enable a server, acting as a publisher of
notifications, to proactively push notifications to external notifications, to proactively push notifications to external
receivers without the receivers needing to first connect to the receivers without the receivers needing to first connect to the
server, as is the case with dynamic subscriptions. server, as is the case with dynamic subscriptions.
1.1. Applicability Statement 1.1. Applicability Statement
While the YANG modules have 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
skipping to change at page 3, line 38 skipping to change at page 3, line 44
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-11-16 with the actual date of the publication of this document. RFC YYYY, where YYYY is the number assigned to
[I-D.ietf-netconf-http-client-server].
2021-02-02 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 20 skipping to change at page 4, line 34
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 2. Overview of Publisher to Receiver 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. This example shows the flow assuming that
Subscribed Notifications is used and therefore a <subscription-
started> notification is sent before sending the first notification.
The example would be the same for when Subscribed Notification is not
used by removing the first POST message for <susbscription-started>.
------------- --------------
| Publisher | | Receiver |
------------- --------------
Establish TCP ------>
Establish TLS ------>
Send HTTPS POST message
with <subscription- ------>
started> notification
Send 200 (OK) for The protocol consists of two HTTP-based target resources presented by
<------ <subscription-started> the receiver:
Send HTTPS POST message o A target resource enabling the publisher to discover what optional
with YANG defined ------> capabilities a receiver supports. Publishers SHOULD query this
notification #1 target when before sending any notifications or if ever an error
occurs.
Send HTTPS POST message o A target resource enabling to publish to send one or more
with YANG defined ------> notification to a receiver. This document defines support for
notification #2 sending only one notification per message; a future effort MAY
Send 204 (No Content) extend the protocol to send multiple notifications per message.
<------ for notification #1
Send 204 (No Content) The protocol is illustrated in the diagram below:
<------ for notification #2
Send HTTPS POST message ------------- --------------
with YANG defined -------> | Publisher | | Receiver |
notification #3 ------------- --------------
Send 204 (No Content) Send HTTPS GET message ------>
<------ for notification #3 to discover receiver's
capabilities
The content of the exchange would look something like this. <------ Send 200 (OK) containing
capabilities supported
by the receiver
Request: +-- For Each Notification (MAY be pipelined) ---------------------+
| |
| Send HTTPS POST message ------> |
| with YANG defined |
| notification |
| |
| <------ Send 204 (No Content) |
+-----------------------------------------------------------------+
POST /some/path HTTP/1.1 Note that, for RFC 8639 configured subscriptions, the very first
Host: my-receiver.my-domain.com notification must be the "subscription-started" notification.
Content-Type: application/yang-data+xml
<notification The POST messages MAY be "pipelined" (not illustrated in the diagram
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> above), whereby multiple notifications are sent without waiting for
<eventTime>2019-03-22T12:35:00Z</eventTime> the HTTP response for a previous request.
<foo xmlns="https://example.com/my-foobar-module">
...
</foo>
</notification>
<notification 3. Discovering a Receiver's Capabilities
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 3.1. Applicability
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: For publishers using Subscription to YANG Notifications [RFC8639],
dynamic discovery of a receiver's supported encoding is necessary
only when the "/subscriptions/subscription/encoding" leaf is not
configured, per the "encoding" leaf's description statement in the
"ietf-subscribed-notification" module. FIXME: do they need to
discover *any* capabilities?
HTTP/1.1 204 No Content 3.2. Request
Date: Fri, 03 Mar 2019 12:35:00 GMT
Server: my-receiver.my-domain.com
HTTP/1.1 204 No Content To learn the capabilities of a receiver, a publisher can issue an
Date: Fri, 03 Mar 2019 12:35:00 GMT HTTPS GET request to the "capabilities" resource under a known path
Server: my-receiver.my-domain.com on the receiver with "Accept" header set using the "application/xml"
and/or "application/json" media-types, with latter as the mandatory
to implement, and the default in case the type is not specified.
HTTP/1.1 204 No Content 3.3. Response
Date: Fri, 03 Mar 2019 12:35:01 GMT
Server: my-receiver.my-domain.com
2. Learning Receiver Capabilities The receiver responds with a "200 (OK)" message, having the "Content-
Type" header set to either "application/xml" or "application/json"
(which ever was selected), and containing in the response body a list
of the receiver's capabilities encoded in the selected format.
2.1. Introduction Even though a YANG module is not defined for this interaction, the
response body MUST conform to the following YANG-modeled format:
To learn the capabilities of the receiver, the publisher can issue a container receiver-capabilities {
HTTPS GET request with Accept-Type set to application/ietf-https- description
notif-cap+xml or application/ietf-https-notif-cap+json, with latter "A container for a list of capabilities supported by
as the mandatory to implement, and the default in case the type is the receiver.";
not specified. If the receiver supports capabilities such as binary leaf-list receiver-capability {
encoding of data, it can return that as a capability in a response. type string {
Please note that, when used in conjunction with Subscription to YANG pattern "urn:ietf:capability:https-notif-receiver:*";
Notifications [RFC8639], dynamic discovery of the receiver's }
supported encoding is considered only when the description
"/subscriptions/subscription/encoding" leaf is not configured, per "A capability supported by the receiver. A full list of
the "encoding" leaf's description statement. capabilities is defined in the 'Capabilities for HTTPS
Notification Receivers' registry (see RFC XXXX).";
}
}
2.2. Example 3.4. Example
The publisher can send the following request to learn the receiver The publisher can send the following request to learn the receiver
capabilities. The Accept-Type states its preferred order for capabilities. In this example, the "Accept" states that the receiver
Content-Type that it wants to receive starting with XML, and if not wants to receive notifications in XML but, if not supported, to use
supported, to use JSON encoding. Currently, there is only one JSON encoding.
capability of binary encoding defined.
GET / HTTP/1.1 GET /some/path/capabilities HTTP/1.1
Host: example.com Host: example.com
Accept-Type: application/ietf-https-notif-cap+xml, application/ietf-https-notif-cap+json Accept: application/xml, application/json
In case the receiver supports the first Accept-Type, its response If the receiver is able to reply using "application/xml", and
should look like this: assuming it is able to receive JSON and XML encoded notifications,
the response might look like this:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Wed, 26 Feb 2020 20:33:30 GMT Date: Wed, 26 Feb 2020 20:33:30 GMT
Server: example-server Server: example-server
Cache-Control: no-cache Cache-Control: no-cache
Content-Type: application/ietf-https-notif-cap+xml Content-Type: application/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:capability:https-notif-receiver:encoding:json\
</receiver-capability>
<receiver-capability>\
urn:ietf:capability:https-notif-receiver:encoding:xml\
</receiver-capability> </receiver-capability>
</receiver-capabilities> </receiver-capabilities>
3. The "ietf-sub-notif-recv-list" Module If the receiver is unable to reply using "application/xml", the
response might look like this:
3.1. Data Model Overview HTTP/1.1 200 OK
Date: Wed, 26 Feb 2020 20:33:30 GMT
Server: example-server
Cache-Control: no-cache
Content-Type: application/json
Content-Length: nnn
This YANG module augments ietf-subscribed-notifications module to {
define a choice of transport types that other modules such as the receiver-capabilities {
ietf-https-notif module can use to define a transport specific "receiver-capability": [
receiver. "urn:ietf:capability:https-notif-receiver:encoding:json",
"urn:ietf:capability:https-notif-receiver:encoding:xml"
]
}
}
module: ietf-sub-notif-recv-list 4. Sending Event Notifications
augment /sn:subscriptions:
+--rw receiver-instances
+--rw receiver-instance* [name]
+--rw name string
+--rw (transport-type)
augment /sn:subscriptions/sn:subscription/sn:receivers/sn:receiver:
+--rw receiver-instance-ref? leafref
3.2. YANG Module 4.1. Request
<CODE BEGINS> file "ietf-sub-notif-recv-list@2020-11-16.yang" The publisher sends an HTTPS POST request to the "relay-
module ietf-sub-notif-recv-list { notifications" resource under a known path on the receiver with the
yang-version 1.1; "Content-Type" header set to either "application/json" or
namespace "urn:ietf:params:xml:ns:yang:ietf-sub-notif-recv-list"; "application/xml" and a request body containing the notification
prefix "snrl"; encoded using the specified format.
import ietf-subscribed-notifications { XML-encoded notifications are encoded using the format defined by
prefix sn; NETCONF Event Notifications [RFC5277] for XML.
reference JSON-encoded notifications are encoded the same as specified in
"I-D.ietf-netconf-subscribed-notifications"; Section 6.4 in RESTCONF [RFC8040] with the following deviations:
}
organization o The notifications do not contain the "data:" prefix used by SSE.
"IETF NETCONF Working Group";
contact o Instead of saying that, for JSON-encoding purposes, the module
"WG Web: <http://tools.ietf.org/wg/netconf> name for the "notification" element is "ietf-restconf, the module
WG List: <netconf@ietf.org> name will instead by "ietf-https-notif".
Authors: Mahesh Jethanandani (mjethanandani at gmail dot com) 4.2. Response
Kent Watsen (kent plus ietf at watsen dot net)";
description
"YANG module for augmenting Subscribed Notifications to add
a transport type.
Copyright (c) 2018 IETF Trust and the persons identified as The response should be "204 (No Content)".
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 4.3. Example
the RFC itself for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL An XML-encoded notification might be sent as follows:
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-11-16" { POST /some/path/relay-notification HTTP/1.1
description Host: example.com
"Initial Version."; Content-Type: application/xml
reference
"RFC XXXX, YANG Data Module for HTTPS Notifications.";
}
augment "/sn:subscriptions" { <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
container receiver-instances { <eventTime>2019-03-22T12:35:00Z</eventTime>
description <event xmlns="https://example.com/example-mod">
"A container for all instances of receivers."; <event-class>fault</fault>
<reporting-entity>
<card>Ethernet0</card>
</reporting-entity>
<severity>major</severity>
</event>
</notification>
list receiver-instance { A JSON-encoded notification might be sent as follows:
key "name";
leaf name { POST /some/path/relay-notification HTTP/1.1
type string; Host: example.com
description Content-Type: application/json
"An arbitrary but unique name for this receiver instance.";
}
choice transport-type { {
mandatory true; "ietf-https-notif:notification": {
description "eventTime": "2013-12-21T00:01:00Z",
"Choice of different types of transports used to send "example-mod:event" : {
notifications."; "event-class" : "fault",
} "reporting-entity" : { "card" : "Ethernet0" },
description "severity" : "major"
"A list of all receiver instances."; }
} }
}
And, in either case, the response might be as follows:
} HTTP/1.1 204 No Content
description Date: Wed, 26 Feb 2020 20:33:30 GMT
"Augment the subscriptions container to define the transport Server: example-server
type.";
}
augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" { 5. The "ietf-subscribed-notif-receivers" Module
leaf receiver-instance-ref {
type leafref {
path "/sn:subscriptions/snrl:receiver-instances/" +
"snrl:receiver-instance/snrl:name";
}
description
"Reference to a receiver instance.";
}
description
"Augment the subscriptions container to define an optional
reference to a receiver instance.";
}
} 5.1. Data Model Overview
<CODE ENDS>
4. The "ietf-https-notif" Module This YANG module augments the "ietf-subscribed-notifications" module
to define a choice of transport types that other modules such as the
"ietf-https-notif-transport" module can use to define a transport
specific receiver.
4.1. Data Model Overview [note: '\' line wrapping for formatting only]
This YANG module is a definition of a set of receivers that are module: ietf-subscribed-notif-receivers
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. augment /sn:subscriptions:
+--rw receiver-instances
+--rw receiver-instance* [name]
+--rw name string
+--rw (transport-type)
augment /sn:subscriptions/sn:subscription/sn:receivers/sn:receiver:\
module: ietf-https-notif +--rw receiver-instance-ref? leafref
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 5.2. YANG Module
The YANG module imports Common YANG Data Types [RFC6991], A YANG Data The YANG module imports Subscription to YANG Notifications [RFC8639].
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-subscribed-notif-receivers@2021-02-02.yang"
[note: '\' line wrapping for formatting only]
<CODE BEGINS> file "ietf-https-notif@2020-11-16.yang" module ietf-subscribed-notif-receivers {
module ietf-https-notif {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-https-notif"; namespace
prefix "hn"; "urn:ietf:params:xml:ns:yang:ietf-subscribed-notif-receivers";
prefix "snr";
import ietf-subscribed-notifications { import ietf-subscribed-notifications {
prefix sn; prefix sn;
reference reference
"I-D.ietf-netconf-subscribed-notifications"; "RFC 8639: Subscription to YANG 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 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)
skipping to change at page 12, line 23 skipping to change at page 10, line 12
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. "This YANG module is implemented by Publishers implementing
the 'ietf-subscribed-notifications' module defined in RFC 8639.
Copyright (c) 2018 IETF Trust and the persons identified as While this module is defined in RFC XXXX, which primarily
defines an HTTPS-based transport for notifications, this module
is not HTTP-specific. It is a generic extension that can be
used by any 'notif' transport.
This module defines two 'augment' statements. One statement
augments a 'container' statement called 'receiver-instances'
into the top-level 'subscriptions' container. The other
statement, called 'receiver-instance-ref', augemnts a 'leaf'
statement into each 'receiver' that references one of the
afore mentioned receiver instances. This indirection enables
multiple configured subscriptions to send notifications to
the same receiver instance.
Copyright (c) 2021 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-11-16" { revision "2021-02-02" {
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 description
"HTTPS transport for notifications."; "A container for all instances of receivers.";
}
augment "/sn:subscriptions/snrl:receiver-instances/" + list receiver-instance {
"snrl:receiver-instance/snrl:transport-type" { key "name";
case https {
container https-receiver {
description
"HTTPS receiver for notification";
uses httpc:http-client-stack-grouping { leaf name {
refine "transport/tcp" { type string;
// create the logical impossibility of enabling "tcp" description
// transport "An arbitrary but unique name for this receiver
if-feature "not httpc:tcp-supported"; instance.";
}
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 { choice transport-type {
mandatory true;
description description
"Specifies mechanism for identifying the receiver. "Choice of different types of transports used to
The publisher MUST NOT include any content in a send notifications. The 'case' statements must
notification that the user is not authorized to view."; be augmented in by other modules.";
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
"A list of all receiver instances.";
} }
}
description
"Augment the subscriptions container to define the
transport type.";
}
augment
"/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {
leaf receiver-instance-ref {
type leafref {
path "/sn:subscriptions/snr:receiver-instances/" +
"snr:receiver-instance/snr:name";
}
description
"Reference to a receiver instance.";
} }
description description
"Augment the transport-type choice to define this transport."; "Augment the subscriptions container to define an optional
reference to a receiver instance.";
} }
} }
<CODE ENDS> <CODE ENDS>
5. Security Considerations 6. The "ietf-https-notif-transport" Module
6.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-
subscribed-notif-receivers" module to define a transport specific
receiver.
As mentioned earlier, it uses a POST method to deliver the
notification. The "http-receiver/tls/http-client-parameters/path"
leaf 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.
[note: '\' line wrapping for formatting only]
module: ietf-https-notif-transport
augment /sn:subscriptions/snr:receiver-instances
/snr:receiver-instance/snr:transport-type:
+--:(https)
+--rw https-receiver
+--rw (transport)
| +--:(tcp) {tcp-supported,not httpc:tcp-supported}?
| | +--rw tcp
| | +--rw tcp-client-parameters
| | | +--rw remote-address inet:host
| | | +--rw remote-port? inet:port-number
| | | +--rw local-address? inet:ip-address
| | | | {local-binding-supported}?
| | | +--rw local-port? inet:port-number
| | | | {local-binding-supported}?
| | | +--rw proxy-server! {proxy-connect}?
| | | | ...
| | | +--rw keepalives! {keepalives-supported}?
| | | ...
| | +--rw http-client-parameters
| | +--rw client-identity!
| | | ...
| | +--rw proxy-connect! {proxy-connect}?
| | ...
| +--:(tls) {tls-supported}?
| +--rw tls
| +--rw tcp-client-parameters
| | +--rw remote-address inet:host
| | +--rw remote-port? inet:port-number
| | +--rw local-address? inet:ip-address
| | | {local-binding-supported}?
| | +--rw local-port? inet:port-number
| | | {local-binding-supported}?
| | +--rw proxy-server! {proxy-connect}?
| | | ...
| | +--rw keepalives! {keepalives-supported}?
| | ...
| +--rw tls-client-parameters
| | +--rw client-identity!
| | | ...
| | +--rw server-authentication
| | | ...
| | +--rw hello-params
| | | {tls-client-hello-params-config}?
| | | ...
| | +--rw keepalives {tls-client-keepalives}?
| | ...
| +--rw http-client-parameters
| +--rw client-identity!
| | ...
| +--rw proxy-connect! {proxy-connect}?
| | ...
| +--rw path string
+--rw receiver-identity {receiver-identity}?
+--rw cert-maps
+--rw cert-to-name* [id]
+--rw id uint32
+--rw fingerprint x509c2n:tls-fingerprint
+--rw map-type identityref
+--rw name string
6.2. YANG module
The YANG module imports A YANG Data Model for SNMP Configuration
[RFC7407], Subscription to YANG Notifications [RFC8639], and YANG
Groupings for HTTP Clients and HTTP Servers
[I-D.ietf-netconf-http-client-server].
The YANG module is shown below.
<CODE BEGINS> file "ietf-https-notif-transport@2021-02-02.yang"
[note: '\' line wrapping for formatting only]
module ietf-https-notif-transport {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-https-notif-transport";\
prefix "hnt";
import ietf-x509-cert-to-name {
prefix x509c2n;
reference
"RFC 7407: YANG Data Model for SNMP Configuration.";
}
import ietf-subscribed-notifications {
prefix sn;
reference
"RFC 8639: Subscription to YANG Notifications";
}
import ietf-subscribed-notif-receivers {
prefix snr;
reference
"RFC XXXX: An HTTPS-based Transport for
Configured Subscriptions";
}
import ietf-http-client {
prefix httpc;
reference
"RFC YYYY: YANG Groupings for HTTP Clients and HTTP Servers";
}
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
"This YANG module is implemented by Publishers that implement
the 'ietf-subscribed-notifications' module defined in RFC 8639.
This module augments a 'case' statement called 'https' into
the 'choice' statement called 'transport-type' defined
by the 'ietf-https-notif-transport' module defined in RFC XXXX. \
Copyright (c) 2021 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 "2021-02-02" {
description
"Initial Version.";
reference
"RFC XXXX, YANG Data Module for HTTPS Notifications.";
}
feature receiver-identity {
description
"Indicates if the server supports filtering notifications
based on the receiver's identity derived from its TLS
certificate.";
}
identity https {
base sn:transport;
description
"HTTPS transport for notifications.";
}
grouping https-receiver-grouping {
description
"A grouping that may be used by other modules wishing to
configure HTTPS-based notifications without using RFC 8639.";
uses httpc:http-client-stack-grouping {
refine "transport/tcp" {
// create the logical impossibility of enabling the
// "tcp" transport (i.e., "HTTP" without the 'S').
if-feature "not httpc:tcp-supported";
}
augment "transport/tls/tls/http-client-parameters" {
leaf path {
type string;
mandatory true;
description
"URI prefix to the target resources. Under this
path the receiver must support both the 'capabilities'
and 'relay-notification' resource targets, as described
in RFC XXXX.";
}
description
"Augmentation to add a receiver-specific path for the
'capabilities' and 'relay-notification' resources.";
}
}
container receiver-identity {
if-feature receiver-identity;
description
"Maps the receiver's TLS certificate to a local identity
enabling access control to be applied to filter out
notifications that the receiver may not be 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.";
}
}
}
augment "/sn:subscriptions/snr:receiver-instances/" +
"snr:receiver-instance/snr:transport-type" {
case https {
container https-receiver {
description
"The HTTPS receiver to send notifications to.";
uses https-receiver-grouping;
}
}
description
"Augment the transport-type choice to include the 'https'
transport.";
}
}
<CODE ENDS>
7. 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 14, line 40 skipping to change at page 17, line 44
and vulnerability of the data nodes defined in them. and vulnerability of the data nodes defined in them.
There are a number of data nodes defined in this YANG module that are There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config) in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability: and their sensitivity/vulnerability:
o The 'path' node in ietf-https-notif module can be modified by a o The "path" node in "ietf-subscribed-notif-receivers" module can be
malcious user to point to an invalid URI. modified by a malicious user to point to an invalid URI.
Some of the readable data nodes in YANG module may be considered Some of the readable data nodes in 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, get-config, or important to control read access (e.g., via get, get-config, or
notification) to these data nodes. The model does not define any notification) to these data nodes. The model does not define any
readable subtrees and data nodes. readable subtrees and data nodes.
Some of the RPC operations in YANG module may be considered sensitive Some of the RPC operations in YANG module may be considered sensitive
or vulnerable in some network environments. It is thus important to or vulnerable in some network environments. It is thus important to
control access to these operations. The model does not define any control access to these operations. The model does not define any
RPC operations. RPC operations.
6. Receiving Event Notifications 8. IANA Considerations
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".
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. 8.1. The "IETF XML" Registry
7.1. URI Registration This document registers two URIs in the "ns" subregistry of the "IETF
XML" registry [RFC3688]. Following the format in [RFC3688], the
following registrations are requested:
in the IETF XML registry [RFC3688]. Following the format in RFC URI: urn:ietf:params:xml:ns:yang:ietf-subscribed-notif-receivers
3688, the following registration is requested to be made: Registrant Contact: The IESG
XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-http-notif URI: urn:ietf:params:xml:ns:yang:ietf-https-notif-transport
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 namespace.
Registrant Contact: The IESG. XML: N/A, the requested URI is an XML 8.2. The "YANG Module Names" Registry
namespace.
7.2. YANG Module Name Registration This document registers two YANG modules in the "YANG Module Names"
registry [RFC6020]. Following the format in [RFC6020], the following
registrations are requested:
This document registers one YANG module in the YANG Module Names name: ietf-subscribed-notif-receivers
registry YANG [RFC6020]. namespace: urn:ietf:params:xml:ns:yang:ietf-subscribed-notif-receivers
prefix: snr
reference: RFC XXXX
name: ietf-https-notif name: ietf-https-notif-transport
namespace: urn:ietf:params:xml:ns:yang:ietf-https-notif namespace: urn:ietf:params:xml:ns:yang:ietf-https-notif-transport
prefix: hn prefix: hnt
reference: RFC XXXX reference: RFC XXXX
name: ietf-sub-recv-list 8.3. The "Capabilities for HTTPS Notification Receivers" Registry
namespace: urn:ietf:params:xml:ns:yang:ietf-sub-notif-recv-list
prefix: snrl
reference: RFC XXXX
7.3. Media Types Following the guidelines defined in [RFC5226], this document defines
a new registry called "Capabilities for HTTPS Notification
Receivers". This registry defines capabilities that can be supported
by HTTPS-based notification receivers.
7.3.1. Media Type "application/ietf-https-notif-cap+xml The following note shall be at the top of the registry:
Type name: application This registry defines capabilities that can be
supported by HTTPS-based notification receivers.
Subtype name: ietf-https-notif-cap+xml The fields for each registry are:
Required parameters: None o URN
Optional parameters: None * The name of the URN (required).
Encoding considerations: * The URN must conform to the syntax described by [RFC8141].
8-bit Each conceptual YANG data node is encoded according to the XML
Encoding Rules and Canonical Format for the specific YANG data node
type defined in YANG 1.1 [RFC7950].
Security considerations: * The URN must begin with the string "urn:ietf:capability:https-
Security considerations related to the generation and consumption of notif-receiver".
RESTCONF messages are discussed in Section NN of RFC XXXX.
Additional security considerations are specific to the semantics of o Reference
particular YANG data models. Each YANG module is expected to specify
security considerations for the YANG data defined in that module.
Interoperability considerations: N/A * The RFC that defined the URN.
Published specification: RFC XXXX * The RFC must be in the form "RFC <Number>: <Title>.
Applications that use this media type: o Description
Instance document data parsers used within a protocol or automation
tool that utilize YANG-defined data structures.
Fragment identifier considerations: * An arbitrary description of the algorithm (optional).
Fragment identifiers for this type are not defined. All YANG data
nodes are accessible as resources using the path in the request URI.
Additional information: * The description should be no more than a few sentences.
Deprecated alias names for this type: N/A * The description is to be in English, but may contain UTF-8
Magic number(s): N/A characters as may be needed in some cases.
File extension(s): None
Macintosh file type code(s): "TEXT"
Person & email address to contact for further information: The update policy is either "RFC Required". Updates do not otherwise
See Author's Address section of RFC XXXX. require an expert review by a Designated Expert.
Intended usage: COMMON Following is the initial assignment for this registry:
Restrictions on usage: N/A Record:
Name: urn:ietf:capability:https-notif-receiver:encoding:json
Reference: RFC XXXX
Description: Identifies support for JSON-encoded notifications.
Author: See Author's Address section of RFC XXXX Record:
Name: urn:ietf:capability:https-notif-receiver:encoding:xml
Reference: RFC XXXX
Description: Identifies support for XML-encoded notifications.
Change controller: 9. References
Internet Engineering Task Force (mailto:iesg@ietf.org)
Provisional registration? (standards tree only): no 9.1. Normative references
7.3.2. Media Type "application/ietf-https-notif-cap+json [I-D.ietf-netconf-http-client-server]
Watsen, K., "YANG Groupings for HTTP Clients and HTTP
Servers", draft-ietf-netconf-http-client-server-05 (work
in progress), August 2020.
Type name: application [I-D.ietf-netconf-notification-messages]
Voit, E., Jenkins, T., Birkholz, H., Bierman, A., and A.
Clemm, "Notification Message Headers and Bundles", draft-
ietf-netconf-notification-messages-08 (work in progress),
November 2019.
Subtype name: ietf-https-notif-cap+json [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Required parameters: None [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
Optional parameters: None [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>.
Encoding considerations: [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
8-bit Each conceptual YANG data node is encoded according to the XML Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008,
Encoding Rules and Canonical Format for the specific YANG data node <https://www.rfc-editor.org/info/rfc5277>.
type defined in JSON Encoding of Data Modeled with YANG [RFC7951].
Security considerations: [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
Security considerations related to the generation and consumption of the Network Configuration Protocol (NETCONF)", RFC 6020,
RESTCONF messages are discussed in Section NN of RFC XXXX. DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
Additional security considerations are specific to the semantics of [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
particular YANG data models. Each YANG module is expected to specify and A. Bierman, Ed., "Network Configuration Protocol
security considerations for the YANG data defined in that module. (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
Interoperability considerations: N/A [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
Published specification: RFC XXXX [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>.
Applications that use this media type: [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
Instance document data parsers used within a protocol or automation RFC 7950, DOI 10.17487/RFC7950, August 2016,
tool that utilize YANG-defined data structures. <https://www.rfc-editor.org/info/rfc7950>.
Fragment identifier considerations: [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Fragment identifiers for this type are not defined. All YANG data Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
nodes are accessible as resources using the path in the request URI. <https://www.rfc-editor.org/info/rfc8040>.
Additional information: [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Deprecated alias names for this type: N/A [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Magic number(s): N/A Access Control Model", STD 91, RFC 8341,
File extension(s): None DOI 10.17487/RFC8341, March 2018,
Macintosh file type code(s): "TEXT" <https://www.rfc-editor.org/info/rfc8341>.
Person & email address to contact for further information: [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
See Author's Address section of RFC XXXX. Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
Intended usage: COMMON [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>.
Restrictions on usage: N/A 9.2. Informative references
Author: See Author's Address section of RFC XXXX [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
Change controller: [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names
Internet Engineering Task Force (mailto:iesg@ietf.org) (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
<https://www.rfc-editor.org/info/rfc8141>.
Provisional registration? (standards tree only): no Appendix A. Configuration Examples
8. Examples This non-normative section shows two examples for how the "ietf-
https-notif-transport" module can be used to configure a publisher to
send notifications to a receiver.
This section shows some examples in how the module can be used. In both examples, the Publisher, acting as an HTTPS client, is
configured to send notifications to a receiver at address 192.0.2.1,
port 443, and configures the "path" leaf value to "/some/path", with
server certificates, and the corresponding trust store that is used
to authenticate a connection.
8.1. Subscribed Notification based Configuration A.1. Using Subscribed Notifications (RFC 8639)
This example shows how a HTTPS client can be configured to send This example shows how an RFC 8639 [RFC8639] based publisher can be
notifications to a receiver at address 192.0.2.1, port 443, a 'path', configured to send notifications to a receiver.
with server certificates, and the corresponding trust store that is
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-n\
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notificatio\ otifications">
ns"> <receiver-instances xmlns="urn:ietf:params:xml:ns:yang:ietf-subsc\
<receiver-instances ribed-notif-receivers">
xmlns="urn:ietf:params:xml:ns:yang:ietf-sub-notif-recv-list">
<receiver-instance> <receiver-instance>
<name>foo</name> <name>global-receiver-def</name>
<https-receiver <https-receiver xmlns="urn:ietf:params:xml:ns:yang:ietf-https\
xmlns="urn:ietf:params:xml:ns:yang:ietf-https-notif" -notif-transport"
xmlns:x509c2n="urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-na\ xmlns:x509c2n="urn:ietf:params:xml:ns:yang:ietf-x509-cert-t\
me"> o-name">
<tls> <tls>
<tcp-client-parameters> <tcp-client-parameters>
<remote-address>my-receiver.my-domain.com</remote-address> <remote-address>receiver.example.com</remote-address>
<remote-port>443</remote-port> <remote-port>443</remote-port>
</tcp-client-parameters> </tcp-client-parameters>
<tls-client-parameters> <tls-client-parameters>
<server-authentication> <server-authentication>
<ca-certs> <ca-certs>
<local-definition> <local-definition>
<certificate> <certificate>
<name>Server Cert Issuer #1</name> <name>Server Cert Issuer #1</name>
<cert-data>base64encodedvalue==</cert-data> <cert-data>base64encodedvalue==</cert-data>
</certificate> </certificate>
</local-definition> </local-definition>
</ca-certs> </ca-certs>
</server-authentication> </server-authentication>
</tls-client-parameters> </tls-client-parameters>
<http-client-parameters> <http-client-parameters>
<client-identity> <client-identity>
<basic> <basic>
<user-id>my-name</user-id> <user-id>my-name</user-id>
<password>my-password</password> <cleartext-password>my-password</cleartext-password\
>
</basic> </basic>
</client-identity> </client-identity>
<path>/some/path</path> <path>/some/path</path>
</http-client-parameters> </http-client-parameters>
</tls> </tls>
<receiver-identity> <receiver-identity>
<cert-maps> <cert-maps>
<cert-to-name> <cert-to-name>
<id>1</id> <id>1</id>
<fingerprint>11:0A:05:11:00</fingerprint> <fingerprint>11:0A:05:11:00</fingerprint>
<map-type>x509c2n:san-any</map-type> <map-type>x509c2n:san-any</map-type>
</cert-to-name> </cert-to-name>
</cert-maps> </cert-maps>
</receiver-identity> </receiver-identity>
</https-receiver> </https-receiver>
</receiver-instance> </receiver-instance>
</receiver-instances> </receiver-instances>
<subscription> <subscription>
<id>6666</id> <id>6666</id>
<transport xmlns:hn="urn:ietf:params:xml:ns:yang:ietf-https-no\ <transport xmlns:ph="urn:ietf:params:xml:ns:yang:ietf-https-not\
tif"> if-transport">ph:https</transport>
hn:https <stream-subtree-filter>some-subtree-filter</stream-subtree-filt\
</transport> er>
<stream-subtree-filter>foo</stream-subtree-filter>
<stream>some-stream</stream> <stream>some-stream</stream>
<receivers> <receivers>
<receiver> <receiver>
<name>my-receiver</name> <name>subscription-specific-receiver-def</name>
<receiver-instance-ref <receiver-instance-ref xmlns="urn:ietf:params:xml:ns:yang:i\
xmlns="urn:ietf:params:xml:ns:yang:ietf-sub-notif-recv-list">\ etf-subscribed-notif-receivers">global-receiver-def</receiver-instance-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">
<certificate-bags> <certificate-bags>
<certificate-bag> <certificate-bag>
<name>explicitly-trusted-server-ca-certs</name> <name>explicitly-trusted-server-ca-certs</name>
<description> <description>
Trust anchors (i.e. CA certs) that are used to authenticat\ Trust anchors (i.e. CA certs) that are used to
e authenticate connections to receivers. Receivers
server connections. Servers are authenticated if their are authenticated if their certificate has a chain
certificate has a chain of trust to one of these CA of trust to one of these CA certificates.
certificates. certificates.
</description> </description>
<certificate> <certificate>
<name>ca.example.com</name> <name>ca.example.com</name>
<cert-data>base64encodedvalue==</cert-data> <cert-data>base64encodedvalue==</cert-data>
</certificate> </certificate>
<certificate> <certificate>
<name>Fred Flintstone</name> <name>Fred Flintstone</name>
<cert-data>base64encodedvalue==</cert-data> <cert-data>base64encodedvalue==</cert-data>
</certificate> </certificate>
skipping to change at page 20, line 40 skipping to change at page 24, line 4
<certificate> <certificate>
<name>ca.example.com</name> <name>ca.example.com</name>
<cert-data>base64encodedvalue==</cert-data> <cert-data>base64encodedvalue==</cert-data>
</certificate> </certificate>
<certificate> <certificate>
<name>Fred Flintstone</name> <name>Fred Flintstone</name>
<cert-data>base64encodedvalue==</cert-data> <cert-data>base64encodedvalue==</cert-data>
</certificate> </certificate>
</certificate-bag> </certificate-bag>
</certificate-bags> </certificate-bags>
</truststore> </truststore>
</config> </config>
8.2. Non Subscribed Notification based Configuration A.2. Not Using Subscribed Notifications
In the case that it is desired to use HTTPS notif outside of In the case that it is desired to use HTTPS-based notifications
Subscribed Notifications, there would have to be a module to define outside of Subscribed Notifications, an application-specific module
the configuration for where and how to send the notification, such as would to need define the configuration for sending the notification.
the following:
Following is an example module. Note that the module is "uses" the
"https-receiver-grouping" grouping from the "ietf-https-notif-
transport" module.
[note: '\' line wrapping for formatting only] [note: '\' line wrapping for formatting only]
module example-custom-module { module example-custom-module {
yang-version 1.1; yang-version 1.1;
namespace "http://example.com/example-custom-module"; namespace "http://example.com/example-custom-module";
prefix "custom"; prefix "custom";
import ietf-http-client { import ietf-https-notif-transport {
prefix httpc; prefix "hnt";
reference reference
"I-D.ietf-netconf-http-client-server"; "RFC XXXX:
An HTTPS-based Transport for Configured Subscriptions";
} }
organization organization
"Example, Inc."; "Example, Inc.";
contact contact
"Support at example.com"; "Support at example.com";
description description
"Example of module not using Subscribed Notifications module."; "Example of module not using Subscribed Notifications module.";
revision "2020-11-16" { revision "2021-02-02" {
description description
"Initial Version."; "Initial Version.";
reference reference
"RFC XXXX, YANG Data Module for HTTPS Notifications."; "RFC XXXX, YANG Data Module for HTTPS Notifications.";
} }
container example-module { container example-module {
description description
"Example of using HTTPS notif without having to "Example of using HTTPS notif without having to
implement Subscribed Notifications."; implement Subscribed Notifications.";
skipping to change at page 21, line 39 skipping to change at page 25, line 8
} }
container example-module { container example-module {
description description
"Example of using HTTPS notif without having to "Example of using HTTPS notif without having to
implement Subscribed Notifications."; implement Subscribed Notifications.";
container https-receivers { container https-receivers {
description description
"A container of all HTTPS notif receivers."; "A container of all HTTPS notif receivers.";
list https-receiver { list https-receiver {
key "name"; 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 description
"Just include the grouping from ietf-http-client to "A list of HTTPS nofif receivers.";
realize the 'HTTPS stack'."; leaf name {
type string;
description
"A unique name for the https notif receiver.";
}
uses hnt:https-receiver-grouping;
} }
} }
} }
} }
This example shows how a HTTPS client can be configured to send Following is what the corresponding configuration looks like:
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>
<local-definition>
<certificate>
<name>Server Cert Issuer #1</name>
<cert-data>base64encodedvalue==</cert-data>
</certificate>
</local-definition>
</ca-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">
<certificate-bags>
<certificate-bag>
<name>explicitly-trusted-server-ca-certs</name>
<description>
Trust anchors (i.e. CA certs) that are used to authenticat\
e
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-data>base64encodedvalue==</cert-data>
</certificate>
<certificate>
<name>Fred Flintstone</name>
<cert-data>base64encodedvalue==</cert-data>
</certificate>
</certificate-bag>
</certificate-bags>
</truststore>
</config>
8.3. Bundled Message
In the case of "bundled-message" as defined in Notification Message
Headers and Bundles [I-D.ietf-netconf-notification-messages],
something that this module supports, 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
9. Contributors
10. Acknowledgements
11. 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-05 (work
in progress), August 2020.
[I-D.ietf-netconf-notification-messages]
Voit, E., Jenkins, T., Birkholz, H., Bierman, A., and A.
Clemm, "Notification Message Headers and Bundles", draft-
ietf-netconf-notification-messages-08 (work in progress),
November 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<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
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<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",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
RFC 7951, DOI 10.17487/RFC7951, August 2016,
<https://www.rfc-editor.org/info/rfc7951>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [note: '\' line wrapping for formatting only]
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration <?xml version="1.0" encoding="UTF-8"?>
Access Control Model", STD 91, RFC 8341, <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
DOI 10.17487/RFC8341, March 2018, <example-module xmlns="http://example.com/example-custom-module">
<https://www.rfc-editor.org/info/rfc8341>. <https-receivers>
<https-receiver>
<name>foo</name>
<tls>
<tcp-client-parameters>
<remote-address>receiver.example.com</remote-address>
<remote-port>443</remote-port>
</tcp-client-parameters>
<tls-client-parameters>
<server-authentication>
<ca-certs>
<local-definition>
<certificate>
<name>Server Cert Issuer #1</name>
<cert-data>base64encodedvalue==</cert-data>
</certificate>
</local-definition>
</ca-certs>
</server-authentication>
</tls-client-parameters>
<http-client-parameters>
<client-identity>
<basic>
<user-id>my-name</user-id>
<cleartext-password>my-password</cleartext-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">
<certificate-bags>
<certificate-bag>
<name>explicitly-trusted-server-ca-certs</name>
<description>
Trust anchors (i.e. CA certs) that are used to
authenticate connections to receivers. Receivers
are authenticated if their certificate has a chain
of trust to one of these CA certificates.
</description>
<certificate>
<name>ca.example.com</name>
<cert-data>base64encodedvalue==</cert-data>
</certificate>
<certificate>
<name>Fred Flintstone</name>
<cert-data>base64encodedvalue==</cert-data>
</certificate>
</certificate-bag>
</certificate-bags>
</truststore>
</config>
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Acknowledgements
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, The authors would like to thank for following for lively discussions
E., and A. Tripathy, "Subscription to YANG Notifications", on list and in the halls (ordered by first name): Eric Voit, Henning
RFC 8639, DOI 10.17487/RFC8639, September 2019, Rogge, Martin Bjorklund, Reshad Rahman, and Rob Wilton.
<https://www.rfc-editor.org/info/rfc8639>.
Authors' Addresses Authors' Addresses
Mahesh Jethanandani Mahesh Jethanandani
Kloud Services Kloud Services
Email: mjethanandani@gmail.com Email: mjethanandani@gmail.com
Kent Watsen Kent Watsen
Watsen Networks Watsen Networks
USA
Email: kent+ietf@watsen.net Email: kent+ietf@watsen.net
 End of changes. 167 change blocks. 
770 lines changed or deleted 788 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/