idnits 2.17.1 draft-ietf-netconf-udp-notif-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 376 has weird spacing: '...address inet...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Note that receivers MAY NOT be already up and running when the configuration of the subscription takes effect on the monitored device. The first message MUST be a separate subscription-started notification to indicate the Receiver that the stream has started flowing. Then, the notifications can be sent immediately without delay. All the subscription state notifications, as defined in [RFC8639], MUST be encapsulated in separate notification messages. -- The document date (October 3, 2020) is 1298 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) -- Looks like a reference, but probably isn't: '1' on line 648 == Unused Reference: 'RFC4347' is defined on line 569, but no explicit reference was found in the text == Unused Reference: 'RFC5234' is defined on line 573, but no explicit reference was found in the text == Unused Reference: 'RFC5246' is defined on line 578, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 583, but no explicit reference was found in the text == Unused Reference: 'RFC6347' is defined on line 595, but no explicit reference was found in the text == Unused Reference: 'RFC8040' is defined on line 607, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-15) exists of draft-ietf-netconf-https-notif-04 Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF G. Zheng 3 Internet-Draft T. Zhou 4 Intended status: Standards Track Huawei 5 Expires: April 6, 2021 T. Graf 6 Swisscom 7 P. Francois 8 INSA-Lyon 9 P. Lucente 10 NTT 11 October 3, 2020 13 UDP-based Transport for Configured Subscriptions 14 draft-ietf-netconf-udp-notif-00 16 Abstract 18 This document describes an UDP-based notification mechanism to 19 collect data from networking devices. A shim header is proposed to 20 facilitate the streaming of data directly from line cards to a 21 collector. The objective is to rely on a lightweight approach to 22 allow for higher frequency and better transit performance compared to 23 already established notification mechanisms. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 6, 2021. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Configured Subscription to UDP-Notif . . . . . . . . . . . . 4 67 3. UDP-Based Transport . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Design Overview . . . . . . . . . . . . . . . . . . . . . 4 69 3.2. Format of the UDP-Notif Message Header . . . . . . . . . 5 70 3.3. Options . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.3.1. Fragmentation Option . . . . . . . . . . . . . . . . 6 72 3.4. Data Encoding . . . . . . . . . . . . . . . . . . . . . . 7 73 4. Congestion Control . . . . . . . . . . . . . . . . . . . . . 8 74 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 8 75 6. A YANG Data Model for Management of UDP-Notif . . . . . . . . 8 76 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 82 11.2. Informative References . . . . . . . . . . . . . . . . . 14 83 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 86 1. Introduction 88 Sub-Notif [RFC8639] defines a mechanism that lets a collector 89 subscribe to the publication of YANG-defined data maintained in a 90 YANG [RFC7950] datastore. The mechanism separates the management and 91 control of subscriptions from the transport used to deliver the data. 92 Three transport mechanisms, namely NETCONF transport [RFC8640], 93 RESTCONF transport [RFC8650], and HTTPS transport 94 [I-D.ietf-netconf-https-notif] have been defined so far for such 95 notification messages. 97 While powerful in its features and general in their architecture, the 98 currently available transport mechanisms need to be complemented to 99 support data publications at high velocity from devices that feature 100 a distributed architecture. The currently available transports are 101 based on TCP and lack the efficiency needed to continuously send 102 notifications at high velocity. 104 This document specifies a transport option for Sub-Notif that 105 leverages UDP. Specifically, it facilitates the distributed data 106 collection mechanism described in 107 [I-D.unyte-netconf-distributed-notif]. In the case of data 108 originating from multiple line cards, centralized designs require 109 data to be internally forwarded from those line cards to the push 110 server, presumably on a route processor, which then combines the 111 individual data items into a single consolidated stream. The 112 centralized data collection mechanism can result in a performance 113 bottleneck, especially when large amounts of data are involved. 115 What is needed is the support for a mechanism that allows for 116 directly pushing multiple substreams, e.g. one from each line card, 117 without passing them through an additional processing stage for 118 internal consolidation. The proposed UDP-based transport allows for 119 such a distributed data collection approach. 121 o Firstly, a UDP approach reduces the burden of maintaining a large 122 amount of active TCP connections at the collector, notably in 123 cases where it collects data from the line cards of a large amount 124 of networking devices. 126 o Secondly, as no connection state needs to be maintained, UDP 127 encapsulation can be easily implemented by the hardware of the 128 publication streamer, which will further improve performance. 130 o Ultimately, such advantages allow for a larger data analysis 131 feature set, as more voluminous, finer grained data sets can be 132 streamed to the collector. 134 The transport described in this document can be used for transmitting 135 notification messages over both IPv4 and IPv6. 137 This document describes the notification mechanism. It is intended 138 to be used in conjunction with [RFC8639], extended by 139 [I-D.unyte-netconf-distributed-notif]. 141 Section 2 describes the control of the proposed transport mechanism. 142 Section 3 details the notification mechanism and message format. 143 Section 4 discusses congestion control. Section 5 covers the 144 applicability of the proposed mechanism. 146 2. Configured Subscription to UDP-Notif 148 This section describes how the proposed mechanism can be controlled 149 using subscription channels based on NETCONF or RESTCONF. 151 Following the usual approach of Sub-Notif, configured subscriptions 152 contain the location information of all the receivers, including the 153 IP address and the port number, so that the publisher can actively 154 send UDP-Notif messages to the corresponding receivers. 156 Note that receivers MAY NOT be already up and running when the 157 configuration of the subscription takes effect on the monitored 158 device. The first message MUST be a separate subscription-started 159 notification to indicate the Receiver that the stream has started 160 flowing. Then, the notifications can be sent immediately without 161 delay. All the subscription state notifications, as defined in 162 [RFC8639], MUST be encapsulated in separate notification messages. 164 3. UDP-Based Transport 166 In this section, we specify the UDP-Notif Transport behaviour. 167 Section 3.1 describes the general design of the solution. 168 Section 3.2 specifies the UDP-Notif message format. Section 3.3 169 describes a generic optional sub TLV format. Section 3.3.1 uses such 170 options to provide a fragmentation solution for large UDP-Notif 171 message payloads. Section 3.4 describes the encoding of the message 172 payload. 174 3.1. Design Overview 176 As specified in Sub-Notif, the telemetry data is encapsulated in the 177 NETCONF/RESTCONF notification message, which is then encapsulated and 178 carried using transport protocols such as TLS or HTTP2. Figure 1 179 illustrates the the structure of an UDP-Notif message. 181 o The Message Header contains information that facilitate the 182 message transmission before deserializing the notification 183 message. 185 o Notification Message is the encoded content that the publication 186 stream transports. The common encoding methods include GPB [1], 187 CBOR [RFC7049], JSON, and XML. 188 [I-D.ietf-netconf-notification-messages] describes the structure 189 of the Notification Message for single notifications and bundled 190 notifications. 192 +-------+ +--------------+ +--------------+ 193 | UDP | | Message | | Notification | 194 | | | Header | | Message | 195 +-------+ +--------------+ +--------------+ 197 Figure 1: UDP-Notif Message Overview 199 3.2. Format of the UDP-Notif Message Header 201 The UDP-Notif Message Header contains information that facilitate the 202 message transmission before deserializing the notification message. 203 The data format is shown in Figure 2. 205 0 1 2 3 206 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 207 +-------+-------+---------------+-------------------------------+ 208 | Vers. | ET | Header Len | Message Length | 209 +-------+-------+---------------+-------------------------------+ 210 | Message-Generator-ID | 211 +---------------------------------------------------------------+ 212 | Message ID | 213 +---------------------------------------------------------------+ 214 ~ Options ~ 215 +---------------------------------------------------------------+ 217 Figure 2: UDP-Notif Message Header Format 219 The Message Header contains the following field: 221 o Version represents the PDU (Protocol Data Unit) encoding version. 222 The initial version value is 0. 224 o ET is a 4 bit identifier to indicate the encoding type used for 225 the Notification Message. 16 types of encoding can be expressed: 227 * 0: GPB; 229 * 1: CBOR; 231 * 2: JSON; 233 * 3: XML; 235 * others are reserved. 237 o Header Length is the length of the message header in octets, 238 including both the fixed header and the options. 240 o Message Length is the total length of the message within one UDP 241 datagram, measured in octets, including the message header. 243 o Message-Generator-ID is a 32-bit identifier of the process which 244 created the notification message. This allows disambiguation of 245 an information source, such as the identification of different 246 line cards sending the notification messages. The source IP 247 address of the UDP datagrams SHOULD NOT be interpreted as the 248 identifier for the host that originated the UDP-Notif message. 249 Indeed, the streamer sending the UDP-Notif message could be a 250 relay for the actual source of data carried within UDP-Notif 251 messages. 253 o The Message ID is generated continuously by the sender of UDP- 254 Notif messages. Different subscribers share the same Message ID 255 sequence. 257 o Options is a variable-length field in the TLV format. When the 258 Header Length is larger than 12 octets, which is the length of the 259 fixed header, Options TLVs follow directly after the fixed message 260 header (i.e., Message ID). The details of the options are 261 described in the following section. 263 3.3. Options 265 All the options are defined with the following format, illustrated in 266 Figure 3. 268 0 1 2 3 269 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 270 +---------------+---------------+-------------------------------- 271 | Type | Length | Variable-length data 272 +---------------+---------------+-------------------------------- 274 Figure 3: Generic Option Format 276 o Type: 1 octet describing the option type; 278 o Length: 1 octet of the TLV Length, including the Type and Length 279 fields; 281 o Variable-length data: 0 or more octets of TLV Value. 283 3.3.1. Fragmentation Option 285 The UDP payload length is limited to 65535. Application level 286 headers will make the actual payload shorter. Even though binary 287 encodings such as GPB and CBOR may not require more space than what 288 is left, more voluminous encodings such as JSON and XML may suffer 289 from this size limitation. Although IPv4 and IPv6 senders can 290 fragment outgoing packets exceeding their Maximum Transmission 291 Unit(MTU), fragmented IP packets may not be desired for operational 292 and performance reasons. 294 Consequently, implementations of the mechanism SHOULD provide a 295 configurable max-fragment-size option to control the maximum size of 296 a payload. 298 0 1 2 3 299 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 300 +---------------+---------------+ 301 | Type | Length | 302 +-------------------------------+---------------+-------------+-+ 303 | Fragment Number |L| 304 +-------------------------------------------------------------+-+ 306 Figure 4: Fragmentation Option Format 308 The Fragmentation Option is to be included when the message content 309 is fragmented into multiple pieces. Different fragments of one 310 message share the same Message ID. An illustration is provided in 311 Figure 4. The fields of this TLV are: 313 o Type: indicates Fragmentation Option. The Type value is to be 314 asigned. 316 o Length: is a fixed value of 6 octets. 318 o Fragment Number: indicates the sequence number of the current 319 fragment. 321 o L: is a flag to indicate whether the current fragment is the last 322 one. When 0 is set, the current fragment is not the last one, 323 hence more fragments are expected. When 1 is set, the current 324 fragment is the last one. 326 3.4. Data Encoding 328 UDP-Notif message data can be encoded in GPB, CBOR, XML or JSON 329 format. It is conceivable that additional encodings may be supported 330 in the future. This can be accomplished by augmenting the 331 subscription data model with additional identity statements used to 332 refer to requested encodings. 334 Implementation MAY support multiple encoding methods per 335 subscription. When bundled notifications are supported between the 336 publisher and the receiver, only subscribed notifications with the 337 same encoding can be bundled in a given message. 339 4. Congestion Control 341 Congestion control mechanisms that respond to congestion by reducing 342 traffic rates and establish a degree of fairness between flows that 343 share the same path are vital to the stable operation of the Internet 344 [RFC2914]. While efficient, UDP has no built-in congestion control 345 mechanism. Because streaming telemetry can generate unlimited 346 amounts of data, transferring this data over UDP may be considered 347 problematic. It is not recommended to use the proposed mechanism 348 over congestion-sensitive network paths. The only environments where 349 UDP-Notif is expected to be used are managed networks. The 350 deployments require that the network path has been explicitly 351 provisioned to handle the traffic through traffic engineering 352 mechanisms, such as rate limiting or capacity reservations. The UDP- 353 Notif Message ID can be used to deduce congestion based on packet 354 loss detection. Hence the collector can notify the device to use a 355 lower streaming rate. The interaction to control the streaming rate 356 on the device is out of the scope of this document. 358 5. Applicability 360 The target application for UDP-Notif is the collection of data-plane 361 information. The lack of reliability of the data streaming mechanism 362 is thus considered acceptable as the mechanism is to be used in 363 controlled environments, mitigating the risk of information loss, 364 while allowing for publication of very large amounts of data. 365 Moreover, in this context, sporadic events when incomplete data 366 collection is provided is not critical for the proper management of 367 the network. 369 6. A YANG Data Model for Management of UDP-Notif 371 The YANG model defined in Section 9 has two leafs augmented into one 372 place of Sub-Notif [RFC8639], plus one identity. 374 module: ietf-udp-subscribed-notifications 375 augment /sn:subscriptions/sn:subscription/sn:receivers/sn:receiver: 376 +--rw address inet:ip-address 377 +--rw port inet:port-number 378 +--rw enable-fragment? boolean 379 +--rw max-fragment-size? uint32 381 7. YANG Module 383 file "ietf-udp-notif@2020-04-27.yang" 384 module ietf-udp-notif { 385 yang-version 1.1; 386 namespace 387 "urn:ietf:params:xml:ns:yang:ietf-udp-notif"; 388 prefix un; 389 import ietf-subscribed-notifications { 390 prefix sn; 391 reference 392 "RFC 8639: Subscription to YANG Notifications"; 393 } 394 import ietf-inet-types { 395 prefix inet; 396 reference 397 "RFC 6991: Common YANG Data Types"; 398 } 400 organization "IETF NETCONF (Network Configuration) Working Group"; 401 contact 402 "WG Web: 403 WG List: 405 Authors: Guangying Zheng 406 407 Tianran Zhou 408 409 Thomas Graf 410 411 Pierre Francois 412 413 Paolo Lucente 414 "; 416 description 417 "Defines UDP-Notif as a supported transport for subscribed 418 event notifications. 420 Copyright (c) 2018 IETF Trust and the persons identified as authors 421 of the code. All rights reserved. 423 Redistribution and use in source and binary forms, with or without 424 modification, is permitted pursuant to, and subject to the license 425 terms contained in, the Simplified BSD License set forth in Section 426 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 427 (https://trustee.ietf.org/license-info). 429 This version of this YANG module is part of RFC XXXX; see the RFC 431 itself for full legal notices."; 433 revision 2020-04-27 { 434 description 435 "Initial version"; 436 reference 437 "RFC XXXX: UDP-based Notifications for Streaming Telemetry"; 438 } 440 identity udp-notif { 441 base sn:transport; 442 description 443 "UDP-Notif is used as transport for notification messages 444 and state change notifications."; 445 } 447 identity encode-cbor { 448 base sn:encoding; 449 description 450 "Encode data using CBOR as described in RFC 7049."; 451 reference 452 "RFC 7049: Concise Binary Object Representation"; 453 } 455 identity encode-gpb { 456 base sn:encoding; 457 description 458 "Encode data using GPB."; 459 } 461 grouping target-receiver { 462 description 463 "Provides a reusable description of a UDP-Notif target receiver."; 464 leaf address { 465 type inet:ip-address; 466 mandatory true; 467 description 468 "IP address of target UDP-Notif receiver, which can be an 469 IPv4 address or an IPV6 address."; 470 } 471 leaf port { 472 type inet:port-number; 473 mandatory true; 474 description 475 "Port number of target UDP-Notif receiver, if not specified, 476 the system should use default port number."; 478 } 480 leaf enable-fragment { 481 type boolean; 482 default false; 483 description 484 "The switch for the fragment feature. When disabled, the 485 publisher will not allow fragment for a very large data"; 486 } 488 leaf max-fragment-size { 489 when "../enable-fragment = true"; 490 type uint32; 491 description "UDP-Notif provides a configurable max-fragment-size 492 to control the size of each message."; 493 } 494 } 496 augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" { 497 description 498 "This augmentation allows UDP-Notif specific parameters to be 499 exposed for a subscription."; 500 uses target-receiver; 501 } 502 } 503 505 8. IANA Considerations 507 This RFC requests that IANA assigns one UDP port number in the 508 "Registered Port Numbers" range with the service name "udp-notif". 509 This port will be the default port for the UDP-based notification 510 Streaming Telemetry (UDP-Notif) for NETCONF and RESTCONF. Below is 511 the registration template following the rules of [RFC6335]. 513 Service Name: udp-notif 515 Transport Protocol(s): UDP 517 Assignee: IESG 519 Contact: IETF Chair 521 Description: UDP-based Publication Streaming Telemetry 523 Reference: RFC XXXX 525 Port Number: PORT-X 526 IANA is requested to assign a new URI from the IETF XML Registry 527 [RFC3688]. The following URI is suggested: 529 URI: urn:ietf:params:xml:ns:yang:ietf-udp-notif 530 Registrant Contact: The IESG. 531 XML: N/A; the requested URI is an XML namespace. 533 This document also requests a new YANG module name in the YANG Module 534 Names registry [RFC7950] with the following suggestion: 536 name: ietf-udp-notif 537 namespace: urn:ietf:params:xml:ns:yang:ietf-udp-notif 538 prefix: un 539 reference: RFC XXXX 541 9. Security Considerations 543 TBD 545 10. Acknowledgements 547 The authors of this documents would like to thank Alexander Clemm, 548 Eric Voit, Huiyang Yang, Kent Watsen, Mahesh Jethanandani, Stephane 549 Frenot, Timothy Carey, Tim Jenkins, and Yunan Gu for their 550 constructive suggestions for improving this document. 552 11. References 554 11.1. Normative References 556 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 557 Requirement Levels", BCP 14, RFC 2119, 558 DOI 10.17487/RFC2119, March 1997, 559 . 561 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 562 RFC 2914, DOI 10.17487/RFC2914, September 2000, 563 . 565 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 566 DOI 10.17487/RFC3688, January 2004, 567 . 569 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 570 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, 571 . 573 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 574 Specifications: ABNF", STD 68, RFC 5234, 575 DOI 10.17487/RFC5234, January 2008, 576 . 578 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 579 (TLS) Protocol Version 1.2", RFC 5246, 580 DOI 10.17487/RFC5246, August 2008, 581 . 583 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 584 and A. Bierman, Ed., "Network Configuration Protocol 585 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 586 . 588 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 589 Cheshire, "Internet Assigned Numbers Authority (IANA) 590 Procedures for the Management of the Service Name and 591 Transport Protocol Port Number Registry", BCP 165, 592 RFC 6335, DOI 10.17487/RFC6335, August 2011, 593 . 595 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 596 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 597 January 2012, . 599 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 600 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 601 October 2013, . 603 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 604 RFC 7950, DOI 10.17487/RFC7950, August 2016, 605 . 607 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 608 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 609 . 611 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 612 E., and A. Tripathy, "Subscription to YANG Notifications", 613 RFC 8639, DOI 10.17487/RFC8639, September 2019, 614 . 616 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 617 E., and A. Tripathy, "Dynamic Subscription to YANG Events 618 and Datastores over NETCONF", RFC 8640, 619 DOI 10.17487/RFC8640, September 2019, 620 . 622 [RFC8650] Voit, E., Rahman, R., Nilsen-Nygaard, E., Clemm, A., and 623 A. Bierman, "Dynamic Subscription to YANG Events and 624 Datastores over RESTCONF", RFC 8650, DOI 10.17487/RFC8650, 625 November 2019, . 627 11.2. Informative References 629 [I-D.ietf-netconf-https-notif] 630 Jethanandani, M. and K. Watsen, "An HTTPS-based Transport 631 for Configured Subscriptions", draft-ietf-netconf-https- 632 notif-04 (work in progress), July 2020. 634 [I-D.ietf-netconf-notification-messages] 635 Voit, E., Jenkins, T., Birkholz, H., Bierman, A., and A. 636 Clemm, "Notification Message Headers and Bundles", draft- 637 ietf-netconf-notification-messages-08 (work in progress), 638 November 2019. 640 [I-D.unyte-netconf-distributed-notif] 641 Zhou, T., Zheng, G., Voit, E., Graf, T., and P. Francois, 642 "Subscription to Distributed Notifications", draft-unyte- 643 netconf-distributed-notif-00 (work in progress), June 644 2020. 646 11.3. URIs 648 [1] https://developers.google.com/protocol-buffers/ 650 Authors' Addresses 652 Guangying Zheng 653 Huawei 654 101 Yu-Hua-Tai Software Road 655 Nanjing, Jiangsu 656 China 658 Email: zhengguangying@huawei.com 660 Tianran Zhou 661 Huawei 662 156 Beiqing Rd., Haidian District 663 Beijing 664 China 666 Email: zhoutianran@huawei.com 667 Thomas Graf 668 Swisscom 669 Binzring 17 670 Zuerich 8045 671 Switzerland 673 Email: thomas.graf@swisscom.com 675 Pierre Francois 676 INSA-Lyon 677 Lyon 678 France 680 Email: pierre.francois@insa-lyon.fr 682 Paolo Lucente 683 NTT 684 Siriusdreef 70-72 685 Hoofddorp, WT 2132 686 NL 688 Email: paolo@ntt.net