idnits 2.17.1 draft-ietf-netconf-udp-notif-03.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 8 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 469 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 (12 July 2021) is 1013 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 631, but no explicit reference was found in the text == Unused Reference: 'RFC8040' is defined on line 647, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-08) exists of draft-ietf-netconf-distributed-notif-02 == Outdated reference: A later version (-15) exists of draft-ietf-netconf-https-notif-08 Summary: 2 errors (**), 0 flaws (~~), 8 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: 13 January 2022 T. Graf 6 Swisscom 7 P. Francois 8 INSA-Lyon 9 P. Lucente 10 NTT 11 12 July 2021 13 UDP-based Transport for Configured Subscriptions 14 draft-ietf-netconf-udp-notif-03 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 13 January 2022. 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 (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Simplified BSD License text 60 as described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 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. Data Encoding . . . . . . . . . . . . . . . . . . . . . . 7 71 4. Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 4.1. Segmentation Option . . . . . . . . . . . . . . . . . . . 8 73 4.2. Private Encoding Option . . . . . . . . . . . . . . . . . 9 74 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 9 75 5.1. Congestion Control . . . . . . . . . . . . . . . . . . . 10 76 5.2. Message Size . . . . . . . . . . . . . . . . . . . . . . 10 77 5.3. Reliability . . . . . . . . . . . . . . . . . . . . . . . 10 78 6. A YANG Data Model for Management of UDP-Notif . . . . . . . . 11 79 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 82 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 85 11.2. Informative References . . . . . . . . . . . . . . . . . 15 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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 96 [I-D.ietf-netconf-https-notif] have been defined so far for such 97 notification messages. 99 While powerful in their features and general in their architecture, 100 the currently available transport mechanisms need to be complemented 101 to support data publications at high velocity from devices that 102 feature a distributed architecture. The currently available 103 transports are based on TCP and lack the efficiency needed to 104 continuously send notifications at high velocity. 106 This document specifies a transport option for Sub-Notif that 107 leverages UDP. Specifically, it facilitates the distributed data 108 collection mechanism described in 109 [I-D.ietf-netconf-distributed-notif]. In the case of publishing from 110 multiple network processors on multiple line cards, centralized 111 designs require data to be internally forwarded from those network 112 processors to the push server, presumably on a route processor, which 113 then combines the individual data items into a single consolidated 114 stream. The centralized data collection mechanism can result in a 115 performance bottleneck, especially when large amounts of data are 116 involved. 118 What is needed is a mechanism that allows for directly publishing 119 from multiple network processors on line cards, without passing them 120 through an additional processing stage for internal consolidation. 121 The proposed UDP-based transport allows for such a distributed data 122 publishing approach. 124 * Firstly, a UDP approach reduces the burden of maintaining a large 125 amount of active TCP connections at the receiver, notably in cases 126 where it collects data from network processors on line cards from 127 a large amount of networking devices. 129 * Secondly, as no connection state needs to be maintained, UDP 130 encapsulation can be easily implemented by the hardware of the 131 publication streamer, which will further improve performance. 133 * Ultimately, such advantages allow for a larger data analysis 134 feature set, as more voluminous, finer grained data sets can be 135 streamed to the receiver. 137 The transport described in this document can be used for transmitting 138 notification messages over both IPv4 and IPv6. 140 This document describes the notification mechanism. It is intended 141 to be used in conjunction with [RFC8639], extended by 142 [I-D.ietf-netconf-distributed-notif]. 144 Section 2 describes the control of the proposed transport mechanism. 145 Section 3 details the notification mechanism and message format. 146 Section 4 describes the use of options in the notification message 147 header. Section 5 covers the applicability of the proposed 148 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 4 173 describes a generic optional sub TLV format. Section 4.1 uses such 174 options to provide a segmentation solution for large UDP-Notif 175 message payloads. Section 3.3 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. This 183 document defines a UDP based transport. Figure 1 illustrates the 184 structure of an UDP-Notif message. 186 * The Message Header contains information that facilitate the 187 message transmission before deserializing the notification 188 message. 190 * Notification Message is the encoded content that the publication 191 stream transports. The common encoding methods include, CBOR 192 [RFC7049], JSON, and XML. 193 [I-D.ietf-netconf-notification-messages] describes the structure 194 of the Notification Message for single notifications and bundled 195 notifications. 197 +-------+ +--------------+ +--------------+ 198 | UDP | | Message | | Notification | 199 | | | Header | | Message | 200 +-------+ +--------------+ +--------------+ 202 Figure 1: UDP-Notif Message Overview 204 3.2. Format of the UDP-Notif Message Header 206 The UDP-Notif Message Header contains information that facilitate the 207 message transmission before deserializing the notification message. 208 The data format is shown in Figure 2. 210 0 1 2 3 211 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 212 +-----+-+-------+---------------+-------------------------------+ 213 | Ver |S| ET | Header Len | Message Length | 214 +-----+-+-------+---------------+-------------------------------+ 215 | Observation-Domain-ID | 216 +---------------------------------------------------------------+ 217 | Message-ID | 218 +---------------------------------------------------------------+ 219 ~ Options ~ 220 +---------------------------------------------------------------+ 222 Figure 2: UDP-Notif Message Header Format 224 The Message Header contains the following field: 226 * Ver represents the PDU (Protocol Data Unit) encoding version. The 227 initial version value is 0. 229 * S represents the space of encoding type specified in the ET field. 230 When S is unset, ET represents the standard encoding types as 231 defined in this document. When S is set, ET represents a private 232 space to be freely used for non standard encodings. 234 * ET is a 4 bit identifier to indicate the encoding type used for 235 the Notification Message. 16 types of encoding can be expressed. 236 When the S bit is unset, the following values apply: 238 - 0: CBOR; 240 - 1: JSON; 242 - 2: XML; 244 - others are reserved. 246 * Header Len is the length of the message header in octets, 247 including both the fixed header and the options. 249 * Message Length is the total length of the message within one UDP 250 datagram, measured in octets, including the message header. 252 * Observation-Domain-ID is a 32-bit identifier of the Observation 253 Domain that led to the production of the notification message, as 254 defined in [I-D.ietf-netconf-notification-messages]. This allows 255 disambiguation of an information source, such as the 256 identification of different line cards sending the notification 257 messages. The source IP address of the UDP datagrams SHOULD NOT 258 be interpreted as the identifier for the host that originated the 259 UDP-Notif message. Indeed, the streamer sending the UDP-Notif 260 message could be a relay for the actual source of data carried 261 within UDP-Notif messages. 263 * The Message ID is generated continuously by the sender of UDP- 264 Notif messages. Different subscribers share the same Message ID 265 sequence. 267 * Options is a variable-length field in the TLV format. When the 268 Header Length is larger than 12 octets, which is the length of the 269 fixed header, Options TLVs follow directly after the fixed message 270 header (i.e., Message ID). The details of the options are 271 described in Section 4. 273 3.3. Data Encoding 275 UDP-Notif message data can be encoded in CBOR, XML or JSON format. 276 It is conceivable that additional encodings may be supported in the 277 future. This can be accomplished by augmenting the subscription data 278 model with additional identity statements used to refer to requested 279 encodings. 281 Private encodings can be supported through the use of the S bit of 282 the header. When the S bit is set, the value of the ET field is left 283 to be defined and agreed upon by the users of the private encoding. 284 An option is defined in Section 4.2 for more verbose encoding 285 descriptions than what can be described with the ET field. 287 Implementation MAY support multiple encoding methods per 288 subscription. When bundled notifications are supported between the 289 publisher and the receiver, only subscribed notifications with the 290 same encoding can be bundled in a given message. 292 4. Options 294 All the options are defined with the following format, illustrated in 295 Figure 3. 297 0 1 2 3 298 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 299 +---------------+---------------+-------------------------------- 300 | Type | Length | Variable-length data 301 +---------------+---------------+-------------------------------- 303 Figure 3: Generic Option Format 305 * Type: 1 octet describing the option type; 307 * Length: 1 octet representing the total number of octets in the 308 TLV, including the Type and Length fields; 310 * Variable-length data: 0 or more octets of TLV Value. 312 4.1. Segmentation Option 314 The UDP payload length is limited to 65535. Application level 315 headers will make the actual payload shorter. Even though binary 316 encodings such as CBOR may not require more space than what is left, 317 more voluminous encodings such as JSON and XML may suffer from this 318 size limitation. Although IPv4 and IPv6 senders can fragment 319 outgoing packets exceeding their Maximum Transmission Unit(MTU), 320 fragmented IP packets may not be desired for operational and 321 performance reasons. 323 Consequently, implementations of the mechanism SHOULD provide a 324 configurable max-segment-size option to control the maximum size of a 325 payload. 327 0 1 2 3 328 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 329 +---------------+---------------+-----------------------------+-+ 330 | Type | Length | Segment Number |L| 331 +---------------+---------------+-----------------------------+-+ 333 Figure 4: Segmentation Option Format 335 The Segmentation Option is to be included when the message content is 336 segmented into multiple pieces. Different segments of one message 337 share the same Message ID. An illustration is provided in Figure 4. 338 The fields of this TLV are: 340 * Type: Generic option field which indicates a Segmentation Option. 341 The Type value is to be assigned. 343 * Length: Generic option field which indicates the length of this 344 option. It is a fixed value of 4 octets for the Segmentation 345 Option. 347 * Segment Number: 15-bit value indicating the sequence number of the 348 current segment. The first segment of a segmented message has a 349 Segment Number value of 0. 351 * L: is a flag to indicate whether the current segment is the last 352 one of the message. When 0 is set, the current segment is not the 353 last one. When 1 is set, the current segment is the last one, 354 meaning that the total number of segments used to transport this 355 message is the value of the current Segment Number + 1. 357 An implementation of this specification MUST NOT rely on IP 358 fragmentation by default to carry large messages. An implementation 359 of this specification MUST either restrict the size of individual 360 messages carried over this protocol, or support the segmentation 361 option. 363 4.2. Private Encoding Option 365 The space to describe private encodings in the ET field of the UDP- 366 Notif header being limited, an option is provided to describe custom 367 encodings. The fields of this option are as follows. 369 0 1 2 3 370 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 371 +---------------+---------------+-------------------------------- 372 | Type | Length | Variable length enc. descr. 373 +---------------+---------------+-------------------------------- 375 Figure 5: Private Encoding Option Format 377 * Type: Generic option field which indicates a Private Encoding 378 Option. The Type value is to be assigned. 380 * Length: Generic option field which indicates the length of this 381 option. It is a variable value. 383 * Enc. Descr: The description of the private encoding used for this 384 message. The values to be used for such private encodings is left 385 to be defined by the users of private encodings. 387 This option SHOULD only be used when the S bit of the header is set, 388 as providing a private encoding description for standard encodings is 389 meaningless. 391 5. Applicability 393 In this section, we provide an applicability statement for the 394 proposed mechanism, following the recommendations of [RFC8085]. 396 The proposed mechanism falls in the category of UDP applications 397 "designed for use within the network of a single network operator or 398 on networks of an adjacent set of cooperating network operators, to 399 be deployed in controlled environments". Implementations of the 400 proposed mechanism should thus follow the recommendations in place 401 for such specific applications. In the following, we discuss 402 recommendations on congestion control, message size guidelines, 403 reliability considerations. 405 5.1. Congestion Control 407 The proposed application falls into the category of applications 408 performing transfer of large amounts of data. It is expected that 409 the operator using the solution configures QoS on its related flows. 410 As per [RFC8085], such applications MAY choose not to implement any 411 form of congestion control, but follow the following principles. 413 It is NOT RECOMMENDED to use the proposed mechanism over congestion- 414 sensitive network paths. The only environments where UDP-Notif is 415 expected to be used are managed networks. The deployments require 416 that the network path has been explicitly provisioned to handle the 417 traffic through traffic engineering mechanisms, such as rate limiting 418 or capacity reservations. 420 Implementation of the proposal SHOULD NOT push unlimited amounts of 421 traffic by default, and SHOULD require the users to explicitly 422 configure such a mode of operation. 424 Burst mitigation through packet pacing is RECOMMENDED. Disabling 425 burst mitigation SHOULD require the users to explicitly configure 426 such a mode of operation. 428 Applications SHOULD monitor packet losses and provide means to the 429 user for retrieving information on such losses. The UDP-Notif 430 Message ID can be used to deduce congestion based on packet loss 431 detection. Hence the receiver can notify the device to use a lower 432 streaming rate. The interaction to control the streaming rate on the 433 device is out of the scope of this document. 435 5.2. Message Size 437 [RFC8085] recommends not to rely on IP fragmentation for messages 438 whose size result in IP packets exceeding the MTU along the path. 439 The segmentation option of the current specification permits 440 segmentation of the UDP Notif message content without relying on IP 441 fragmentation. Implementation of the current specification SHOULD 442 allow for the configuration of the MTU. 444 5.3. Reliability 446 The target application for UDP-Notif is the collection of data-plane 447 information. The lack of reliability of the data streaming mechanism 448 is thus considered acceptable as the mechanism is to be used in 449 controlled environments, mitigating the risk of information loss, 450 while allowing for publication of very large amounts of data. 451 Moreover, in this context, sporadic events when incomplete data 452 collection is provided is not critical for the proper management of 453 the network, as information collected for the devices through the 454 means of the proposed mechanism is to be often refreshed. 456 A receiver implementation for this protocol SHOULD deal with 457 potential loss of packets carrying a part of segmented payload, by 458 discarding packets that were received, but cannot be re-assembled as 459 a complete message within a given amount of time. This time SHOULD 460 be configurable. 462 6. A YANG Data Model for Management of UDP-Notif 464 The YANG model defined in Section 7 has two leaves augmented into one 465 place of Sub-Notif [RFC8639], plus one identity. 467 module: ietf-udp-subscribed-notifications 468 augment /sn:subscriptions/sn:subscription/sn:receivers/sn:receiver: 469 +--rw address inet:ip-address 470 +--rw port inet:port-number 471 +--rw enable-fragment? boolean 472 +--rw max-fragment-size? uint32 474 7. YANG Module 476 file "ietf-udp-notif@2020-04-27.yang" 477 module ietf-udp-notif { 478 yang-version 1.1; 479 namespace 480 "urn:ietf:params:xml:ns:yang:ietf-udp-notif"; 481 prefix un; 482 import ietf-subscribed-notifications { 483 prefix sn; 484 reference 485 "RFC 8639: Subscription to YANG Notifications"; 486 } 487 import ietf-inet-types { 488 prefix inet; 489 reference 490 "RFC 6991: Common YANG Data Types"; 491 } 493 organization "IETF NETCONF (Network Configuration) Working Group"; 494 contact 495 "WG Web: 496 WG List: 498 Authors: Guangying Zheng 499 500 Tianran Zhou 501 502 Thomas Graf 503 504 Pierre Francois 505 506 Paolo Lucente 507 "; 509 description 510 "Defines UDP-Notif as a supported transport for subscribed 511 event notifications. 513 Copyright (c) 2018 IETF Trust and the persons identified as authors 514 of the code. All rights reserved. 516 Redistribution and use in source and binary forms, with or without 517 modification, is permitted pursuant to, and subject to the license 518 terms contained in, the Simplified BSD License set forth in Section 519 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 520 (https://trustee.ietf.org/license-info). 522 This version of this YANG module is part of RFC XXXX; see the RFC 524 itself for full legal notices."; 526 revision 2020-04-27 { 527 description 528 "Initial version"; 529 reference 530 "RFC XXXX: UDP-based Notifications for Streaming Telemetry"; 531 } 533 identity udp-notif { 534 base sn:transport; 535 description 536 "UDP-Notif is used as transport for notification messages 537 and state change notifications."; 538 } 540 identity encode-cbor { 541 base sn:encoding; 542 description 543 "Encode data using CBOR as described in RFC 7049."; 544 reference 545 "RFC 7049: Concise Binary Object Representation"; 546 } 547 grouping target-receiver { 548 description 549 "Provides a reusable description of a UDP-Notif target receiver."; 550 leaf address { 551 type inet:ip-address; 552 mandatory true; 553 description 554 "IP address of target UDP-Notif receiver, which can be an 555 IPv4 address or an IPV6 address."; 556 } 557 leaf port { 558 type inet:port-number; 559 mandatory true; 560 description 561 "Port number of target UDP-Notif receiver, if not specified, 562 the system should use default port number."; 563 } 565 leaf enable-fragment { 566 type boolean; 567 default false; 568 description 569 "The switch for the fragment feature. When disabled, the 570 publisher will not allow fragment for a very large data"; 571 } 573 leaf max-fragment-size { 574 when "../enable-fragment = true"; 575 type uint32; 576 description "UDP-Notif provides a configurable max-fragment-size 577 to control the size of each message."; 578 } 579 } 581 augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" { 582 description 583 "This augmentation allows UDP-Notif specific parameters to be 584 exposed for a subscription."; 585 uses target-receiver; 586 } 587 } 588 590 8. IANA Considerations 592 IANA is requested to assign a new URI from the IETF XML Registry 593 [RFC3688]. The following URI is suggested: 595 URI: urn:ietf:params:xml:ns:yang:ietf-udp-notif 596 Registrant Contact: The IESG. 597 XML: N/A; the requested URI is an XML namespace. 599 This document also requests a new YANG module name in the YANG Module 600 Names registry [RFC7950] with the following suggestion: 602 name: ietf-udp-notif 603 namespace: urn:ietf:params:xml:ns:yang:ietf-udp-notif 604 prefix: un 605 reference: RFC XXXX 607 9. Security Considerations 609 As stated in the Applicability analysis in Section 5, this protocol 610 is to be used in controlled environments, so that network operators 611 might not require to secure the transport mechanism described in this 612 document. An approach to secure this protocol is out of the scope of 613 this document. 615 10. Acknowledgements 617 The authors of this documents would like to thank Alexander Clemm, 618 Eric Voit, Huiyang Yang, Kent Watsen, Mahesh Jethanandani, Stephane 619 Frenot, Timothy Carey, Tim Jenkins, and Yunan Gu for their 620 constructive suggestions for improving this document. 622 11. References 624 11.1. Normative References 626 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 627 Requirement Levels", BCP 14, RFC 2119, 628 DOI 10.17487/RFC2119, March 1997, 629 . 631 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 632 RFC 2914, DOI 10.17487/RFC2914, September 2000, 633 . 635 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 636 DOI 10.17487/RFC3688, January 2004, 637 . 639 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 640 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 641 October 2013, . 643 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 644 RFC 7950, DOI 10.17487/RFC7950, August 2016, 645 . 647 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 648 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 649 . 651 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 652 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 653 March 2017, . 655 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 656 E., and A. Tripathy, "Subscription to YANG Notifications", 657 RFC 8639, DOI 10.17487/RFC8639, September 2019, 658 . 660 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 661 E., and A. Tripathy, "Dynamic Subscription to YANG Events 662 and Datastores over NETCONF", RFC 8640, 663 DOI 10.17487/RFC8640, September 2019, 664 . 666 [RFC8650] Voit, E., Rahman, R., Nilsen-Nygaard, E., Clemm, A., and 667 A. Bierman, "Dynamic Subscription to YANG Events and 668 Datastores over RESTCONF", RFC 8650, DOI 10.17487/RFC8650, 669 November 2019, . 671 11.2. Informative References 673 [I-D.ietf-netconf-distributed-notif] 674 Zhou, T., Zheng, G., Voit, E., Graf, T., and P. Francois, 675 "Subscription to Distributed Notifications", Work in 676 Progress, Internet-Draft, draft-ietf-netconf-distributed- 677 notif-02, May 2021, . 680 [I-D.ietf-netconf-https-notif] 681 Jethanandani, M. and K. Watsen, "An HTTPS-based Transport 682 for YANG Notifications", Work in Progress, Internet-Draft, 683 draft-ietf-netconf-https-notif-08, 22 February 2021, 684 . 687 [I-D.ietf-netconf-notification-messages] 688 Voit, E., Jenkins, T., Birkholz, H., Bierman, A., and A. 689 Clemm, "Notification Message Headers and Bundles", Work in 690 Progress, Internet-Draft, draft-ietf-netconf-notification- 691 messages-08, 17 November 2019, 692 . 695 Authors' Addresses 697 Guangying Zheng 698 Huawei 699 101 Yu-Hua-Tai Software Road 700 Nanjing 701 Jiangsu, 702 China 704 Email: zhengguangying@huawei.com 706 Tianran Zhou 707 Huawei 708 156 Beiqing Rd., Haidian District 709 Beijing 710 China 712 Email: zhoutianran@huawei.com 714 Thomas Graf 715 Swisscom 716 Binzring 17 717 CH- Zuerich 8045 718 Switzerland 720 Email: thomas.graf@swisscom.com 722 Pierre Francois 723 INSA-Lyon 724 Lyon 725 France 727 Email: pierre.francois@insa-lyon.fr 729 Paolo Lucente 730 NTT 731 Siriusdreef 70-72 732 Hoofddorp, WT 2132 733 Netherlands 734 Email: paolo@ntt.net