idnits 2.17.1 draft-ietf-netconf-tcp-client-server-10.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 263 has weird spacing: '...nterval uin...' == Line 521 has weird spacing: '...address ine...' == Line 525 has weird spacing: '...address ine...' -- The document date (18 May 2021) is 1064 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) == Outdated reference: A later version (-34) exists of draft-ietf-netconf-crypto-types-19 == Outdated reference: A later version (-20) exists of draft-ietf-netconf-http-client-server-06 == Outdated reference: A later version (-35) exists of draft-ietf-netconf-keystore-21 == Outdated reference: A later version (-36) exists of draft-ietf-netconf-netconf-client-server-22 == Outdated reference: A later version (-36) exists of draft-ietf-netconf-restconf-client-server-22 == Outdated reference: A later version (-40) exists of draft-ietf-netconf-ssh-client-server-23 == Outdated reference: A later version (-26) exists of draft-ietf-netconf-tcp-client-server-09 == Outdated reference: A later version (-41) exists of draft-ietf-netconf-tls-client-server-23 == Outdated reference: A later version (-28) exists of draft-ietf-netconf-trust-anchors-14 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). 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: 19 November 2021 Hochschule Esslingen 6 18 May 2021 8 YANG Groupings for TCP Clients and TCP Servers 9 draft-ietf-netconf-tcp-client-server-10 11 Abstract 13 This document defines three YANG 1.1 modules to support the 14 configuration of TCP clients and TCP servers. The modules include 15 basic parameters of a TCP connection relevant for client or server 16 applications, as well as client configuration required for traversing 17 proxies. The modules can be used either standalone or in conjunction 18 with configuration of other stack protocol layers. 20 Editorial Note (To be removed by RFC Editor) 22 This draft contains placeholder values that need to be replaced with 23 finalized values at the time of publication. This note summarizes 24 all of the substitutions that are needed. No other RFC Editor 25 instructions are specified elsewhere in this document. 27 Artwork in this document contains shorthand references to drafts in 28 progress. Please apply the following replacements: 30 * "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- 31 types 33 * "DDDD" --> the assigned RFC value for this draft 35 Artwork in this document contains placeholder values for the date of 36 publication of this draft. Please apply the following replacement: 38 * "2021-05-18" --> the publication date of this draft 40 The following Appendix section is to be removed prior to publication: 42 * Appendix A. Change Log 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at https://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on 19 November 2021. 61 Copyright Notice 63 Copyright (c) 2021 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 68 license-info) in effect on the date of publication of this document. 69 Please review these documents carefully, as they describe your rights 70 and restrictions with respect to this document. Code Components 71 extracted from this document must include Simplified BSD License text 72 as described in Section 4.e of the Trust Legal Provisions and are 73 provided without warranty as described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 1.1. Relation to other RFCs . . . . . . . . . . . . . . . . . 3 79 1.2. Specification Language . . . . . . . . . . . . . . . . . 5 80 1.3. Adherence to the NMDA . . . . . . . . . . . . . . . . . . 5 81 2. The "ietf-tcp-common" Module . . . . . . . . . . . . . . . . 5 82 2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 6 83 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 8 84 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 8 85 3. The "ietf-tcp-client" Module . . . . . . . . . . . . . . . . 11 86 3.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 11 87 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 13 88 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 14 89 4. The "ietf-tcp-server" Module . . . . . . . . . . . . . . . . 21 90 4.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 21 91 4.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 22 92 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 22 93 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 94 5.1. The "ietf-tcp-common" YANG Module . . . . . . . . . . . . 25 95 5.2. The "ietf-tcp-client" YANG Module . . . . . . . . . . . . 26 96 5.3. The "ietf-tcp-server" YANG Module . . . . . . . . . . . . 27 98 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 99 6.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 27 100 6.2. The "YANG Module Names" Registry . . . . . . . . . . . . 28 101 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 102 7.1. Normative References . . . . . . . . . . . . . . . . . . 28 103 7.2. Informative References . . . . . . . . . . . . . . . . . 29 104 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 31 105 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 31 106 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 31 107 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 31 108 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 32 109 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 32 110 A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 32 111 A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 32 112 A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 32 113 A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 32 114 A.10. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 32 115 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 33 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 118 1. Introduction 120 This document defines three YANG 1.1 [RFC7950] modules to support the 121 configuration of TCP clients and TCP servers (TCP is defined in 122 [RFC0793]), either as standalone or in conjunction with configuration 123 of other stack protocol layers. 125 The modules focus on three different types of base TCP parameters 126 that matter for TCP-based applications: First, the modules cover 127 fundamental configuration of a TCP client or TCP server application, 128 such as addresses and port numbers. Second, a reusable grouping 129 enables modification of application-specific parameters for a TCP 130 connections, such as use of TCP keep-alives. And third, client 131 configuration for traversing proxies is included as well. In each 132 case, the modules have a very narrow scope and focus on a minimum set 133 of required parameters. 135 1.1. Relation to other RFCs 137 This document presents one or more YANG modules [RFC7950] that are 138 part of a collection of RFCs that work together to, ultimately, 139 enable the configuration of the clients and servers of both the 140 NETCONF [RFC6241] and RESTCONF [RFC8040] protocols. 142 The modules have been defined in a modular fashion to enable their 143 use by other efforts, some of which are known to be in progress at 144 the time of this writing, with many more expected to be defined in 145 time. 147 The normative dependency relationship between the various RFCs in the 148 collection is presented in the below diagram. The labels in the 149 diagram represent the primary purpose provided by each RFC. 150 Hyperlinks to each RFC are provided below the diagram. 152 crypto-types 153 ^ ^ 154 / \ 155 / \ 156 truststore keystore 157 ^ ^ ^ ^ 158 | +---------+ | | 159 | | | | 160 | +------------+ | 161 tcp-client-server | / | | 162 ^ ^ ssh-client-server | | 163 | | ^ tls-client-server 164 | | | ^ ^ http-client-server 165 | | | | | ^ 166 | | | +-----+ +---------+ | 167 | | | | | | 168 | +-----------|--------|--------------+ | | 169 | | | | | | 170 +-----------+ | | | | | 171 | | | | | | 172 | | | | | | 173 netconf-client-server restconf-client-server 175 +=======================+===========================================+ 176 |Label in Diagram | Originating RFC | 177 +=======================+===========================================+ 178 |crypto-types | [I-D.ietf-netconf-crypto-types] | 179 +-----------------------+-------------------------------------------+ 180 |truststore | [I-D.ietf-netconf-trust-anchors] | 181 +-----------------------+-------------------------------------------+ 182 |keystore | [I-D.ietf-netconf-keystore] | 183 +-----------------------+-------------------------------------------+ 184 |tcp-client-server | [I-D.ietf-netconf-tcp-client-server] | 185 +-----------------------+-------------------------------------------+ 186 |ssh-client-server | [I-D.ietf-netconf-ssh-client-server] | 187 +-----------------------+-------------------------------------------+ 188 |tls-client-server | [I-D.ietf-netconf-tls-client-server] | 189 +-----------------------+-------------------------------------------+ 190 |http-client-server | [I-D.ietf-netconf-http-client-server] | 191 +-----------------------+-------------------------------------------+ 192 |netconf-client-server | [I-D.ietf-netconf-netconf-client-server] | 193 +-----------------------+-------------------------------------------+ 194 |restconf-client-server | [I-D.ietf-netconf-restconf-client-server] | 195 +-----------------------+-------------------------------------------+ 197 Table 1: Label to RFC Mapping 199 1.2. Specification Language 201 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 202 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 203 "OPTIONAL" in this document are to be interpreted as described in BCP 204 14 [RFC2119] [RFC8174] when, and only when, they appear in all 205 capitals, as shown here. 207 1.3. Adherence to the NMDA 209 This document is compliant with the Network Management Datastore 210 Architecture (NMDA) [RFC8342]. It does not define any protocol 211 accessible nodes that are "config false". 213 2. The "ietf-tcp-common" Module 215 This section defines a YANG 1.1 module called "ietf-tcp-common". A 216 high-level overview of the module is provided in Section 2.1. 217 Examples illustrating the module's use are provided in Examples 218 (Section 2.2). The YANG module itself is defined in Section 2.3. 220 2.1. Data Model Overview 222 This section provides an overview of the "ietf-tcp-common" module in 223 terms of its features and groupings. 225 2.1.1. Model Scope 227 This document defines a common "grouping" statement for basic TCP 228 connection parameters that matter to applications. In some TCP 229 stacks, such parameters can also directly be set by an application 230 using system calls, such as the sockets API. The base YANG model in 231 this document focuses on modeling TCP keep-alives. This base model 232 can be extended as needed. 234 2.1.2. Features 236 The following diagram lists all the "feature" statements defined in 237 the "ietf-tcp-common" module: 239 Features: 240 +-- keepalives-supported 242 | The diagram above uses syntax that is similar to but not 243 | defined in [RFC8340]. 245 2.1.3. Groupings 247 The "ietf-tcp-common" module defines the following "grouping" 248 statement: 250 * tcp-common-grouping 252 This grouping is presented in the following subsection. 254 2.1.3.1. The "tcp-common-grouping" Grouping 256 The following tree diagram [RFC8340] illustrates the "tcp-common- 257 grouping" grouping: 259 grouping tcp-common-grouping 260 +-- keepalives! {keepalives-supported}? 261 +-- idle-time uint16 262 +-- max-probes uint16 263 +-- probe-interval uint16 265 Comments: 267 * The "keepalives" node is a "presence" node so that the mandatory 268 descendent nodes do not imply that keepalives must be configured. 270 * The "idle-time", "max-probes", and "probe-interval" nodes have the 271 common meanings. Please see the YANG module in Section 2.3 for 272 details. 274 2.1.4. Protocol-accessible Nodes 276 The "ietf-tcp-common" module defines only "grouping" statements that 277 are used by other modules to instantiate protocol-accessible nodes. 279 2.1.5. Guidelines for Configuring TCP Keep-Alives 281 Network stacks may include "keep-alives" in their TCP 282 implementations, although this practice is not universally accepted. 283 If keep-alives are included, [RFC1122] mandates that the application 284 MUST be able to turn them on or off for each TCP connection, and that 285 they MUST default to off. 287 Keep-alive mechanisms exist in many protocols. Depending on the 288 protocol stack, TCP keep-alives may only be one out of several 289 alternatives. Which mechanism(s) to use depends on the use case and 290 application requirements. If keep-alives are needed by an 291 application, it is RECOMMENDED that the aliveness check happens only 292 at the protocol layers that are meaningful to the application. 294 A TCP keep-alive mechanism SHOULD only be invoked in server 295 applications that might otherwise hang indefinitely and consume 296 resources unnecessarily if a client crashes or aborts a connection 297 during a network failure [RFC1122]. TCP keep-alives may consume 298 significant resources both in the network and in endpoints (e.g., 299 battery power). In addition, frequent keep-alives risk network 300 congestion. The higher the frequency of keep-alives, the higher the 301 overhead. 303 Given the cost of keep-alives, parameters have to be configured 304 carefully: 306 * The default idle interval (leaf "idle-time") MUST default to no 307 less than two hours, i.e., 7200 seconds [RFC1122]. A lower value 308 MAY be configured, but keep-alive messages SHOULD NOT be 309 transmitted more frequently than once every 15 seconds. Longer 310 intervals SHOULD be used when possible. 312 * The maximum number of sequential keep-alive probes that can fail 313 (leaf "max-probes") trades off responsiveness and robustness 314 against packet loss. ACK segments that contain no data are not 315 reliably transmitted by TCP. Consequently, if a keep-alive 316 mechanism is implemented it MUST NOT interpret failure to respond 317 to any specific probe as a dead connection [RFC1122]. Typically a 318 single-digit number should suffice. 320 * TCP implementations may include a parameter for the number of 321 seconds between TCP keep-alive probes (leaf "probe-interval"). In 322 order to avoid congestion, the time interval between probes MUST 323 NOT be smaller than one second. Significantly longer intervals 324 SHOULD be used. It is important to note that keep-alive probes 325 (or replies) can get dropped due to network congestion. Sending 326 further probe messages into a congested path after a short 327 interval, without backing off timers, could cause harm and result 328 in a congestion collapse. Therefore it is essential to pick a 329 large, conservative value for this interval. 331 2.2. Example Usage 333 This section presents an example showing the "tcp-common-grouping" 334 populated with some data. 336 337 338 339 340 15 341 3 342 30 343 344 346 2.3. YANG Module 348 The ietf-tcp-common YANG module references [RFC6991]. 350 file "ietf-tcp-common@2021-05-18.yang" 352 module ietf-tcp-common { 353 yang-version 1.1; 354 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-common"; 355 prefix tcpcmn; 357 organization 358 "IETF NETCONF (Network Configuration) Working Group and the 359 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group"; 361 contact 362 "WG Web: 363 364 WG List: 365 366 Authors: Kent Watsen 367 Michael Scharf 368 "; 370 description 371 "This module defines reusable groupings for TCP commons that 372 can be used as a basis for specific TCP common instances. 374 Copyright (c) 2021 IETF Trust and the persons identified 375 as authors of the code. All rights reserved. 377 Redistribution and use in source and binary forms, with 378 or without modification, is permitted pursuant to, and 379 subject to the license terms contained in, the Simplified 380 BSD License set forth in Section 4.c of the IETF Trust's 381 Legal Provisions Relating to IETF Documents 382 (https://trustee.ietf.org/license-info). 384 This version of this YANG module is part of RFC DDDD 385 (https://www.rfc-editor.org/info/rfcDDDD); see the RFC 386 itself for full legal notices. 388 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 389 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 390 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 391 are to be interpreted as described in BCP 14 (RFC 2119) 392 (RFC 8174) when, and only when, they appear in all 393 capitals, as shown here."; 395 revision 2021-05-18 { 396 description 397 "Initial version"; 398 reference 399 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers"; 400 } 402 // Features 404 feature keepalives-supported { 405 description 406 "Indicates that keepalives are supported."; 407 } 409 // Groupings 410 grouping tcp-common-grouping { 411 description 412 "A reusable grouping for configuring TCP parameters common 413 to TCP connections as well as the operating system as a 414 whole."; 415 container keepalives { 416 if-feature "keepalives-supported"; 417 presence 418 "Indicates that keepalives are enabled. This statement is 419 present so the mandatory descendant nodes do not imply that 420 this node must be configured."; 421 description 422 "Configures the keep-alive policy, to proactively test the 423 aliveness of the TCP peer. An unresponsive TCP peer is 424 dropped after approximately (idle-time + max-probes 425 * probe-interval) seconds."; 426 leaf idle-time { 427 type uint16 { 428 range "1..max"; 429 } 430 units "seconds"; 431 mandatory true; 432 description 433 "Sets the amount of time after which if no data has been 434 received from the TCP peer, a TCP-level probe message 435 will be sent to test the aliveness of the TCP peer. 436 Two hours (7200 seconds) is safe value, per RFC 1122."; 437 reference 438 "RFC 1122: 439 Requirements for Internet Hosts -- Communication Layers"; 440 } 441 leaf max-probes { 442 type uint16 { 443 range "1..max"; 444 } 445 mandatory true; 446 description 447 "Sets the maximum number of sequential keep-alive probes 448 that can fail to obtain a response from the TCP peer 449 before assuming the TCP peer is no longer alive."; 450 } 451 leaf probe-interval { 452 type uint16 { 453 range "1..max"; 454 } 455 units "seconds"; 456 mandatory true; 457 description 458 "Sets the time interval between failed probes. The interval 459 SHOULD be significantly longer than one second in order to 460 avoid harm on a congested link."; 461 } 462 } // container keepalives 463 } // grouping tcp-common-grouping 465 } 467 469 3. The "ietf-tcp-client" Module 471 This section defines a YANG 1.1 module called "ietf-tcp-client". A 472 high-level overview of the module is provided in Section 3.1. 473 Examples illustrating the module's use are provided in Examples 474 (Section 3.2). The YANG module itself is defined in Section 3.3. 476 3.1. Data Model Overview 478 This section provides an overview of the "ietf-tcp-client" module in 479 terms of its features and groupings. 481 3.1.1. Features 483 The following diagram lists all the "feature" statements defined in 484 the "ietf-tcp-client" module: 486 Features: 487 +-- local-binding-supported 488 +-- tcp-client-keepalives 489 +-- proxy-connect 490 +-- socks5-gss-api 491 +-- socks5-username-password 493 | The diagram above uses syntax that is similar to but not 494 | defined in [RFC8340]. 496 3.1.2. Groupings 498 The "ietf-tcp-client" module defines the following "grouping" 499 statement: 501 * tcp-client-grouping 503 This grouping is presented in the following subsection. 505 3.1.2.1. The "tcp-client-grouping" Grouping 507 The following tree diagram [RFC8340] illustrates the "tcp-client- 508 grouping" grouping: 510 grouping tcp-client-grouping 511 +-- remote-address inet:host 512 +-- remote-port? inet:port-number 513 +-- local-address? inet:ip-address 514 | {local-binding-supported}? 515 +-- local-port? inet:port-number 516 | {local-binding-supported}? 517 +-- proxy-server! {proxy-connect}? 518 | +-- (proxy-type) 519 | +--:(socks4) 520 | | +-- socks4-parameters 521 | | +-- remote-address inet:ip-address 522 | | +-- remote-port? inet:port-number 523 | +--:(socks4a) 524 | | +-- socks4a-parameters 525 | | +-- remote-address inet:host 526 | | +-- remote-port? inet:port-number 527 | +--:(socks5) 528 | +-- socks5-parameters 529 | +-- remote-address inet:host 530 | +-- remote-port? inet:port-number 531 | +-- authentication-parameters! 532 | +-- (auth-type) 533 | +--:(gss-api) {socks5-gss-api}? 534 | | +-- gss-api 535 | +--:(username-password) 536 | {socks5-username-password}? 537 | +-- username-password 538 | +-- username string 539 | +---u ct:password-grouping 540 +---u tcpcmn:tcp-common-grouping 542 Comments: 544 * The "remote-address" node, which is mandatory, may be configured 545 as an IPv4 address, an IPv6 address, a hostname. 547 * The "remote-port" node is not mandatory, but its default value is 548 the invalid value '0', thus forcing the consuming data model to 549 refine it in order to provide it an appropriate default value. 551 * The "local-address" node, which is enabled by the "local-binding- 552 supported" feature (Section 2.1.2), may be configured as an IPv4 553 address, an IPv6 address, or a wildcard value. 555 * The "local-port" node, which is enabled by the "local-binding- 556 supported" feature (Section 2.1.2), is not mandatory. Its default 557 value is '0', indicating that the operating system can pick an 558 arbitrary port number. 560 * The "proxy-server" node is enabled by a "feature" statement and, 561 for servers that enable it, is a "presence" container so that the 562 descendent "mandatory true" choice node doesn't imply that the 563 proxy-server node must be configured. 565 * This grouping uses the "tcp-common-grouping" grouping discussed in 566 Section 2.1.3.1. 568 3.1.3. Protocol-accessible Nodes 570 The "ietf-tcp-client" module defines only "grouping" statements that 571 are used by other modules to instantiate protocol-accessible nodes. 573 3.2. Example Usage 575 This section presents two examples showing the "tcp-client-grouping" 576 populated with some data. This example shows a TCP-client configured 577 to not connect via a proxy: 579 580 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 597 598 www.example.com 599 443 600 0.0.0.0 601 0 602 603 604 proxy.my-domain.com 605 1080 606 607 608 foobar 609 secret 610 611 612 613 614 615 15 616 3 617 30 618 619 621 3.3. YANG Module 623 The ietf-tcp-client YANG module references [RFC6991]. 625 file "ietf-tcp-client@2021-05-18.yang" 627 module ietf-tcp-client { 628 yang-version 1.1; 629 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-client"; 630 prefix tcpc; 632 import ietf-inet-types { 633 prefix inet; 634 reference 635 "RFC 6991: Common YANG Data Types"; 636 } 638 import ietf-crypto-types { 639 prefix ct; 640 reference 641 "RFC AAAA: YANG Data Types and Groupings for Cryptography"; 642 } 643 import ietf-tcp-common { 644 prefix tcpcmn; 645 reference 646 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers"; 647 } 649 organization 650 "IETF NETCONF (Network Configuration) Working Group and the 651 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group"; 653 contact 654 "WG Web: 655 656 WG List: 657 658 Authors: Kent Watsen 659 Michael Scharf 660 "; 662 description 663 "This module defines reusable groupings for TCP clients that 664 can be used as a basis for specific TCP client instances. 666 Copyright (c) 2021 IETF Trust and the persons identified 667 as authors of the code. All rights reserved. 669 Redistribution and use in source and binary forms, with 670 or without modification, is permitted pursuant to, and 671 subject to the license terms contained in, the Simplified 672 BSD License set forth in Section 4.c of the IETF Trust's 673 Legal Provisions Relating to IETF Documents 674 (https://trustee.ietf.org/license-info). 676 This version of this YANG module is part of RFC DDDD 677 (https://www.rfc-editor.org/info/rfcDDDD); see the RFC 678 itself for full legal notices. 680 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 681 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 682 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 683 are to be interpreted as described in BCP 14 (RFC 2119) 684 (RFC 8174) when, and only when, they appear in all 685 capitals, as shown here."; 687 revision 2021-05-18 { 688 description 689 "Initial version"; 690 reference 691 "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 using 727 username/password when initiating TCP connections via 728 and SOCKS Version 5 proxy server."; 729 reference 730 "RFC 1928: SOCKS Protocol Version 5"; 731 } 733 // Groupings 735 grouping tcp-client-grouping { 736 description 737 "A reusable grouping for configuring a TCP client. 739 Note that this grouping uses fairly typical descendant 740 node names such that a stack of 'uses' statements will 741 have name conflicts. It is intended that the consuming 742 data model will resolve the issue (e.g., by wrapping 743 the 'uses' statement in a container called 744 'tcp-client-parameters'). This model purposely does 745 not do this itself so as to provide maximum flexibility 746 to consuming models."; 748 leaf remote-address { 749 type inet:host; 750 mandatory true; 751 description 752 "The IP address or hostname of the remote peer to 753 establish a connection with. If a domain name is 754 configured, then the DNS resolution should happen on 755 each connection attempt. If the DNS resolution 756 results in multiple IP addresses, the IP addresses 757 are tried according to local preference order until 758 a connection has been established or until all IP 759 addresses have failed."; 760 } 761 leaf remote-port { 762 type inet:port-number; 763 default "0"; 764 description 765 "The IP port number for the remote peer to establish a 766 connection with. An invalid default value (0) is used 767 (instead of 'mandatory true') so that as application 768 level data model may 'refine' it with an application 769 specific default port number value."; 770 } 771 leaf local-address { 772 if-feature "local-binding-supported"; 773 type inet:ip-address; 774 description 775 "The local IP address/interface (VRF?) to bind to for when 776 connecting to the remote peer. INADDR_ANY ('0.0.0.0') or 777 INADDR6_ANY ('0:0:0:0:0:0:0:0' a.k.a. '::') MAY be used to 778 explicitly indicate the implicit default, that the server 779 can bind to any IPv4 or IPv6 addresses, respectively."; 780 } 781 leaf local-port { 782 if-feature "local-binding-supported"; 783 type inet:port-number; 784 default "0"; 785 description 786 "The local IP port number to bind to for when connecting 787 to the remote peer. The port number '0', which is the 788 default value, indicates that any available local port 789 number may be used."; 790 } 791 container proxy-server { 792 if-feature "proxy-connect"; 793 presence 794 "Indicates that a proxy connection has been configured. 795 Present so that the mandatory descendent nodes do not 796 imply that this node must be configured."; 797 choice proxy-type { 798 mandatory true; 799 description 800 "Selects a proxy connection protocol."; 801 case socks4 { 802 container socks4-parameters { 803 leaf remote-address { 804 type inet:ip-address; 805 mandatory true; 806 description 807 "The IP address of the proxy server."; 808 } 809 leaf remote-port { 810 type inet:port-number; 811 default "1080"; 812 description 813 "The IP port number for the proxy server."; 814 } 815 description 816 "Parameters for connecting to a TCP-based proxy 817 server using the SOCKS4 protocol."; 818 reference 819 "SOCKS, Proceedings: 1992 Usenix Security Symposium."; 820 } 821 } 822 case socks4a { 823 container socks4a-parameters { 824 leaf remote-address { 825 type inet:host; 826 mandatory true; 827 description 828 "The IP address or hostname of the proxy server."; 829 } 830 leaf remote-port { 831 type inet:port-number; 832 default "1080"; 833 description 834 "The IP port number for the proxy server."; 836 } 837 description 838 "Parameters for connecting to a TCP-based proxy 839 server using the SOCKS4a protocol."; 840 reference 841 "SOCKS Proceedings: 842 1992 Usenix Security Symposium. 843 OpenSSH message: 844 SOCKS 4A: A Simple Extension to SOCKS 4 Protocol 845 https://www.openssh.com/txt/socks4a.protocol"; 846 } 847 } 848 case socks5 { 849 container socks5-parameters { 850 leaf remote-address { 851 type inet:host; 852 mandatory true; 853 description 854 "The IP address or hostname of the proxy server."; 855 } 856 leaf remote-port { 857 type inet:port-number; 858 default "1080"; 859 description 860 "The IP port number for the proxy server."; 861 } 862 container authentication-parameters { 863 presence 864 "Indicates that an authentication mechanism 865 has been configured. Present so that the 866 mandatory descendent nodes do not imply that 867 this node must be configured."; 868 description 869 "A container for SOCKS Version 5 authentication 870 mechanisms. 872 A complete list of methods is defined at: 873 https://www.iana.org/assignments/socks-methods 874 /socks-methods.xhtml."; 875 reference 876 "RFC 1928: SOCKS Protocol Version 5"; 877 choice auth-type { 878 mandatory true; 879 description 880 "A choice amongst supported SOCKS Version 5 881 authentication mechanisms."; 882 case gss-api { 883 if-feature "socks5-gss-api"; 884 container gss-api { 885 description 886 "Contains GSS-API configuration. Defines 887 as an empty container to enable specific 888 GSS-API configuration to be augmented in 889 by future modules."; 890 reference 891 "RFC 1928: SOCKS Protocol Version 5 892 RFC 2743: Generic Security Service 893 Application Program Interface 894 Version 2, Update 1"; 895 } 896 } 897 case username-password { 898 if-feature "socks5-username-password"; 899 container username-password { 900 leaf username { 901 type string; 902 mandatory true; 903 description 904 "The 'username' value to use for client 905 identification."; 906 } 907 uses ct:password-grouping { 908 description 909 "The password to be used for client 910 authentication."; 911 } 912 description 913 "Contains Username/Password configuration."; 914 reference 915 "RFC 1929: Username/Password Authentication 916 for SOCKS V5"; 917 } 918 } 919 } 920 } 921 description 922 "Parameters for connecting to a TCP-based proxy server 923 using the SOCKS5 protocol."; 924 reference 925 "RFC 1928: SOCKS Protocol Version 5"; 926 } 927 } 928 } 929 description 930 "Proxy server settings."; 931 } 932 uses tcpcmn:tcp-common-grouping { 933 augment "keepalives" { 934 if-feature "tcp-client-keepalives"; 935 description 936 "Add an if-feature statement so that implementations 937 can choose to support TCP client keepalives."; 938 } 939 } 940 } 941 } 943 945 4. The "ietf-tcp-server" Module 947 This section defines a YANG 1.1 module called "ietf-tcp-server". A 948 high-level overview of the module is provided in Section 4.1. 949 Examples illustrating the module's use are provided in Examples 950 (Section 4.2). The YANG module itself is defined in Section 4.3. 952 4.1. Data Model Overview 954 This section provides an overview of the "ietf-tcp-server" module in 955 terms of its features and groupings. 957 4.1.1. Features 959 The following diagram lists all the "feature" statements defined in 960 the "ietf-tcp-server" module: 962 Features: 963 +-- tcp-server-keepalives 965 | The diagram above uses syntax that is similar to but not 966 | defined in [RFC8340]. 968 4.1.2. Groupings 970 The "ietf-tcp-server" module defines the following "grouping" 971 statement: 973 * tcp-server-grouping 975 This grouping is presented in the following subsection. 977 4.1.2.1. The "tcp-server-grouping" Grouping 979 The following tree diagram [RFC8340] illustrates the "tcp-server- 980 grouping" grouping: 982 grouping tcp-server-grouping 983 +-- local-address inet:ip-address 984 +-- local-port? inet:port-number 985 +---u tcpcmn:tcp-common-grouping 987 Comments: 989 * The "local-address" node, which is mandatory, may be configured as 990 an IPv4 address, an IPv6 address, or a wildcard value. 992 * The "local-port" node is not mandatory, but its default value is 993 the invalid value '0', thus forcing the consuming data model to 994 refine it in order to provide it an appropriate default value. 996 * This grouping uses the "tcp-common-grouping" grouping discussed in 997 Section 2.1.3.1. 999 4.1.3. Protocol-accessible Nodes 1001 The "ietf-tcp-server" module defines only "grouping" statements that 1002 are used by other modules to instantiate protocol-accessible nodes. 1004 4.2. Example Usage 1006 This section presents an example showing the "tcp-server-grouping" 1007 populated with some data. 1009 1010 1011 1012 10.20.30.40 1013 7777 1014 1015 15 1016 3 1017 30 1018 1019 1021 4.3. YANG Module 1023 The ietf-tcp-server YANG module references [RFC6991]. 1025 file "ietf-tcp-server@2021-05-18.yang" 1027 module ietf-tcp-server { 1028 yang-version 1.1; 1029 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-server"; 1030 prefix tcps; 1032 import ietf-inet-types { 1033 prefix inet; 1034 reference 1035 "RFC 6991: Common YANG Data Types"; 1036 } 1038 import ietf-tcp-common { 1039 prefix tcpcmn; 1040 reference 1041 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers"; 1042 } 1044 organization 1045 "IETF NETCONF (Network Configuration) Working Group and the 1046 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group"; 1048 contact 1049 "WG Web: 1050 1051 WG List: 1052 1053 Authors: Kent Watsen 1054 Michael Scharf 1055 "; 1057 description 1058 "This module defines reusable groupings for TCP servers that 1059 can be used as a basis for specific TCP server instances. 1061 Copyright (c) 2021 IETF Trust and the persons identified 1062 as authors of the code. All rights reserved. 1064 Redistribution and use in source and binary forms, with 1065 or without modification, is permitted pursuant to, and 1066 subject to the license terms contained in, the Simplified 1067 BSD License set forth in Section 4.c of the IETF Trust's 1068 Legal Provisions Relating to IETF Documents 1069 (https://trustee.ietf.org/license-info). 1071 This version of this YANG module is part of RFC DDDD 1072 (https://www.rfc-editor.org/info/rfcDDDD); see the RFC 1073 itself for full legal notices. 1075 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1076 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1077 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 1078 are to be interpreted as described in BCP 14 (RFC 2119) 1079 (RFC 8174) when, and only when, they appear in all 1080 capitals, as shown here."; 1082 revision 2021-05-18 { 1083 description 1084 "Initial version"; 1085 reference 1086 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers"; 1087 } 1089 // Features 1091 feature tcp-server-keepalives { 1092 description 1093 "Per socket TCP keepalive parameters are configurable for 1094 TCP servers on the server implementing this feature."; 1095 } 1097 // Groupings 1099 grouping tcp-server-grouping { 1100 description 1101 "A reusable grouping for configuring a TCP server. 1103 Note that this grouping uses fairly typical descendent 1104 node names such that a stack of 'uses' statements will 1105 have name conflicts. It is intended that the consuming 1106 data model will resolve the issue (e.g., by wrapping 1107 the 'uses' statement in a container called 1108 'tcp-server-parameters'). This model purposely does 1109 not do this itself so as to provide maximum flexibility 1110 to consuming models."; 1111 leaf local-address { 1112 type inet:ip-address; 1113 mandatory true; 1114 description 1115 "The local IP address to listen on for incoming 1116 TCP client connections. INADDR_ANY (0.0.0.0) or 1117 INADDR6_ANY (0:0:0:0:0:0:0:0 a.k.a. ::) MUST be 1118 used when the server is to listen on all IPv4 or 1119 IPv6 addresses, respectively."; 1120 } 1121 leaf local-port { 1122 type inet:port-number; 1123 default "0"; 1124 description 1125 "The local port number to listen on for incoming TCP 1126 client connections. An invalid default value (0) 1127 is used (instead of 'mandatory true') so that an 1128 application level data model may 'refine' it with 1129 an application specific default port number value."; 1130 } 1131 uses tcpcmn:tcp-common-grouping { 1132 augment "keepalives" { 1133 if-feature "tcp-server-keepalives"; 1134 description 1135 "Add an if-feature statement so that implementations 1136 can choose to support TCP server keepalives."; 1137 } 1138 } 1139 } 1140 } 1142 1144 5. Security Considerations 1146 5.1. The "ietf-tcp-common" YANG Module 1148 The "ietf-tcp-common" YANG module defines "grouping" statements that 1149 are designed to be accessed via YANG based management protocols, such 1150 as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols 1151 have mandatory-to-implement secure transport layers (e.g., SSH, TLS) 1152 with mutual authentication. 1154 The NETCONF access control model (NACM) [RFC8341] provides the means 1155 to restrict access for particular users to a pre-configured subset of 1156 all available protocol operations and content. 1158 Since the module in this document only define groupings, these 1159 considerations are primarily for the designers of other modules that 1160 use these groupings. 1162 None of the readable data nodes defined in this YANG module are 1163 considered sensitive or vulnerable in network environments. The NACM 1164 "default-deny-all" extension has not been set for any data nodes 1165 defined in this module. 1167 None of the writable data nodes defined in this YANG module are 1168 considered sensitive or vulnerable in network environments. The NACM 1169 "default-deny-write" extension has not been set for any data nodes 1170 defined in this module. 1172 This module does not define any RPCs, actions, or notifications, and 1173 thus the security consideration for such is not provided here. 1175 5.2. The "ietf-tcp-client" YANG Module 1177 The "ietf-tcp-client" YANG module defines "grouping" statements that 1178 are designed to be accessed via YANG based management protocols, such 1179 as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols 1180 have mandatory-to-implement secure transport layers (e.g., SSH, TLS) 1181 with mutual authentication. 1183 The NETCONF access control model (NACM) [RFC8341] provides the means 1184 to restrict access for particular users to a pre-configured subset of 1185 all available protocol operations and content. 1187 Since the module in this document only define groupings, these 1188 considerations are primarily for the designers of other modules that 1189 use these groupings. 1191 One readable data node defined in this YANG module may be considered 1192 sensitive or vulnerable in some network environments. This node is 1193 as follows: 1195 * The "proxy-server/socks5-parameters/authentication-parameters/ 1196 username-password/password" node: 1198 The cleartext "password" node defined in the "tcp-client- 1199 grouping" grouping is additionally sensitive to read operations 1200 such that, in normal use cases, it should never be returned to 1201 a client. For this reason, the NACM extension "default-deny- 1202 all" has been applied to it. 1204 None of the writable data nodes defined in this YANG module are 1205 considered sensitive or vulnerable in network environments. The NACM 1206 "default-deny-write" extension has not been set for any data nodes 1207 defined in this module. 1209 This module does not define any RPCs, actions, or notifications, and 1210 thus the security consideration for such is not provided here. 1212 Implementations are RECOMMENDED to implement the "local-binding- 1213 supported" feature for cryptographically-secure protocols, so as to 1214 enable more granular ingress/egress firewall rulebases. It is NOT 1215 RECOMMENDED to implement this feature for unsecure protocols, as per 1216 [RFC6056]. 1218 5.3. The "ietf-tcp-server" YANG Module 1220 The "ietf-tcp-server" YANG module defines "grouping" statements that 1221 are designed to be accessed via YANG based management protocols, such 1222 as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols 1223 have mandatory-to-implement secure transport layers (e.g., SSH, TLS) 1224 with mutual authentication. 1226 The NETCONF access control model (NACM) [RFC8341] provides the means 1227 to restrict access for particular users to a pre-configured subset of 1228 all available protocol operations and content. 1230 Since the module in this document only define groupings, these 1231 considerations are primarily for the designers of other modules that 1232 use these groupings. 1234 None of the readable data nodes defined in this YANG module are 1235 considered sensitive or vulnerable in network environments. The NACM 1236 "default-deny-all" extension has not been set for any data nodes 1237 defined in this module. 1239 None of the writable data nodes defined in this YANG module are 1240 considered sensitive or vulnerable in network environments. The NACM 1241 "default-deny-write" extension has not been set for any data nodes 1242 defined in this module. 1244 This module does not define any RPCs, actions, or notifications, and 1245 thus the security consideration for such is not provided here. 1247 6. IANA Considerations 1249 6.1. The "IETF XML" Registry 1251 This document registers two URIs in the "ns" subregistry of the IETF 1252 XML Registry [RFC3688]. Following the format in [RFC3688], the 1253 following registrations are requested: 1255 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-common 1256 Registrant Contact: The IESG 1257 XML: N/A, the requested URI is an XML namespace. 1259 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-client 1260 Registrant Contact: The IESG 1261 XML: N/A, the requested URI is an XML namespace. 1263 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-server 1264 Registrant Contact: The IESG 1265 XML: N/A, the requested URI is an XML namespace. 1267 6.2. The "YANG Module Names" Registry 1269 This document registers two YANG modules in the YANG Module Names 1270 registry [RFC6020]. Following the format in [RFC6020], the following 1271 registrations are requested: 1273 name: ietf-tcp-common 1274 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-common 1275 prefix: tcpcmn 1276 reference: RFC DDDD 1278 name: ietf-tcp-client 1279 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-client 1280 prefix: tcpc 1281 reference: RFC DDDD 1283 name: ietf-tcp-server 1284 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-server 1285 prefix: tcps 1286 reference: RFC DDDD 1288 7. References 1290 7.1. Normative References 1292 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1293 Requirement Levels", BCP 14, RFC 2119, 1294 DOI 10.17487/RFC2119, March 1997, 1295 . 1297 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1298 the Network Configuration Protocol (NETCONF)", RFC 6020, 1299 DOI 10.17487/RFC6020, October 2010, 1300 . 1302 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1303 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1304 . 1306 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1307 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1308 . 1310 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1311 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1312 May 2017, . 1314 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1315 Access Control Model", STD 91, RFC 8341, 1316 DOI 10.17487/RFC8341, March 2018, 1317 . 1319 7.2. Informative References 1321 [I-D.ietf-netconf-crypto-types] 1322 Watsen, K., "YANG Data Types and Groupings for 1323 Cryptography", Work in Progress, Internet-Draft, draft- 1324 ietf-netconf-crypto-types-19, 10 February 2021, 1325 . 1328 [I-D.ietf-netconf-http-client-server] 1329 Watsen, K., "YANG Groupings for HTTP Clients and HTTP 1330 Servers", Work in Progress, Internet-Draft, draft-ietf- 1331 netconf-http-client-server-06, 10 February 2021, 1332 . 1335 [I-D.ietf-netconf-keystore] 1336 Watsen, K., "A YANG Data Model for a Keystore", Work in 1337 Progress, Internet-Draft, draft-ietf-netconf-keystore-21, 1338 10 February 2021, . 1341 [I-D.ietf-netconf-netconf-client-server] 1342 Watsen, K., "NETCONF Client and Server Models", Work in 1343 Progress, Internet-Draft, draft-ietf-netconf-netconf- 1344 client-server-22, 10 February 2021, 1345 . 1348 [I-D.ietf-netconf-restconf-client-server] 1349 Watsen, K., "RESTCONF Client and Server Models", Work in 1350 Progress, Internet-Draft, draft-ietf-netconf-restconf- 1351 client-server-22, 10 February 2021, 1352 . 1355 [I-D.ietf-netconf-ssh-client-server] 1356 Watsen, K., "YANG Groupings for SSH Clients and SSH 1357 Servers", Work in Progress, Internet-Draft, draft-ietf- 1358 netconf-ssh-client-server-23, 10 February 2021, 1359 . 1362 [I-D.ietf-netconf-tcp-client-server] 1363 Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients 1364 and TCP Servers", Work in Progress, Internet-Draft, draft- 1365 ietf-netconf-tcp-client-server-09, 10 February 2021, 1366 . 1369 [I-D.ietf-netconf-tls-client-server] 1370 Watsen, K., "YANG Groupings for TLS Clients and TLS 1371 Servers", Work in Progress, Internet-Draft, draft-ietf- 1372 netconf-tls-client-server-23, 10 February 2021, 1373 . 1376 [I-D.ietf-netconf-trust-anchors] 1377 Watsen, K., "A YANG Data Model for a Truststore", Work in 1378 Progress, Internet-Draft, draft-ietf-netconf-trust- 1379 anchors-14, 10 February 2021, 1380 . 1383 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1384 RFC 793, DOI 10.17487/RFC0793, September 1981, 1385 . 1387 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1388 Communication Layers", STD 3, RFC 1122, 1389 DOI 10.17487/RFC1122, October 1989, 1390 . 1392 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1393 DOI 10.17487/RFC3688, January 2004, 1394 . 1396 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 1397 Protocol Port Randomization", BCP 156, RFC 6056, 1398 DOI 10.17487/RFC6056, January 2011, 1399 . 1401 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1402 and A. Bierman, Ed., "Network Configuration Protocol 1403 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1404 . 1406 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1407 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1408 . 1410 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1411 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1412 . 1414 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1415 and R. Wilton, "Network Management Datastore Architecture 1416 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1417 . 1419 Appendix A. Change Log 1421 This section is to be removed before publishing as an RFC. 1423 A.1. 00 to 01 1425 * Added 'local-binding-supported' feature to TCP-client model. 1427 * Added 'keepalives-supported' feature to TCP-common model. 1429 * Added 'external-endpoint-values' container and 'external- 1430 endpoints' feature to TCP-server model. 1432 A.2. 01 to 02 1434 * Removed the 'external-endpoint-values' container and 'external- 1435 endpoints' feature from the TCP-server model. 1437 A.3. 02 to 03 1439 * Moved the common model section to be before the client and server 1440 specific sections. 1442 * Added sections "Model Scope" and "Usage Guidelines for Configuring 1443 TCP Keep-Alives" to the common model section. 1445 A.4. 03 to 04 1447 * Fixed a few typos. 1449 A.5. 04 to 05 1451 * Removed commented out "grouping tcp-system-grouping" statement 1452 kept for reviewers. 1454 * Added a "Note to Reviewers" note to first page. 1456 A.6. 05 to 06 1458 * Added support for TCP proxies. 1460 A.7. 06 to 07 1462 * Expanded "Data Model Overview section(s) [remove "wall" of tree 1463 diagrams]. 1465 * Updated the Security Considerations section. 1467 A.8. 07 to 08 1469 * Added missing IANA registration for "ietf-tcp-common" 1471 * Added "mandatory true" for the "username" and "password" leafs 1473 * Added an example of a TCP-client configured to connect via a proxy 1475 * Fixed issues found by the SecDir review of the "keystore" draft. 1477 * Updated the "ietf-tcp-client" module to use the new "password- 1478 grouping" grouping from the "crypto-types" module. 1480 A.9. 08 to 09 1482 * Addressed comments raised by YANG Doctor in the ct/ts/ks drafts. 1484 A.10. 09 to 10 1486 * Updated Abstract and Intro to address comments by Tom Petch. 1488 * Removed the "tcp-connection-grouping" grouping (now models use the 1489 "tcp-common-grouping" directly). 1491 * Added XML-comment above examples explaining the reason for the 1492 unusual top-most element's presence. 1494 * Added Securty Considerations section for the "local-binding- 1495 supported" feature. 1497 * Replaced some hardcoded refs to elements. 1499 * Fixed nits found by YANG Doctor reviews. 1501 * Aligned modules with `pyang -f` formatting. 1503 * Added an "Acknowledgements" secetion. 1505 Acknowledgements 1507 The authors would like to thank for following for lively discussions 1508 on list and in the halls (ordered by first name): Juergen 1509 Schoenwaelder, Ladislav Lhotka, Nick Hancock, and Tom Petch. 1511 Authors' Addresses 1513 Kent Watsen 1514 Watsen Networks 1516 Email: kent+ietf@watsen.net 1518 Michael Scharf 1519 Hochschule Esslingen - University of Applied Sciences 1521 Email: michael.scharf@hs-esslingen.de