draft-ietf-netconf-https-notif-03.txt   draft-ietf-netconf-https-notif-04.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: January 10, 2021 Watsen Networks Expires: January 28, 2021 Watsen Networks
July 9, 2020 July 27, 2020
An HTTPS-based Transport for Configured Subscriptions An HTTPS-based Transport for Configured Subscriptions
draft-ietf-netconf-https-notif-03 draft-ietf-netconf-https-notif-04
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 January 10, 2021. This Internet-Draft will expire on January 28, 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 3, line 38 skipping to change at page 3, line 38
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-07-10 with the actual date of the publication of this document. 2020-07-21 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 30 skipping to change at page 4, line 30
1.5. Receiver and Publisher Interaction 1.5. Receiver and Publisher Interaction
The interaction between the receiver and the publisher can be of type The interaction between the receiver and the publisher can be of type
"pipelining" or send multiple notifications as part of a "bundled- "pipelining" or send multiple notifications as part of a "bundled-
message", as defined in Notification Message Headers and Bundles message", as defined in Notification Message Headers and Bundles
[I-D.ietf-netconf-notification-messages] [I-D.ietf-netconf-notification-messages]
1.5.1. Pipelining of messages 1.5.1. Pipelining of messages
In the case of "pipelining", the flow of messages would look In the case of "pipelining", the flow of messages would look
something like this. 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 | | Publisher | | Receiver |
------------- -------------- ------------- --------------
Establish TCP ------> Establish TCP ------>
Establish TLS ------> Establish TLS ------>
Send HTTPS POST message Send HTTPS POST message
with <subscription- ------>
started> notification
Send 200 (OK) for
<------ <subscription-started>
Send HTTPS POST message
with YANG defined ------> with YANG defined ------>
notification #1 notification #1
Send HTTPS POST message Send HTTPS POST message
with YANG defined ------> with YANG defined ------>
notification #2 notification #2
Send 204 (No Content) Send 204 (No Content)
<------ for notification #1 <------ for notification #1
Send 204 (No Content) Send 204 (No Content)
<------ for notification #2 <------ for notification #2
Send HTTPS POST message Send HTTPS POST message
with YANG defined -------> with YANG defined ------->
notification #3 notification #3
Send 204 (No Content) Send 204 (No Content)
<------ for notification #3 <------ for notification #3
The content of the exchange would look something like this. The content of the exchange would look something like this.
Request: Request:
POST /some/path HTTP/1.1 POST /some/path HTTP/1.1
Host: my-receiver.my-domain.com Host: my-receiver.my-domain.com
Content-Type: application/yang-data+xml Content-Type: application/yang-data+xml
<notification <notification
skipping to change at page 8, line 25 skipping to change at page 8, line 25
augment /sn:subscriptions: augment /sn:subscriptions:
+--rw receiver-instances +--rw receiver-instances
+--rw receiver-instance* [name] +--rw receiver-instance* [name]
+--rw name string +--rw name string
+--rw (transport-type) +--rw (transport-type)
augment /sn:subscriptions/sn:subscription/sn:receivers/sn:receiver: augment /sn:subscriptions/sn:subscription/sn:receivers/sn:receiver:
+--rw receiver-instance-ref? leafref +--rw receiver-instance-ref? leafref
3.2. YANG Module 3.2. YANG Module
<CODE BEGINS> file "ietf-sub-notif-recv-list@2020-07-10.yang" <CODE BEGINS> file "ietf-sub-notif-recv-list@2020-07-21.yang"
module ietf-sub-notif-recv-list { module ietf-sub-notif-recv-list {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-sub-notif-recv-list"; namespace "urn:ietf:params:xml:ns:yang:ietf-sub-notif-recv-list";
prefix "snrl"; prefix "snrl";
import ietf-subscribed-notifications { import ietf-subscribed-notifications {
prefix sn; prefix sn;
reference reference
"I-D.ietf-netconf-subscribed-notifications"; "I-D.ietf-netconf-subscribed-notifications";
skipping to change at page 9, line 23 skipping to change at page 9, line 23
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-07-10" { revision "2020-07-21" {
description description
"Initial Version."; "Initial Version.";
reference reference
"RFC XXXX, YANG Data Module for HTTPS Notifications."; "RFC XXXX, YANG Data Module for HTTPS Notifications.";
} }
augment "/sn:subscriptions" { augment "/sn:subscriptions" {
container receiver-instances { container receiver-instances {
description description
"A container for all instances of receivers."; "A container for all instances of receivers.";
skipping to change at page 11, line 28 skipping to change at page 11, line 28
4.2. YANG module 4.2. YANG module
The YANG module imports Common YANG Data Types [RFC6991], A YANG Data The YANG module imports Common YANG Data Types [RFC6991], A YANG Data
Model for SNMP Configuration [RFC7407], JSON Encoding of Data Modeled Model for SNMP Configuration [RFC7407], JSON Encoding of Data Modeled
with YANG [RFC7951], and Subscription to YANG Notifications with YANG [RFC7951], and Subscription to YANG Notifications
[RFC8639]. [RFC8639].
The YANG module is shown below. The YANG module is shown below.
<CODE BEGINS> file "ietf-https-notif@2020-07-10.yang" <CODE BEGINS> file "ietf-https-notif@2020-07-21.yang"
module ietf-https-notif { module ietf-https-notif {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-https-notif"; namespace "urn:ietf:params:xml:ns:yang:ietf-https-notif";
prefix "hn"; prefix "hn";
import ietf-subscribed-notifications { import ietf-subscribed-notifications {
prefix sn; prefix sn;
reference reference
"I-D.ietf-netconf-subscribed-notifications"; "I-D.ietf-netconf-subscribed-notifications";
} }
skipping to change at page 12, line 44 skipping to change at page 12, line 44
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-07-10" { revision "2020-07-21" {
description description
"Initial Version."; "Initial Version.";
reference reference
"RFC XXXX, YANG Data Module for HTTPS Notifications."; "RFC XXXX, YANG Data Module for HTTPS Notifications.";
} }
identity https { identity https {
base sn:transport; base sn:transport;
description description
"HTTPS transport for notifications."; "HTTPS transport for notifications.";
skipping to change at page 19, line 6 skipping to change at page 19, line 6
xmlns="urn:ietf:params:xml:ns:yang:ietf-https-notif" xmlns="urn:ietf:params:xml:ns:yang:ietf-https-notif"
xmlns:x509c2n="urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-na\ xmlns:x509c2n="urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-na\
me"> me">
<tls> <tls>
<tcp-client-parameters> <tcp-client-parameters>
<remote-address>my-receiver.my-domain.com</remote-address> <remote-address>my-receiver.my-domain.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>explicitly-trusted-server-ca-certs</ca-certs> <ca-certs>
<server-certs>explicitly-trusted-server-certs</server-certs> <local-definition>
<certificate>
<name>Server Cert Issuer #1</name>
<cert-data>base64encodedvalue==</cert-data>
</certificate>
</local-definition>
</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> <password>my-password</password>
</basic> </basic>
</client-identity> </client-identity>
<path>/some/path</path> <path>/some/path</path>
skipping to change at page 19, line 46 skipping to change at page 20, line 4
<receivers> <receivers>
<receiver> <receiver>
<name>my-receiver</name> <name>my-receiver</name>
<receiver-instance-ref <receiver-instance-ref
xmlns="urn:ietf:params:xml:ns:yang:ietf-sub-notif-recv-list">\ xmlns="urn:ietf:params:xml:ns:yang:ietf-sub-notif-recv-list">\
foo</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">
<certificates> <certificate-bags>
<name>explicitly-trusted-server-certs</name> <certificate-bag>
<description> <name>explicitly-trusted-server-ca-certs</name>
Specific server authentication certificates for explicitly <description>
trusted servers. These are needed for server certificates Trust anchors (i.e. CA certs) that are used to authenticat\
that are not signed by a pinned CA. e
</description> server connections. Servers are authenticated if their
<certificate> certificate has a chain of trust to one of these CA
<name>Fred Flintstone</name> certificates.
<cert>base64encodedvalue==</cert> </description>
</certificate> <certificate>
</certificates> <name>ca.example.com</name>
<certificates> <cert-data>base64encodedvalue==</cert-data>
<name>explicitly-trusted-server-ca-certs</name> </certificate>
<description> <certificate>
Trust anchors (i.e. CA certs) that are used to authenticate <name>Fred Flintstone</name>
server connections. Servers are authenticated if their <cert-data>base64encodedvalue==</cert-data>
certificate has a chain of trust to one of these CA </certificate>
certificates. </certificate-bag>
</description> </certificate-bags>
<certificate>
<name>ca.example.com</name>
<cert>base64encodedvalue==</cert>
</certificate>
</certificates>
</truststore> </truststore>
</config> </config>
8.2. Non Subscribed Notification based Configuration 8.2. Non Subscribed Notification based Configuration
In the case that it is desired to use HTTPS notif outside of In the case that it is desired to use HTTPS notif outside of
Subscribed Notifications, there would have to be a module to define Subscribed Notifications, there would have to be a module to define
the configuration for where and how to send the notification, such as the configuration for where and how to send the notification, such as
the following: the following:
skipping to change at page 21, line 11 skipping to change at page 21, line 11
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-07-10" { revision "2020-07-21" {
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 22, line 16 skipping to change at page 22, line 16
} }
} }
} }
} }
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, a 'path', notifications to a receiver at address 192.0.2.1, port 443, a 'path',
with server certificates, and the corresponding trust store that is with server certificates, and the corresponding trust store that is
used 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">
<example-module <example-module
xmlns="http://example.com/example-custom-module"> xmlns="http://example.com/example-custom-module">
<https-receivers> <https-receivers>
<https-receiver> <https-receiver>
<name>foo</name> <name>foo</name>
<tls> <tls>
<tcp-client-parameters> <tcp-client-parameters>
<remote-address>my-receiver.my-domain.com</remote-address> <remote-address>my-receiver.my-domain.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>explicitly-trusted-server-ca-certs</ca-certs> <ca-certs>
<server-certs>explicitly-trusted-server-certs</server-certs> <local-definition>
</server-authentication> <certificate>
</tls-client-parameters> <name>Server Cert Issuer #1</name>
<http-client-parameters> <cert-data>base64encodedvalue==</cert-data>
<client-identity> </certificate>
<basic> </local-definition>
<user-id>my-name</user-id> </ca-certs>
<password>my-password</password> </server-authentication>
</basic> </tls-client-parameters>
</client-identity> <http-client-parameters>
<path>/some/path</path> <client-identity>
</http-client-parameters> <basic>
</tls> <user-id>my-name</user-id>
</https-receiver> <password>my-password</password>
</https-receivers> </basic>
</example-module> </client-identity>
<path>/some/path</path>
</http-client-parameters>
<truststore xmlns="urn:ietf:params:xml:ns:yang:ietf-truststore"> </tls>
<certificates> </https-receiver>
<name>explicitly-trusted-server-certs</name> </https-receivers>
<description> </example-module>
Specific server authentication certificates for explicitly
trusted servers. These are needed for server certificates <truststore xmlns="urn:ietf:params:xml:ns:yang:ietf-truststore">
that are not signed by a pinned CA. <certificate-bags>
</description> <certificate-bag>
<certificate> <name>explicitly-trusted-server-ca-certs</name>
<name>Fred Flintstone</name> <description>
<cert>base64encodedvalue==</cert> Trust anchors (i.e. CA certs) that are used to authenticat\
</certificate> e
</certificates> server connections. Servers are authenticated if their
<certificates> certificate has a chain of trust to one of these CA
<name>explicitly-trusted-server-ca-certs</name> certificates.
<description> </description>
Trust anchors (i.e. CA certs) that are used to authenticate <certificate>
server connections. Servers are authenticated if their <name>ca.example.com</name>
certificate has a chain of trust to one of these CA <cert-data>base64encodedvalue==</cert-data>
certificates. </certificate>
</description> <certificate>
<certificate> <name>Fred Flintstone</name>
<name>ca.example.com</name> <cert-data>base64encodedvalue==</cert-data>
<cert>base64encodedvalue==</cert> </certificate>
</certificate> </certificate-bag>
</certificates> </certificate-bags>
</truststore> </truststore>
</config> </config>
8.3. 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 |
 End of changes. 20 change blocks. 
105 lines changed or deleted 118 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/