idnits 2.17.1 draft-ietf-netconf-tcp-client-server-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 124 has weird spacing: '...address ine...' == Line 131 has weird spacing: '...nterval uin...' == Line 311 has weird spacing: '...address ine...' == Line 316 has weird spacing: '...nterval uin...' == Line 467 has weird spacing: '...nterval uin...' == (1 more instance...) -- The document date (July 2, 2019) is 1758 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: January 3, 2020 Hochschule Esslingen 6 July 2, 2019 8 YANG Groupings for TCP Clients and TCP Servers 9 draft-ietf-netconf-tcp-client-server-02 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-07-02" --> 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 January 3, 2020. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . . . 8 77 5. The TCP Common Model . . . . . . . . . . . . . . . . . . . . 10 78 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 10 79 5.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 11 80 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 11 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 83 7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 15 84 7.2. The YANG Module Names Registry . . . . . . . . . . . . . 15 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 87 8.2. Informative References . . . . . . . . . . . . . . . . . 16 88 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 18 89 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 18 90 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 18 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 93 1. Introduction 95 This document defines three YANG 1.1 [RFC7950] modules: the first 96 defines a grouping for configuring a generic TCP client, the second 97 defines a grouping for configuring a generic TCP server, and the 98 third defines a grouping common to the TCP clients and TCP servers. 100 It is intended that these groupings will be used either standalone, 101 for TCP-based protocols, as part of a stack of protocol-specific 102 configuration models. For instance, these groupings could help 103 define the configuration module for SSH, TLS, or HTTP based 104 applications. 106 2. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in BCP 111 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 3. The TCP Client Model 116 3.1. Tree Diagram 118 This section provides a tree diagram [RFC8340] for the "ietf-tcp- 119 client" module. 121 module: ietf-tcp-client 123 grouping tcp-client-grouping 124 +-- remote-address inet:host 125 +-- remote-port? inet:port-number 126 +-- local-address? inet:ip-address {local-binding-supported}? 127 +-- local-port? inet:port-number {local-binding-supported}? 128 +-- keepalives! {keepalives-supported}? 129 +-- idle-time uint16 130 +-- max-probes uint16 131 +-- probe-interval uint16 133 3.2. Example Usage 135 This section presents an example showing the tcp-client-grouping 136 populated with some data. 138 139 www.example.com 140 443 141 0.0.0.0 142 0 143 144 15 145 3 146 30 147 148 150 3.3. YANG Module 152 The ietf-tcp-client YANG module references [RFC6991]. 154 file "ietf-tcp-client@2019-07-02.yang" 155 module ietf-tcp-client { 156 yang-version 1.1; 157 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-client"; 158 prefix tcpc; 160 import ietf-inet-types { 161 prefix inet; 162 reference 163 "RFC 6991: Common YANG Data Types"; 164 } 166 import ietf-tcp-common { 167 prefix tcpcmn; 168 reference 169 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers"; 170 } 172 organization 173 "IETF NETCONF (Network Configuration) Working Group and the 174 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group"; 176 contact 177 "WG Web: 178 179 WG List: 180 181 Authors: Kent Watsen 182 Michael Scharf 183 "; 185 description 186 "This module defines reusable groupings for TCP clients that 187 can be used as a basis for specific TCP client instances. 189 Copyright (c) 2019 IETF Trust and the persons identified 190 as authors of the code. All rights reserved. 192 Redistribution and use in source and binary forms, with 193 or without modification, is permitted pursuant to, and 194 subject to the license terms contained in, the Simplified 195 BSD License set forth in Section 4.c of the IETF Trust's 196 Legal Provisions Relating to IETF Documents 197 (https://trustee.ietf.org/license-info). 199 This version of this YANG module is part of RFC XXXX 200 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 201 itself for full legal notices.; 203 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 204 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 205 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 206 are to be interpreted as described in BCP 14 (RFC 2119) 207 (RFC 8174) when, and only when, they appear in all 208 capitals, as shown here."; 210 revision 2019-07-02 { 211 description 212 "Initial version"; 213 reference 214 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers"; 215 } 217 // Features 219 feature local-binding-supported { 220 description 221 "Indicates that the server supports configuring local 222 bindings (i.e., the local address and local port) for 223 TCP clients."; 224 } 226 feature tcp-client-keepalives { 227 description 228 "Per socket TCP keepalive parameters are configurable for 229 TCP clients on the server implementing this feature."; 230 } 232 // Groupings 233 grouping tcp-client-grouping { 234 description 235 "A reusable grouping for configuring a TCP client. 237 Note that this grouping uses fairly typical descendent 238 node names such that a stack of 'uses' statements will 239 have name conflicts. It is intended that the consuming 240 data model will resolve the issue (e.g., by wrapping 241 the 'uses' statement in a container called 242 'tcp-client-parameters'). This model purposely does 243 not do this itself so as to provide maximum flexibility 244 to consuming models."; 246 leaf remote-address { 247 type inet:host; 248 mandatory true; 249 description 250 "The IP address or hostname of the remote peer to 251 establish a connection with. If a domain name is 252 configured, then the DNS resolution should happen on 253 each connection attempt. If the the DNS resolution 254 results in multiple IP addresses, the IP addresses 255 are tried according to local preference order until 256 a connection has been established or until all IP 257 addresses have failed."; 258 } 259 leaf remote-port { 260 type inet:port-number; 261 default "0"; 262 description 263 "The IP port number for the remote peer to establish a 264 connection with. An invalid default value (0) is used 265 (instead of 'mandatory true') so that as application 266 level data model may 'refine' it with an application 267 specific default port number value."; 268 } 269 leaf local-address { 270 if-feature "local-binding-supported"; 271 type inet:ip-address; 272 description 273 "The local IP address/interface (VRF?) to bind to for when 274 connecting to the remote peer. INADDR_ANY ('0.0.0.0') or 275 INADDR6_ANY ('0:0:0:0:0:0:0:0' a.k.a. '::') MAY be used to 276 explicitly indicate the implicit default, that the server 277 can bind to any IPv4 or IPv6 addresses, respectively."; 278 } 279 leaf local-port { 280 if-feature "local-binding-supported"; 281 type inet:port-number; 282 default "0"; 283 description 284 "The local IP port number to bind to for when connecting 285 to the remote peer. The port number '0', which is the 286 default value, indicates that any available local port 287 number may be used."; 288 } 289 uses tcpcmn:tcp-connection-grouping { 290 augment "keepalives" { 291 if-feature "tcp-client-keepalives"; 292 description 293 "Add an if-feature statement so that implementations 294 can choose to support TCP client keepalives."; 295 } 296 } 297 } 298 } 299 301 4. The TCP Server Model 303 4.1. Tree Diagram 305 This section provides a tree diagram [RFC8340] for the "ietf-tcp- 306 server" module. 308 module: ietf-tcp-server 310 grouping tcp-server-grouping 311 +-- local-address inet:ip-address 312 +-- local-port? inet:port-number 313 +-- keepalives! {keepalives-supported}? 314 +-- idle-time uint16 315 +-- max-probes uint16 316 +-- probe-interval uint16 318 4.2. Example Usage 320 This section presents an example showing the tcp-server-grouping 321 populated with some data. 323 324 10.20.30.40 325 7777 326 327 15 328 3 329 30 330 331 333 4.3. YANG Module 335 The ietf-tcp-server YANG module references [RFC6991]. 337 file "ietf-tcp-server@2019-07-02.yang" 338 module ietf-tcp-server { 339 yang-version 1.1; 340 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-server"; 341 prefix tcps; 343 import ietf-inet-types { 344 prefix inet; 345 reference 346 "RFC 6991: Common YANG Data Types"; 347 } 349 import ietf-tcp-common { 350 prefix tcpcmn; 351 reference 352 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers"; 353 } 355 organization 356 "IETF NETCONF (Network Configuration) Working Group and the 357 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group"; 359 contact 360 "WG Web: 361 362 WG List: 363 364 Authors: Kent Watsen 365 Michael Scharf 366 "; 368 description 369 "This module defines reusable groupings for TCP servers that 370 can be used as a basis for specific TCP server instances. 372 Copyright (c) 2019 IETF Trust and the persons identified 373 as authors of the code. All rights reserved. 375 Redistribution and use in source and binary forms, with 376 or without modification, is permitted pursuant to, and 377 subject to the license terms contained in, the Simplified 378 BSD License set forth in Section 4.c of the IETF Trust's 379 Legal Provisions Relating to IETF Documents 380 (https://trustee.ietf.org/license-info). 382 This version of this YANG module is part of RFC XXXX 383 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 384 itself for full legal notices.; 386 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 387 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 388 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 389 are to be interpreted as described in BCP 14 (RFC 2119) 390 (RFC 8174) when, and only when, they appear in all 391 capitals, as shown here."; 393 revision 2019-07-02 { 394 description 395 "Initial version"; 396 reference 397 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers"; 398 } 400 // Features 402 feature tcp-server-keepalives { 403 description 404 "Per socket TCP keepalive parameters are configurable for 405 TCP servers on the server implementing this feature."; 406 } 408 // Groupings 410 grouping tcp-server-grouping { 411 description 412 "A reusable grouping for configuring a TCP server. 414 Note that this grouping uses fairly typical descendent 415 node names such that a stack of 'uses' statements will 416 have name conflicts. It is intended that the consuming 417 data model will resolve the issue (e.g., by wrapping 418 the 'uses' statement in a container called 419 'tcp-server-parameters'). This model purposely does 420 not do this itself so as to provide maximum flexibility 421 to consuming models."; 422 leaf local-address { 423 type inet:ip-address; 424 mandatory true; 425 description 426 "The local IP address to listen on for incoming 427 TCP client connections. INADDR_ANY (0.0.0.0) or 428 INADDR6_ANY (0:0:0:0:0:0:0:0 a.k.a. ::) MUST be 429 used when the server is to listen on all IPv4 or 430 IPv6 addresses, respectively."; 431 } 432 leaf local-port { 433 type inet:port-number; 434 default "0"; 435 description 436 "The local port number to listen on for incoming TCP 437 client connections. An invalid default value (0) 438 is used (instead of 'mandatory true') so that an 439 application level data model may 'refine' it with 440 an application specific default port number value."; 441 } 442 uses tcpcmn:tcp-connection-grouping { 443 augment "keepalives" { 444 if-feature "tcp-server-keepalives"; 445 description 446 "Add an if-feature statement so that implementations 447 can choose to support TCP server keepalives."; 448 } 449 } 450 } 451 } 452 454 5. The TCP Common Model 456 5.1. Tree Diagram 458 This section provides a tree diagram [RFC8340] for the "ietf-tcp- 459 common" module. 461 module: ietf-tcp-common 463 grouping tcp-common-grouping 464 +-- keepalives! {keepalives-supported}? 465 +-- idle-time uint16 466 +-- max-probes uint16 467 +-- probe-interval uint16 468 grouping tcp-connection-grouping 469 +-- keepalives! {keepalives-supported}? 470 +-- idle-time uint16 471 +-- max-probes uint16 472 +-- probe-interval uint16 474 5.2. Example Usage 476 This section presents an example showing the tcp-common-grouping 477 populated with some data. 479 480 481 15 482 3 483 30 484 485 487 5.3. YANG Module 489 The ietf-tcp-common YANG module references [RFC6991]. 491 file "ietf-tcp-common@2019-07-02.yang" 492 module ietf-tcp-common { 493 yang-version 1.1; 494 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-common"; 495 prefix tcpcmn; 497 organization 498 "IETF NETCONF (Network Configuration) Working Group and the 499 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group"; 501 contact 502 "WG Web: 503 504 WG List: 505 506 Authors: Kent Watsen 507 Michael Scharf 508 "; 510 description 511 "This module defines reusable groupings for TCP commons that 512 can be used as a basis for specific TCP common instances. 514 Copyright (c) 2019 IETF Trust and the persons identified 515 as authors of the code. All rights reserved. 517 Redistribution and use in source and binary forms, with 518 or without modification, is permitted pursuant to, and 519 subject to the license terms contained in, the Simplified 520 BSD License set forth in Section 4.c of the IETF Trust's 521 Legal Provisions Relating to IETF Documents 522 (https://trustee.ietf.org/license-info). 524 This version of this YANG module is part of RFC XXXX 525 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 526 itself for full legal notices.; 528 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 529 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 530 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 531 are to be interpreted as described in BCP 14 (RFC 2119) 532 (RFC 8174) when, and only when, they appear in all 533 capitals, as shown here."; 535 revision 2019-07-02 { 536 description 537 "Initial version"; 538 reference 539 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers"; 540 } 542 // Features 543 feature keepalives-supported { 544 description 545 "Indicates that keepalives are supported."; 546 } 548 // Groupings 550 grouping tcp-common-grouping { 551 description 552 "A reusable grouping for configuring TCP parameters common 553 to TCP connections as well as the operating system as a 554 whole."; 555 container keepalives { 556 if-feature "keepalives-supported"; 557 presence "Indicates that keepalives are enabled."; 558 description 559 "Configures the keep-alive policy, to proactively test the 560 aliveness of the TCP peer. An unresponsive TCP peer is 561 dropped after approximately (idle-time * 60) + (max-probes 562 * probe-interval) seconds."; 563 leaf idle-time { 564 type uint16 { 565 range "1..max"; 566 } 567 units "seconds"; 568 mandatory true; 569 description 570 "Sets the amount of time after which if no data has been 571 received from the TCP peer, a TCP-level probe message 572 will be sent to test the aliveness of the TCP peer."; 573 } 574 leaf max-probes { 575 type uint16 { 576 range "1..max"; 577 } 578 mandatory true; 579 description 580 "Sets the maximum number of sequential keep-alive probes 581 that can fail to obtain a response from the TCP peer 582 before assuming the TCP peer is no longer alive."; 583 } 584 leaf probe-interval { 585 type uint16 { 586 range "1..max"; 587 } 588 units "seconds"; 589 mandatory true; 590 description 591 "Sets the time interval between failed probes."; 592 } 593 } // container keepalives 594 } // grouping tcp-common-grouping 596 grouping tcp-connection-grouping { 597 description 598 "A reusable grouping for configuring TCP parameters common 599 to TCP connections."; 600 uses tcp-common-grouping; 601 } 603 /* 604 The following is for a future bis... 606 This comment is here now so as support discussion with TCPM. 607 This comment will be removed before publication. 609 Should future system-level parameters be defined as a 610 grouping or a container? 612 grouping tcp-system-grouping { 613 description 614 "A reusable grouping for configuring TCP parameters common 615 to the operating system as a whole."; 617 // currently just a placeholder 618 } 619 */ 621 } 622 624 6. Security Considerations 626 The YANG modules defined in this document are designed to be accessed 627 via YANG based management protocols, such as NETCONF [RFC6241] and 628 RESTCONF [RFC8040]. Both of these protocols have mandatory-to- 629 implement secure transport layers (e.g., SSH, TCP) with mutual 630 authentication. 632 The NETCONF access control model (NACM) [RFC8341] provides the means 633 to restrict access for particular users to a pre-configured subset of 634 all available protocol operations and content. 636 Since the modules defined in this document only define groupings, 637 these considerations are primarily for the designers of other modules 638 that use these groupings. 640 There are a number of data nodes defined in the YANG modules that are 641 writable/creatable/deletable (i.e., config true, which is the 642 default). These data nodes may be considered sensitive or vulnerable 643 in some network environments. Write operations (e.g., edit-config) 644 to these data nodes without proper protection can have a negative 645 effect on network operations. These are the subtrees and data nodes 646 and their sensitivity/vulnerability: 648 None of the writable/creatable/deletable data nodes in 649 the YANG modules defined in this document are considered more 650 sensitive or vulnerable then standard configuration. 652 Some of the readable data nodes in the YANG modules may be considered 653 sensitive or vulnerable in some network environments. It is thus 654 important to control read access (e.g., via get, get-config, or 655 notification) to these data nodes. These are the subtrees and data 656 nodes and their sensitivity/vulnerability: 658 None of the readable data nodes in the YANG modules 659 defined in this document are considered more sensitive or vulnerable 660 then standard configuration. 662 This document does not define any RPC actions and hence this section 663 does not consider the security of RPCs. 665 7. IANA Considerations 667 7.1. The IETF XML Registry 669 This document registers two URIs in the "ns" subregistry of the IETF 670 XML Registry [RFC3688]. Following the format in [RFC3688], the 671 following registrations are requested: 673 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-client 674 Registrant Contact: The NETCONF WG of the IETF. 675 XML: N/A, the requested URI is an XML namespace. 677 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-server 678 Registrant Contact: The NETCONF WG of the IETF. 679 XML: N/A, the requested URI is an XML namespace. 681 7.2. The YANG Module Names Registry 683 This document registers two YANG modules in the YANG Module Names 684 registry [RFC6020]. Following the format in [RFC6020], the following 685 registrations are requested: 687 name: ietf-tcp-common 688 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-common 689 prefix: tcpcmn 690 reference: RFC XXXX 692 name: ietf-tcp-client 693 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-client 694 prefix: tcpc 695 reference: RFC XXXX 697 name: ietf-tcp-server 698 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-server 699 prefix: tcps 700 reference: RFC XXXX 702 8. References 704 8.1. Normative References 706 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 707 Requirement Levels", BCP 14, RFC 2119, 708 DOI 10.17487/RFC2119, March 1997, 709 . 711 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 712 the Network Configuration Protocol (NETCONF)", RFC 6020, 713 DOI 10.17487/RFC6020, October 2010, 714 . 716 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 717 RFC 6991, DOI 10.17487/RFC6991, July 2013, 718 . 720 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 721 RFC 7950, DOI 10.17487/RFC7950, August 2016, 722 . 724 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 725 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 726 May 2017, . 728 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 729 Access Control Model", STD 91, RFC 8341, 730 DOI 10.17487/RFC8341, March 2018, 731 . 733 8.2. Informative References 735 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 736 DOI 10.17487/RFC3688, January 2004, 737 . 739 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 740 and A. Bierman, Ed., "Network Configuration Protocol 741 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 742 . 744 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 745 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 746 . 748 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 749 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 750 . 752 Appendix A. Change Log 754 A.1. 00 to 01 756 o Added 'local-binding-supported' feature to TCP-client model. 758 o Added 'keepalives-supported' feature to TCP-common model. 760 o Added 'external-endpoint-values' container and 'external- 761 endpoints' feature to TCP-server model. 763 A.2. 01 to 02 765 o Removed the 'external-endpoint-values' container and 'external- 766 endpoints' feature from the TCP-server model. 768 Authors' Addresses 770 Kent Watsen 771 Watsen Networks 773 EMail: kent+ietf@watsen.net 775 Michael Scharf 776 Hochschule Esslingen - University of Applied Sciences 778 EMail: michael.scharf@hs-esslingen.de