idnits 2.17.1 draft-ietf-netconf-tcp-client-server-12.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 273 has weird spacing: '...nterval uin...' == Line 533 has weird spacing: '...address ine...' == Line 537 has weird spacing: '...address ine...' -- The document date (7 March 2022) is 780 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-21 == Outdated reference: A later version (-20) exists of draft-ietf-netconf-http-client-server-08 == Outdated reference: A later version (-35) exists of draft-ietf-netconf-keystore-23 == Outdated reference: A later version (-36) exists of draft-ietf-netconf-netconf-client-server-24 == Outdated reference: A later version (-36) exists of draft-ietf-netconf-restconf-client-server-24 == Outdated reference: A later version (-40) exists of draft-ietf-netconf-ssh-client-server-26 == Outdated reference: A later version (-26) exists of draft-ietf-netconf-tcp-client-server-11 == Outdated reference: A later version (-41) exists of draft-ietf-netconf-tls-client-server-26 == Outdated reference: A later version (-28) exists of draft-ietf-netconf-trust-anchors-16 -- 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: 8 September 2022 Hochschule Esslingen 6 7 March 2022 8 YANG Groupings for TCP Clients and TCP Servers 9 draft-ietf-netconf-tcp-client-server-12 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 * 2022-03-07 --> 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 8 September 2022. 61 Copyright Notice 63 Copyright (c) 2022 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 Revised BSD License text as 72 described in Section 4.e of the Trust Legal Provisions and are 73 provided without warranty as described in the Revised 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 1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 82 2. The "ietf-tcp-common" Module . . . . . . . . . . . . . . . . 6 83 2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 6 84 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 8 85 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 8 86 3. The "ietf-tcp-client" Module . . . . . . . . . . . . . . . . 11 87 3.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 11 88 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 13 89 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 14 90 4. The "ietf-tcp-server" Module . . . . . . . . . . . . . . . . 21 91 4.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 21 92 4.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 23 93 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 23 94 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 95 5.1. The "ietf-tcp-common" YANG Module . . . . . . . . . . . . 26 96 5.2. The "ietf-tcp-client" YANG Module . . . . . . . . . . . . 26 97 5.3. The "ietf-tcp-server" YANG Module . . . . . . . . . . . . 27 98 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 99 6.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 28 100 6.2. The "YANG Module Names" Registry . . . . . . . . . . . . 28 101 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 102 7.1. Normative References . . . . . . . . . . . . . . . . . . 29 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 . . . . . . . . . . . . . . . . . . . . . . . . 32 107 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 32 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 . . . . . . . . . . . . . . . . . . . . . . . . 33 114 A.10. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 33 115 A.11. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 33 116 A.12. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 33 117 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 33 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 120 1. Introduction 122 This document defines three YANG 1.1 [RFC7950] modules to support the 123 configuration of TCP clients and TCP servers (TCP is defined in 124 [RFC0793]), either as standalone or in conjunction with configuration 125 of other stack protocol layers. 127 The modules focus on three different types of base TCP parameters 128 that matter for TCP-based applications: First, the modules cover 129 fundamental configuration of a TCP client or TCP server application, 130 such as addresses and port numbers. Second, a reusable grouping 131 enables modification of application-specific parameters for a TCP 132 connections, such as use of TCP keep-alives. And third, client 133 configuration for traversing proxies is included as well. In each 134 case, the modules have a very narrow scope and focus on a minimum set 135 of required parameters. 137 1.1. Relation to other RFCs 139 This document presents one or more YANG modules [RFC7950] that are 140 part of a collection of RFCs that work together to, ultimately, 141 enable the configuration of the clients and servers of both the 142 NETCONF [RFC6241] and RESTCONF [RFC8040] protocols. 144 The modules have been defined in a modular fashion to enable their 145 use by other efforts, some of which are known to be in progress at 146 the time of this writing, with many more expected to be defined in 147 time. 149 The normative dependency relationship between the various RFCs in the 150 collection is presented in the below diagram. The labels in the 151 diagram represent the primary purpose provided by each RFC. 152 Hyperlinks to each RFC are provided below the diagram. 154 crypto-types 155 ^ ^ 156 / \ 157 / \ 158 truststore keystore 159 ^ ^ ^ ^ 160 | +---------+ | | 161 | | | | 162 | +------------+ | 163 tcp-client-server | / | | 164 ^ ^ ssh-client-server | | 165 | | ^ tls-client-server 166 | | | ^ ^ http-client-server 167 | | | | | ^ 168 | | | +-----+ +---------+ | 169 | | | | | | 170 | +-----------|--------|--------------+ | | 171 | | | | | | 172 +-----------+ | | | | | 173 | | | | | | 174 | | | | | | 175 netconf-client-server restconf-client-server 177 +=======================+===========================================+ 178 |Label in Diagram | Originating RFC | 179 +=======================+===========================================+ 180 |crypto-types | [I-D.ietf-netconf-crypto-types] | 181 +-----------------------+-------------------------------------------+ 182 |truststore | [I-D.ietf-netconf-trust-anchors] | 183 +-----------------------+-------------------------------------------+ 184 |keystore | [I-D.ietf-netconf-keystore] | 185 +-----------------------+-------------------------------------------+ 186 |tcp-client-server | [I-D.ietf-netconf-tcp-client-server] | 187 +-----------------------+-------------------------------------------+ 188 |ssh-client-server | [I-D.ietf-netconf-ssh-client-server] | 189 +-----------------------+-------------------------------------------+ 190 |tls-client-server | [I-D.ietf-netconf-tls-client-server] | 191 +-----------------------+-------------------------------------------+ 192 |http-client-server | [I-D.ietf-netconf-http-client-server] | 193 +-----------------------+-------------------------------------------+ 194 |netconf-client-server | [I-D.ietf-netconf-netconf-client-server] | 195 +-----------------------+-------------------------------------------+ 196 |restconf-client-server | [I-D.ietf-netconf-restconf-client-server] | 197 +-----------------------+-------------------------------------------+ 199 Table 1: Label to RFC Mapping 201 1.2. Specification Language 203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 205 "OPTIONAL" in this document are to be interpreted as described in BCP 206 14 [RFC2119] [RFC8174] when, and only when, they appear in all 207 capitals, as shown here. 209 1.3. Adherence to the NMDA 211 This document is compliant with the Network Management Datastore 212 Architecture (NMDA) [RFC8342]. It does not define any protocol 213 accessible nodes that are "config false". 215 1.4. Conventions 217 Various examples used in this document use a placeholder value for 218 binary data that has been base64 encoded (e.g., "BASE64VALUE="). 219 This placeholder value is used as real base64 encoded structures are 220 often many lines long and hence distracting to the example being 221 presented. 223 2. The "ietf-tcp-common" Module 225 This section defines a YANG 1.1 module called "ietf-tcp-common". A 226 high-level overview of the module is provided in Section 2.1. 227 Examples illustrating the module's use are provided in Examples 228 (Section 2.2). The YANG module itself is defined in Section 2.3. 230 2.1. Data Model Overview 232 This section provides an overview of the "ietf-tcp-common" module in 233 terms of its features and groupings. 235 2.1.1. Model Scope 237 This document defines a common "grouping" statement for basic TCP 238 connection parameters that matter to applications. In some TCP 239 stacks, such parameters can also directly be set by an application 240 using system calls, such as the sockets API. The base YANG model in 241 this document focuses on modeling TCP keep-alives. This base model 242 can be extended as needed. 244 2.1.2. Features 246 The following diagram lists all the "feature" statements defined in 247 the "ietf-tcp-common" module: 249 Features: 250 +-- keepalives-supported 252 | The diagram above uses syntax that is similar to but not 253 | defined in [RFC8340]. 255 2.1.3. Groupings 257 The "ietf-tcp-common" module defines the following "grouping" 258 statement: 260 * tcp-common-grouping 262 This grouping is presented in the following subsection. 264 2.1.3.1. The "tcp-common-grouping" Grouping 266 The following tree diagram [RFC8340] illustrates the "tcp-common- 267 grouping" grouping: 269 grouping tcp-common-grouping 270 +-- keepalives! {keepalives-supported}? 271 +-- idle-time uint16 272 +-- max-probes uint16 273 +-- probe-interval uint16 275 Comments: 277 * The "keepalives" node is a "presence" node so that the mandatory 278 descendant nodes do not imply that keepalives must be configured. 280 * The "idle-time", "max-probes", and "probe-interval" nodes have the 281 common meanings. Please see the YANG module in Section 2.3 for 282 details. 284 2.1.4. Protocol-accessible Nodes 286 The "ietf-tcp-common" module defines only "grouping" statements that 287 are used by other modules to instantiate protocol-accessible nodes. 289 2.1.5. Guidelines for Configuring TCP Keep-Alives 291 Network stacks may include "keep-alives" in their TCP 292 implementations, although this practice is not universally accepted. 293 If keep-alives are included, [RFC1122] mandates that the application 294 MUST be able to turn them on or off for each TCP connection, and that 295 they MUST default to off. 297 Keep-alive mechanisms exist in many protocols. Depending on the 298 protocol stack, TCP keep-alives may only be one out of several 299 alternatives. Which mechanism(s) to use depends on the use case and 300 application requirements. If keep-alives are needed by an 301 application, it is RECOMMENDED that the aliveness check happens only 302 at the protocol layers that are meaningful to the application. 304 A TCP keep-alive mechanism SHOULD only be invoked in server 305 applications that might otherwise hang indefinitely and consume 306 resources unnecessarily if a client crashes or aborts a connection 307 during a network failure [RFC1122]. TCP keep-alives may consume 308 significant resources both in the network and in endpoints (e.g., 309 battery power). In addition, frequent keep-alives risk network 310 congestion. The higher the frequency of keep-alives, the higher the 311 overhead. 313 Given the cost of keep-alives, parameters have to be configured 314 carefully: 316 * The default idle interval (leaf "idle-time") MUST default to no 317 less than two hours, i.e., 7200 seconds [RFC1122]. A lower value 318 MAY be configured, but keep-alive messages SHOULD NOT be 319 transmitted more frequently than once every 15 seconds. Longer 320 intervals SHOULD be used when possible. 322 * The maximum number of sequential keep-alive probes that can fail 323 (leaf "max-probes") trades off responsiveness and robustness 324 against packet loss. ACK segments that contain no data are not 325 reliably transmitted by TCP. Consequently, if a keep-alive 326 mechanism is implemented it MUST NOT interpret failure to respond 327 to any specific probe as a dead connection [RFC1122]. Typically, 328 a single-digit number should suffice. 330 * TCP implementations may include a parameter for the number of 331 seconds between TCP keep-alive probes (leaf "probe-interval"). In 332 order to avoid congestion, the time interval between probes MUST 333 NOT be smaller than one second. Significantly longer intervals 334 SHOULD be used. It is important to note that keep-alive probes 335 (or replies) can get dropped due to network congestion. Sending 336 further probe messages into a congested path after a short 337 interval, without backing off timers, could cause harm and result 338 in a congestion collapse. Therefore it is essential to pick a 339 large, conservative value for this interval. 341 2.2. Example Usage 343 This section presents an example showing the "tcp-common-grouping" 344 populated with some data. 346 347 349 350 351 15 352 3 353 30 354 355 357 2.3. YANG Module 359 The ietf-tcp-common YANG module references [RFC6991]. 361 file "ietf-tcp-common@2022-03-07.yang" 362 module ietf-tcp-common { 363 yang-version 1.1; 364 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-common"; 365 prefix tcpcmn; 367 organization 368 "IETF NETCONF (Network Configuration) Working Group and the 369 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group"; 371 contact 372 "WG Web: https://datatracker.ietf.org/wg/netconf 373 https://datatracker.ietf.org/wg/tcpm 374 WG List: NETCONF WG list 375 TCPM WG list 376 Authors: Kent Watsen 377 Michael Scharf 378 "; 380 description 381 "This module defines reusable groupings for TCP commons that 382 can be used as a basis for specific TCP common instances. 384 Copyright (c) 2021 IETF Trust and the persons identified 385 as authors of the code. All rights reserved. 387 Redistribution and use in source and binary forms, with 388 or without modification, is permitted pursuant to, and 389 subject to the license terms contained in, the Revised 390 BSD License set forth in Section 4.c of the IETF Trust's 391 Legal Provisions Relating to IETF Documents 392 (https://trustee.ietf.org/license-info). 394 This version of this YANG module is part of RFC DDDD 395 (https://www.rfc-editor.org/info/rfcDDDD); see the RFC 396 itself for full legal notices. 398 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 399 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 400 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 401 are to be interpreted as described in BCP 14 (RFC 2119) 402 (RFC 8174) when, and only when, they appear in all 403 capitals, as shown here."; 405 revision 2022-03-07 { 406 description 407 "Initial version"; 408 reference 409 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers"; 411 } 413 // Features 415 feature keepalives-supported { 416 description 417 "Indicates that keepalives are supported."; 418 } 420 // Groupings 422 grouping tcp-common-grouping { 423 description 424 "A reusable grouping for configuring TCP parameters common 425 to TCP connections as well as the operating system as a 426 whole."; 427 container keepalives { 428 if-feature "keepalives-supported"; 429 presence 430 "Indicates that keepalives are enabled. This statement is 431 present so the mandatory descendant nodes do not imply that 432 this node must be configured."; 433 description 434 "Configures the keep-alive policy, to proactively test the 435 aliveness of the TCP peer. An unresponsive TCP peer is 436 dropped after approximately (idle-time + max-probes 437 * probe-interval) seconds."; 438 leaf idle-time { 439 type uint16 { 440 range "1..max"; 441 } 442 units "seconds"; 443 mandatory true; 444 description 445 "Sets the amount of time after which if no data has been 446 received from the TCP peer, a TCP-level probe message 447 will be sent to test the aliveness of the TCP peer. 448 Two hours (7200 seconds) is safe value, per RFC 1122."; 449 reference 450 "RFC 1122: 451 Requirements for Internet Hosts -- Communication Layers"; 452 } 453 leaf max-probes { 454 type uint16 { 455 range "1..max"; 456 } 457 mandatory true; 458 description 459 "Sets the maximum number of sequential keep-alive probes 460 that can fail to obtain a response from the TCP peer 461 before assuming the TCP peer is no longer alive."; 462 } 463 leaf probe-interval { 464 type uint16 { 465 range "1..max"; 466 } 467 units "seconds"; 468 mandatory true; 469 description 470 "Sets the time interval between failed probes. The interval 471 SHOULD be significantly longer than one second in order to 472 avoid harm on a congested link."; 473 } 474 } // container keepalives 475 } // grouping tcp-common-grouping 477 } 479 481 3. The "ietf-tcp-client" Module 483 This section defines a YANG 1.1 module called "ietf-tcp-client". A 484 high-level overview of the module is provided in Section 3.1. 485 Examples illustrating the module's use are provided in Examples 486 (Section 3.2). The YANG module itself is defined in Section 3.3. 488 3.1. Data Model Overview 490 This section provides an overview of the "ietf-tcp-client" module in 491 terms of its features and groupings. 493 3.1.1. Features 495 The following diagram lists all the "feature" statements defined in 496 the "ietf-tcp-client" module: 498 Features: 499 +-- local-binding-supported 500 +-- tcp-client-keepalives 501 +-- proxy-connect 502 +-- socks5-gss-api 503 +-- socks5-username-password 505 | The diagram above uses syntax that is similar to but not 506 | defined in [RFC8340]. 508 3.1.2. Groupings 510 The "ietf-tcp-client" module defines the following "grouping" 511 statement: 513 * tcp-client-grouping 515 This grouping is presented in the following subsection. 517 3.1.2.1. The "tcp-client-grouping" Grouping 519 The following tree diagram [RFC8340] illustrates the "tcp-client- 520 grouping" grouping: 522 grouping tcp-client-grouping 523 +-- remote-address inet:host 524 +-- remote-port? inet:port-number 525 +-- local-address? inet:ip-address 526 | {local-binding-supported}? 527 +-- local-port? inet:port-number 528 | {local-binding-supported}? 529 +-- proxy-server! {proxy-connect}? 530 | +-- (proxy-type) 531 | +--:(socks4) 532 | | +-- socks4-parameters 533 | | +-- remote-address inet:ip-address 534 | | +-- remote-port? inet:port-number 535 | +--:(socks4a) 536 | | +-- socks4a-parameters 537 | | +-- remote-address inet:host 538 | | +-- remote-port? inet:port-number 539 | +--:(socks5) 540 | +-- socks5-parameters 541 | +-- remote-address inet:host 542 | +-- remote-port? inet:port-number 543 | +-- authentication-parameters! 544 | +-- (auth-type) 545 | +--:(gss-api) {socks5-gss-api}? 546 | | +-- gss-api 547 | +--:(username-password) 548 | {socks5-username-password}? 549 | +-- username-password 550 | +-- username string 551 | +---u ct:password-grouping 552 +---u tcpcmn:tcp-common-grouping 554 Comments: 556 * The "remote-address" node, which is mandatory, may be configured 557 as an IPv4 address, an IPv6 address, a hostname. 559 * The "remote-port" node is not mandatory, but its default value is 560 the invalid value '0', thus forcing the consuming data model to 561 refine it in order to provide it an appropriate default value. 563 * The "local-address" node, which is enabled by the "local-binding- 564 supported" feature (Section 2.1.2), may be configured as an IPv4 565 address, an IPv6 address, or a wildcard value. 567 * The "local-port" node, which is enabled by the "local-binding- 568 supported" feature (Section 2.1.2), is not mandatory. Its default 569 value is '0', indicating that the operating system can pick an 570 arbitrary port number. 572 * The "proxy-server" node is enabled by a "feature" statement and, 573 for servers that enable it, is a "presence" container so that the 574 descendant "mandatory true" choice node does not imply that the 575 proxy-server node must be configured. 577 * This grouping uses the "tcp-common-grouping" grouping discussed in 578 Section 2.1.3.1. 580 3.1.3. Protocol-accessible Nodes 582 The "ietf-tcp-client" module defines only "grouping" statements that 583 are used by other modules to instantiate protocol-accessible nodes. 585 3.2. Example Usage 587 This section presents two examples showing the "tcp-client-grouping" 588 populated with some data. This example shows a TCP-client configured 589 to not connect via a proxy: 591 592 594 595 www.example.com 596 443 597 0.0.0.0 598 0 599 600 15 601 3 602 30 603 604 606 This example shows a TCP-client configured to connect via a proxy: 608 609 611 612 www.example.com 613 443 614 0.0.0.0 615 0 616 617 618 proxy.my-domain.com 619 1080 620 621 622 foobar 623 secret 624 625 626 627 628 629 15 630 3 631 30 632 633 635 3.3. YANG Module 637 The ietf-tcp-client YANG module references [RFC6991]. 639 file "ietf-tcp-client@2022-03-07.yang" 641 module ietf-tcp-client { 642 yang-version 1.1; 643 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-client"; 644 prefix tcpc; 646 import ietf-inet-types { 647 prefix inet; 648 reference 649 "RFC 6991: Common YANG Data Types"; 650 } 652 import ietf-crypto-types { 653 prefix ct; 654 reference 655 "RFC AAAA: YANG Data Types and Groupings for Cryptography"; 656 } 658 import ietf-tcp-common { 659 prefix tcpcmn; 660 reference 661 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers"; 662 } 664 organization 665 "IETF NETCONF (Network Configuration) Working Group and the 666 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group"; 668 contact 669 "WG Web: https://datatracker.ietf.org/wg/netconf 670 https://datatracker.ietf.org/wg/tcpm 671 WG List: NETCONF WG list 672 TCPM WG list 673 Authors: Kent Watsen 674 Michael Scharf 675 "; 677 description 678 "This module defines reusable groupings for TCP clients that 679 can be used as a basis for specific TCP client instances. 681 Copyright (c) 2021 IETF Trust and the persons identified 682 as authors of the code. All rights reserved. 684 Redistribution and use in source and binary forms, with 685 or without modification, is permitted pursuant to, and 686 subject to the license terms contained in, the Revised 687 BSD License set forth in Section 4.c of the IETF Trust's 688 Legal Provisions Relating to IETF Documents 689 (https://trustee.ietf.org/license-info). 691 This version of this YANG module is part of RFC DDDD 692 (https://www.rfc-editor.org/info/rfcDDDD); see the RFC 693 itself for full legal notices. 695 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 696 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 697 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 698 are to be interpreted as described in BCP 14 (RFC 2119) 699 (RFC 8174) when, and only when, they appear in all 700 capitals, as shown here."; 702 revision 2022-03-07 { 703 description 704 "Initial version"; 705 reference 706 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers"; 707 } 709 // Features 711 feature local-binding-supported { 712 description 713 "Indicates that the server supports configuring local 714 bindings (i.e., the local address and local port) for 715 TCP clients."; 716 } 718 feature tcp-client-keepalives { 719 description 720 "Per socket TCP keepalive parameters are configurable for 721 TCP clients on the server implementing this feature."; 722 } 724 feature proxy-connect { 725 description 726 "Proxy connection configuration is configurable for 727 TCP clients on the server implementing this feature."; 728 } 730 feature socks5-gss-api { 731 description 732 "Indicates that the server supports authenticating 733 using GSSAPI when initiating TCP connections via 734 and SOCKS Version 5 proxy server."; 736 reference 737 "RFC 1928: SOCKS Protocol Version 5"; 738 } 740 feature socks5-username-password { 741 description 742 "Indicates that the server supports authenticating using 743 username/password when initiating TCP connections via 744 and SOCKS Version 5 proxy server."; 745 reference 746 "RFC 1928: SOCKS Protocol Version 5"; 747 } 749 // Groupings 751 grouping tcp-client-grouping { 752 description 753 "A reusable grouping for configuring a TCP client. 755 Note that this grouping uses fairly typical descendant 756 node names such that a stack of 'uses' statements will 757 have name conflicts. It is intended that the consuming 758 data model will resolve the issue (e.g., by wrapping 759 the 'uses' statement in a container called 760 'tcp-client-parameters'). This model purposely does 761 not do this itself so as to provide maximum flexibility 762 to consuming models."; 764 leaf remote-address { 765 type inet:host; 766 mandatory true; 767 description 768 "The IP address or hostname of the remote peer to 769 establish a connection with. If a domain name is 770 configured, then the DNS resolution should happen on 771 each connection attempt. If the DNS resolution 772 results in multiple IP addresses, the IP addresses 773 are tried according to local preference order until 774 a connection has been established or until all IP 775 addresses have failed."; 776 } 777 leaf remote-port { 778 type inet:port-number; 779 default "0"; 780 description 781 "The IP port number for the remote peer to establish a 782 connection with. An invalid default value (0) is used 783 (instead of 'mandatory true') so that as application 784 level data model may 'refine' it with an application 785 specific default port number value."; 786 } 787 leaf local-address { 788 if-feature "local-binding-supported"; 789 type inet:ip-address; 790 description 791 "The local IP address/interface (VRF?) to bind to for when 792 connecting to the remote peer. INADDR_ANY ('0.0.0.0') or 793 INADDR6_ANY ('0:0:0:0:0:0:0:0' a.k.a. '::') MAY be used to 794 explicitly indicate the implicit default, that the server 795 can bind to any IPv4 or IPv6 addresses, respectively."; 796 } 797 leaf local-port { 798 if-feature "local-binding-supported"; 799 type inet:port-number; 800 default "0"; 801 description 802 "The local IP port number to bind to for when connecting 803 to the remote peer. The port number '0', which is the 804 default value, indicates that any available local port 805 number may be used."; 806 } 807 container proxy-server { 808 if-feature "proxy-connect"; 809 presence 810 "Indicates that a proxy connection has been configured. 811 Present so that the mandatory descendant nodes do not 812 imply that this node must be configured."; 813 choice proxy-type { 814 mandatory true; 815 description 816 "Selects a proxy connection protocol."; 817 case socks4 { 818 container socks4-parameters { 819 leaf remote-address { 820 type inet:ip-address; 821 mandatory true; 822 description 823 "The IP address of the proxy server."; 824 } 825 leaf remote-port { 826 type inet:port-number; 827 default "1080"; 828 description 829 "The IP port number for the proxy server."; 830 } 831 description 832 "Parameters for connecting to a TCP-based proxy 833 server using the SOCKS4 protocol."; 834 reference 835 "SOCKS, Proceedings: 1992 Usenix Security Symposium."; 836 } 837 } 838 case socks4a { 839 container socks4a-parameters { 840 leaf remote-address { 841 type inet:host; 842 mandatory true; 843 description 844 "The IP address or hostname of the proxy server."; 845 } 846 leaf remote-port { 847 type inet:port-number; 848 default "1080"; 849 description 850 "The IP port number for the proxy server."; 851 } 852 description 853 "Parameters for connecting to a TCP-based proxy 854 server using the SOCKS4a protocol."; 855 reference 856 "SOCKS Proceedings: 857 1992 Usenix Security Symposium. 858 OpenSSH message: 859 SOCKS 4A: A Simple Extension to SOCKS 4 Protocol 860 https://www.openssh.com/txt/socks4a.protocol"; 861 } 862 } 863 case socks5 { 864 container socks5-parameters { 865 leaf remote-address { 866 type inet:host; 867 mandatory true; 868 description 869 "The IP address or hostname of the proxy server."; 870 } 871 leaf remote-port { 872 type inet:port-number; 873 default "1080"; 874 description 875 "The IP port number for the proxy server."; 876 } 877 container authentication-parameters { 878 presence 879 "Indicates that an authentication mechanism 880 has been configured. Present so that the 881 mandatory descendant nodes do not imply that 882 this node must be configured."; 883 description 884 "A container for SOCKS Version 5 authentication 885 mechanisms. 887 A complete list of methods is defined at: 888 https://www.iana.org/assignments/socks-methods 889 /socks-methods.xhtml."; 890 reference 891 "RFC 1928: SOCKS Protocol Version 5"; 892 choice auth-type { 893 mandatory true; 894 description 895 "A choice amongst supported SOCKS Version 5 896 authentication mechanisms."; 897 case gss-api { 898 if-feature "socks5-gss-api"; 899 container gss-api { 900 description 901 "Contains GSS-API configuration. Defines 902 as an empty container to enable specific 903 GSS-API configuration to be augmented in 904 by future modules."; 905 reference 906 "RFC 1928: SOCKS Protocol Version 5 907 RFC 2743: Generic Security Service 908 Application Program Interface 909 Version 2, Update 1"; 910 } 911 } 912 case username-password { 913 if-feature "socks5-username-password"; 914 container username-password { 915 leaf username { 916 type string; 917 mandatory true; 918 description 919 "The 'username' value to use for client 920 identification."; 921 } 922 uses ct:password-grouping { 923 description 924 "The password to be used for client 925 authentication."; 926 } 927 description 928 "Contains Username/Password configuration."; 929 reference 930 "RFC 1929: Username/Password Authentication 931 for SOCKS V5"; 932 } 933 } 934 } 935 } 936 description 937 "Parameters for connecting to a TCP-based proxy server 938 using the SOCKS5 protocol."; 939 reference 940 "RFC 1928: SOCKS Protocol Version 5"; 941 } 942 } 943 } 944 description 945 "Proxy server settings."; 946 } 948 uses tcpcmn:tcp-common-grouping { 949 augment "keepalives" { 950 if-feature "tcp-client-keepalives"; 951 description 952 "Add an if-feature statement so that implementations 953 can choose to support TCP client keepalives."; 954 } 955 } 956 } 957 } 959 961 4. The "ietf-tcp-server" Module 963 This section defines a YANG 1.1 module called "ietf-tcp-server". A 964 high-level overview of the module is provided in Section 4.1. 965 Examples illustrating the module's use are provided in Examples 966 (Section 4.2). The YANG module itself is defined in Section 4.3. 968 4.1. Data Model Overview 970 This section provides an overview of the "ietf-tcp-server" module in 971 terms of its features and groupings. 973 4.1.1. Features 975 The following diagram lists all the "feature" statements defined in 976 the "ietf-tcp-server" module: 978 Features: 979 +-- tcp-server-keepalives 981 | The diagram above uses syntax that is similar to but not 982 | defined in [RFC8340]. 984 4.1.2. Groupings 986 The "ietf-tcp-server" module defines the following "grouping" 987 statement: 989 * tcp-server-grouping 991 This grouping is presented in the following subsection. 993 4.1.2.1. The "tcp-server-grouping" Grouping 995 The following tree diagram [RFC8340] illustrates the "tcp-server- 996 grouping" grouping: 998 grouping tcp-server-grouping 999 +-- local-address inet:ip-address 1000 +-- local-port? inet:port-number 1001 +---u tcpcmn:tcp-common-grouping 1003 Comments: 1005 * The "local-address" node, which is mandatory, may be configured as 1006 an IPv4 address, an IPv6 address, or a wildcard value. 1008 * The "local-port" node is not mandatory, but its default value is 1009 the invalid value '0', thus forcing the consuming data model to 1010 refine it in order to provide it an appropriate default value. 1012 * This grouping uses the "tcp-common-grouping" grouping discussed in 1013 Section 2.1.3.1. 1015 4.1.3. Protocol-accessible Nodes 1017 The "ietf-tcp-server" module defines only "grouping" statements that 1018 are used by other modules to instantiate protocol-accessible nodes. 1020 4.2. Example Usage 1022 This section presents an example showing the "tcp-server-grouping" 1023 populated with some data. 1025 1026 1028 1029 10.20.30.40 1030 7777 1031 1032 15 1033 3 1034 30 1035 1036 1038 4.3. YANG Module 1040 The ietf-tcp-server YANG module references [RFC6991]. 1042 file "ietf-tcp-server@2022-03-07.yang" 1044 module ietf-tcp-server { 1045 yang-version 1.1; 1046 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-server"; 1047 prefix tcps; 1049 import ietf-inet-types { 1050 prefix inet; 1051 reference 1052 "RFC 6991: Common YANG Data Types"; 1053 } 1055 import ietf-tcp-common { 1056 prefix tcpcmn; 1057 reference 1058 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers"; 1059 } 1061 organization 1062 "IETF NETCONF (Network Configuration) Working Group and the 1063 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group"; 1065 contact 1066 "WG Web: https://datatracker.ietf.org/wg/netconf 1067 https://datatracker.ietf.org/wg/tcpm 1069 WG List: NETCONF WG list 1070 TCPM WG list 1071 Authors: Kent Watsen 1072 Michael Scharf 1073 "; 1075 description 1076 "This module defines reusable groupings for TCP servers that 1077 can be used as a basis for specific TCP server instances. 1079 Copyright (c) 2021 IETF Trust and the persons identified 1080 as authors of the code. All rights reserved. 1082 Redistribution and use in source and binary forms, with 1083 or without modification, is permitted pursuant to, and 1084 subject to the license terms contained in, the Revised 1085 BSD License set forth in Section 4.c of the IETF Trust's 1086 Legal Provisions Relating to IETF Documents 1087 (https://trustee.ietf.org/license-info). 1089 This version of this YANG module is part of RFC DDDD 1090 (https://www.rfc-editor.org/info/rfcDDDD); see the RFC 1091 itself for full legal notices. 1093 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1094 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1095 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 1096 are to be interpreted as described in BCP 14 (RFC 2119) 1097 (RFC 8174) when, and only when, they appear in all 1098 capitals, as shown here."; 1100 revision 2022-03-07 { 1101 description 1102 "Initial version"; 1103 reference 1104 "RFC DDDD: YANG Groupings for TCP Clients and TCP Servers"; 1105 } 1107 // Features 1109 feature tcp-server-keepalives { 1110 description 1111 "Per socket TCP keepalive parameters are configurable for 1112 TCP servers on the server implementing this feature."; 1113 } 1115 // Groupings 1116 grouping tcp-server-grouping { 1117 description 1118 "A reusable grouping for configuring a TCP server. 1120 Note that this grouping uses fairly typical descendant 1121 node names such that a stack of 'uses' statements will 1122 have name conflicts. It is intended that the consuming 1123 data model will resolve the issue (e.g., by wrapping 1124 the 'uses' statement in a container called 1125 'tcp-server-parameters'). This model purposely does 1126 not do this itself so as to provide maximum flexibility 1127 to consuming models."; 1128 leaf local-address { 1129 type inet:ip-address; 1130 mandatory true; 1131 description 1132 "The local IP address to listen on for incoming 1133 TCP client connections. INADDR_ANY (0.0.0.0) or 1134 INADDR6_ANY (0:0:0:0:0:0:0:0 a.k.a. ::) MUST be 1135 used when the server is to listen on all IPv4 or 1136 IPv6 addresses, respectively."; 1137 } 1138 leaf local-port { 1139 type inet:port-number; 1140 default "0"; 1141 description 1142 "The local port number to listen on for incoming TCP 1143 client connections. An invalid default value (0) 1144 is used (instead of 'mandatory true') so that an 1145 application level data model may 'refine' it with 1146 an application specific default port number value."; 1147 } 1148 uses tcpcmn:tcp-common-grouping { 1149 augment "keepalives" { 1150 if-feature "tcp-server-keepalives"; 1151 description 1152 "Add an if-feature statement so that implementations 1153 can choose to support TCP server keepalives."; 1154 } 1155 } 1156 } 1157 } 1159 1161 5. Security Considerations 1163 5.1. The "ietf-tcp-common" YANG Module 1165 The "ietf-tcp-common" YANG module defines "grouping" statements that 1166 are designed to be accessed via YANG based management protocols, such 1167 as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols 1168 have mandatory-to-implement secure transport layers (e.g., SSH, TLS) 1169 with mutual authentication. 1171 The NETCONF access control model (NACM) [RFC8341] provides the means 1172 to restrict access for particular users to a pre-configured subset of 1173 all available protocol operations and content. 1175 Since the module in this document only define groupings, these 1176 considerations are primarily for the designers of other modules that 1177 use these groupings. 1179 None of the readable data nodes defined in this YANG module are 1180 considered sensitive or vulnerable in network environments. The NACM 1181 "default-deny-all" extension has not been set for any data nodes 1182 defined in this module. 1184 None of the writable data nodes defined in this YANG module are 1185 considered sensitive or vulnerable in network environments. The NACM 1186 "default-deny-write" extension has not been set for any data nodes 1187 defined in this module. 1189 This module does not define any RPCs, actions, or notifications, and 1190 thus the security consideration for such is not provided here. 1192 5.2. The "ietf-tcp-client" YANG Module 1194 The "ietf-tcp-client" YANG module defines "grouping" statements that 1195 are designed to be accessed via YANG based management protocols, such 1196 as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols 1197 have mandatory-to-implement secure transport layers (e.g., SSH, TLS) 1198 with mutual authentication. 1200 The NETCONF access control model (NACM) [RFC8341] provides the means 1201 to restrict access for particular users to a pre-configured subset of 1202 all available protocol operations and content. 1204 Since the module in this document only define groupings, these 1205 considerations are primarily for the designers of other modules that 1206 use these groupings. 1208 One readable data node defined in this YANG module may be considered 1209 sensitive or vulnerable in some network environments. This node is 1210 as follows: 1212 * The "proxy-server/socks5-parameters/authentication-parameters/ 1213 username-password/password" node: 1215 The cleartext "password" node defined in the "tcp-client- 1216 grouping" grouping is additionally sensitive to read operations 1217 such that, in normal use cases, it should never be returned to 1218 a client. For this reason, the NACM extension "default-deny- 1219 all" has been applied to it. 1221 None of the writable data nodes defined in this YANG module are 1222 considered sensitive or vulnerable in network environments. The NACM 1223 "default-deny-write" extension has not been set for any data nodes 1224 defined in this module. 1226 This module does not define any RPCs, actions, or notifications, and 1227 thus the security consideration for such is not provided here. 1229 Implementations are RECOMMENDED to implement the "local-binding- 1230 supported" feature for cryptographically-secure protocols, so as to 1231 enable more granular ingress/egress firewall rulebases. It is NOT 1232 RECOMMENDED to implement this feature for unsecure protocols, as per 1233 [RFC6056]. 1235 5.3. The "ietf-tcp-server" YANG Module 1237 The "ietf-tcp-server" YANG module defines "grouping" statements that 1238 are designed to be accessed via YANG based management protocols, such 1239 as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols 1240 have mandatory-to-implement secure transport layers (e.g., SSH, TLS) 1241 with mutual authentication. 1243 The NETCONF access control model (NACM) [RFC8341] provides the means 1244 to restrict access for particular users to a pre-configured subset of 1245 all available protocol operations and content. 1247 Since the module in this document only define groupings, these 1248 considerations are primarily for the designers of other modules that 1249 use these groupings. 1251 None of the readable data nodes defined in this YANG module are 1252 considered sensitive or vulnerable in network environments. The NACM 1253 "default-deny-all" extension has not been set for any data nodes 1254 defined in this module. 1256 None of the writable data nodes defined in this YANG module are 1257 considered sensitive or vulnerable in network environments. The NACM 1258 "default-deny-write" extension has not been set for any data nodes 1259 defined in this module. 1261 This module does not define any RPCs, actions, or notifications, and 1262 thus the security consideration for such is not provided here. 1264 6. IANA Considerations 1266 6.1. The "IETF XML" Registry 1268 This document registers two URIs in the "ns" subregistry of the IETF 1269 XML Registry [RFC3688]. Following the format in [RFC3688], the 1270 following registrations are requested: 1272 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-common 1273 Registrant Contact: The IESG 1274 XML: N/A, the requested URI is an XML namespace. 1276 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-client 1277 Registrant Contact: The IESG 1278 XML: N/A, the requested URI is an XML namespace. 1280 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-server 1281 Registrant Contact: The IESG 1282 XML: N/A, the requested URI is an XML namespace. 1284 6.2. The "YANG Module Names" Registry 1286 This document registers two YANG modules in the YANG Module Names 1287 registry [RFC6020]. Following the format in [RFC6020], the following 1288 registrations are requested: 1290 name: ietf-tcp-common 1291 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-common 1292 prefix: tcpcmn 1293 reference: RFC DDDD 1295 name: ietf-tcp-client 1296 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-client 1297 prefix: tcpc 1298 reference: RFC DDDD 1300 name: ietf-tcp-server 1301 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-server 1302 prefix: tcps 1303 reference: RFC DDDD 1305 7. References 1307 7.1. Normative References 1309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1310 Requirement Levels", BCP 14, RFC 2119, 1311 DOI 10.17487/RFC2119, March 1997, 1312 . 1314 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1315 the Network Configuration Protocol (NETCONF)", RFC 6020, 1316 DOI 10.17487/RFC6020, October 2010, 1317 . 1319 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1320 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1321 . 1323 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1324 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1325 . 1327 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1328 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1329 May 2017, . 1331 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1332 Access Control Model", STD 91, RFC 8341, 1333 DOI 10.17487/RFC8341, March 2018, 1334 . 1336 7.2. Informative References 1338 [I-D.ietf-netconf-crypto-types] 1339 Watsen, K., "YANG Data Types and Groupings for 1340 Cryptography", Work in Progress, Internet-Draft, draft- 1341 ietf-netconf-crypto-types-21, 14 September 2021, 1342 . 1345 [I-D.ietf-netconf-http-client-server] 1346 Watsen, K., "YANG Groupings for HTTP Clients and HTTP 1347 Servers", Work in Progress, Internet-Draft, draft-ietf- 1348 netconf-http-client-server-08, 14 December 2021, 1349 . 1352 [I-D.ietf-netconf-keystore] 1353 Watsen, K., "A YANG Data Model for a Keystore", Work in 1354 Progress, Internet-Draft, draft-ietf-netconf-keystore-23, 1355 14 December 2021, . 1358 [I-D.ietf-netconf-netconf-client-server] 1359 Watsen, K., "NETCONF Client and Server Models", Work in 1360 Progress, Internet-Draft, draft-ietf-netconf-netconf- 1361 client-server-24, 14 December 2021, 1362 . 1365 [I-D.ietf-netconf-restconf-client-server] 1366 Watsen, K., "RESTCONF Client and Server Models", Work in 1367 Progress, Internet-Draft, draft-ietf-netconf-restconf- 1368 client-server-24, 14 December 2021, 1369 . 1372 [I-D.ietf-netconf-ssh-client-server] 1373 Watsen, K., "YANG Groupings for SSH Clients and SSH 1374 Servers", Work in Progress, Internet-Draft, draft-ietf- 1375 netconf-ssh-client-server-26, 14 December 2021, 1376 . 1379 [I-D.ietf-netconf-tcp-client-server] 1380 Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients 1381 and TCP Servers", Work in Progress, Internet-Draft, draft- 1382 ietf-netconf-tcp-client-server-11, 14 December 2021, 1383 . 1386 [I-D.ietf-netconf-tls-client-server] 1387 Watsen, K., "YANG Groupings for TLS Clients and TLS 1388 Servers", Work in Progress, Internet-Draft, draft-ietf- 1389 netconf-tls-client-server-26, 14 December 2021, 1390 . 1393 [I-D.ietf-netconf-trust-anchors] 1394 Watsen, K., "A YANG Data Model for a Truststore", Work in 1395 Progress, Internet-Draft, draft-ietf-netconf-trust- 1396 anchors-16, 14 December 2021, 1397 . 1400 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1401 RFC 793, DOI 10.17487/RFC0793, September 1981, 1402 . 1404 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1405 Communication Layers", STD 3, RFC 1122, 1406 DOI 10.17487/RFC1122, October 1989, 1407 . 1409 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1410 DOI 10.17487/RFC3688, January 2004, 1411 . 1413 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 1414 Protocol Port Randomization", BCP 156, RFC 6056, 1415 DOI 10.17487/RFC6056, January 2011, 1416 . 1418 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1419 and A. Bierman, Ed., "Network Configuration Protocol 1420 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1421 . 1423 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1424 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1425 . 1427 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1428 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1429 . 1431 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1432 and R. Wilton, "Network Management Datastore Architecture 1433 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1434 . 1436 Appendix A. Change Log 1438 This section is to be removed before publishing as an RFC. 1440 A.1. 00 to 01 1442 * Added 'local-binding-supported' feature to TCP-client model. 1444 * Added 'keepalives-supported' feature to TCP-common model. 1446 * Added 'external-endpoint-values' container and 'external- 1447 endpoints' feature to TCP-server model. 1449 A.2. 01 to 02 1451 * Removed the 'external-endpoint-values' container and 'external- 1452 endpoints' feature from the TCP-server model. 1454 A.3. 02 to 03 1456 * Moved the common model section to be before the client and server 1457 specific sections. 1459 * Added sections "Model Scope" and "Usage Guidelines for Configuring 1460 TCP Keep-Alives" to the common model section. 1462 A.4. 03 to 04 1464 * Fixed a few typos. 1466 A.5. 04 to 05 1468 * Removed commented out "grouping tcp-system-grouping" statement 1469 kept for reviewers. 1471 * Added a "Note to Reviewers" note to first page. 1473 A.6. 05 to 06 1475 * Added support for TCP proxies. 1477 A.7. 06 to 07 1479 * Expanded "Data Model Overview section(s) [remove "wall" of tree 1480 diagrams]. 1482 * Updated the Security Considerations section. 1484 A.8. 07 to 08 1486 * Added missing IANA registration for "ietf-tcp-common" 1488 * Added "mandatory true" for the "username" and "password" leafs 1490 * Added an example of a TCP-client configured to connect via a proxy 1492 * Fixed issues found by the SecDir review of the "keystore" draft. 1494 * Updated the "ietf-tcp-client" module to use the new "password- 1495 grouping" grouping from the "crypto-types" module. 1497 A.9. 08 to 09 1499 * Addressed comments raised by YANG Doctor in the ct/ts/ks drafts. 1501 A.10. 09 to 10 1503 * Updated Abstract and Intro to address comments by Tom Petch. 1505 * Removed the "tcp-connection-grouping" grouping (now models use the 1506 "tcp-common-grouping" directly). 1508 * Added XML-comment above examples explaining the reason for the 1509 unusual top-most element's presence. 1511 * Added Securty Considerations section for the "local-binding- 1512 supported" feature. 1514 * Replaced some hardcoded refs to elements. 1516 * Fixed nits found by YANG Doctor reviews. 1518 * Aligned modules with `pyang -f` formatting. 1520 * Added an "Acknowledgements" secetion. 1522 A.11. 10 to 11 1524 * Replaced "base64encodedvalue==" with "BASE64VALUE=" in examples. 1526 * Minor editorial nits 1528 A.12. 11 to 12 1530 * Fixed up the 'WG Web' and 'WG List' lines in YANG module(s) 1532 * Fixed up copyright (i.e., s/Simplified/Revised/) in YANG module(s) 1534 Acknowledgements 1536 The authors would like to thank for following for lively discussions 1537 on list and in the halls (ordered by first name): Juergen 1538 Schoenwaelder, Ladislav Lhotka, Nick Hancock, and Tom Petch. 1540 Authors' Addresses 1542 Kent Watsen 1543 Watsen Networks 1544 Email: kent+ietf@watsen.net 1545 Michael Scharf 1546 Hochschule Esslingen - University of Applied Sciences 1547 Email: michael.scharf@hs-esslingen.de