idnits 2.17.1 draft-ietf-netconf-tcp-client-server-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 121 has weird spacing: '...address ine...' == Line 128 has weird spacing: '...nterval uin...' == Line 300 has weird spacing: '...address ine...' == Line 305 has weird spacing: '...nterval uin...' == Line 456 has weird spacing: '...nterval uin...' == (1 more instance...) -- The document date (May 17, 2019) is 1796 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: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group K. Watsen 3 Internet-Draft Watsen Networks 4 Intended status: Standards Track M. Scharf 5 Expires: November 18, 2019 Hochschule Esslingen 6 May 17, 2019 8 YANG Groupings for TCP Clients and TCP Servers 9 draft-ietf-netconf-tcp-client-server-00 11 Abstract 13 This document defines three YANG modules: the first defines a 14 grouping for configuring a generic TCP client, the second defines a 15 grouping for configuring a generic TCP server, and the third defines 16 a grouping common to the TCP clients and TCP servers. 18 Editorial Note (To be removed by RFC Editor) 20 This draft contains many placeholder values that need to be replaced 21 with finalized values at the time of publication. This note 22 summarizes all of the substitutions that are needed. No other RFC 23 Editor instructions are specified elsewhere in this document. 25 Artwork in this document contains placeholder values for the date of 26 publication of this draft. Please apply the following replacement: 28 o "2019-05-17" --> the publication date of this draft 30 The following Appendix section is to be removed prior to publication: 32 o Appendix A. Change Log 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on November 18, 2019. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. The TCP Client Model . . . . . . . . . . . . . . . . . . . . 3 70 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 3 71 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 3 72 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 4 73 4. The TCP Server Model . . . . . . . . . . . . . . . . . . . . 7 74 4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 7 75 4.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 7 76 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 7 77 5. The TCP Common Model . . . . . . . . . . . . . . . . . . . . 10 78 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 10 79 5.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 10 80 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 11 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 83 7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 14 84 7.2. The YANG Module Names Registry . . . . . . . . . . . . . 15 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 87 8.2. Informative References . . . . . . . . . . . . . . . . . 16 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 90 1. Introduction 92 This document defines three YANG 1.1 [RFC7950] modules: the first 93 defines a grouping for configuring a generic TCP client, the second 94 defines a grouping for configuring a generic TCP server, and the 95 third defines a grouping common to the TCP clients and TCP servers. 97 It is intended that these groupings will be used either standalone, 98 for TCP-based protocols, as part of a stack of protocol-specific 99 configuration models. For instance, these groupings could help 100 define the configuration module for SSH, TLS, or HTTP based 101 applications. 103 2. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described in BCP 108 14 [RFC2119] [RFC8174] when, and only when, they appear in all 109 capitals, as shown here. 111 3. The TCP Client Model 113 3.1. Tree Diagram 115 This section provides a tree diagram [RFC8340] for the "ietf-tcp- 116 client" module. 118 module: ietf-tcp-client 120 grouping tcp-client-grouping 121 +-- remote-address inet:host 122 +-- remote-port? inet:port-number 123 +-- local-address? inet:ip-address 124 +-- local-port? inet:port-number 125 +-- keepalives! 126 +-- idle-time uint16 127 +-- max-probes uint16 128 +-- probe-interval uint16 130 3.2. Example Usage 132 This section presents an example showing the tcp-client-grouping 133 populated with some data. 135 136 www.example.com 137 443 138 0.0.0.0 139 0 140 141 15 142 3 143 30 144 145 147 3.3. YANG Module 149 The ietf-tcp-client YANG module references [RFC6991]. 151 file "ietf-tcp-client@2019-05-17.yang" 152 module ietf-tcp-client { 153 yang-version 1.1; 154 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-client"; 155 prefix tcpc; 157 import ietf-inet-types { 158 prefix inet; 159 reference 160 "RFC 6991: Common YANG Data Types"; 161 } 163 import ietf-tcp-common { 164 prefix tcpcmn; 165 reference 166 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers"; 167 } 169 organization 170 "IETF NETCONF (Network Configuration) Working Group and the 171 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group"; 173 contact 174 "WG Web: 175 176 WG List: 177 178 Authors: Kent Watsen 179 Michael Scharf 180 "; 182 description 183 "This module defines reusable groupings for TCP clients that 184 can be used as a basis for specific TCP client instances. 186 Copyright (c) 2019 IETF Trust and the persons identified 187 as authors of the code. All rights reserved. 189 Redistribution and use in source and binary forms, with 190 or without modification, is permitted pursuant to, and 191 subject to the license terms contained in, the Simplified 192 BSD License set forth in Section 4.c of the IETF Trust's 193 Legal Provisions Relating to IETF Documents 194 (https://trustee.ietf.org/license-info). 196 This version of this YANG module is part of RFC XXXX 197 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 198 itself for full legal notices.; 200 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 201 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 202 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 203 are to be interpreted as described in BCP 14 (RFC 2119) 204 (RFC 8174) when, and only when, they appear in all 205 capitals, as shown here."; 207 revision 2019-05-17 { 208 description 209 "Initial version"; 210 reference 211 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers"; 212 } 214 // Features 216 feature tcp-client-keepalives { 217 description 218 "Per socket TCP keepalive parameters are configurable for 219 TCP clients on the server implementing this feature."; 220 } 222 // Groupings 224 grouping tcp-client-grouping { 225 description 226 "A reusable grouping for configuring a TCP client. 228 Note that this grouping uses fairly typical descendent 229 node names such that a stack of 'uses' statements will 230 have name conflicts. It is intended that the consuming 231 data model will resolve the issue (e.g., by wrapping 232 the 'uses' statement in a container called 233 'tcp-client-parameters'). This model purposely does 234 not do this itself so as to provide maximum flexibility 235 to consuming models."; 237 leaf remote-address { 238 type inet:host; 239 mandatory true; 240 description 241 "The IP address or hostname of the remote peer to 242 establish a connection with. If a domain name is 243 configured, then the DNS resolution should happen on 244 each connection attempt. If the the DNS resolution 245 results in multiple IP addresses, the IP addresses 246 are tried according to local preference order until 247 a connection has been established or until all IP 248 addresses have failed."; 249 } 250 leaf remote-port { 251 type inet:port-number; 252 default "0"; 253 description 254 "The IP port number for the remote peer to establish a 255 connection with. An invalid default value (0) is used 256 (instead of 'mandatory true') so that as application 257 level data model may 'refine' it with an application 258 specific default port number value."; 259 } 260 leaf local-address { 261 type inet:ip-address; 262 description 263 "The local IP address/interface (VRF?) to bind to for when 264 connecting to the remote peer. INADDR_ANY ('0.0.0.0') or 265 INADDR6_ANY ('0:0:0:0:0:0:0:0' a.k.a. '::') MAY be used to 266 explicitly indicate the implicit default, that the server 267 can bind to any IPv4 or IPv6 addresses, respectively."; 268 } 269 leaf local-port { 270 type inet:port-number; 271 default "0"; 272 description 273 "The local IP port number to bind to for when connecting 274 to the remote peer. The port number '0', which is the 275 default value, indicates that any available local port 276 number may be used."; 277 } 278 uses tcpcmn:tcp-connection-grouping { 279 augment "keepalives" { 280 if-feature "tcp-client-keepalives"; 281 description 282 "Add an if-feature statement so that implementations 283 can choose to support TCP client keepalives."; 284 } 285 } 286 } 287 } 288 290 4. The TCP Server Model 292 4.1. Tree Diagram 294 This section provides a tree diagram [RFC8340] for the "ietf-tcp- 295 server" module. 297 module: ietf-tcp-server 299 grouping tcp-server-grouping 300 +-- local-address inet:ip-address 301 +-- local-port? inet:port-number 302 +-- keepalives! 303 +-- idle-time uint16 304 +-- max-probes uint16 305 +-- probe-interval uint16 307 4.2. Example Usage 309 This section presents an example showing the tcp-server-grouping 310 populated with some data. 312 313 10.20.30.40 314 7777 315 316 15 317 3 318 30 319 320 322 4.3. YANG Module 324 The ietf-tcp-server YANG module references [RFC6991]. 326 file "ietf-tcp-server@2019-05-17.yang" 327 module ietf-tcp-server { 328 yang-version 1.1; 329 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-server"; 330 prefix tcps; 332 import ietf-inet-types { 333 prefix inet; 334 reference 335 "RFC 6991: Common YANG Data Types"; 336 } 338 import ietf-tcp-common { 339 prefix tcpcmn; 340 reference 341 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers"; 342 } 344 organization 345 "IETF NETCONF (Network Configuration) Working Group and the 346 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group"; 348 contact 349 "WG Web: 350 351 WG List: 352 353 Authors: Kent Watsen 354 Michael Scharf 355 "; 357 description 358 "This module defines reusable groupings for TCP servers that 359 can be used as a basis for specific TCP server instances. 361 Copyright (c) 2019 IETF Trust and the persons identified 362 as authors of the code. All rights reserved. 364 Redistribution and use in source and binary forms, with 365 or without modification, is permitted pursuant to, and 366 subject to the license terms contained in, the Simplified 367 BSD License set forth in Section 4.c of the IETF Trust's 368 Legal Provisions Relating to IETF Documents 369 (https://trustee.ietf.org/license-info). 371 This version of this YANG module is part of RFC XXXX 372 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 373 itself for full legal notices.; 374 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 375 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 376 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 377 are to be interpreted as described in BCP 14 (RFC 2119) 378 (RFC 8174) when, and only when, they appear in all 379 capitals, as shown here."; 381 revision 2019-05-17 { 382 description 383 "Initial version"; 384 reference 385 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers"; 386 } 388 // Features 390 feature tcp-server-keepalives { 391 description 392 "Per socket TCP keepalive parameters are configurable for 393 TCP servers on the server implementing this feature."; 394 } 396 // Groupings 398 grouping tcp-server-grouping { 399 description 400 "A reusable grouping for configuring a TCP server. 402 Note that this grouping uses fairly typical descendent 403 node names such that a stack of 'uses' statements will 404 have name conflicts. It is intended that the consuming 405 data model will resolve the issue (e.g., by wrapping 406 the 'uses' statement in a container called 407 'tcp-server-parameters'). This model purposely does 408 not do this itself so as to provide maximum flexibility 409 to consuming models."; 411 leaf local-address { 412 type inet:ip-address; 413 mandatory true; 414 description 415 "The local IP address to listen on for incoming 416 TCL client connections. INADDR_ANY (0.0.0.0) or 417 INADDR6_ANY (0:0:0:0:0:0:0:0 a.k.a. ::) MUST be 418 used when the server is to listen on all IPv4 or 419 IPv6 addresses, respectively."; 420 } 421 leaf local-port { 422 type inet:port-number; 423 default "0"; 424 description 425 "The local port number to listen on for incoming TCP 426 client connections. An invalid default value (0) 427 is used (instead of 'mandatory true') so that an 428 application level data model may 'refine' it with 429 an application specific default port number value."; 430 } 431 uses tcpcmn:tcp-connection-grouping { 432 augment "keepalives" { 433 if-feature "tcp-server-keepalives"; 434 description 435 "Add an if-feature statement so that implementations 436 can choose to support TCP server keepalives."; 437 } 438 } 439 } 440 } 441 443 5. The TCP Common Model 445 5.1. Tree Diagram 447 This section provides a tree diagram [RFC8340] for the "ietf-tcp- 448 common" module. 450 module: ietf-tcp-common 452 grouping tcp-common-grouping 453 +-- keepalives! 454 +-- idle-time uint16 455 +-- max-probes uint16 456 +-- probe-interval uint16 457 grouping tcp-connection-grouping 458 +-- keepalives! 459 +-- idle-time uint16 460 +-- max-probes uint16 461 +-- probe-interval uint16 463 5.2. Example Usage 465 This section presents an example showing the tcp-common-grouping 466 populated with some data. 468 469 470 15 471 3 472 30 473 474 476 5.3. YANG Module 478 The ietf-tcp-common YANG module references [RFC6991]. 480 file "ietf-tcp-common@2019-05-17.yang" 481 module ietf-tcp-common { 482 yang-version 1.1; 483 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-common"; 484 prefix tcpcmn; 486 organization 487 "IETF NETCONF (Network Configuration) Working Group and the 488 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group"; 490 contact 491 "WG Web: 492 493 WG List: 494 495 Authors: Kent Watsen 496 Michael Scharf 497 "; 499 description 500 "This module defines reusable groupings for TCP commons that 501 can be used as a basis for specific TCP common instances. 503 Copyright (c) 2019 IETF Trust and the persons identified 504 as authors of the code. All rights reserved. 506 Redistribution and use in source and binary forms, with 507 or without modification, is permitted pursuant to, and 508 subject to the license terms contained in, the Simplified 509 BSD License set forth in Section 4.c of the IETF Trust's 510 Legal Provisions Relating to IETF Documents 511 (https://trustee.ietf.org/license-info). 513 This version of this YANG module is part of RFC XXXX 514 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 515 itself for full legal notices.; 516 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 517 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 518 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 519 are to be interpreted as described in BCP 14 (RFC 2119) 520 (RFC 8174) when, and only when, they appear in all 521 capitals, as shown here."; 523 revision 2019-05-17 { 524 description 525 "Initial version"; 526 reference 527 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers"; 528 } 530 // Groupings 532 grouping tcp-common-grouping { 533 description 534 "A reusable grouping for configuring TCP parameters common 535 to TCP connections as well as the operating system as a 536 whole."; 537 container keepalives { 538 presence "Indicates that keepalives are enabled."; 539 description 540 "Configures the keep-alive policy, to proactively test the 541 aliveness of the TCP peer. An unresponsive TCP peer is 542 dropped after approximately (idle-time * 60) + (max-probes 543 * probe-interval) seconds."; 544 leaf idle-time { 545 type uint16 { 546 range "1..max"; 547 } 548 units "seconds"; 549 mandatory true; 550 description 551 "Sets the amount of time after which if no data has been 552 received from the TCP peer, a TCP-level probe message 553 will be sent to test the aliveness of the TCP peer."; 554 } 555 leaf max-probes { 556 type uint16 { 557 range "1..max"; 558 } 559 mandatory true; 560 description 561 "Sets the maximum number of sequential keep-alive probes 562 that can fail to obtain a response from the TCP peer 563 before assuming the TCP peer is no longer alive."; 565 } 566 leaf probe-interval { 567 type uint16 { 568 range "1..max"; 569 } 570 units "seconds"; 571 mandatory true; 572 description 573 "Sets the time interval between failed probes."; 574 } 575 } // container keepalives 576 } // grouping tcp-common-grouping 578 grouping tcp-connection-grouping { 579 description 580 "A reusable grouping for configuring TCP parameters common 581 to TCP connections."; 582 uses tcp-common-grouping; 583 } 585 /* 586 The following is for a future bis... 587 This comment is here now so as support discussion with TCPM. 588 This comment will be removed before publication. 590 Should future system-level parameters be defined as a 591 grouping or a container? 593 grouping tcp-system-grouping { 594 description 595 "A reusable grouping for configuring TCP parameters common 596 to the operating system as a whole."; 598 // currently just a placeholder 599 } 600 */ 602 } 603 605 6. Security Considerations 607 The YANG modules defined in this document are designed to be accessed 608 via YANG based management protocols, such as NETCONF [RFC6241] and 609 RESTCONF [RFC8040]. Both of these protocols have mandatory-to- 610 implement secure transport layers (e.g., SSH, TCP) with mutual 611 authentication. 613 The NETCONF access control model (NACM) [RFC8341] provides the means 614 to restrict access for particular users to a pre-configured subset of 615 all available protocol operations and content. 617 Since the modules defined in this document only define groupings, 618 these considerations are primarily for the designers of other modules 619 that use these groupings. 621 There are a number of data nodes defined in the YANG modules that are 622 writable/creatable/deletable (i.e., config true, which is the 623 default). These data nodes may be considered sensitive or vulnerable 624 in some network environments. Write operations (e.g., edit-config) 625 to these data nodes without proper protection can have a negative 626 effect on network operations. These are the subtrees and data nodes 627 and their sensitivity/vulnerability: 629 None of the writable/creatable/deletable data nodes in 630 the YANG modules defined in this document are considered more 631 sensitive or vulnerable then standard configuration. 633 Some of the readable data nodes in the YANG modules may be considered 634 sensitive or vulnerable in some network environments. It is thus 635 important to control read access (e.g., via get, get-config, or 636 notification) to these data nodes. These are the subtrees and data 637 nodes and their sensitivity/vulnerability: 639 None of the readable data nodes in the YANG modules 640 defined in this document are considered more sensitive or vulnerable 641 then standard configuration. 643 This document does not define any RPC actions and hence this section 644 does not consider the security of RPCs. 646 7. IANA Considerations 648 7.1. The IETF XML Registry 650 This document registers two URIs in the "ns" subregistry of the IETF 651 XML Registry [RFC3688]. Following the format in [RFC3688], the 652 following registrations are requested: 654 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-client 655 Registrant Contact: The NETCONF WG of the IETF. 656 XML: N/A, the requested URI is an XML namespace. 658 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-server 659 Registrant Contact: The NETCONF WG of the IETF. 660 XML: N/A, the requested URI is an XML namespace. 662 7.2. The YANG Module Names Registry 664 This document registers two YANG modules in the YANG Module Names 665 registry [RFC6020]. Following the format in [RFC6020], the following 666 registrations are requested: 668 name: ietf-tcp-common 669 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-common 670 prefix: tcpcmn 671 reference: RFC XXXX 673 name: ietf-tcp-client 674 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-client 675 prefix: tcpc 676 reference: RFC XXXX 678 name: ietf-tcp-server 679 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-server 680 prefix: tcps 681 reference: RFC XXXX 683 8. References 685 8.1. Normative References 687 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 688 Requirement Levels", BCP 14, RFC 2119, 689 DOI 10.17487/RFC2119, March 1997, 690 . 692 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 693 the Network Configuration Protocol (NETCONF)", RFC 6020, 694 DOI 10.17487/RFC6020, October 2010, 695 . 697 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 698 RFC 6991, DOI 10.17487/RFC6991, July 2013, 699 . 701 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 702 RFC 7950, DOI 10.17487/RFC7950, August 2016, 703 . 705 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 706 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 707 May 2017, . 709 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 710 Access Control Model", STD 91, RFC 8341, 711 DOI 10.17487/RFC8341, March 2018, 712 . 714 8.2. Informative References 716 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 717 DOI 10.17487/RFC3688, January 2004, 718 . 720 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 721 and A. Bierman, Ed., "Network Configuration Protocol 722 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 723 . 725 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 726 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 727 . 729 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 730 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 731 . 733 Authors' Addresses 735 Kent Watsen 736 Watsen Networks 738 EMail: kent+ietf@watsen.net 740 Michael Scharf 741 Hochschule Esslingen - University of Applied Sciences 743 EMail: michael.scharf@hs-esslingen.de