draft-ietf-netconf-https-notif-04.txt   draft-ietf-netconf-https-notif-05.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 28, 2021 Watsen Networks Expires: April 26, 2021 Watsen Networks
July 27, 2020 October 23, 2020
An HTTPS-based Transport for Configured Subscriptions An HTTPS-based Transport for Configured Subscriptions
draft-ietf-netconf-https-notif-04 draft-ietf-netconf-https-notif-05
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 28, 2021. This Internet-Draft will expire on April 26, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
2. Learning Receiver Capabilities . . . . . . . . . . . . . . . 7 2. Learning Receiver Capabilities . . . . . . . . . . . . . . . 7
2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. The "ietf-sub-notif-recv-list" Module . . . . . . . . . . . . 8 3. The "ietf-sub-notif-recv-list" Module . . . . . . . . . . . . 8
3.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 8 3.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 8
3.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 8
4. The "ietf-https-notif" Module . . . . . . . . . . . . . . . . 10 4. The "ietf-https-notif" Module . . . . . . . . . . . . . . . . 10
4.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 10 4.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 10
4.2. YANG module . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. YANG module . . . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. Receiving Event Notifications . . . . . . . . . . . . . . . . 14 6. Encoding Event Notifications . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7.1. URI Registration . . . . . . . . . . . . . . . . . . . . 15 7.1. URI Registration . . . . . . . . . . . . . . . . . . . . 16
7.2. YANG Module Name Registration . . . . . . . . . . . . . . 15 7.2. YANG Module Name Registration . . . . . . . . . . . . . . 16
7.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 16 7.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 16
7.3.1. Media Type "application/ietf-https-notif-cap+xml . . 16 7.3.1. Media Type "application/ietf-https-notif-cap+xml . . 16
7.3.2. Media Type "application/ietf-https-notif-cap+json . . 17 7.3.2. Media Type "application/ietf-https-notif-cap+json . . 17
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Subscribed Notification based Configuration . . . . . . . 18 8.1. Subscribed Notification based Configuration . . . . . . . 19
8.2. Non Subscribed Notification based Configuration . . . . . 20 8.2. Non Subscribed Notification based Configuration . . . . . 21
8.3. Bundled Message . . . . . . . . . . . . . . . . . . . . . 23 8.3. Bundled Message . . . . . . . . . . . . . . . . . . . . . 24
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
11. Normative references . . . . . . . . . . . . . . . . . . . . 25 11. Normative references . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
Subscription to YANG Notifications [RFC8639] defines a YANG data Subscription to YANG Notifications [RFC8639] defines a YANG data
module for configuring subscribed notifications. It defines a module for configuring subscribed notifications. It defines a
"subscriptions" container that contains a list of receivers, but it "subscriptions" container that contains a list of receivers, but it
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-21 with the actual date of the publication of this document. 2020-10-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 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-21.yang" <CODE BEGINS> file "ietf-sub-notif-recv-list@2020-10-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-21" { revision "2020-10-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-21.yang" <CODE BEGINS> file "ietf-https-notif@2020-10-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-21" { revision "2020-10-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 14, line 44 skipping to change at page 14, line 44
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data notification) to these data nodes. These are the subtrees and data
nodes and their sensitivity/vulnerability: nodes and their sensitivity/vulnerability:
Some of the RPC operations in this YANG module may be considered Some of the RPC operations in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus
important to control access to these operations. These are the important to control access to these operations. These are the
operations and their sensitivity/vulnerability: operations and their sensitivity/vulnerability:
6. Receiving Event Notifications 6. Encoding Event Notifications
Encoding notifications for the HTTPS notifications is the same as the Notifications are encoded as defined in RESTCONF [RFC8040]
encoding notifications as defined in RESTCONF [RFC8040] Section 6.4, Section 6.4. The examples in that section apply for sending
with the following changes. Instead of saying that for JSON-encoding notifications over the "https-notif" based transport.
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 An example of YANG-Push in JSON would look something like this:
that would be sent over the HTTPS notif transport would appear as
follows:
data: { data: {
data: "ietf-https-notif:notification" : { data: "ietf-restconf:notification" : {
data: "eventTime" : "2013-12-21T00:01:00Z", data: "eventTime" : "2017-10-25T08:00:11.22Z",
data: "example-mod:event" : { data: "ietf-yang-push:push-update" : {
data: "event-class" : "fault", data: "id" : 1011,
data: "reporting-entity" : { "card" : "Ethernet0" }, data: "datastore-contents" : {
data: "severity" : "major" data: "ietf-interfaces:interfaces" : {
data: "interface": [
data: {
data: "name": "eth0",
data: "oper-status": "up"
data: }
data: ],
data: },
data: "eventClass" : "state",
data: "reportingEntity": {
data: "card": "Ethernet0"
data: }
data: "severity" : "minor"
data: }
data: } data: }
data: } data: }
data: } data: }
An example of YANG-Push in XML would look something like this:
data: <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
data: <eventTime>2017-10-25T08:00:11.22Z</eventTime>
data: <push-update xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push">
data: <id>1011</id>
data: <datastore-contents>
data: <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
data: <interface>
data: <name>eth0</name>
data: <oper-status>up</oper-status>
data: </interface>
data: </interfaces>
data: <eventClass>state</eventClass>
data: <reportingEntity>
data: <card>Ethernet0</card>
data: </reportingEntity>
data: <serverity>minor</serverity>
data: </datastore-contents>
data: </push-update>
data: </notification>
7. IANA Considerations 7. IANA Considerations
This document registers two URI, two YANG module and two Media Types. This document registers two URI, two YANG module and two Media Types.
7.1. URI Registration 7.1. URI Registration
in the IETF XML registry [RFC3688]. Following the format in RFC in the IETF XML registry [RFC3688]. Following the format in RFC
3688, the following registration is requested to be made: 3688, the following registration is requested to be made:
URI: urn:ietf:params:xml:ns:yang:ietf-http-notif URI: urn:ietf:params:xml:ns:yang:ietf-http-notif
skipping to change at page 19, line 40 skipping to change at page 20, line 24
<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\
tif">
hn:https
</transport>
<stream-subtree-filter>foo</stream-subtree-filter> <stream-subtree-filter>foo</stream-subtree-filter>
<stream>some-stream</stream> <stream>some-stream</stream>
<receivers> <receivers>
<receiver> <receiver>
<name>my-receiver</name> <name>my-receiver</name>
<receiver-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>
skipping to change at page 21, line 11 skipping to change at page 21, line 45
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-21" { revision "2020-10-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.";
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 {
skipping to change at page 25, line 49 skipping to change at page 25, line 49
Server: my-receiver.my-domain.com Server: my-receiver.my-domain.com
9. Contributors 9. Contributors
10. Acknowledgements 10. Acknowledgements
11. Normative references 11. Normative references
[I-D.ietf-netconf-http-client-server] [I-D.ietf-netconf-http-client-server]
Watsen, K., "YANG Groupings for HTTP Clients and HTTP Watsen, K., "YANG Groupings for HTTP Clients and HTTP
Servers", draft-ietf-netconf-http-client-server-04 (work Servers", draft-ietf-netconf-http-client-server-05 (work
in progress), July 2020. in progress), August 2020.
[I-D.ietf-netconf-notification-messages] [I-D.ietf-netconf-notification-messages]
Voit, E., Jenkins, T., Birkholz, H., Bierman, A., and A. Voit, E., Jenkins, T., Birkholz, H., Bierman, A., and A.
Clemm, "Notification Message Headers and Bundles", draft- Clemm, "Notification Message Headers and Bundles", draft-
ietf-netconf-notification-messages-08 (work in progress), ietf-netconf-notification-messages-08 (work in progress),
November 2019. November 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
 End of changes. 19 change blocks. 
37 lines changed or deleted 70 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/