idnits 2.17.1 draft-ietf-netconf-tcp-client-server-09.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7950]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 245 has weird spacing: '...nterval uin...' == Line 414 has weird spacing: '...is node must ...' == Line 523 has weird spacing: '...address ine...' == Line 527 has weird spacing: '...address ine...' -- The document date (10 February 2021) is 1142 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) == Missing Reference: 'RFC1122' is mentioned on line 313, but not defined == Missing Reference: 'RFC793bis' is mentioned on line 279, but not defined ** Obsolete undefined reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-34) exists of draft-ietf-netconf-crypto-types-18 == Outdated reference: A later version (-20) exists of draft-ietf-netconf-http-client-server-05 == Outdated reference: A later version (-35) exists of draft-ietf-netconf-keystore-20 == Outdated reference: A later version (-36) exists of draft-ietf-netconf-netconf-client-server-21 == Outdated reference: A later version (-36) exists of draft-ietf-netconf-restconf-client-server-21 == Outdated reference: A later version (-40) exists of draft-ietf-netconf-ssh-client-server-22 == Outdated reference: A later version (-24) exists of draft-ietf-netconf-tcp-client-server-08 == Outdated reference: A later version (-41) exists of draft-ietf-netconf-tls-client-server-22 == Outdated reference: A later version (-28) exists of draft-ietf-netconf-trust-anchors-13 Summary: 2 errors (**), 0 flaws (~~), 16 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: 14 August 2021 Hochschule Esslingen 6 10 February 2021 8 YANG Groupings for TCP Clients and TCP Servers 9 draft-ietf-netconf-tcp-client-server-09 11 Abstract 13 This document defines three YANG 1.1 [RFC7950] modules to support the 14 configuration of TCP clients and TCP servers, either as standalone or 15 in conjunction with a stack protocol layer specific configurations. 17 Editorial Note (To be removed by RFC Editor) 19 This draft contains placeholder values that need to be replaced with 20 finalized values at the time of publication. This note summarizes 21 all of the substitutions that are needed. No other RFC Editor 22 instructions are specified elsewhere in this document. 24 Artwork in this document contains shorthand references to drafts in 25 progress. Please apply the following replacements: 27 * "DDDD" --> the assigned RFC value for this draft 29 Artwork in this document contains placeholder values for the date of 30 publication of this draft. Please apply the following replacement: 32 * "2021-02-10" --> the publication date of this draft 34 The following Appendix section is to be removed prior to publication: 36 * Appendix A. Change Log 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on 14 August 2021. 55 Copyright Notice 57 Copyright (c) 2021 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 62 license-info) in effect on the date of publication of this document. 63 Please review these documents carefully, as they describe your rights 64 and restrictions with respect to this document. Code Components 65 extracted from this document must include Simplified BSD License text 66 as described in Section 4.e of the Trust Legal Provisions and are 67 provided without warranty as described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.1. Relation to other RFCs . . . . . . . . . . . . . . . . . 3 73 1.2. Specification Language . . . . . . . . . . . . . . . . . 5 74 1.3. Adherence to the NMDA . . . . . . . . . . . . . . . . . . 5 75 2. The "ietf-tcp-common" Module . . . . . . . . . . . . . . . . 5 76 2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 5 77 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 8 78 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 8 79 3. The "ietf-tcp-client" Module . . . . . . . . . . . . . . . . 11 80 3.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 11 81 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 13 82 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 14 83 4. The "ietf-tcp-server" Module . . . . . . . . . . . . . . . . 21 84 4.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 21 85 4.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 22 86 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 22 87 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 88 5.1. The "ietf-tcp-common" YANG Module . . . . . . . . . . . . 25 89 5.2. The "ietf-tcp-client" YANG Module . . . . . . . . . . . . 26 90 5.3. The "ietf-tcp-server" YANG Module . . . . . . . . . . . . 27 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 92 6.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 27 93 6.2. The "YANG Module Names" Registry . . . . . . . . . . . . 28 94 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 95 7.1. Normative References . . . . . . . . . . . . . . . . . . 28 96 7.2. Informative References . . . . . . . . . . . . . . . . . 29 97 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 30 98 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 30 99 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 31 100 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 31 101 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 31 102 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 31 103 A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 31 104 A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 31 105 A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 31 106 A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 32 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 109 1. Introduction 111 This document defines three YANG 1.1 [RFC7950] modules to support the 112 configuration of TCP clients and TCP servers, either as standalone or 113 in conjunction with a stack protocol layer specific configurations. 115 1.1. Relation to other RFCs 117 This document presents one or more YANG modules [RFC7950] that are 118 part of a collection of RFCs that work together to, ultimately, 119 enable the configuration of the clients and servers of both the 120 NETCONF [RFC6241] and RESTCONF [RFC8040] protocols. 122 The modules have been defined in a modular fashion to enable their 123 use by other efforts, some of which are known to be in progress at 124 the time of this writing, with many more expected to be defined in 125 time. 127 The normative dependency relationship between the various RFCs in the 128 collection is presented in the below diagram. The labels in the 129 diagram represent the primary purpose provided by each RFC. 130 Hyperlinks to each RFC are provided below the diagram. 132 crypto-types 133 ^ ^ 134 / \ 135 / \ 136 truststore keystore 137 ^ ^ ^ ^ 138 | +---------+ | | 139 | | | | 140 | +------------+ | 141 tcp-client-server | / | | 142 ^ ^ ssh-client-server | | 143 | | ^ tls-client-server 144 | | | ^ ^ http-client-server 145 | | | | | ^ 146 | | | +-----+ +---------+ | 147 | | | | | | 148 | +-----------|--------|--------------+ | | 149 | | | | | | 150 +-----------+ | | | | | 151 | | | | | | 152 | | | | | | 153 netconf-client-server restconf-client-server 155 +=======================+===========================================+ 156 |Label in Diagram | Originating RFC | 157 +=======================+===========================================+ 158 |crypto-types | [I-D.ietf-netconf-crypto-types] | 159 +-----------------------+-------------------------------------------+ 160 |truststore | [I-D.ietf-netconf-trust-anchors] | 161 +-----------------------+-------------------------------------------+ 162 |keystore | [I-D.ietf-netconf-keystore] | 163 +-----------------------+-------------------------------------------+ 164 |tcp-client-server | [I-D.ietf-netconf-tcp-client-server] | 165 +-----------------------+-------------------------------------------+ 166 |ssh-client-server | [I-D.ietf-netconf-ssh-client-server] | 167 +-----------------------+-------------------------------------------+ 168 |tls-client-server | [I-D.ietf-netconf-tls-client-server] | 169 +-----------------------+-------------------------------------------+ 170 |http-client-server | [I-D.ietf-netconf-http-client-server] | 171 +-----------------------+-------------------------------------------+ 172 |netconf-client-server | [I-D.ietf-netconf-netconf-client-server] | 173 +-----------------------+-------------------------------------------+ 174 |restconf-client-server | [I-D.ietf-netconf-restconf-client-server] | 175 +-----------------------+-------------------------------------------+ 177 Table 1: Label to RFC Mapping 179 1.2. Specification Language 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 183 "OPTIONAL" in this document are to be interpreted as described in BCP 184 14 [RFC2119] [RFC8174] when, and only when, they appear in all 185 capitals, as shown here. 187 1.3. Adherence to the NMDA 189 This document in compliant with the Network Management Datastore 190 Architecture (NMDA) [RFC8342]. It does not define any protocol 191 accessible nodes that are "config false". 193 2. The "ietf-tcp-common" Module 195 This section defines a YANG 1.1 [RFC7950] module called "ietf-tcp- 196 common". A high-level overview of the module is provided in 197 Section 2.1. Examples illustatrating the module's use are provided 198 in Examples (Section 2.2). The YANG module itself is defined in 199 Section 2.3. 201 2.1. Data Model Overview 203 This section provides an overview of the "ietf-tcp-common" module in 204 terms of its features and groupings. 206 2.1.1. Model Scope 208 This document defines a common "grouping" statement for basic TCP 209 connection parameters that matter to applications. In some TCP 210 stacks, such parameters can also directly be set by an application 211 using system calls, such as the socket API. The base YANG model in 212 this document focuses on modeling TCP keep-alives. This base model 213 can be extended as needed. 215 2.1.2. Features 217 The following diagram lists all the "feature" statements defined in 218 the "ietf-tcp-common" module: 220 Features: 221 +-- keepalives-supported 223 | The diagram above uses syntax that is similar to but not 224 | defined in [RFC8340]. 226 2.1.3. Groupings 228 The "ietf-tcp-common" module defines the following "grouping" 229 statements: 231 * tcp-common-grouping 232 * tcp-connection-grouping 234 These groupings are presented in the following subsections. 236 2.1.3.1. The "tcp-common-grouping" Grouping 238 The following tree diagram [RFC8340] illustrates the "tcp-common- 239 grouping" grouping: 241 grouping tcp-common-grouping 242 +-- keepalives! {keepalives-supported}? 243 +-- idle-time uint16 244 +-- max-probes uint16 245 +-- probe-interval uint16 247 Comments: 249 * The "keepalives" node is a "presence" node so that the decendent 250 nodes' "mandatory true" doesn't imply that keepalives must be 251 configured. 253 * The "idle-time", "max-probes", and "probe-interval" nodes have the 254 common meanings. Please see the YANG module in Section 2.3 for 255 details. 257 2.1.3.2. The "tcp-connection-grouping" Grouping 259 The following tree diagram [RFC8340] illustrates the "tcp-connection- 260 grouping" grouping: 262 grouping tcp-connection-grouping 263 +---u tcp-common-grouping 265 Comments: 267 * This grouping uses the "tcp-common-grouping" grouping discussed in 268 Section 2.1.3.1. 270 2.1.4. Protocol-accessible Nodes 272 The "ietf-tcp-common" module does not contain any protocol-accessible 273 nodes. 275 2.1.5. Guidelines for Configuring TCP Keep-Alives 277 Network stacks may include "keep-alives" in their TCP 278 implementations, although this practice is not universally accepted. 279 If keep-alives are included, [RFC1122] [RFC793bis] mandates that the 280 application MUST be able to turn them on or off for each TCP 281 connection, and that they MUST default to off. 283 Keep-alive mechanisms exist in many protocols. Depending on the 284 protocol stack, TCP keep-alives may only be one out of several 285 alternatives. Which mechanism(s) to use depends on the use case and 286 application requirements. If keep-alives are needed by an 287 application, it is RECOMMENDED that the aliveness check happens only 288 at the protocol layers that are meaningful to the application. 290 A TCP keep-alive mechanism SHOULD only be invoked in server 291 applications that might otherwise hang indefinitely and consume 292 resources unnecessarily if a client crashes or aborts a connection 293 during a network failure [RFC1122]. TCP keep-alives may consume 294 significant resources both in the network and in endpoints (e.g., 295 battery power). In addition, frequent keep-alives risk network 296 congestion. The higher the frequency of keep-alives, the higher the 297 overhead. 299 Given the cost of keep-alives, parameters have to be configured 300 carefully: 302 * The default idle interval (leaf "idle-time") MUST default to no 303 less than two hours, i.e., 7200 seconds [RFC1122]. A lower value 304 MAY be configured, but keep-alive messages SHOULD NOT be 305 transmitted more frequently than once every 15 seconds. Longer 306 intervals SHOULD be used when possible. 308 * The maximum number of sequential keep-alive probes that can fail 309 (leaf "max-probes") trades off responsiveness and robustness 310 against packet loss. ACK segments that contain no data are not 311 reliably transmitted by TCP. Consequently, if a keep-alive 312 mechanism is implemented it MUST NOT interpret failure to respond 313 to any specific probe as a dead connection [RFC1122]. Typically a 314 single-digit number should suffice. 316 * TCP implementations may include a parameter for the number of 317 seconds between TCP keep-alive probes (leaf "probe-interval"). In 318 order to avoid congestion, the time interval between probes MUST 319 NOT be smaller than one second. Significantly longer intervals 320 SHOULD be used. It is important to note that keep-alive probes 321 (or replies) can get dropped due to network congestion. Sending 322 further probe messages into a congested path after a short 323 interval, without backing off timers, could cause harm and result 324 in a congestion collapse. Therefore it is essential to pick a 325 large, conservative value for this interval. 327 2.2. Example Usage 329 This section presents an example showing the "tcp-common-grouping" 330 populated with some data. 332 333 334 15 335 3 336 30 337 338 340 2.3. YANG Module 342 The ietf-tcp-common YANG module references [RFC6991]. 344 file "ietf-tcp-common@2021-02-10.yang" 346 module ietf-tcp-common { 347 yang-version 1.1; 348 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-common"; 349 prefix tcpcmn; 351 organization 352 "IETF NETCONF (Network Configuration) Working Group and the 353 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group"; 355 contact 356 "WG Web: 357 358 WG List: 359 360 Authors: Kent Watsen 361 Michael Scharf 362 "; 364 description 365 "This module defines reusable groupings for TCP commons that 366 can be used as a basis for specific TCP common instances. 368 Copyright (c) 2020 IETF Trust and the persons identified 369 as authors of the code. All rights reserved. 371 Redistribution and use in source and binary forms, with 372 or without modification, is permitted pursuant to, and 373 subject to the license terms contained in, the Simplified 374 BSD License set forth in Section 4.c of the IETF Trust's 375 Legal Provisions Relating to IETF Documents 376 (https://trustee.ietf.org/license-info). 378 This version of this YANG module is part of RFC DDDD 379 (https://www.rfc-editor.org/info/rfcDDDD); see the RFC 380 itself for full legal notices. 382 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 383 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 384 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 385 are to be interpreted as described in BCP 14 (RFC 2119) 386 (RFC 8174) when, and only when, they appear in all 387 capitals, as shown here."; 389 revision 2021-02-10 { 390 description 391 "Initial version"; 392 reference 393 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers"; 394 } 396 // Features 397 feature keepalives-supported { 398 description 399 "Indicates that keepalives are supported."; 400 } 402 // Groupings 404 grouping tcp-common-grouping { 405 description 406 "A reusable grouping for configuring TCP parameters common 407 to TCP connections as well as the operating system as a 408 whole."; 409 container keepalives { 410 if-feature "keepalives-supported"; 411 presence 412 "Indicates that keepalives are enabled. Present so that 413 the decendant nodes' 'mandatory true' doesn't imply that 414 this node must be configured."; 415 description 416 "Configures the keep-alive policy, to proactively test the 417 aliveness of the TCP peer. An unresponsive TCP peer is 418 dropped after approximately (idle-time + max-probes 419 * probe-interval) seconds."; 420 leaf idle-time { 421 type uint16 { 422 range "1..max"; 423 } 424 units "seconds"; 425 mandatory true; 426 description 427 "Sets the amount of time after which if no data has been 428 received from the TCP peer, a TCP-level probe message 429 will be sent to test the aliveness of the TCP peer. 430 Two hours (7200 seconds) is safe value, per RFC 1122."; 431 reference 432 "RFC 1122: 433 Requirements for Internet Hosts -- Communication Layers"; 434 } 435 leaf max-probes { 436 type uint16 { 437 range "1..max"; 438 } 439 mandatory true; 440 description 441 "Sets the maximum number of sequential keep-alive probes 442 that can fail to obtain a response from the TCP peer 443 before assuming the TCP peer is no longer alive."; 444 } 445 leaf probe-interval { 446 type uint16 { 447 range "1..max"; 448 } 449 units "seconds"; 450 mandatory true; 451 description 452 "Sets the time interval between failed probes. The interval 453 SHOULD be significantly longer than one second in order to 454 avoid harm on a congested link."; 455 } 456 } // container keepalives 457 } // grouping tcp-common-grouping 459 grouping tcp-connection-grouping { 460 description 461 "A reusable grouping for configuring TCP parameters common 462 to TCP connections."; 463 uses tcp-common-grouping; 464 } 466 } 468 470 3. The "ietf-tcp-client" Module 472 This section defines a YANG 1.1 [RFC7950] module called "ietf-tcp- 473 client". A high-level overview of the module is provided in 474 Section 3.1. Examples illustatrating the module's use are provided 475 in Examples (Section 3.2). The YANG module itself is defined in 476 Section 3.3. 478 3.1. Data Model Overview 480 This section provides an overview of the "ietf-tcp-client" module in 481 terms of its features and groupings. 483 3.1.1. Features 485 The following diagram lists all the "feature" statements defined in 486 the "ietf-tcp-client" module: 488 Features: 489 +-- local-binding-supported 490 +-- tcp-client-keepalives 491 +-- proxy-connect 492 +-- socks5-gss-api 493 +-- socks5-username-password 495 | The diagram above uses syntax that is similar to but not 496 | defined in [RFC8340]. 498 3.1.2. Groupings 500 The "ietf-tcp-client" module defines the following "grouping" 501 statement: 503 * tcp-client-grouping 505 This grouping is presented in the following subsection. 507 3.1.2.1. The "tcp-client-grouping" Grouping 509 The following tree diagram [RFC8340] illustrates the "tcp-client- 510 grouping" grouping: 512 grouping tcp-client-grouping 513 +-- remote-address inet:host 514 +-- remote-port? inet:port-number 515 +-- local-address? inet:ip-address 516 | {local-binding-supported}? 517 +-- local-port? inet:port-number 518 | {local-binding-supported}? 519 +-- proxy-server! {proxy-connect}? 520 | +-- (proxy-type) 521 | +--:(socks4) 522 | | +-- socks4-parameters 523 | | +-- remote-address inet:ip-address 524 | | +-- remote-port? inet:port-number 525 | +--:(socks4a) 526 | | +-- socks4a-parameters 527 | | +-- remote-address inet:host 528 | | +-- remote-port? inet:port-number 529 | +--:(socks5) 530 | +-- socks5-parameters 531 | +-- remote-address inet:host 532 | +-- remote-port? inet:port-number 533 | +-- authentication-parameters! 534 | +-- (auth-type) 535 | +--:(gss-api) {socks5-gss-api}? 536 | | +-- gss-api 537 | +--:(username-password) 538 | {socks5-username-password}? 539 | +-- username-password 540 | +-- username string 541 | +---u ct:password-grouping 542 +---u tcpcmn:tcp-connection-grouping 544 Comments: 546 * The "remote-address" node, which is mandatory, may be configured 547 as an IPv4 address, an IPv6 address, a hostname. 549 * The "remote-port" node is not mandatory, but its default value is 550 the invalid value '0', thus forcing the consuming data model to 551 refine it in order to provide it an appropriate default value. 553 * The "local-address" node, which is enabled by the "local-binding- 554 supported" feature (Section 2.1.2), may be configured as an IPv4 555 address, an IPv6 address, or a wildcard value. 557 * The "local-port" node, which is enabled by the "local-binding- 558 supported" feature (Section 2.1.2), is not mandatory. Its default 559 value is '0', indicating that the operating system can pick an 560 arbitrary port number. 562 * The "proxy-server" node is enabled by a "feature" statement and, 563 for servers that enable it, is a "presence" container so that the 564 decendent "mandatory true" choice node doesn't imply that the 565 proxt-server node must be configured. 567 * This grouping uses the "tcp-connection-grouping" grouping 568 discussed in Section 2.1.3.2. 570 3.1.3. Protocol-accessible Nodes 572 The "ietf-tcp-client" module does not contain any protocol-accessible 573 nodes. 575 3.2. Example Usage 577 This section presents two examples showing the "tcp-client-grouping" 578 populated with some data. This example shows a TCP-client configured 579 to not connect via a proxy: 581 582 www.example.com 583 443 584 0.0.0.0 585 0 586 587 15 588 3 589 30 590 591 593 This example shows a TCP-client configured to connect via a proxy: 595 596 www.example.com 597 443 598 0.0.0.0 599 0 600 601 602 proxy.my-domain.com 603 1080 604 605 606 foobar 607 secret 608 609 610 611 612 613 15 614 3 615 30 616 617 619 3.3. YANG Module 621 The ietf-tcp-client YANG module references [RFC6991]. 623 file "ietf-tcp-client@2021-02-10.yang" 625 module ietf-tcp-client { 626 yang-version 1.1; 627 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-client"; 628 prefix tcpc; 630 import ietf-inet-types { 631 prefix inet; 632 reference 633 "RFC 6991: Common YANG Data Types"; 634 } 636 import ietf-crypto-types { 637 prefix ct; 638 reference 639 "RFC AAAA: YANG Data Types and Groupings for Cryptography"; 640 } 642 import ietf-tcp-common { 643 prefix tcpcmn; 644 reference 645 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers"; 646 } 648 organization 649 "IETF NETCONF (Network Configuration) Working Group and the 650 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group"; 652 contact 653 "WG Web: 654 655 WG List: 656 657 Authors: Kent Watsen 658 Michael Scharf 659 "; 661 description 662 "This module defines reusable groupings for TCP clients that 663 can be used as a basis for specific TCP client instances. 665 Copyright (c) 2020 IETF Trust and the persons identified 666 as authors of the code. All rights reserved. 668 Redistribution and use in source and binary forms, with 669 or without modification, is permitted pursuant to, and 670 subject to the license terms contained in, the Simplified 671 BSD License set forth in Section 4.c of the IETF Trust's 672 Legal Provisions Relating to IETF Documents 673 (https://trustee.ietf.org/license-info). 675 This version of this YANG module is part of RFC DDDD 676 (https://www.rfc-editor.org/info/rfcDDDD); see the RFC 677 itself for full legal notices. 679 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 680 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 681 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 682 are to be interpreted as described in BCP 14 (RFC 2119) 683 (RFC 8174) when, and only when, they appear in all 684 capitals, as shown here."; 686 revision 2021-02-10 { 687 description 688 "Initial version"; 689 reference 690 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers"; 692 } 694 // Features 696 feature local-binding-supported { 697 description 698 "Indicates that the server supports configuring local 699 bindings (i.e., the local address and local port) for 700 TCP clients."; 701 } 703 feature tcp-client-keepalives { 704 description 705 "Per socket TCP keepalive parameters are configurable for 706 TCP clients on the server implementing this feature."; 707 } 709 feature proxy-connect { 710 description 711 "Proxy connection configuration is configurable for 712 TCP clients on the server implementing this feature."; 713 } 715 feature socks5-gss-api { 716 description 717 "Indicates that the server supports authenticating 718 using GSSAPI when initiating TCP connections via 719 and SOCKS Version 5 proxy server."; 720 reference 721 "RFC 1928: SOCKS Protocol Version 5"; 722 } 724 feature socks5-username-password { 725 description 726 "Indicates that the server supports authenticating 727 using username/password when initiating TCP 728 connections via and SOCKS Version 5 proxy 729 server."; 730 reference 731 "RFC 1928: SOCKS Protocol Version 5"; 732 } 734 // Groupings 736 grouping tcp-client-grouping { 737 description 738 "A reusable grouping for configuring a TCP client. 740 Note that this grouping uses fairly typical descendent 741 node names such that a stack of 'uses' statements will 742 have name conflicts. It is intended that the consuming 743 data model will resolve the issue (e.g., by wrapping 744 the 'uses' statement in a container called 745 'tcp-client-parameters'). This model purposely does 746 not do this itself so as to provide maximum flexibility 747 to consuming models."; 749 leaf remote-address { 750 type inet:host; 751 mandatory true; 752 description 753 "The IP address or hostname of the remote peer to 754 establish a connection with. If a domain name is 755 configured, then the DNS resolution should happen on 756 each connection attempt. If the DNS resolution 757 results in multiple IP addresses, the IP addresses 758 are tried according to local preference order until 759 a connection has been established or until all IP 760 addresses have failed."; 761 } 762 leaf remote-port { 763 type inet:port-number; 764 default "0"; 765 description 766 "The IP port number for the remote peer to establish a 767 connection with. An invalid default value (0) is used 768 (instead of 'mandatory true') so that as application 769 level data model may 'refine' it with an application 770 specific default port number value."; 771 } 772 leaf local-address { 773 if-feature "local-binding-supported"; 774 type inet:ip-address; 775 description 776 "The local IP address/interface (VRF?) to bind to for when 777 connecting to the remote peer. INADDR_ANY ('0.0.0.0') or 778 INADDR6_ANY ('0:0:0:0:0:0:0:0' a.k.a. '::') MAY be used to 779 explicitly indicate the implicit default, that the server 780 can bind to any IPv4 or IPv6 addresses, respectively."; 781 } 782 leaf local-port { 783 if-feature "local-binding-supported"; 784 type inet:port-number; 785 default "0"; 786 description 787 "The local IP port number to bind to for when connecting 788 to the remote peer. The port number '0', which is the 789 default value, indicates that any available local port 790 number may be used."; 791 } 793 container proxy-server { 794 if-feature "proxy-connect"; 795 presence 796 "Indicates that a proxy connection is configured. 797 Present so that the 'proxy-type' node's 'mandatory 798 true' doesn't imply that the proxy connection 799 must be configured."; 800 choice proxy-type { 801 mandatory true; 802 description 803 "Selects a proxy connection protocol."; 804 case socks4 { 805 container socks4-parameters { 806 leaf remote-address { 807 type inet:ip-address; 808 mandatory true; 809 description 810 "The IP address of the proxy server."; 811 } 812 leaf remote-port { 813 type inet:port-number; 814 default "1080"; 815 description 816 "The IP port number for the proxy server."; 817 } 818 description 819 "Parameters for connecting to a TCP-based proxy 820 server using the SOCKS4 protocol."; 821 reference 822 "SOCKS, Proceedings: 1992 Usenix Security Symposium."; 823 } 824 } 825 case socks4a { 826 container socks4a-parameters { 827 leaf remote-address { 828 type inet:host; 829 mandatory true; 830 description 831 "The IP address or hostname of the proxy server."; 832 } 833 leaf remote-port { 834 type inet:port-number; 835 default "1080"; 836 description 837 "The IP port number for the proxy server."; 838 } 839 description 840 "Parameters for connecting to a TCP-based proxy 841 server using the SOCKS4a protocol."; 842 reference 843 "SOCKS Proceedings: 844 1992 Usenix Security Symposium. 845 OpenSSH message: 846 SOCKS 4A: A Simple Extension to SOCKS 4 Protocol 847 https://www.openssh.com/txt/socks4a.protocol"; 848 } 849 } 850 case socks5 { 851 container socks5-parameters { 852 leaf remote-address { 853 type inet:host; 854 mandatory true; 855 description 856 "The IP address or hostname of the proxy server."; 857 } 858 leaf remote-port { 859 type inet:port-number; 860 default "1080"; 861 description 862 "The IP port number for the proxy server."; 863 } 864 container authentication-parameters { 865 presence 866 "Indicates that an authentication mechanism 867 has been configured. Present so that the 868 'auth-type' node's 'mandatory true' doesn't 869 imply that an authentication mechanism 870 must be configured."; 871 description 872 "A container for SOCKS Version 5 authentication 873 mechanisms. 875 A complete list of methods is defined at: 876 https://www.iana.org/assignments/socks-methods 877 /socks-methods.xhtml."; 878 reference 879 "RFC 1928: SOCKS Protocol Version 5"; 880 choice auth-type { 881 mandatory true; 882 description 883 "A choice amongst supported SOCKS Version 5 884 authentication mechanisms."; 885 case gss-api { 886 if-feature socks5-gss-api; 887 container gss-api { 888 description 889 "Contains GSS-API configuration. Defines 890 as an empty container to enable specific 891 GSS-API configuration to be augmented in 892 by future modules."; 893 reference 894 "RFC 1928: SOCKS Protocol Version 5 895 RFC 2743: Generic Security Service 896 Application Program Interface 897 Version 2, Update 1"; 898 } 899 } 900 case username-password { 901 if-feature socks5-username-password; 902 container username-password { 903 leaf username { 904 type string; 905 mandatory true; 906 description 907 "The 'username' value to use for client 908 identification."; 909 } 910 uses ct:password-grouping { 911 description 912 "The password to be used for client 913 authentication."; 914 } 915 description 916 "Contains Username/Password configuration."; 917 reference 918 "RFC 1929: Username/Password Authentication 919 for SOCKS V5"; 920 } 921 } 922 } 923 } 924 description 925 "Parameters for connecting to a TCP-based proxy server 926 using the SOCKS5 protocol."; 927 reference 928 "RFC 1928: SOCKS Protocol Version 5"; 929 } 930 } 931 } 932 description 933 "Proxy server settings."; 934 } 936 uses tcpcmn:tcp-connection-grouping { 937 augment "keepalives" { 938 if-feature "tcp-client-keepalives"; 939 description 940 "Add an if-feature statement so that implementations 941 can choose to support TCP client keepalives."; 942 } 943 } 944 } 945 } 947 949 4. The "ietf-tcp-server" Module 951 This section defines a YANG 1.1 [RFC7950] module called "ietf-tcp- 952 server". A high-level overview of the module is provided in 953 Section 4.1. Examples illustatrating the module's use are provided 954 in Examples (Section 4.2). The YANG module itself is defined in 955 Section 4.3. 957 4.1. Data Model Overview 959 This section provides an overview of the "ietf-tcp-server" module in 960 terms of its features and groupings. 962 4.1.1. Features 964 The following diagram lists all the "feature" statements defined in 965 the "ietf-tcp-server" module: 967 Features: 968 +-- tcp-server-keepalives 970 | The diagram above uses syntax that is similar to but not 971 | defined in [RFC8340]. 973 4.1.2. Groupings 975 The "ietf-tcp-server" module defines the following "grouping" 976 statement: 978 * tcp-server-grouping 979 This grouping is presented in the following subsection. 981 4.1.2.1. The "tcp-server-grouping" Grouping 983 The following tree diagram [RFC8340] illustrates the "tcp-server- 984 grouping" grouping: 986 grouping tcp-server-grouping 987 +-- local-address inet:ip-address 988 +-- local-port? inet:port-number 989 +---u tcpcmn:tcp-connection-grouping 991 Comments: 993 * The "local-address" node, which is mandatory, may be configured as 994 an IPv4 address, an IPv6 address, or a wildcard value. 996 * The "local-port" node is not mandatory, but its default value is 997 the invalid value '0', thus forcing the consuming data model to 998 refine it in order to provide it an appropriate default value. 1000 * This grouping uses the "tcp-connection-grouping" grouping 1001 discussed in Section 2.1.3.2. 1003 4.1.3. Protocol-accessible Nodes 1005 The "ietf-tcp-server" module does not contain any protocol-accessible 1006 nodes. 1008 4.2. Example Usage 1010 This section presents an example showing the "tcp-server-grouping" 1011 populated with some data. 1013 1014 10.20.30.40 1015 7777 1016 1017 15 1018 3 1019 30 1020 1021 1023 4.3. YANG Module 1025 The ietf-tcp-server YANG module references [RFC6991]. 1027 file "ietf-tcp-server@2021-02-10.yang" 1029 module ietf-tcp-server { 1030 yang-version 1.1; 1031 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-server"; 1032 prefix tcps; 1034 import ietf-inet-types { 1035 prefix inet; 1036 reference 1037 "RFC 6991: Common YANG Data Types"; 1038 } 1040 import ietf-tcp-common { 1041 prefix tcpcmn; 1042 reference 1043 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers"; 1044 } 1046 organization 1047 "IETF NETCONF (Network Configuration) Working Group and the 1048 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group"; 1050 contact 1051 "WG Web: 1052 1053 WG List: 1054 1055 Authors: Kent Watsen 1056 Michael Scharf 1057 "; 1059 description 1060 "This module defines reusable groupings for TCP servers that 1061 can be used as a basis for specific TCP server instances. 1063 Copyright (c) 2020 IETF Trust and the persons identified 1064 as authors of the code. All rights reserved. 1066 Redistribution and use in source and binary forms, with 1067 or without modification, is permitted pursuant to, and 1068 subject to the license terms contained in, the Simplified 1069 BSD License set forth in Section 4.c of the IETF Trust's 1070 Legal Provisions Relating to IETF Documents 1071 (https://trustee.ietf.org/license-info). 1073 This version of this YANG module is part of RFC DDDD 1074 (https://www.rfc-editor.org/info/rfcDDDD); see the RFC 1075 itself for full legal notices. 1077 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1078 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1079 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 1080 are to be interpreted as described in BCP 14 (RFC 2119) 1081 (RFC 8174) when, and only when, they appear in all 1082 capitals, as shown here."; 1084 revision 2021-02-10 { 1085 description 1086 "Initial version"; 1087 reference 1088 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers"; 1089 } 1091 // Features 1093 feature tcp-server-keepalives { 1094 description 1095 "Per socket TCP keepalive parameters are configurable for 1096 TCP servers on the server implementing this feature."; 1097 } 1099 // Groupings 1101 grouping tcp-server-grouping { 1102 description 1103 "A reusable grouping for configuring a TCP server. 1105 Note that this grouping uses fairly typical descendent 1106 node names such that a stack of 'uses' statements will 1107 have name conflicts. It is intended that the consuming 1108 data model will resolve the issue (e.g., by wrapping 1109 the 'uses' statement in a container called 1110 'tcp-server-parameters'). This model purposely does 1111 not do this itself so as to provide maximum flexibility 1112 to consuming models."; 1113 leaf local-address { 1114 type inet:ip-address; 1115 mandatory true; 1116 description 1117 "The local IP address to listen on for incoming 1118 TCP client connections. INADDR_ANY (0.0.0.0) or 1119 INADDR6_ANY (0:0:0:0:0:0:0:0 a.k.a. ::) MUST be 1120 used when the server is to listen on all IPv4 or 1121 IPv6 addresses, respectively."; 1123 } 1124 leaf local-port { 1125 type inet:port-number; 1126 default "0"; 1127 description 1128 "The local port number to listen on for incoming TCP 1129 client connections. An invalid default value (0) 1130 is used (instead of 'mandatory true') so that an 1131 application level data model may 'refine' it with 1132 an application specific default port number value."; 1133 } 1134 uses tcpcmn:tcp-connection-grouping { 1135 augment "keepalives" { 1136 if-feature "tcp-server-keepalives"; 1137 description 1138 "Add an if-feature statement so that implementations 1139 can choose to support TCP server keepalives."; 1140 } 1141 } 1142 } 1143 } 1145 1147 5. Security Considerations 1149 5.1. The "ietf-tcp-common" YANG Module 1151 The "ietf-tcp-common" YANG module defines "grouping" statements that 1152 are designed to be accessed via YANG based management protocols, such 1153 as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols 1154 have mandatory-to-implement secure transport layers (e.g., SSH, TLS) 1155 with mutual authentication. 1157 The NETCONF access control model (NACM) [RFC8341] provides the means 1158 to restrict access for particular users to a pre-configured subset of 1159 all available protocol operations and content. 1161 Since the module in this document only define groupings, these 1162 considerations are primarily for the designers of other modules that 1163 use these groupings. 1165 None of the readable data nodes defined in this YANG module are 1166 considered sensitive or vulnerable in network environments. The NACM 1167 "default-deny-all" extension has not been set for any data nodes 1168 defined in this module. 1170 None of the writable data nodes defined in this YANG module are 1171 considered sensitive or vulnerable in network environments. The NACM 1172 "default-deny-write" extension has not been set for any data nodes 1173 defined in this module. 1175 This module does not define any RPCs, actions, or notifications, and 1176 thus the security consideration for such is not provided here. 1178 5.2. The "ietf-tcp-client" YANG Module 1180 The "ietf-tcp-client" YANG module defines "grouping" statements that 1181 are designed to be accessed via YANG based management protocols, such 1182 as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols 1183 have mandatory-to-implement secure transport layers (e.g., SSH, TLS) 1184 with mutual authentication. 1186 The NETCONF access control model (NACM) [RFC8341] provides the means 1187 to restrict access for particular users to a pre-configured subset of 1188 all available protocol operations and content. 1190 Since the module in this document only define groupings, these 1191 considerations are primarily for the designers of other modules that 1192 use these groupings. 1194 One readable data node defined in this YANG module may be considered 1195 sensitive or vulnerable in some network environments. This node is 1196 as follows: 1198 * The "proxy-server/socks5-parameters/authentication-parameters/ 1199 username-password/password" node: 1201 The cleartext "password" node defined in the "tcp-client- 1202 grouping" grouping is additionally sensitive to read operations 1203 such that, in normal use cases, it should never be returned to 1204 a client. For this reason, the NACM extension "default-deny- 1205 all" has been applied to it. 1207 None of the writable data nodes defined in this YANG module are 1208 considered sensitive or vulnerable in network environments. The NACM 1209 "default-deny-write" extension has not been set for any data nodes 1210 defined in this module. 1212 This module does not define any RPCs, actions, or notifications, and 1213 thus the security consideration for such is not provided here. 1215 5.3. The "ietf-tcp-server" YANG Module 1217 The "ietf-tcp-server" YANG module defines "grouping" statements that 1218 are designed to be accessed via YANG based management protocols, such 1219 as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols 1220 have mandatory-to-implement secure transport layers (e.g., SSH, TLS) 1221 with mutual authentication. 1223 The NETCONF access control model (NACM) [RFC8341] provides the means 1224 to restrict access for particular users to a pre-configured subset of 1225 all available protocol operations and content. 1227 Since the module in this document only define groupings, these 1228 considerations are primarily for the designers of other modules that 1229 use these groupings. 1231 None of the readable data nodes defined in this YANG module are 1232 considered sensitive or vulnerable in network environments. The NACM 1233 "default-deny-all" extension has not been set for any data nodes 1234 defined in this module. 1236 None of the writable data nodes defined in this YANG module are 1237 considered sensitive or vulnerable in network environments. The NACM 1238 "default-deny-write" extension has not been set for any data nodes 1239 defined in this module. 1241 This module does not define any RPCs, actions, or notifications, and 1242 thus the security consideration for such is not provided here. 1244 6. IANA Considerations 1246 6.1. The "IETF XML" Registry 1248 This document registers two URIs in the "ns" subregistry of the IETF 1249 XML Registry [RFC3688]. Following the format in [RFC3688], the 1250 following registrations are requested: 1252 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-common 1253 Registrant Contact: The IESG 1254 XML: N/A, the requested URI is an XML namespace. 1256 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-client 1257 Registrant Contact: The IESG 1258 XML: N/A, the requested URI is an XML namespace. 1260 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-server 1261 Registrant Contact: The IESG 1262 XML: N/A, the requested URI is an XML namespace. 1264 6.2. The "YANG Module Names" Registry 1266 This document registers two YANG modules in the YANG Module Names 1267 registry [RFC6020]. Following the format in [RFC6020], the following 1268 registrations are requested: 1270 name: ietf-tcp-common 1271 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-common 1272 prefix: tcpcmn 1273 reference: RFC DDDD 1275 name: ietf-tcp-client 1276 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-client 1277 prefix: tcpc 1278 reference: RFC DDDD 1280 name: ietf-tcp-server 1281 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-server 1282 prefix: tcps 1283 reference: RFC DDDD 1285 7. References 1287 7.1. Normative References 1289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1290 Requirement Levels", BCP 14, RFC 2119, 1291 DOI 10.17487/RFC2119, March 1997, 1292 . 1294 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1295 the Network Configuration Protocol (NETCONF)", RFC 6020, 1296 DOI 10.17487/RFC6020, October 2010, 1297 . 1299 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1300 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1301 . 1303 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1304 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1305 . 1307 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1308 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1309 May 2017, . 1311 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1312 Access Control Model", STD 91, RFC 8341, 1313 DOI 10.17487/RFC8341, March 2018, 1314 . 1316 7.2. Informative References 1318 [I-D.ietf-netconf-crypto-types] 1319 Watsen, K., "YANG Data Types and Groupings for 1320 Cryptography", Work in Progress, Internet-Draft, draft- 1321 ietf-netconf-crypto-types-18, 20 August 2020, 1322 . 1325 [I-D.ietf-netconf-http-client-server] 1326 Watsen, K., "YANG Groupings for HTTP Clients and HTTP 1327 Servers", Work in Progress, Internet-Draft, draft-ietf- 1328 netconf-http-client-server-05, 20 August 2020, 1329 . 1332 [I-D.ietf-netconf-keystore] 1333 Watsen, K., "A YANG Data Model for a Keystore", Work in 1334 Progress, Internet-Draft, draft-ietf-netconf-keystore-20, 1335 20 August 2020, . 1338 [I-D.ietf-netconf-netconf-client-server] 1339 Watsen, K., "NETCONF Client and Server Models", Work in 1340 Progress, Internet-Draft, draft-ietf-netconf-netconf- 1341 client-server-21, 20 August 2020, 1342 . 1345 [I-D.ietf-netconf-restconf-client-server] 1346 Watsen, K., "RESTCONF Client and Server Models", Work in 1347 Progress, Internet-Draft, draft-ietf-netconf-restconf- 1348 client-server-21, 20 August 2020, 1349 . 1352 [I-D.ietf-netconf-ssh-client-server] 1353 Watsen, K., "YANG Groupings for SSH Clients and SSH 1354 Servers", Work in Progress, Internet-Draft, draft-ietf- 1355 netconf-ssh-client-server-22, 20 August 2020, 1356 . 1359 [I-D.ietf-netconf-tcp-client-server] 1360 Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients 1361 and TCP Servers", Work in Progress, Internet-Draft, draft- 1362 ietf-netconf-tcp-client-server-08, 20 August 2020, 1363 . 1366 [I-D.ietf-netconf-tls-client-server] 1367 Watsen, K., "YANG Groupings for TLS Clients and TLS 1368 Servers", Work in Progress, Internet-Draft, draft-ietf- 1369 netconf-tls-client-server-22, 20 August 2020, 1370 . 1373 [I-D.ietf-netconf-trust-anchors] 1374 Watsen, K., "A YANG Data Model for a Truststore", Work in 1375 Progress, Internet-Draft, draft-ietf-netconf-trust- 1376 anchors-13, 20 August 2020, . 1379 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1380 DOI 10.17487/RFC3688, January 2004, 1381 . 1383 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1384 and A. Bierman, Ed., "Network Configuration Protocol 1385 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1386 . 1388 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1389 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1390 . 1392 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1393 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1394 . 1396 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1397 and R. Wilton, "Network Management Datastore Architecture 1398 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1399 . 1401 Appendix A. Change Log 1403 This section is to be removed before publishing as an RFC. 1405 A.1. 00 to 01 1406 * Added 'local-binding-supported' feature to TCP-client model. 1408 * Added 'keepalives-supported' feature to TCP-common model. 1410 * Added 'external-endpoint-values' container and 'external- 1411 endpoints' feature to TCP-server model. 1413 A.2. 01 to 02 1415 * Removed the 'external-endpoint-values' container and 'external- 1416 endpoints' feature from the TCP-server model. 1418 A.3. 02 to 03 1420 * Moved the common model section to be before the client and server 1421 specific sections. 1423 * Added sections "Model Scope" and "Usage Guidelines for Configuring 1424 TCP Keep-Alives" to the common model section. 1426 A.4. 03 to 04 1428 * Fixed a few typos. 1430 A.5. 04 to 05 1432 * Removed commented out "grouping tcp-system-grouping" statement 1433 kept for reviewers. 1435 * Added a "Note to Reviewers" note to first page. 1437 A.6. 05 to 06 1439 * Added support for TCP proxies. 1441 A.7. 06 to 07 1443 * Expanded "Data Model Overview section(s) [remove "wall" of tree 1444 diagrams]. 1446 * Updated the Security Considerations section. 1448 A.8. 07 to 08 1450 * Added missing IANA registration for "ietf-tcp-common" 1452 * Added "mandatory true" for the "username" and "password" leafs 1453 * Added an example of a TCP-client configured to connect via a proxy 1455 * Fixed issues found by the SecDir review of the "keystore" draft. 1457 * Updated the "ietf-tcp-client" module to use the new "password- 1458 grouping" grouping from the "crypto-types" module. 1460 A.9. 08 to 09 1462 * Addressed comments raised by YANG Doctor in the ct/ts/ks drafts. 1464 Authors' Addresses 1466 Kent Watsen 1467 Watsen Networks 1469 Email: kent+ietf@watsen.net 1471 Michael Scharf 1472 Hochschule Esslingen - University of Applied Sciences 1474 Email: michael.scharf@hs-esslingen.de