An HTTPS-based Transport for YANG Notifications
draft-ietf-netconf-https-notif-15
| Document | Type | Active Internet-Draft (netconf WG) | |
|---|---|---|---|
| Authors | Mahesh Jethanandani , Kent Watsen | ||
| Last updated | 2024-03-20 (Latest revision 2024-02-01) | ||
| Replaces | draft-mahesh-netconf-https-notif | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Yang Validation | 0 errors, 2 warnings | ||
| Reviews |
HTTPDIR Telechat review
by Mark Nottingham
Ready w/issues
YANGDOCTORS Last Call review
(of
-06)
by Acee Lindem
Almost ready
|
||
| Additional resources |
Yang catalog entry for ietf-https-notif@2020-10-21.yang
Yang catalog entry for ietf-sub-notif-recv-list@2020-10-21.yang Yang impact analysis for draft-ietf-netconf-https-notif Mailing list discussion |
||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Qiufang Ma | ||
| Shepherd write-up | Show Last changed 2022-08-26 | ||
| IESG | IESG state | IESG Evaluation::AD Followup | |
| Action Holder | |||
| Consensus boilerplate | Yes | ||
| Telechat date |
(None)
Needs a YES. Has enough positions to pass. |
||
| Responsible AD | Mahesh Jethanandani | ||
| Send notices to | maqiufang1@huawei.com | ||
| IANA | IANA review state | Version Changed - Review Needed | |
| IANA expert review state | Expert Reviews OK | ||
| IANA expert review comments | This is up to the usual standard for YANG documents. I note that in the example in A.1 we see the following: <map-type>x509c2n:san-any</map-type> in which the "x509c2n:" is a namespace prefix correctly declared above, and used in running text content of an XML element. In the general case this WILL NOT WORK and requires that software which processes text encoded this way has a special feature offered by some but not all XML parsers, namely, that it will make available to calling software the mapping between XML namespaces and their declared prefixes. This is generally not regarded as a best practice. I would like this to see this special requirement for processing software to be called out in the RFC text. However, multiple YANG specifications use this nonstandard idiom and have declined to call out the requirement, so, as I said, this is up to the normal YANG standard. If that's good enough for the editors, then I see no further issues with this draft. |
draft-ietf-netconf-https-notif-15
lt;https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
tls-client-server-36>.
9.2. Informative references
[RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names
(URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
<https://www.rfc-editor.org/info/rfc8141>.
Appendix A. Configuration 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.
In both examples, the publisher, being an HTTPS client, is configured
to send notifications to a receiver.
A.1. Using Subscribed Notifications (RFC 8639)
This example shows how an RFC 8639 [RFC8639] based publisher can be
configured to send notifications to a receiver.
=============== NOTE: '\' line wrapping per RFC 8792 ================
<?xml version="1.0" encoding="UTF-8"?>
<subscriptions
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications\
">
<receiver-instances
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notif-recei\
Jethanandani & Watsen Expires 4 August 2024 [Page 24]
Internet-Draft HTTPS Notification Transport February 2024
vers">
<receiver-instance>
<name>global-receiver-def</name>
<https-receiver
xmlns="urn:ietf:params:xml:ns:yang:ietf-https-notif-transp\
ort"
xmlns:x509c2n="urn:ietf:params:xml:ns:yang:ietf-x509-cert-\
to-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
xmlns="urn:ietf:params:xml:ns:yang:ietf-https-notif-\
transport">/some/path</path>
</http-client-parameters>
</tls>
<receiver-identity>
<cert-maps>
<cert-to-name>
<id>1</id>
<fingerprint>11:0A:05:11:00</fingerprint>
<map-type>x509c2n:san-any</map-type>
</cert-to-name>
</cert-maps>
</receiver-identity>
</https-receiver>
</receiver-instance>
Jethanandani & Watsen Expires 4 August 2024 [Page 25]
Internet-Draft HTTPS Notification Transport February 2024
</receiver-instances>
<subscription>
<id>6666</id>
<transport xmlns:ph="urn:ietf:params:xml:ns:yang:ietf-https-noti\
f-transport">ph:https</transport>
<stream-subtree-filter>
<some-subtree-filter/>
</stream-subtree-filter>
<stream>some-stream</stream>
<receivers>
<receiver>
<name>subscription-specific-receiver-def</name>
<receiver-instance-ref xmlns="urn:ietf:params:xml:ns:yang:ie\
tf-subscribed-notif-receivers">global-receiver-def</receiver-instanc\
e-ref>
</receiver>
</receivers>
</subscription>
</subscriptions>
<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.
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>
A.2. Not Using Subscribed Notifications
In the case that it is desired to use HTTPS-based notifications
outside of Subscribed Notifications, an application-specific module
would need to define the configuration for sending the notification.
Jethanandani & Watsen Expires 4 August 2024 [Page 26]
Internet-Draft HTTPS Notification Transport February 2024
Following is an example module. Note that the module "uses" the
"https-receiver-grouping" grouping from the "ietf-https-notif-
transport" module.
module example-custom-module {
yang-version 1.1;
namespace "http://example.com/example-custom-module";
prefix "custom";
import ietf-https-notif-transport {
prefix "hnt";
reference
"RFC XXXX:
An HTTPS-based Transport for Configured Subscriptions";
}
organization
"Example, Inc.";
contact
"Support at example.com";
description
"Example of module not using Subscribed Notifications module.";
revision "2024-02-01" {
description
"Initial Version.";
reference
"RFC XXXX: An HTTPS-based Transport for YANG 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";
description
"A list of HTTPS notif receivers.";
leaf name {
type string;
description
"A unique name for the https notif receiver.";
Jethanandani & Watsen Expires 4 August 2024 [Page 27]
Internet-Draft HTTPS Notification Transport February 2024
}
uses hnt:https-receiver-grouping;
}
}
}
}
Following is what the corresponding configuration looks like:
<?xml version="1.0" encoding="UTF-8"?>
<example-module xmlns="http://example.com/example-custom-module">
<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>
Jethanandani & Watsen Expires 4 August 2024 [Page 28]
Internet-Draft HTTPS Notification Transport February 2024
Acknowledgements
The authors would like to thank for following for lively discussions
on list and in the halls (ordered by first name): Eric Voit, Henning
Rogge, Martin Bjorklund, Reshad Rahman, and Rob Wilton.
In addition, the authors would also like to thank Quifang Ma for
providing thoughtful comments as part of shepherd writeup.
Authors' Addresses
Mahesh Jethanandani
Kloud Services
Email: mjethanandani@gmail.com
Kent Watsen
Watsen Networks
Email: kent+ietf@watsen.net
Jethanandani & Watsen Expires 4 August 2024 [Page 29]