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