idnits 2.17.1
draft-ietf-netconf-https-notif-02.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 3 instances of too long lines in the document, the longest one
being 16 characters in excess of 72.
== There are 4 instances of lines with non-RFC2606-compliant FQDNs in the
document.
-- The document has examples using IPv4 documentation addresses according
to RFC6890, but does not use any IPv6 documentation addresses. Maybe
there should be IPv6 examples, too?
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 217 has weird spacing: '...address ine...'
-- The document date (March 9, 2020) is 1480 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
No issues found here.
Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 NETCONF M. Jethanandani
3 Internet-Draft VMware
4 Intended status: Standards Track K. Watsen
5 Expires: September 10, 2020 Watsen Networks
6 March 9, 2020
8 An HTTPS-based Transport for Configured Subscriptions
9 draft-ietf-netconf-https-notif-02
11 Abstract
13 This document defines a YANG data module for configuring HTTPS based
14 configured subscription, as defined in RFC 8639. The use of HTTPS
15 maximizes transport-level interoperability, while allowing for
16 encoding selection from text, e.g. XML or JSON, to binary.
18 Status of This Memo
20 This Internet-Draft is submitted in full conformance with the
21 provisions of BCP 78 and BCP 79.
23 Internet-Drafts are working documents of the Internet Engineering
24 Task Force (IETF). Note that other groups may also distribute
25 working documents as Internet-Drafts. The list of current Internet-
26 Drafts is at https://datatracker.ietf.org/drafts/current/.
28 Internet-Drafts are draft documents valid for a maximum of six months
29 and may be updated, replaced, or obsoleted by other documents at any
30 time. It is inappropriate to use Internet-Drafts as reference
31 material or to cite them other than as "work in progress."
33 This Internet-Draft will expire on September 10, 2020.
35 Copyright Notice
37 Copyright (c) 2020 IETF Trust and the persons identified as the
38 document authors. All rights reserved.
40 This document is subject to BCP 78 and the IETF Trust's Legal
41 Provisions Relating to IETF Documents
42 (https://trustee.ietf.org/license-info) in effect on the date of
43 publication of this document. Please review these documents
44 carefully, as they describe your rights and restrictions with respect
45 to this document. Code Components extracted from this document must
46 include Simplified BSD License text as described in Section 4.e of
47 the Trust Legal Provisions and are provided without warranty as
48 described in the Simplified BSD License.
50 Table of Contents
52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
53 1.1. Applicability Statement . . . . . . . . . . . . . . . . . 3
54 1.2. Note to RFC Editor . . . . . . . . . . . . . . . . . . . 3
55 1.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
56 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
57 1.4.1. Subscribed Notifications . . . . . . . . . . . . . . 3
58 2. Learning Receiver Capabilities . . . . . . . . . . . . . . . 4
59 2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4
60 2.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4
61 3. YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 5
62 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
63 3.2. YANG module . . . . . . . . . . . . . . . . . . . . . . . 6
64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
66 5.1. URI Registration . . . . . . . . . . . . . . . . . . . . 11
67 5.2. YANG Module Name Registration . . . . . . . . . . . . . . 11
68 5.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 11
69 5.3.1. Media Type "application/ietf-https-notif-cap+xml . . 11
70 5.3.2. Media Type "application/ietf-https-notif-cap+json . . 12
71 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14
72 6.1. HTTPS Configured Subscription . . . . . . . . . . . . . . 14
73 6.2. Bundled Message . . . . . . . . . . . . . . . . . . . . . 16
74 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17
75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
77 9.1. Normative references . . . . . . . . . . . . . . . . . . 17
78 9.2. Informative references . . . . . . . . . . . . . . . . . 19
79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
81 1. Introduction
83 Subscription to YANG Notifications [RFC8639] defines a YANG data
84 module for configuring subscribed notifications. It defines a
85 "subscriptions" container that contains a list of receivers, but it
86 defers the configuration and management of those receivers to other
87 documents. This document defines a YANG 1.1 [RFC7950] data module
88 for configuring and managing HTTPS based receivers for the
89 notifications. Configured subscriptions enable a server, acting as a
90 publisher of notifications, to proactively push notifications to
91 external receivers without the receivers needing to first connect to
92 the server, as is the case with dynamic subscriptions.
94 This document describes how to enable the transmission of YANG
95 modeled notifications, in the configured encoding (i.e., XML, JSON)
96 over HTTPS. Notifications are delivered in the form of a HTTPS POST.
97 The use of HTTPS maximizes transport-level interoperability, while
98 the encoding selection pivots between implementation simplicity (XML,
99 JSON) and throughput (text versus binary).
101 1.1. Applicability Statement
103 While the YANG module has been defined as an augmentation of
104 Subscription to YANG Notifications [RFC8639], the notification method
105 defined in this document MAY be used outside of Subscription to YANG
106 Notifications [RFC8639] by using the grouping defined in the model.
108 1.2. Note to RFC Editor
110 This document uses several placeholder values throughout the
111 document. Please replace them as follows and remove this section
112 before publication.
114 RFC XXXX, where XXXX is the number assigned to this document at the
115 time of publication.
117 2020-03-09 with the actual date of the publication of this document.
119 1.3. Abbreviations
121 +---------+--------------------------------------+
122 | Acronym | Expansion |
123 +---------+--------------------------------------+
124 | HTTP | Hyper Text Transport Protocol |
125 | | |
126 | HTTPS | Hyper Text Transport Protocol Secure |
127 | | |
128 | TCP | Transmission Control Protocol |
129 | | |
130 | TLS | Transport Layer Security |
131 +---------+--------------------------------------+
133 1.4. Terminology
135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
137 "OPTIONAL" in this document are to be interpreted as described in BCP
138 14 [RFC2119] [RFC8174] when, and only when, they appear in all
139 capitals, as shown here.
141 1.4.1. Subscribed Notifications
143 The following terms are defined in Subscription to YANG Notifications
144 [RFC8639].
146 o Subscribed Notifications
148 2. Learning Receiver Capabilities
150 2.1. Introduction
152 To learn the capabilities of the receiver, the publisher can issue a
153 HTTPS GET request with Accept-Type set to application/ietf-https-
154 notif-cap+xml or application/ietf-https-notif-cap+json, with latter
155 as the mandatory to implement, and the default in case the type is
156 not specified. If the receiver supports capabilities such as binary
157 encoding of data, it can return that as a capability in a response.
158 Please note that, when used in conjunction with Subscription to YANG
159 Notifications [RFC8639], dynamic discovery of the receiver's
160 supported encoding is considered only when the
161 "/subscriptions/subscription/encoding" leaf is not configured, per
162 the "encoding" leaf's description statement.
164 2.2. Example
166 The publisher can send the following request to learn the receiver
167 capabilities. The Accept-Type states its preferred order for
168 Content-Type that it wants to receive starting with XML, and if not
169 supported, to use JSON encoding. Currently, there is only one
170 capability of binary encoding defined.
172 GET / HTTP/1.1
173 Host: example.com
174 Accept-Type: application/ietf-https-notif-cap+xml, application/ietf-https-notif-cap+json
176 In case the receiver supports the first Accept-Type, its response
177 should look like this:
179 HTTP/1.1 200 OK
180 Date: Wed, 26 Feb 2020 20:33:30 GMT
181 Server: example-server
182 Cache-Control: no-cache
183 Content-Type: application/ietf-https-notif-cap+xml
184 Content-Length: nnn
186
187
188
189
190
192 3. YANG module
194 3.1. Overview
196 The YANG module is a definition of a set of receivers that are
197 interested in the notifications published by the publisher. The
198 module contains the TCP, TLS and HTTPS parameters that are needed to
199 communicate with the receiver. The module augments the Subscription
200 to YANG Notifications [RFC8639] receiver container to create a
201 reference to a receiver defined by the YANG module. As mentioned
202 earlier, it uses POST method to deliver the notification. The
203 attribute 'path' defines the absolute path for the resource on the
204 receiver, as defined by 'path-absolute' in URI Generic Syntax
205 [RFC3986]. The user-id used by Network Configuration Access Control
206 Model [RFC8341], is that of the receiver and is derived from the
207 certificate presented by the receiver.
209 An abridged tree diagram representing the module is shown below.
211 module: ietf-https-notif
212 augment /sn:subscriptions:
213 +--rw https-receivers
214 +--rw https-receiver* [name]
215 +--rw name string
216 +--rw tcp-params
217 | +--rw remote-address inet:host
218 | +--rw remote-port? inet:port-number
219 | +--rw local-address? inet:ip-address
220 | +--rw local-port? inet:port-number
221 | +--rw keepalives!
222 | ...
223 +--rw tls-params
224 | +--rw client-identity
225 | | ...
226 | +--rw server-authentication
227 | | ...
228 | +--rw hello-params {tls-client-hello-params-config}?
229 | | ...
230 | +--rw keepalives! {tls-client-keepalives}?
231 | ...
232 +--rw http-params
233 | +--rw protocol-version? enumeration
234 | +--rw client-identity
235 | | ...
236 | +--rw proxy-server! {proxy-connect}?
237 | | ...
238 | +--rw path? inet:uri
239 +--rw receiver-identity
240 +--rw cert-maps
241 ...
242 augment /sn:subscriptions/sn:subscription/sn:receivers/sn:receiver:
243 +--rw receiver-ref? leafref
245 3.2. YANG module
247 The YANG module imports Common YANG Data Types [RFC6991], A YANG Data
248 Model for SNMP Configuration [RFC7407], and Subscription to YANG
249 Notifications [RFC8639].
251 The YANG module is shown below.
253 file "ietf-https-notif@2020-03-09.yang"
254 module ietf-https-notif {
255 yang-version 1.1;
256 namespace "urn:ietf:params:xml:ns:yang:ietf-https-notif";
257 prefix "hn";
258 import ietf-inet-types {
259 prefix inet;
260 reference
261 "RFC 6991: Common YANG Data Types.";
262 }
264 import ietf-subscribed-notifications {
265 prefix sn;
266 reference
267 "I-D.ietf-netconf-subscribed-notifications";
268 }
270 import ietf-x509-cert-to-name {
271 prefix x509c2n;
272 reference
273 "RFC 7407: A YANG Data Model for SNMP Configuration";
274 }
276 import ietf-tcp-client {
277 prefix tcpc;
278 }
280 import ietf-tls-client {
281 prefix tlsc;
282 }
284 import ietf-http-client {
285 prefix httpc;
286 }
288 organization
289 "IETF NETCONF Working Group";
291 contact
292 "WG Web:
293 WG List:
295 Authors: Mahesh Jethanandani (mjethanandani at gmail dot com)
296 Kent Watsen (kent plus ietf at watsen dot net)";
297 description
298 "YANG module for configuring HTTPS base configuration.
300 Copyright (c) 2018 IETF Trust and the persons identified as
301 the document authors. All rights reserved.
302 Redistribution and use in source and binary forms, with or
303 without modification, is permitted pursuant to, and subject
304 to the license terms contained in, the Simplified BSD
305 License set forth in Section 4.c of the IETF Trust's Legal
306 Provisions Relating to IETF Documents
307 (http://trustee.ietf.org/license-info).
309 This version of this YANG module is part of RFC XXXX; see
310 the RFC itself for full legal notices.
312 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
313 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
314 'MAY', and 'OPTIONAL' in this document are to be interpreted as
315 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
316 they appear in all capitals, as shown here.";
318 revision "2020-03-09" {
319 description
320 "Initial Version.";
321 reference
322 "RFC XXXX, YANG Data Module for HTTPS Notifications.";
323 }
325 identity https {
326 base sn:transport;
327 description
328 "HTTPS transport for notifications.";
329 }
331 grouping https-receivers {
332 description
333 "Grouping for HTTPS based receivers such that it can be
334 implemented outside the constructs of a Subscription to YANG
335 Notification [RFC8639] module.";
336 container https-receivers {
337 description
338 "HTTPS based notifications.";
340 list https-receiver {
341 key "name";
343 leaf name {
344 type string;
345 description
346 "A name that uniquely identifies this receiver.";
347 }
349 container tcp-params {
350 uses tcpc:tcp-client-grouping;
351 description
352 "TCP client parameters.";
353 }
354 container tls-params {
355 uses tlsc:tls-client-grouping;
356 description
357 "TLS client parameters.";
358 }
360 container http-params {
361 description
362 "HTTP client parameters.";
364 uses httpc:http-client-grouping;
366 leaf path {
367 type inet:uri;
368 description
369 "The absolute path for the resource on the remote
370 HTTPS server. The absolute path as specified in
371 RFC 3986 as 'path-absolute'.";
372 reference
373 "RFC 3986: URI Generic Syntax.";
374 }
375 }
377 container receiver-identity {
378 description
379 "Specifies mechanism for identifying the receiver. The
380 publisher MUST NOT include any content in a notification
381 that the user is not authorized to view.";
383 container cert-maps {
384 uses x509c2n:cert-to-name;
385 description
386 "The cert-maps container is used by a TLS-based HTTP
387 server to map the HTTPS client's presented X.509
388 certificate to a 'local' username. If no matching and
389 valid cert-to-name list entry is found, the publisher
390 MUST close the connection, and MUST NOT
391 not send any notifications over it.";
392 reference
393 "RFC 7407: A YANG Data Model for SNMP Configuration.";
394 }
395 }
396 description
397 "All receivers interested in this notification.";
398 }
399 }
400 }
401 augment "/sn:subscriptions" {
402 description
403 "Augment the subscirbed notification module to add in the
404 receivers container.";
405 uses https-receivers;
406 }
408 augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {
409 leaf receiver-ref {
410 type leafref {
411 path "/sn:subscriptions/hn:https-receivers/hn:https-receiver/" +
412 "hn:name";
413 }
414 description
415 "Reference to a receiver.";
416 }
417 description
418 "Augment the subscriptions container to define the receiver.";
419 }
420 }
421
423 4. Security Considerations
425 The YANG module specified in this document defines a schema for data
426 that is designed to be accessed via network management protocols such
427 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
428 is the secure transport layer, and the mandatory-to-implement secure
429 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
430 is HTTPS, and the mandatory-to-implement secure transport is TLS
431 [RFC8446]. The NETCONF Access Control Model (NACM) [RFC8341]
432 provides the means to restrict access for particular NETCONF or
433 RESTCONF users to a preconfigured subset of all available NETCONF or
434 RESTCONF protocol operations and content.
436 There are a number of data nodes defined in this YANG module that are
437 writable/creatable/deletable (i.e., config true, which is the
438 default). These data nodes may be considered sensitive or vulnerable
439 in some network environments. Write operations (e.g., edit-config)
440 to these data nodes without proper protection can have a negative
441 effect on network operations. These are the subtrees and data nodes
442 and their sensitivity/vulnerability:
444 Some of the readable data nodes in this YANG module may be considered
445 sensitive or vulnerable in some network environments. It is thus
446 important to control read access (e.g., via get, get-config, or
447 notification) to these data nodes. These are the subtrees and data
448 nodes and their sensitivity/vulnerability:
450 Some of the RPC operations in this YANG module may be considered
451 sensitive or vulnerable in some network environments. It is thus
452 important to control access to these operations. These are the
453 operations and their sensitivity/vulnerability:
455 5. IANA Considerations
457 This document registers one URI, one YANG module and two Media Types.
459 5.1. URI Registration
461 in the IETF XML registry [RFC3688]. Following the format in RFC
462 3688, the following registration is requested to be made:
464 URI: urn:ietf:params:xml:ns:yang:ietf-http-notif
466 Registrant Contact: The IESG. XML: N/A, the requested URI is an XML
467 namespace.
469 5.2. YANG Module Name Registration
471 This document registers one YANG module in the YANG Module Names
472 registry YANG [RFC6020].
474 name: ietf-https-notif
475 namespace: urn:ietf:params:xml:ns:yang:ietf-https-notif
476 prefix: hn
477 reference: RFC XXXX
479 5.3. Media Types
481 5.3.1. Media Type "application/ietf-https-notif-cap+xml
483 Type name: application
485 Subtype name: ietf-https-notif-cap+xml
487 Required parameters: None
489 Optional parameters: None
491 Encoding considerations:
492 8-bit Each conceptual YANG data node is encoded according to the XML
493 Encoding Rules and Canonical Format for the specific YANG data node
494 type defined in YANG 1.1 [RFC7950].
496 Security considerations:
497 Security considerations related to the generation and consumption of
498 RESTCONF messages are discussed in Section NN of RFC XXXX.
500 Additional security considerations are specific to the semantics of
501 particular YANG data models. Each YANG module is expected to specify
502 security considerations for the YANG data defined in that module.
504 Interoperability considerations: N/A
506 Published specification: RFC XXXX
508 Applications that use this media type:
509 Instance document data parsers used within a protocol or automation
510 tool that utilize YANG-defined data structures.
512 Fragment identifier considerations:
513 Fragment identifiers for this type are not defined. All YANG data
514 nodes are accessible as resources using the path in the request URI.
516 Additional information:
518 Deprecated alias names for this type: N/A
519 Magic number(s): N/A
520 File extension(s): None
521 Macintosh file type code(s): "TEXT"
523 Person & email address to contact for further information:
524 See Author's Address section of RFC XXXX.
526 Intended usage: COMMON
528 Restrictions on usage: N/A
530 Author: See Author's Address section of RFC XXXX
532 Change controller:
533 Internet Engineering Task Force (mailto:iesg@ietf.org)
535 Provisional registration? (standards tree only): no
537 5.3.2. Media Type "application/ietf-https-notif-cap+json
539 Type name: application
541 Subtype name: ietf-https-notif-cap+json
543 Required parameters: None
544 Optional parameters: None
546 Encoding considerations:
547 8-bit Each conceptual YANG data node is encoded according to the XML
548 Encoding Rules and Canonical Format for the specific YANG data node
549 type defined in JSON Encoding of Data Modeled with YANG [RFC7951].
551 Security considerations:
552 Security considerations related to the generation and consumption of
553 RESTCONF messages are discussed in Section NN of RFC XXXX.
555 Additional security considerations are specific to the semantics of
556 particular YANG data models. Each YANG module is expected to specify
557 security considerations for the YANG data defined in that module.
559 Interoperability considerations: N/A
561 Published specification: RFC XXXX
563 Applications that use this media type:
564 Instance document data parsers used within a protocol or automation
565 tool that utilize YANG-defined data structures.
567 Fragment identifier considerations:
568 Fragment identifiers for this type are not defined. All YANG data
569 nodes are accessible as resources using the path in the request URI.
571 Additional information:
573 Deprecated alias names for this type: N/A
574 Magic number(s): N/A
575 File extension(s): None
576 Macintosh file type code(s): "TEXT"
578 Person & email address to contact for further information:
579 See Author's Address section of RFC XXXX.
581 Intended usage: COMMON
583 Restrictions on usage: N/A
585 Author: See Author's Address section of RFC XXXX
587 Change controller:
588 Internet Engineering Task Force (mailto:iesg@ietf.org)
590 Provisional registration? (standards tree only): no
591 6. Examples
593 This section tries to show some examples in how the model can be
594 used.
596 6.1. HTTPS Configured Subscription
598 This example shows how a HTTPS client can be configured to send
599 notifications to a receiver at address 192.0.2.1, port 443 with
600 server certificates, and the corresponding trust store that is used
601 to authenticate a connection.
603 [note: '\' line wrapping for formatting only]
605
606
607
610 \
614
615 foo
616
617 my-receiver.my-domain.com
618 443
619
620
621
622 explicitly-trusted-server-ca-certs
623 explicitly-trusted-server-certs
624
625
626
627
628
629 my-name
630 my-password
631
632
633 /some/path
634
635
636
637
638 1
639 11:0A:05:11:00
640 x509c2n:san-any
641
642
643
644
645
646
647 6666
648 foo
649 some-stream
650
651
652 my-receiver
653 foo
656
657
658
659
661
662
663 explicitly-trusted-server-certs
664
665 Specific server authentication certificates for explicitly
666 trusted servers. These are needed for server certificates
667 that are not signed by a pinned CA.
668
669
670 Fred Flintstone
671 base64encodedvalue==
672
673
674
675 explicitly-trusted-server-ca-certs
676
677 Trust anchors (i.e. CA certs) that are used to authenticate
678 server connections. Servers are authenticated if their
679 certificate has a chain of trust to one of these CA
680 certificates.
681
682
683 ca.example.com
684 base64encodedvalue==
685
686
688
689
691 6.2. Bundled Message
693 In the case of "bundled-message" as defined in Notification Message
694 Headers and Bundles [I-D.ietf-netconf-notification-messages],
695 something that this module supports, the flow of messages would look
696 something like this.
698 ------------- --------------
699 | Publisher | | Receiver |
700 ------------- --------------
701 Establish TCP ------>
702 Establish TLS ------>
703 Send HTTPS POST message
704 with YANG defined ------>
705 notification #1
706 Send HTTPS POST message
707 with YANG defined ------>
708 notification #2
709 Send 204 (No Content)
710 <------ for notification #1
712 Send 204 (No Content)
713 <------ for notification #2
714 Send HTTPS POST message
715 with YANG defined ------->
716 notification #3
717 Send 204 (No Content)
718 <------ for notification #3
720 The content of the exchange would look something like this.
722 Request:
723 POST /some/path HTTP/1.1
724 Host: my-receiver.my-domain.com
725 Content-Type: application/yang-data+xml
726
728 2019-03-22T12:35:00Z
729
730 ...
731
732
733
735 2019-03-22T12:35:00Z
736
737 ...
738
739
740
742 2019-03-22T12:35:01Z
743
744 ...
745
746
747 Response:
748 HTTP/1.1 204 No Content
749 Date: Fri, 03 Mar 2019 12:35:00 GMT
750 Server: my-receiver.my-domain.com
751 HTTP/1.1 204 No Content
752 Date: Fri, 03 Mar 2019 12:35:00 GMT
753 Server: my-receiver.my-domain.com
754 HTTP/1.1 204 No Content
755 Date: Fri, 03 Mar 2019 12:35:01 GMT
756 Server: my-receiver.my-domain.com
758 7. Contributors
760 8. Acknowledgements
762 9. References
764 9.1. Normative references
766 [I-D.ietf-netconf-notification-messages]
767 Voit, E., Jenkins, T., Birkholz, H., Bierman, A., and A.
768 Clemm, "Notification Message Headers and Bundles", draft-
769 ietf-netconf-notification-messages-08 (work in progress),
770 November 2019.
772 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
773 Requirement Levels", BCP 14, RFC 2119,
774 DOI 10.17487/RFC2119, March 1997,
775 .
777 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
778 DOI 10.17487/RFC3688, January 2004,
779 .
781 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
782 the Network Configuration Protocol (NETCONF)", RFC 6020,
783 DOI 10.17487/RFC6020, October 2010,
784 .
786 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
787 and A. Bierman, Ed., "Network Configuration Protocol
788 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
789 .
791 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
792 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
793 .
795 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
796 RFC 6991, DOI 10.17487/RFC6991, July 2013,
797 .
799 [RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for
800 SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407,
801 December 2014, .
803 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
804 RFC 7950, DOI 10.17487/RFC7950, August 2016,
805 .
807 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
808 RFC 7951, DOI 10.17487/RFC7951, August 2016,
809 .
811 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
812 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
813 .
815 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
816 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
817 May 2017, .
819 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
820 Access Control Model", STD 91, RFC 8341,
821 DOI 10.17487/RFC8341, March 2018,
822 .
824 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
825 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
826 .
828 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
829 E., and A. Tripathy, "Subscription to YANG Notifications",
830 RFC 8639, DOI 10.17487/RFC8639, September 2019,
831 .
833 9.2. Informative references
835 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
836 Resource Identifier (URI): Generic Syntax", STD 66,
837 RFC 3986, DOI 10.17487/RFC3986, January 2005,
838 .
840 Authors' Addresses
842 Mahesh Jethanandani
843 VMware
845 Email: mjethanandani@gmail.com
847 Kent Watsen
848 Watsen Networks
849 USA
851 Email: kent+ietf@watsen.net