idnits 2.17.00 (12 Aug 2021) /tmp/idnits39516/draft-ietf-netconf-udp-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 433 has weird spacing: '...address inet...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (May 26, 2021) is 360 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) == Unused Reference: 'RFC2914' is defined on line 612, but no explicit reference was found in the text == Unused Reference: 'RFC4347' is defined on line 620, but no explicit reference was found in the text == Unused Reference: 'RFC5234' is defined on line 624, but no explicit reference was found in the text == Unused Reference: 'RFC5246' is defined on line 629, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 634, but no explicit reference was found in the text == Unused Reference: 'RFC6347' is defined on line 646, but no explicit reference was found in the text == Unused Reference: 'RFC8040' is defined on line 658, 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 (-03) exists of draft-ietf-netconf-distributed-notif-01 == Outdated reference: A later version (-09) exists of draft-ietf-netconf-https-notif-08 Summary: 4 errors (**), 0 flaws (~~), 13 warnings (==), 2 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: November 27, 2021 T. Graf 6 Swisscom 7 P. Francois 8 INSA-Lyon 9 P. Lucente 10 NTT 11 May 26, 2021 13 UDP-based Transport for Configured Subscriptions 14 draft-ietf-netconf-udp-notif-02 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 data streaming directly from the publishing process on 21 network processor of line cards to receivers. The objective is a 22 lightweight approach to enable higher frequency and less performance 23 impact on publisher and receiver process compared to already 24 established notification mechanisms. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on November 27, 2021. 49 Copyright Notice 51 Copyright (c) 2021 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Configured Subscription to UDP-Notif . . . . . . . . . . . . 4 68 3. UDP-Based Transport . . . . . . . . . . . . . . . . . . . . . 4 69 3.1. Design Overview . . . . . . . . . . . . . . . . . . . . . 4 70 3.2. Format of the UDP-Notif Message Header . . . . . . . . . 5 71 3.3. Options . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.3.1. Segmentation Option . . . . . . . . . . . . . . . . . 7 73 3.4. Data Encoding . . . . . . . . . . . . . . . . . . . . . . 8 74 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 8 75 4.1. Congestion Control . . . . . . . . . . . . . . . . . . . 8 76 4.2. Message Size . . . . . . . . . . . . . . . . . . . . . . 9 77 4.3. Reliability . . . . . . . . . . . . . . . . . . . . . . . 9 78 5. A YANG Data Model for Management of UDP-Notif . . . . . . . . 9 79 6. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 85 10.2. Informative References . . . . . . . . . . . . . . . . . 15 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 88 1. Introduction 90 Sub-Notif [RFC8639] defines a mechanism that lets a receiver 91 subscribe to the publication of YANG-defined data maintained in a 92 YANG [RFC7950] datastore. The mechanism separates the management and 93 control of subscriptions from the transport used to deliver the data. 94 Three transport mechanisms, namely NETCONF transport [RFC8640], 95 RESTCONF transport [RFC8650], and HTTPS transport 97 [I-D.ietf-netconf-https-notif] have been defined so far for such 98 notification messages. 100 While powerful in their features and general in their architecture, 101 the currently available transport mechanisms need to be complemented 102 to support data publications at high velocity from devices that 103 feature a distributed architecture. The currently available 104 transports are based on TCP and lack the efficiency needed to 105 continuously send notifications at high velocity. 107 This document specifies a transport option for Sub-Notif that 108 leverages UDP. Specifically, it facilitates the distributed data 109 collection mechanism described in 110 [I-D.ietf-netconf-distributed-notif]. In the case of publishing from 111 multiple network processors on multiple line cards, centralized 112 designs require data to be internally forwarded from those network 113 processors to the push server, presumably on a route processor, which 114 then combines the individual data items into a single consolidated 115 stream. The centralized data collection mechanism can result in a 116 performance bottleneck, especially when large amounts of data are 117 involved. 119 What is needed is a mechanism that allows for directly publishing 120 from multiple network processors on line cards, without passing them 121 through an additional processing stage for internal consolidation. 122 The proposed UDP-based transport allows for such a distributed data 123 publishing approach. 125 o Firstly, a UDP approach reduces the burden of maintaining a large 126 amount of active TCP connections at the receiver, notably in cases 127 where it collects data from network processors on line cards from 128 a large amount of networking devices. 130 o Secondly, as no connection state needs to be maintained, UDP 131 encapsulation can be easily implemented by the hardware of the 132 publication streamer, which will further improve performance. 134 o Ultimately, such advantages allow for a larger data analysis 135 feature set, as more voluminous, finer grained data sets can be 136 streamed to the receiver. 138 The transport described in this document can be used for transmitting 139 notification messages over both IPv4 and IPv6. 141 This document describes the notification mechanism. It is intended 142 to be used in conjunction with [RFC8639], extended by 143 [I-D.ietf-netconf-distributed-notif]. 145 Section 2 describes the control of the proposed transport mechanism. 146 Section 3 details the notification mechanism and message format. 147 Section 4.1 discusses congestion control. Section 4 covers the 148 applicability of the proposed mechanism. 150 2. Configured Subscription to UDP-Notif 152 This section describes how the proposed mechanism can be controlled 153 using subscription channels based on NETCONF or RESTCONF. 155 Following the usual approach of Sub-Notif, configured subscriptions 156 contain the location information of all the receivers, including the 157 IP address and the port number, so that the publisher can actively 158 send UDP-Notif messages to the corresponding receivers. 160 Note that receivers MAY NOT be already up and running when the 161 configuration of the subscription takes effect on the monitored 162 device. The first message MUST be a separate subscription-started 163 notification to indicate the Receiver that the stream has started 164 flowing. Then, the notifications can be sent immediately without 165 delay. All the subscription state notifications, as defined in 166 [RFC8639], MUST be encapsulated in separate notification messages. 168 3. UDP-Based Transport 170 In this section, we specify the UDP-Notif Transport behavior. 171 Section 3.1 describes the general design of the solution. 172 Section 3.2 specifies the UDP-Notif message format. Section 3.3 173 describes a generic optional sub TLV format. Section 3.3.1 uses such 174 options to provide a segmentation solution for large UDP-Notif 175 message payloads. Section 3.4 describes the encoding of the message 176 payload. 178 3.1. Design Overview 180 As specified in Sub-Notif, the telemetry data is encapsulated in the 181 NETCONF/RESTCONF notification message, which is then encapsulated and 182 carried using transport protocols such as TLS or HTTP2. Figure 1 183 illustrates the structure of an UDP-Notif message. 185 o The Message Header contains information that facilitate the 186 message transmission before deserializing the notification 187 message. 189 o Notification Message is the encoded content that the publication 190 stream transports. The common encoding methods include, CBOR 191 [RFC7049], JSON, and XML. 192 [I-D.ietf-netconf-notification-messages] describes the structure 193 of the Notification Message for single notifications and bundled 194 notifications. 196 +-------+ +--------------+ +--------------+ 197 | UDP | | Message | | Notification | 198 | | | Header | | Message | 199 +-------+ +--------------+ +--------------+ 201 Figure 1: UDP-Notif Message Overview 203 3.2. Format of the UDP-Notif Message Header 205 The UDP-Notif Message Header contains information that facilitate the 206 message transmission before deserializing the notification message. 207 The data format is shown in Figure 2. 209 0 1 2 3 210 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 211 +-----+-+-------+---------------+-------------------------------+ 212 | Ver |S| ET | Header Len | Message Length | 213 +-----+-+-------+---------------+-------------------------------+ 214 | Observation-Domain-ID | 215 +---------------------------------------------------------------+ 216 | Message-ID | 217 +---------------------------------------------------------------+ 218 ~ Options ~ 219 +---------------------------------------------------------------+ 221 Figure 2: UDP-Notif Message Header Format 223 The Message Header contains the following field: 225 o Ver represents the PDU (Protocol Data Unit) encoding version. The 226 initial version value is 0. 228 o S represents the space of encoding type specified in the ET field. 229 When S is unset, ET represents the standard encoding types as 230 defined in this document. When S is set, ET represents a private 231 space to be freely used for nonstandard encodings. 233 o ET is a 4 bit identifier to indicate the encoding type used for 234 the Notification Message. 16 types of encoding can be expressed. 235 When the S bit is unset, the following values apply: 237 * 0: CBOR; 239 * 1: JSON; 240 * 2: XML; 242 * others are reserved. 244 o Header Len is the length of the message header in octets, 245 including both the fixed header and the options. 247 o Message Length is the total length of the message within one UDP 248 datagram, measured in octets, including the message header. 250 o Observation-Domain-ID is a 32-bit identifier of the Observation 251 Domain that led to the production of the notification message, as 252 defined in [I-D.ietf-netconf-notification-messages]. This allows 253 disambiguation of an information source, such as the 254 identification of different line cards sending the notification 255 messages. The source IP address of the UDP datagrams SHOULD NOT 256 be interpreted as the identifier for the host that originated the 257 UDP-Notif message. Indeed, the streamer sending the UDP-Notif 258 message could be a relay for the actual source of data carried 259 within UDP-Notif messages. 261 o The Message ID is generated continuously by the sender of UDP- 262 Notif messages. Different subscribers share the same Message ID 263 sequence. 265 o Options is a variable-length field in the TLV format. When the 266 Header Length is larger than 12 octets, which is the length of the 267 fixed header, Options TLVs follow directly after the fixed message 268 header (i.e., Message ID). The details of the options are 269 described in the following section. 271 3.3. Options 273 All the options are defined with the following format, illustrated in 274 Figure 3. 276 0 1 2 3 277 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 278 +---------------+---------------+-------------------------------- 279 | Type | Length | Variable-length data 280 +---------------+---------------+-------------------------------- 282 Figure 3: Generic Option Format 284 o Type: 1 octet describing the option type; 286 o Length: 1 octet representing the total number of octets in the 287 TLV, including the Type and Length fields; 289 o Variable-length data: 0 or more octets of TLV Value. 291 3.3.1. Segmentation Option 293 The UDP payload length is limited to 65535. Application level 294 headers will make the actual payload shorter. Even though binary 295 encodings such as CBOR may not require more space than what is left, 296 more voluminous encodings such as JSON and XML may suffer from this 297 size limitation. Although IPv4 and IPv6 senders can fragment 298 outgoing packets exceeding their Maximum Transmission Unit(MTU), 299 fragmented IP packets may not be desired for operational and 300 performance reasons. 302 Consequently, implementations of the mechanism SHOULD provide a 303 configurable max-segment-size option to control the maximum size of a 304 payload. 306 0 1 2 3 307 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 308 +---------------+---------------+-----------------------------+-+ 309 | Type | Length | Segment Number |L| 310 +---------------+---------------+-----------------------------+-+ 312 Figure 4: Segmentation Option Format 314 The Segmentation Option is to be included when the message content is 315 segmented into multiple pieces. Different segments of one message 316 share the same Message ID. An illustration is provided in Figure 4. 317 The fields of this TLV are: 319 o Type: Generic option field which indicates a Segmentation Option. 320 The Type value is to be assigned. 322 o Length: Generic option field which indicates the length of this 323 option. It is a fixed value of 4 octets for the Segmentation 324 Option. 326 o Segment Number: 15-bit value indicating the sequence number of the 327 current segment. The first segment of a segmented message has a 328 Segment Number value of 0. 330 o L: is a flag to indicate whether the current segment is the last 331 one of the message. When 0 is set, the current segment is not the 332 last one. When 1 is set, the current segment is the last one, 333 meaning that the total number of segments used to transport this 334 message is the value of the current Segment Number + 1. 336 An implementation of this specification MUST NOT rely on IP 337 fragmentation by default to carry large messages. An implementation 338 of this specification MUST either restrict the size of individual 339 messages carried over this protocol, or support the segmentation 340 option. 342 3.4. Data Encoding 344 UDP-Notif message data can be encoded in CBOR, XML or JSON format. 345 It is conceivable that additional encodings may be supported in the 346 future. This can be accomplished by augmenting the subscription data 347 model with additional identity statements used to refer to requested 348 encodings. 350 Implementation MAY support multiple encoding methods per 351 subscription. When bundled notifications are supported between the 352 publisher and the receiver, only subscribed notifications with the 353 same encoding can be bundled in a given message. 355 4. Applicability 357 In this section, we provide an applicability statement for the 358 proposed mechanism, following the recommendations of [RFC8085]. 360 The proposed mechanism falls in the category of UDP applications 361 "designed for use within the network of a single network operator or 362 on networks of an adjacent set of cooperating network operators, to 363 be deployed in controlled environments". Implementations of the 364 proposed mechanism should thus follow the recommendations in place 365 for such specific applications. In the following, we discuss 366 recommendations on congestion control, message size guidelines, 367 reliability considerations. 369 4.1. Congestion Control 371 The proposed application falls into the category of applications 372 performing transfer of large amounts of data. It is expected that 373 the operator using the solution configures QoS on its related flows. 374 As per [RFC8085], such applications MAY choose not to implement any 375 form of congestion control, but follow the following principles. 377 It is NOT RECOMMENDED to use the proposed mechanism over congestion- 378 sensitive network paths. The only environments where UDP-Notif is 379 expected to be used are managed networks. The deployments require 380 that the network path has been explicitly provisioned to handle the 381 traffic through traffic engineering mechanisms, such as rate limiting 382 or capacity reservations. 384 Implementation of the proposal SHOULD NOT push unlimited amounts of 385 traffic by default, and SHOULD require the users to explicitly 386 configure such a mode of operation. 388 Burst mitigation through packet pacing is RECOMMENDED. Disabling 389 burst mitigation SHOULD require the users to explicitly configure 390 such a mode of operation. 392 Applications SHOULD monitor packet losses and provide means to the 393 user for retrieving information on such losses. The UDP-Notif 394 Message ID can be used to deduce congestion based on packet loss 395 detection. Hence the receiver can notify the device to use a lower 396 streaming rate. The interaction to control the streaming rate on the 397 device is out of the scope of this document. 399 4.2. Message Size 401 [RFC8085] recommends not to rely on IP fragmentation for messages 402 whose size result in IP packets exceeding the MTU along the path. 403 The segmentation option of the current specification permits 404 segmentation of the UDP Notif message content without relying on IP 405 fragmentation. Implementation of the current specification SHOULD 406 allow for the configuration of the MTU. 408 4.3. Reliability 410 The target application for UDP-Notif is the collection of data-plane 411 information. The lack of reliability of the data streaming mechanism 412 is thus considered acceptable as the mechanism is to be used in 413 controlled environments, mitigating the risk of information loss, 414 while allowing for publication of very large amounts of data. 415 Moreover, in this context, sporadic events when incomplete data 416 collection is provided is not critical for the proper management of 417 the network, as information collected for the devices through the 418 means of the proposed mechanism is to be often refreshed. 420 A receiver implementation for this protocol SHOULD deal with 421 potential loss of packets carrying a part of segmented payload, by 422 discarding packets that were received, but cannot be re-assembled as 423 a complete message within a given amount of time. This time SHOULD 424 be configurable. 426 5. A YANG Data Model for Management of UDP-Notif 428 The YANG model defined in Section 9 has two leaf's augmented into one 429 place of Sub-Notif [RFC8639], plus one identity. 431 module: ietf-udp-subscribed-notifications 432 augment /sn:subscriptions/sn:subscription/sn:receivers/sn:receiver: 433 +--rw address inet:ip-address 434 +--rw port inet:port-number 435 +--rw enable-fragment? boolean 436 +--rw max-fragment-size? uint32 438 6. YANG Module 440 file "ietf-udp-notif@2020-04-27.yang" 441 module ietf-udp-notif { 442 yang-version 1.1; 443 namespace 444 "urn:ietf:params:xml:ns:yang:ietf-udp-notif"; 445 prefix un; 446 import ietf-subscribed-notifications { 447 prefix sn; 448 reference 449 "RFC 8639: Subscription to YANG Notifications"; 450 } 451 import ietf-inet-types { 452 prefix inet; 453 reference 454 "RFC 6991: Common YANG Data Types"; 455 } 457 organization "IETF NETCONF (Network Configuration) Working Group"; 458 contact 459 "WG Web: 460 WG List: 462 Authors: Guangying Zheng 463 464 Tianran Zhou 465 466 Thomas Graf 467 468 Pierre Francois 469 470 Paolo Lucente 471 "; 473 description 474 "Defines UDP-Notif as a supported transport for subscribed 475 event notifications. 477 Copyright (c) 2018 IETF Trust and the persons identified as authors 478 of the code. All rights reserved. 480 Redistribution and use in source and binary forms, with or without 481 modification, is permitted pursuant to, and subject to the license 482 terms contained in, the Simplified BSD License set forth in Section 483 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 484 (https://trustee.ietf.org/license-info). 486 This version of this YANG module is part of RFC XXXX; see the RFC 488 itself for full legal notices."; 490 revision 2020-04-27 { 491 description 492 "Initial version"; 493 reference 494 "RFC XXXX: UDP-based Notifications for Streaming Telemetry"; 495 } 497 identity udp-notif { 498 base sn:transport; 499 description 500 "UDP-Notif is used as transport for notification messages 501 and state change notifications."; 502 } 504 identity encode-cbor { 505 base sn:encoding; 506 description 507 "Encode data using CBOR as described in RFC 7049."; 508 reference 509 "RFC 7049: Concise Binary Object Representation"; 510 } 512 grouping target-receiver { 513 description 514 "Provides a reusable description of a UDP-Notif target receiver."; 515 leaf address { 516 type inet:ip-address; 517 mandatory true; 518 description 519 "IP address of target UDP-Notif receiver, which can be an 520 IPv4 address or an IPV6 address."; 521 } 522 leaf port { 523 type inet:port-number; 524 mandatory true; 525 description 526 "Port number of target UDP-Notif receiver, if not specified, 527 the system should use default port number."; 529 } 531 leaf enable-fragment { 532 type boolean; 533 default false; 534 description 535 "The switch for the fragment feature. When disabled, the 536 publisher will not allow fragment for a very large data"; 537 } 539 leaf max-fragment-size { 540 when "../enable-fragment = true"; 541 type uint32; 542 description "UDP-Notif provides a configurable max-fragment-size 543 to control the size of each message."; 544 } 545 } 547 augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" { 548 description 549 "This augmentation allows UDP-Notif specific parameters to be 550 exposed for a subscription."; 551 uses target-receiver; 552 } 553 } 554 556 7. IANA Considerations 558 This RFC requests that IANA assigns one UDP port number in the 559 "Registered Port Numbers" range with the service name "udp-notif". 560 This port will be the default port for the UDP-based notification 561 Streaming Telemetry (UDP-Notif) for NETCONF and RESTCONF. Below is 562 the registration template following the rules of [RFC6335]. 564 Service Name: udp-notif 566 Transport Protocol(s): UDP 568 Assignee: IESG 570 Contact: IETF Chair 572 Description: UDP-based Publication Streaming Telemetry 574 Reference: RFC XXXX 576 Port Number: PORT-X 577 IANA is requested to assign a new URI from the IETF XML Registry 578 [RFC3688]. The following URI is suggested: 580 URI: urn:ietf:params:xml:ns:yang:ietf-udp-notif 581 Registrant Contact: The IESG. 582 XML: N/A; the requested URI is an XML namespace. 584 This document also requests a new YANG module name in the YANG Module 585 Names registry [RFC7950] with the following suggestion: 587 name: ietf-udp-notif 588 namespace: urn:ietf:params:xml:ns:yang:ietf-udp-notif 589 prefix: un 590 reference: RFC XXXX 592 8. Security Considerations 594 TBD 596 9. Acknowledgements 598 The authors of this documents would like to thank Alexander Clemm, 599 Eric Voit, Huiyang Yang, Kent Watsen, Mahesh Jethanandani, Stephane 600 Frenot, Timothy Carey, Tim Jenkins, and Yunan Gu for their 601 constructive suggestions for improving this document. 603 10. References 605 10.1. Normative References 607 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 608 Requirement Levels", BCP 14, RFC 2119, 609 DOI 10.17487/RFC2119, March 1997, 610 . 612 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 613 RFC 2914, DOI 10.17487/RFC2914, September 2000, 614 . 616 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 617 DOI 10.17487/RFC3688, January 2004, 618 . 620 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 621 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, 622 . 624 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 625 Specifications: ABNF", STD 68, RFC 5234, 626 DOI 10.17487/RFC5234, January 2008, 627 . 629 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 630 (TLS) Protocol Version 1.2", RFC 5246, 631 DOI 10.17487/RFC5246, August 2008, 632 . 634 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 635 and A. Bierman, Ed., "Network Configuration Protocol 636 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 637 . 639 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 640 Cheshire, "Internet Assigned Numbers Authority (IANA) 641 Procedures for the Management of the Service Name and 642 Transport Protocol Port Number Registry", BCP 165, 643 RFC 6335, DOI 10.17487/RFC6335, August 2011, 644 . 646 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 647 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 648 January 2012, . 650 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 651 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 652 October 2013, . 654 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 655 RFC 7950, DOI 10.17487/RFC7950, August 2016, 656 . 658 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 659 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 660 . 662 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 663 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 664 March 2017, . 666 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 667 E., and A. Tripathy, "Subscription to YANG Notifications", 668 RFC 8639, DOI 10.17487/RFC8639, September 2019, 669 . 671 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 672 E., and A. Tripathy, "Dynamic Subscription to YANG Events 673 and Datastores over NETCONF", RFC 8640, 674 DOI 10.17487/RFC8640, September 2019, 675 . 677 [RFC8650] Voit, E., Rahman, R., Nilsen-Nygaard, E., Clemm, A., and 678 A. Bierman, "Dynamic Subscription to YANG Events and 679 Datastores over RESTCONF", RFC 8650, DOI 10.17487/RFC8650, 680 November 2019, . 682 10.2. Informative References 684 [I-D.ietf-netconf-distributed-notif] 685 Zhou, T., Zheng, G., Voit, E., Graf, T., and P. Francois, 686 "Subscription to Distributed Notifications", draft-ietf- 687 netconf-distributed-notif-01 (work in progress), June 688 2020. 690 [I-D.ietf-netconf-https-notif] 691 Jethanandani, M. and K. Watsen, "An HTTPS-based Transport 692 for YANG Notifications", draft-ietf-netconf-https-notif-08 693 (work in progress), February 2021. 695 [I-D.ietf-netconf-notification-messages] 696 Voit, E., Jenkins, T., Birkholz, H., Bierman, A., and A. 697 Clemm, "Notification Message Headers and Bundles", draft- 698 ietf-netconf-notification-messages-08 (work in progress), 699 November 2019. 701 Authors' Addresses 703 Guangying Zheng 704 Huawei 705 101 Yu-Hua-Tai Software Road 706 Nanjing, Jiangsu 707 China 709 Email: zhengguangying@huawei.com 711 Tianran Zhou 712 Huawei 713 156 Beiqing Rd., Haidian District 714 Beijing 715 China 717 Email: zhoutianran@huawei.com 718 Thomas Graf 719 Swisscom 720 Binzring 17 721 Zuerich 8045 722 Switzerland 724 Email: thomas.graf@swisscom.com 726 Pierre Francois 727 INSA-Lyon 728 Lyon 729 France 731 Email: pierre.francois@insa-lyon.fr 733 Paolo Lucente 734 NTT 735 Siriusdreef 70-72 736 Hoofddorp, WT 2132 737 NL 739 Email: paolo@ntt.net