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