draft-ietf-netconf-https-notif-00.txt   draft-ietf-netconf-https-notif-01.txt 
NETCONF M. Jethanandani NETCONF M. Jethanandani
Internet-Draft VMware Internet-Draft VMware
Intended status: Standards Track K. Watsen Intended status: Standards Track K. Watsen
Expires: March 20, 2020 Watsen Networks Expires: May 2, 2020 Watsen Networks
September 17, 2019 October 30, 2019
An HTTPS-based Transport for Configured Subscriptions An HTTPS-based Transport for Configured Subscriptions
draft-ietf-netconf-https-notif-00 draft-ietf-netconf-https-notif-01
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 I-D.ietf-netconf-subscribed- configured subscription, as defined in Subscribed Notifications
notifications. The use of HTTPS maximizes transport-level (RFC8639). The use of HTTPS maximizes transport-level
interoperability, while allowing for encoding selection from text, interoperability, while allowing for encoding selection from text,
e.g. XML or JSON, to binary. e.g. XML or JSON, to binary.
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 March 20, 2020. This Internet-Draft will expire on May 2, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 14 skipping to change at page 2, line 14
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Note to RFC Editor . . . . . . . . . . . . . . . . . . . 3 1.1. Note to RFC Editor . . . . . . . . . . . . . . . . . . . 3
1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.1. Subscribed Notifications . . . . . . . . . . . . . . 3 1.3.1. Subscribed Notifications . . . . . . . . . . . . . . 3
2. YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.4. Receiver and Publisher Interaction . . . . . . . . . . . 3
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 1.4.1. Pipelining of messages . . . . . . . . . . . . . . . 4
2.2. YANG module . . . . . . . . . . . . . . . . . . . . . . . 4 2. YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 2.2. YANG module . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. URI Registration . . . . . . . . . . . . . . . . . . . . 7 3. Security Considerations . . . . . . . . . . . . . . . . . . . 11
4.2. YANG Module Name Registration . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. URI Registration . . . . . . . . . . . . . . . . . . . . 11
5.1. HTTPS Configured Subscription . . . . . . . . . . . . . . 8 4.2. YANG Module Name Registration . . . . . . . . . . . . . . 12
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 5.1. HTTPS Configured Subscription . . . . . . . . . . . . . . 12
8. Normative references . . . . . . . . . . . . . . . . . . . . 10 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
8. Normative references . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
Subscribed Notifications [I-D.ietf-netconf-subscribed-notifications] Subscribed Notifications [RFC8639] defines a YANG data module for
defines a YANG data module for configuring subscribed notifications. configuring subscribed notifications. It even defines a
It even defines a subscriptions container that contains a list of subscriptions container that contains a list of receivers. But it
receivers. But it defers the configuration and management of those defers the configuration and management of those receivers to other
receivers to other documents. This document defines a YANG [RFC7950] documents. This document defines a YANG [RFC7950] data module for
data module for configuring and managing HTTPS based receivers for configuring and managing HTTPS based receivers for the notifications.
the notifications. Such a configured receiver can be a third party Such a configured receiver can be a third party collector, collecting
collector, collecting events on behalf of receivers that want to co- events on behalf of receivers that want to correlate events from
relate events from different publishers. Configured subscriptions different publishers. Configured subscriptions enable a server,
enable a server, acting as a publisher of notifications, to acting as a publisher of notifications, to proactively push
proactively push notifications to external receivers without the notifications to external receivers without the receivers needing to
receivers needing to first connect to the server, as is the case with first connect to the server, as is the case with dynamic
dynamic subscriptions. subscriptions.
This document describes how to enable the transmission of YANG This document describes how to enable the transmission of YANG
modeled notifications, in the configured encoding (i.e., XML, JSON) modeled notifications, in the configured encoding (i.e., XML, JSON)
over HTTPS. The use of HTTPS maximizes transport-level over HTTPS. It comes in the form of a HTTPS POST. The use of HTTPS
interoperability, while the encoding selection pivots between maximizes transport-level interoperability, while the encoding
implementation simplicity (XML, JSON) and throughput (text versus selection pivots between implementation simplicity (XML, JSON) and
binary). throughput (text versus binary).
1.1. Note to RFC Editor 1.1. 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.
2019-09-17 with the actual date of the publication of this document. 2019-10-30 with the actual date of the publication of this document.
1.2. Abbreviations 1.2. Abbreviations
+---------+-------------------------------+ +---------+-------------------------------+
| Acronym | Expansion | | Acronym | Expansion |
+---------+-------------------------------+ +---------+-------------------------------+
| HTTP | Hyper Text Transport Protocol | | HTTP | Hyper Text Transport Protocol |
| | | | | |
| TCP | Transmission Control Protocol | | TCP | Transmission Control Protocol |
| | | | | |
| TLS | Transport Layer Security | | TLS | Transport Layer Security |
+---------+-------------------------------+ +---------+-------------------------------+
1.3. Terminology 1.3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC2119 [RFC2119] RFC8174 [RFC8174] when, and only when, they 14 [RFC2119] [RFC8174] when, and only when, they appear in all
appear in all capitals, as shown here. capitals, as shown here.
1.3.1. Subscribed Notifications 1.3.1. Subscribed Notifications
The following terms are defined in Subscribed Notifications The following terms are defined in Subscribed Notifications
[I-D.ietf-netconf-subscribed-notifications]. [RFC8639].
o Subscribed Notifications o Subscribed Notifications
1.4. Receiver and Publisher Interaction
The interaction between the receiver and the publisher can be of type
"pipelining" or send multiple notifications as part of a "bundled-
message", as defined in Notification Message Headers and Bundles
[I-D.ietf-netconf-notification-messages]
1.4.1. Pipelining of messages
In the case of "pipelining", the flow of messages would look
something like this.
------------- --------------
| Publisher | | Receiver |
------------- --------------
Establish TCP ------>
Establish TLS ------>
Send HTTPS POST message
with YANG defined ------>
notification #1
Send HTTPS POST message
with YANG defined ------>
notification #2
Send 204 (No Content)
<------ for notification #1
Send 204 (No Content)
<------ for notification #2
Send HTTPS POST message
with YANG defined ------->
notification #3
Send 204 (No Content)
<------ for notification #3
The content of the exchange would look something like this.
Request:
POST /some/path HTTP/1.1
Host: my-receiver.my-domain.com
Content-Type: application/yang-data+xml
<notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2019-03-22T12:35:00Z</eventTime>
<foo xmlns="https://example.com/my-foobar-module">
...
</foo>
</notification>
<notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2019-03-22T12:35:00Z</eventTime>
<bar xmlns="https://example.com/my-foobar-module">
...
</bar>
</notification>
<notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2019-03-22T12:35:01Z</eventTime>
<baz xmlns="https://example.com/my-foobar-module">
...
</baz>
</notification>
Response:
HTTP/1.1 204 No Content
Date: Fri, 03 Mar 2019 12:35:00 GMT
Server: my-receiver.my-domain.com
HTTP/1.1 204 No Content
Date: Fri, 03 Mar 2019 12:35:00 GMT
Server: my-receiver.my-domain.com
HTTP/1.1 204 No Content
Date: Fri, 03 Mar 2019 12:35:01 GMT
Server: my-receiver.my-domain.com
2. YANG module 2. YANG module
2.1. Overview 2.1. Overview
The YANG module is a definition of a set of receivers that are The YANG module is a definition of a set of receivers that are
interested in the notifications published by the publisher. The interested in the notifications published by the publisher. The
module contains the TCP, TLS and HTTPS parameters that are needed to module contains the TCP, TLS and HTTPS parameters that are needed to
communicate with the receiver. The module augments the Subscribed communicate with the receiver. The module augments the Subscribed
Notifications [I-D.ietf-netconf-subscribed-notifications] receiver Notifications [RFC8639] receiver container to create a reference to a
container to create a reference to a receiver defined by the YANG receiver defined by the YANG module. As mentioned earlier, it uses
module. POST method to deliver the notification. The attribute 'path'
defines the absolute path for the resource on the receiver, as
defined by 'path-absolute' in URI Generic Syntax [RFC3986]. The
user-id used by Network Configuration Access Control Model [RFC8341],
is that of the receiver and is derived from the certificate presented
by the receiver.
An abridged tree diagram representing the module is shown below. An abridged tree diagram representing the module is shown below.
module: ietf-https-notif module: ietf-https-notif
+--rw receivers +--rw receivers
+--rw receiver* [name] +--rw receiver* [name]
+--rw name string +--rw name string
+--rw tcp-params +--rw tcp-params
| +--rw remote-address inet:host | +--rw remote-address inet:host
| +--rw remote-port? inet:port-number | +--rw remote-port? inet:port-number
| +--rw local-address? inet:ip-address | +--rw local-address? inet:ip-address
| +--rw local-port? inet:port-number | +--rw local-port? inet:port-number
| +--rw keepalives! | +--rw keepalives!
| ... | ...
+--rw tls-params +--rw tls-params
| +--rw client-identity | +--rw client-identity
| | ... | | ...
| +--rw server-authentication | +--rw server-authentication
| | ... | | ...
| +--rw hello-params {tls-client-hello-params-config}? | +--rw hello-params {tls-client-hello-params-config}?
| | ... | | ...
| +--rw keepalives! {tls-client-keepalives}? | +--rw keepalives! {tls-client-keepalives}?
| ... | ...
+--rw http-params +--rw http-params
+--rw protocol-version? enumeration | +--rw protocol-version? enumeration
+--rw client-identity | +--rw client-identity
| ... | | ...
+--rw proxy-server! {proxy-connect}? | +--rw proxy-server! {proxy-connect}?
| | ...
| +--rw path? inet:uri
+--rw receiver-identity
+--rw cert-maps
... ...
augment /sn:subscriptions/sn:subscription/sn:receivers/sn:receiver: augment /sn:subscriptions/sn:subscription/sn:receivers/sn:receiver:
+--rw receiver-ref? -> /receivers/receiver/name +--rw receiver-ref? -> /receivers/receiver/name
2.2. YANG module 2.2. YANG module
The YANG module is shown below. The YANG module imports Common YANG Data Types [RFC6991], A YANG Data
Model for SNMP Configuration [RFC7407], and Subscription to YANG
Notifcations [RFC8639].
<CODE BEGINS> file "ietf-https-notif@2019-09-17.yang" <CODE BEGINS> file "ietf-https-notif@2019-10-30.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 "hsn"; prefix "hsn";
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types.";
}
import ietf-subscribed-notifications { import ietf-subscribed-notifications {
prefix sn; prefix sn;
reference reference
"I-D.ietf-netconf-subscribed-notifications"; "I-D.ietf-netconf-subscribed-notifications";
} }
import ietf-x509-cert-to-name {
prefix x509c2n;
reference
"RFC 7407: A YANG Data Model for SNMP Configuration";
}
import ietf-tcp-client { import ietf-tcp-client {
prefix tcpc; prefix tcpc;
} }
import ietf-tls-client { import ietf-tls-client {
prefix tlsc; prefix tlsc;
} }
import ietf-http-client { import ietf-http-client {
prefix httpc; prefix httpc;
skipping to change at page 5, line 44 skipping to change at page 9, line 9
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.";
revision "2019-09-17" { revision "2019-10-30" {
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 6, line 26 skipping to change at page 9, line 39
"A name that uniquely identifies this receiver."; "A name that uniquely identifies this receiver.";
} }
container tcp-params { container tcp-params {
uses tcpc:tcp-client-grouping; uses tcpc:tcp-client-grouping;
description description
"TCP client parameters."; "TCP client parameters.";
} }
container tls-params { container tls-params {
uses tlsc:tls-client-grouping;
description description
"TLS client parameters."; "TLS client parameters.";
uses tlsc:tls-client-grouping;
} }
container http-params { container http-params {
uses httpc:http-client-grouping;
description description
"HTTP client parameters."; "HTTP client parameters.";
uses httpc:http-client-grouping;
leaf path {
type inet:uri;
description
"The absolute path for the resource on the remote
HTTPS server. The absolute path as specified in
RFC 3986 as 'path-absolute'.";
reference
"RFC 3986: URI Generic Syntax.";
}
}
container receiver-identity {
description
"Specifies mechanism for identifying the receiver. The
publisher MUST NOT include any content in a notification
that the user is not authorized to view.";
container cert-maps {
uses x509c2n:cert-to-name;
description
"The cert-maps container is used by a TLS-based HTTP
server to map the HTTPS client's presented X.509
certificate to a 'local' username. If no matching and
valid cert-to-name list entry is found, the publisher
MUST close the connection, and MUST NOT
not send any notifications over it.";
reference
"RFC 7407: A YANG Data Model for SNMP Configuration.";
}
} }
description description
"All receivers interested in this notification."; "All receivers interested in this notification.";
} }
description description
"HTTPS based notifications."; "HTTPS based notifications.";
} }
augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" { augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {
leaf receiver-ref { leaf receiver-ref {
skipping to change at page 8, line 4 skipping to change at page 11, line 48
4. IANA Considerations 4. IANA Considerations
This document registers one URI and one YANG module. This document registers one URI and one YANG module.
4.1. URI Registration 4.1. URI Registration
in the IETF XML registry [RFC3688] [RFC3688]. Following the format in the IETF XML registry [RFC3688] [RFC3688]. Following the format
in RFC 3688, the following registration is requested to be made: in RFC 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
Registrant Contact: The IESG. XML: N/A, the requested URI is an XML Registrant Contact: The IESG. XML: N/A, the requested URI is an XML
namespace. namespace.
4.2. YANG Module Name Registration 4.2. YANG Module Name Registration
This document registers three YANG module in the YANG Module Names This document registers one YANG module in the YANG Module Names
registry YANG [RFC6020]. registry YANG [RFC6020].
name: ietf-https-notif name: ietf-https-notif
namespace: urn:ietf:params:xml:ns:yang:ietf-https-notif namespace: urn:ietf:params:xml:ns:yang:ietf-https-notif
prefix: hn prefix: hn
reference: RFC XXXX reference: RFC XXXX
5. Examples 5. Examples
This section tries to show some examples in how the model can be This section tries to show some examples in how the model can be
used. used.
5.1. HTTPS Configured Subscription 5.1. HTTPS Configured Subscription
This example shows how a HTTPS client can be configured to send This example shows how a HTTPS client can be configured to send
notifications to a receiver at address 192.0.2.1, port 443 with notifications to a receiver at address 192.0.2.1, port 443, a 'path',
server certificates, and the corresponding trust store that is used with server certificates, and the corresponding trust store that is
to authenticate a connection. used to authenticate a connection.
[note: '\' line wrapping for formatting only] [note: '\' line wrapping for formatting only]
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<receivers <receivers
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-n\
ame">
<receiver> <receiver>
<name>foo</name> <name>foo</name>
<tcp-params> <tcp-params>
<remote-address>192.0.2.1</remote-address> <remote-address>my-receiver.my-domain.com</remote-address>
<remote-port>443</remote-port> <remote-port>443</remote-port>
<local-address>192.0.3.1</local-address>
<local-port>63001</local-port>
</tcp-params> </tcp-params>
<tls-params> <tls-params>
<server-authentication> <server-authentication>
<ca-certs>explicitly-trusted-server-ca-certs</ca-certs> <ca-certs>explicitly-trusted-server-ca-certs</ca-certs>
<server-certs>explicitly-trusted-server-certs</server-ce\ <server-certs>explicitly-trusted-server-certs</server-ce\
rts> rts>
</server-authentication> </server-authentication>
</tls-params> </tls-params>
<http-params>
<client-identity>
<basic>
<user-id>my-name</user-id>
<password>my-password</password>
</basic>
</client-identity>
<path>/some/path</path>
</http-params>
<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>
</receiver> </receiver>
</receivers> </receivers>
<subscriptions <subscriptions
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notificatio\ xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notificatio\
ns"> ns">
<subscription> <subscription>
<id>6666</id> <id>6666</id>
<stream-subtree-filter>foo</stream-subtree-filter> <stream-subtree-filter>foo</stream-subtree-filter>
<stream>some-stream</stream> <stream>some-stream</stream>
<receivers> <receivers>
<receiver> <receiver>
<name>my-receiver</name> <name>my-receiver</name>
skipping to change at page 10, line 4 skipping to change at page 14, line 19
certificate has a chain of trust to one of these CA certificate has a chain of trust to one of these CA
certificates. certificates.
</description> </description>
<certificate> <certificate>
<name>ca.example.com</name> <name>ca.example.com</name>
<cert>base64encodedvalue==</cert> <cert>base64encodedvalue==</cert>
</certificate> </certificate>
</certificates> </certificates>
</truststore> </truststore>
</config> </config>
6. Contributors 6. Contributors
7. Acknowledgements 7. Acknowledgements
8. Normative references 8. Normative references
[I-D.ietf-netconf-subscribed-notifications] [I-D.ietf-netconf-notification-messages]
Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and Voit, E., Birkholz, H., Bierman, A., Clemm, A., and T.
A. Tripathy, "Subscription to YANG Event Notifications", Jenkins, "Notification Message Headers and Bundles",
draft-ietf-netconf-subscribed-notifications-26 (work in draft-ietf-netconf-notification-messages-07 (work in
progress), May 2019. progress), August 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>. <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", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
skipping to change at page 11, line 14 skipping to change at page 15, line 43
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341, Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018, DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>. <https://www.rfc-editor.org/info/rfc8341>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
Authors' Addresses [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>.
Authors' Addresses
Mahesh Jethanandani Mahesh Jethanandani
VMware VMware
Email: mjethanandani@gmail.com Email: mjethanandani@gmail.com
Kent Watsen Kent Watsen
Watsen Networks Watsen Networks
USA USA
Email: kent+ietf@watsen.net Email: kent+ietf@watsen.net
 End of changes. 37 change blocks. 
67 lines changed or deleted 249 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/