idnits 2.17.1 draft-ietf-netconf-tcp-client-server-04.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 196 has weird spacing: '...nterval uin...' == Line 201 has weird spacing: '...nterval uin...' == Line 370 has weird spacing: '...address ine...' == Line 377 has weird spacing: '...nterval uin...' == Line 560 has weird spacing: '...address ine...' == (1 more instance...) -- The document date (March 8, 2020) is 1509 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 171, but not defined == Missing Reference: 'RFC793bis' is mentioned on line 133, but not defined ** Obsolete undefined reference: RFC 793 (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 9 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: September 9, 2020 Hochschule Esslingen 6 March 8, 2020 8 YANG Groupings for TCP Clients and TCP Servers 9 draft-ietf-netconf-tcp-client-server-04 11 Abstract 13 This document defines three YANG modules: the first defines a 14 grouping for configuring a generic TCP client, the second defines a 15 grouping for configuring a generic TCP server, and the third defines 16 a grouping common to the TCP clients and TCP servers. 18 Editorial Note (To be removed by RFC Editor) 20 This draft contains many placeholder values that need to be replaced 21 with finalized values at the time of publication. This note 22 summarizes all of the substitutions that are needed. No other RFC 23 Editor instructions are specified elsewhere in this document. 25 Artwork in this document contains placeholder values for the date of 26 publication of this draft. Please apply the following replacement: 28 o "2020-03-08" --> the publication date of this draft 30 The following Appendix section is to be removed prior to publication: 32 o Appendix A. Change Log 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 9, 2020. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. The TCP Common Model . . . . . . . . . . . . . . . . . . . . 3 70 3.1. Model Scope . . . . . . . . . . . . . . . . . . . . . . . 3 71 3.2. Usage Guidelines for Configuring TCP Keep-Alives . . . . 3 72 3.3. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4 73 3.4. Example Usage . . . . . . . . . . . . . . . . . . . . . . 5 74 3.5. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 5 75 4. The TCP Client Model . . . . . . . . . . . . . . . . . . . . 8 76 4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 8 77 4.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 9 78 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 9 79 5. The TCP Server Model . . . . . . . . . . . . . . . . . . . . 12 80 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 12 81 5.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 13 82 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 13 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 85 7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 16 86 7.2. The YANG Module Names Registry . . . . . . . . . . . . . 17 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 89 8.2. Informative References . . . . . . . . . . . . . . . . . 18 90 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 19 91 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 19 92 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 19 93 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 19 94 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 19 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 97 1. Introduction 99 This document defines three YANG 1.1 [RFC7950] modules: the first 100 defines a grouping for configuring a generic TCP client, the second 101 defines a grouping for configuring a generic TCP server, and the 102 third defines a grouping common to the TCP clients and TCP servers. 104 It is intended that these groupings will be used either standalone, 105 for TCP-based protocols, as part of a stack of protocol-specific 106 configuration models. For instance, these groupings could help 107 define the configuration module for SSH, TLS, or HTTP based 108 applications. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in BCP 115 14 [RFC2119] [RFC8174] when, and only when, they appear in all 116 capitals, as shown here. 118 3. The TCP Common Model 120 3.1. Model Scope 122 This document defines a common "grouping" statement for basic TCP 123 connection parameters that matter to applications. In some TCP 124 stacks, such parameters can also directly be set by an application 125 using system calls, such as the socket API. The base YANG model in 126 this document focuses on modeling TCP keep-alives. This base model 127 can be extended as needed. 129 3.2. Usage Guidelines for Configuring TCP Keep-Alives 131 Network stacks may include "keep-alives" in their TCP 132 implementations, although this practice is not universally accepted. 133 If keep-alives are included, [RFC1122] [RFC793bis] mandates that the 134 application MUST be able to turn them on or off for each TCP 135 connection, and that they MUST default to off. 137 Keep-alive mechanisms exist in many protocols. Depending on the 138 protocol stack, TCP keep-alives may only be one out of several 139 alternatives. Which mechanism to use depends on the use case and 140 application requirements. If keep-alives are needed by an 141 application, it is RECOMMENDED that the aliveness check happens at 142 the highest protocol layer possible that is meaningful to the 143 application, in order to maximize the depth of the aliveness check. 145 [[TODO: Further guidance on keep-alives is provided in draft-xyz- 146 tsvwg-... ]] 148 A TCP keep-alive mechanism should only be invoked in server 149 applications that might otherwise hang indefinitely and consume 150 resources unnecessarily if a client crashes or aborts a connection 151 during a network failure [RFC1122]. TCP keep-alives may consume 152 significant resources both in the network and in endpoints (e.g., 153 battery power). In addition, frequent keep-alives risk network 154 congestion. The higher the frequency of keep-alives, the higher the 155 overhead. 157 Given the cost of keep-alives, parameters have to be configured 158 carefully: 160 o The default idle interval (leaf "idle-time") MUST default to no 161 less than two hours, i.e., 7200 seconds [RFC1122]. A lower value 162 MAY be configured, but keep-alive messages SHOULD NOT be 163 transmitted more frequently than once every 15 seconds. Longer 164 intervals SHOULD be used when possible. 166 o The maximum number of sequential keep-alive probes that can fail 167 (leaf "max-probes") trades off responsiveness and robustness 168 against packet loss. ACK segments that contain no data are not 169 reliably transmitted by TCP. Consequently, if a keep-alive 170 mechanism is implemented it MUST NOT interpret failure to respond 171 to any specific probe as a dead connection [RFC1122]. Typically a 172 single-digit number should suffice. 174 o TCP implementations may include a parameter for the number of 175 seconds between TCP keep-alive probes (leaf "probe-interval"). In 176 order to avoid congestion, the time interval between probes MUST 177 NOT be smaller than one second. Significantly longer intervals 178 SHOULD be used. It is important to note that keep-alive probes 179 (or replies) can get dropped due to network congestion. Sending 180 further probe messages into a congested path after a short 181 interval, without backing off timers, could cause harm and result 182 in a congestion collapse. Therefore it is essential to pick a 183 large, conservative value for this interval. 185 3.3. Tree Diagram 187 This section provides a tree diagram [RFC8340] for the "ietf-tcp- 188 common" module. 190 module: ietf-tcp-common 192 grouping tcp-common-grouping 193 +-- keepalives! {keepalives-supported}? 194 +-- idle-time uint16 195 +-- max-probes uint16 196 +-- probe-interval uint16 197 grouping tcp-connection-grouping 198 +-- keepalives! {keepalives-supported}? 199 +-- idle-time uint16 200 +-- max-probes uint16 201 +-- probe-interval uint16 203 3.4. Example Usage 205 This section presents an example showing the tcp-common-grouping 206 populated with some data. 208 209 210 15 211 3 212 30 213 214 216 3.5. YANG Module 218 The ietf-tcp-common YANG module references [RFC6991]. 220 file "ietf-tcp-common@2020-03-08.yang" 222 module ietf-tcp-common { 223 yang-version 1.1; 224 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-common"; 225 prefix tcpcmn; 227 organization 228 "IETF NETCONF (Network Configuration) Working Group and the 229 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group"; 231 contact 232 "WG Web: 233 234 WG List: 235 236 Authors: Kent Watsen 237 Michael Scharf 238 "; 240 description 241 "This module defines reusable groupings for TCP commons that 242 can be used as a basis for specific TCP common instances. 244 Copyright (c) 2019 IETF Trust and the persons identified 245 as authors of the code. All rights reserved. 247 Redistribution and use in source and binary forms, with 248 or without modification, is permitted pursuant to, and 249 subject to the license terms contained in, the Simplified 250 BSD License set forth in Section 4.c of the IETF Trust's 251 Legal Provisions Relating to IETF Documents 252 (https://trustee.ietf.org/license-info). 254 This version of this YANG module is part of RFC XXXX 255 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 256 itself for full legal notices. 258 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 259 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 260 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 261 are to be interpreted as described in BCP 14 (RFC 2119) 262 (RFC 8174) when, and only when, they appear in all 263 capitals, as shown here."; 265 revision 2020-03-08 { 266 description 267 "Initial version"; 268 reference 269 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers"; 270 } 272 // Features 273 feature keepalives-supported { 274 description 275 "Indicates that keepalives are supported."; 276 } 278 // Groupings 280 grouping tcp-common-grouping { 281 description 282 "A reusable grouping for configuring TCP parameters common 283 to TCP connections as well as the operating system as a 284 whole."; 285 container keepalives { 286 if-feature "keepalives-supported"; 287 presence "Indicates that keepalives are enabled."; 288 description 289 "Configures the keep-alive policy, to proactively test the 290 aliveness of the TCP peer. An unresponsive TCP peer is 291 dropped after approximately (idle-time + max-probes 292 * probe-interval) seconds."; 293 leaf idle-time { 294 type uint16 { 295 range "1..max"; 296 } 297 units "seconds"; 298 mandatory true; 299 description 300 "Sets the amount of time after which if no data has been 301 received from the TCP peer, a TCP-level probe message 302 will be sent to test the aliveness of the TCP peer. 303 Two hours (7200 seconds) is safe value, per RFC 1122."; 304 reference 305 "RFC 1122: 306 Requirements for Internet Hosts -- Communication Layers"; 307 } 308 leaf max-probes { 309 type uint16 { 310 range "1..max"; 311 } 312 mandatory true; 313 description 314 "Sets the maximum number of sequential keep-alive probes 315 that can fail to obtain a response from the TCP peer 316 before assuming the TCP peer is no longer alive."; 317 } 318 leaf probe-interval { 319 type uint16 { 320 range "1..max"; 321 } 322 units "seconds"; 323 mandatory true; 324 description 325 "Sets the time interval between failed probes. The interval 326 SHOULD be significantly longer than one second in order to 327 avoid harm on a congested link."; 328 } 329 } // container keepalives 330 } // grouping tcp-common-grouping 332 grouping tcp-connection-grouping { 333 description 334 "A reusable grouping for configuring TCP parameters common 335 to TCP connections."; 336 uses tcp-common-grouping; 337 } 339 /* 340 The following is for a future bis... 341 This comment is here now so as support discussion with TCPM. 342 This comment will be removed before publication. 344 Should future system-level parameters be defined as a 345 grouping or a container? 347 grouping tcp-system-grouping { 348 description 349 "A reusable grouping for configuring TCP parameters common 350 to the operating system as a whole."; 352 // currently just a placeholder 353 } 354 */ 356 } 358 360 4. The TCP Client Model 362 4.1. Tree Diagram 364 This section provides a tree diagram [RFC8340] for the "ietf-tcp- 365 client" module. 367 module: ietf-tcp-client 369 grouping tcp-client-grouping 370 +-- remote-address inet:host 371 +-- remote-port? inet:port-number 372 +-- local-address? inet:ip-address {local-binding-supported}? 373 +-- local-port? inet:port-number {local-binding-supported}? 374 +-- keepalives! {keepalives-supported}? 375 +-- idle-time uint16 376 +-- max-probes uint16 377 +-- probe-interval uint16 379 4.2. Example Usage 381 This section presents an example showing the tcp-client-grouping 382 populated with some data. 384 385 www.example.com 386 443 387 0.0.0.0 388 0 389 390 15 391 3 392 30 393 394 396 4.3. YANG Module 398 The ietf-tcp-client YANG module references [RFC6991]. 400 file "ietf-tcp-client@2020-03-08.yang" 402 module ietf-tcp-client { 403 yang-version 1.1; 404 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-client"; 405 prefix tcpc; 407 import ietf-inet-types { 408 prefix inet; 409 reference 410 "RFC 6991: Common YANG Data Types"; 411 } 413 import ietf-tcp-common { 414 prefix tcpcmn; 415 reference 416 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers"; 417 } 419 organization 420 "IETF NETCONF (Network Configuration) Working Group and the 421 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group"; 423 contact 424 "WG Web: 425 426 WG List: 427 428 Authors: Kent Watsen 429 Michael Scharf 430 "; 432 description 433 "This module defines reusable groupings for TCP clients that 434 can be used as a basis for specific TCP client instances. 436 Copyright (c) 2019 IETF Trust and the persons identified 437 as authors of the code. All rights reserved. 439 Redistribution and use in source and binary forms, with 440 or without modification, is permitted pursuant to, and 441 subject to the license terms contained in, the Simplified 442 BSD License set forth in Section 4.c of the IETF Trust's 443 Legal Provisions Relating to IETF Documents 444 (https://trustee.ietf.org/license-info). 446 This version of this YANG module is part of RFC XXXX 447 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 448 itself for full legal notices. 450 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 451 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 452 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 453 are to be interpreted as described in BCP 14 (RFC 2119) 454 (RFC 8174) when, and only when, they appear in all 455 capitals, as shown here."; 457 revision 2020-03-08 { 458 description 459 "Initial version"; 460 reference 461 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers"; 462 } 464 // Features 466 feature local-binding-supported { 467 description 468 "Indicates that the server supports configuring local 469 bindings (i.e., the local address and local port) for 470 TCP clients."; 471 } 473 feature tcp-client-keepalives { 474 description 475 "Per socket TCP keepalive parameters are configurable for 476 TCP clients on the server implementing this feature."; 477 } 479 // Groupings 481 grouping tcp-client-grouping { 482 description 483 "A reusable grouping for configuring a TCP client. 485 Note that this grouping uses fairly typical descendent 486 node names such that a stack of 'uses' statements will 487 have name conflicts. It is intended that the consuming 488 data model will resolve the issue (e.g., by wrapping 489 the 'uses' statement in a container called 490 'tcp-client-parameters'). This model purposely does 491 not do this itself so as to provide maximum flexibility 492 to consuming models."; 494 leaf remote-address { 495 type inet:host; 496 mandatory true; 497 description 498 "The IP address or hostname of the remote peer to 499 establish a connection with. If a domain name is 500 configured, then the DNS resolution should happen on 501 each connection attempt. If the DNS resolution 502 results in multiple IP addresses, the IP addresses 503 are tried according to local preference order until 504 a connection has been established or until all IP 505 addresses have failed."; 506 } 507 leaf remote-port { 508 type inet:port-number; 509 default "0"; 510 description 511 "The IP port number for the remote peer to establish a 512 connection with. An invalid default value (0) is used 513 (instead of 'mandatory true') so that as application 514 level data model may 'refine' it with an application 515 specific default port number value."; 516 } 517 leaf local-address { 518 if-feature "local-binding-supported"; 519 type inet:ip-address; 520 description 521 "The local IP address/interface (VRF?) to bind to for when 522 connecting to the remote peer. INADDR_ANY ('0.0.0.0') or 523 INADDR6_ANY ('0:0:0:0:0:0:0:0' a.k.a. '::') MAY be used to 524 explicitly indicate the implicit default, that the server 525 can bind to any IPv4 or IPv6 addresses, respectively."; 526 } 527 leaf local-port { 528 if-feature "local-binding-supported"; 529 type inet:port-number; 530 default "0"; 531 description 532 "The local IP port number to bind to for when connecting 533 to the remote peer. The port number '0', which is the 534 default value, indicates that any available local port 535 number may be used."; 536 } 537 uses tcpcmn:tcp-connection-grouping { 538 augment "keepalives" { 539 if-feature "tcp-client-keepalives"; 540 description 541 "Add an if-feature statement so that implementations 542 can choose to support TCP client keepalives."; 543 } 544 } 545 } 546 } 548 550 5. The TCP Server Model 552 5.1. Tree Diagram 554 This section provides a tree diagram [RFC8340] for the "ietf-tcp- 555 server" module. 557 module: ietf-tcp-server 559 grouping tcp-server-grouping 560 +-- local-address inet:ip-address 561 +-- local-port? inet:port-number 562 +-- keepalives! {keepalives-supported}? 563 +-- idle-time uint16 564 +-- max-probes uint16 565 +-- probe-interval uint16 567 5.2. Example Usage 569 This section presents an example showing the tcp-server-grouping 570 populated with some data. 572 573 10.20.30.40 574 7777 575 576 15 577 3 578 30 579 580 582 5.3. YANG Module 584 The ietf-tcp-server YANG module references [RFC6991]. 586 file "ietf-tcp-server@2020-03-08.yang" 588 module ietf-tcp-server { 589 yang-version 1.1; 590 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-server"; 591 prefix tcps; 593 import ietf-inet-types { 594 prefix inet; 595 reference 596 "RFC 6991: Common YANG Data Types"; 597 } 599 import ietf-tcp-common { 600 prefix tcpcmn; 601 reference 602 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers"; 603 } 605 organization 606 "IETF NETCONF (Network Configuration) Working Group and the 607 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group"; 609 contact 610 "WG Web: 611 612 WG List: 613 614 Authors: Kent Watsen 615 Michael Scharf 616 "; 618 description 619 "This module defines reusable groupings for TCP servers that 620 can be used as a basis for specific TCP server instances. 622 Copyright (c) 2019 IETF Trust and the persons identified 623 as authors of the code. All rights reserved. 625 Redistribution and use in source and binary forms, with 626 or without modification, is permitted pursuant to, and 627 subject to the license terms contained in, the Simplified 628 BSD License set forth in Section 4.c of the IETF Trust's 629 Legal Provisions Relating to IETF Documents 630 (https://trustee.ietf.org/license-info). 632 This version of this YANG module is part of RFC XXXX 633 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 634 itself for full legal notices. 636 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 637 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 638 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 639 are to be interpreted as described in BCP 14 (RFC 2119) 640 (RFC 8174) when, and only when, they appear in all 641 capitals, as shown here."; 643 revision 2020-03-08 { 644 description 645 "Initial version"; 646 reference 647 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers"; 648 } 650 // Features 652 feature tcp-server-keepalives { 653 description 654 "Per socket TCP keepalive parameters are configurable for 655 TCP servers on the server implementing this feature."; 656 } 658 // Groupings 660 grouping tcp-server-grouping { 661 description 662 "A reusable grouping for configuring a TCP server. 664 Note that this grouping uses fairly typical descendent 665 node names such that a stack of 'uses' statements will 666 have name conflicts. It is intended that the consuming 667 data model will resolve the issue (e.g., by wrapping 668 the 'uses' statement in a container called 669 'tcp-server-parameters'). This model purposely does 670 not do this itself so as to provide maximum flexibility 671 to consuming models."; 672 leaf local-address { 673 type inet:ip-address; 674 mandatory true; 675 description 676 "The local IP address to listen on for incoming 677 TCP client connections. INADDR_ANY (0.0.0.0) or 678 INADDR6_ANY (0:0:0:0:0:0:0:0 a.k.a. ::) MUST be 679 used when the server is to listen on all IPv4 or 680 IPv6 addresses, respectively."; 681 } 682 leaf local-port { 683 type inet:port-number; 684 default "0"; 685 description 686 "The local port number to listen on for incoming TCP 687 client connections. An invalid default value (0) 688 is used (instead of 'mandatory true') so that an 689 application level data model may 'refine' it with 690 an application specific default port number value."; 691 } 692 uses tcpcmn:tcp-connection-grouping { 693 augment "keepalives" { 694 if-feature "tcp-server-keepalives"; 695 description 696 "Add an if-feature statement so that implementations 697 can choose to support TCP server keepalives."; 698 } 699 } 700 } 701 } 703 705 6. Security Considerations 707 The YANG modules defined in this document are designed to be accessed 708 via YANG based management protocols, such as NETCONF [RFC6241] and 709 RESTCONF [RFC8040]. Both of these protocols have mandatory-to- 710 implement secure transport layers (e.g., SSH, TCP) with mutual 711 authentication. 713 The NETCONF access control model (NACM) [RFC8341] provides the means 714 to restrict access for particular users to a pre-configured subset of 715 all available protocol operations and content. 717 Since the modules defined in this document only define groupings, 718 these considerations are primarily for the designers of other modules 719 that use these groupings. 721 There are a number of data nodes defined in the YANG modules that are 722 writable/creatable/deletable (i.e., config true, which is the 723 default). These data nodes may be considered sensitive or vulnerable 724 in some network environments. Write operations (e.g., edit-config) 725 to these data nodes without proper protection can have a negative 726 effect on network operations. These are the subtrees and data nodes 727 and their sensitivity/vulnerability: 729 None of the writable/creatable/deletable data nodes in 730 the YANG modules defined in this document are considered more 731 sensitive or vulnerable then standard configuration. 733 Some of the readable data nodes in the YANG modules may be considered 734 sensitive or vulnerable in some network environments. It is thus 735 important to control read access (e.g., via get, get-config, or 736 notification) to these data nodes. These are the subtrees and data 737 nodes and their sensitivity/vulnerability: 739 None of the readable data nodes in the YANG modules 740 defined in this document are considered more sensitive or vulnerable 741 then standard configuration. 743 This document does not define any RPC actions and hence this section 744 does not consider the security of RPCs. 746 7. IANA Considerations 748 7.1. The IETF XML Registry 750 This document registers two URIs in the "ns" subregistry of the IETF 751 XML Registry [RFC3688]. Following the format in [RFC3688], the 752 following registrations are requested: 754 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-client 755 Registrant Contact: The NETCONF WG of the IETF. 756 XML: N/A, the requested URI is an XML namespace. 758 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-server 759 Registrant Contact: The NETCONF WG of the IETF. 760 XML: N/A, the requested URI is an XML namespace. 762 7.2. The YANG Module Names Registry 764 This document registers two YANG modules in the YANG Module Names 765 registry [RFC6020]. Following the format in [RFC6020], the following 766 registrations are requested: 768 name: ietf-tcp-common 769 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-common 770 prefix: tcpcmn 771 reference: RFC XXXX 773 name: ietf-tcp-client 774 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-client 775 prefix: tcpc 776 reference: RFC XXXX 778 name: ietf-tcp-server 779 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-server 780 prefix: tcps 781 reference: RFC XXXX 783 8. References 785 8.1. Normative References 787 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 788 Requirement Levels", BCP 14, RFC 2119, 789 DOI 10.17487/RFC2119, March 1997, 790 . 792 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 793 the Network Configuration Protocol (NETCONF)", RFC 6020, 794 DOI 10.17487/RFC6020, October 2010, 795 . 797 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 798 RFC 6991, DOI 10.17487/RFC6991, July 2013, 799 . 801 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 802 RFC 7950, DOI 10.17487/RFC7950, August 2016, 803 . 805 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 806 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 807 May 2017, . 809 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 810 Access Control Model", STD 91, RFC 8341, 811 DOI 10.17487/RFC8341, March 2018, 812 . 814 8.2. Informative References 816 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 817 DOI 10.17487/RFC3688, January 2004, 818 . 820 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 821 and A. Bierman, Ed., "Network Configuration Protocol 822 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 823 . 825 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 826 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 827 . 829 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 830 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 831 . 833 Appendix A. Change Log 835 A.1. 00 to 01 837 o Added 'local-binding-supported' feature to TCP-client model. 839 o Added 'keepalives-supported' feature to TCP-common model. 841 o Added 'external-endpoint-values' container and 'external- 842 endpoints' feature to TCP-server model. 844 A.2. 01 to 02 846 o Removed the 'external-endpoint-values' container and 'external- 847 endpoints' feature from the TCP-server model. 849 A.3. 02 to 03 851 o Moved the common model section to be before the client and server 852 specific sections. 854 o Added sections "Model Scope" and "Usage Guidelines for Configuring 855 TCP Keep-Alives" to the common model section. 857 A.4. 03 to 04 859 o Fixed a few typos. 861 Authors' Addresses 863 Kent Watsen 864 Watsen Networks 866 EMail: kent+ietf@watsen.net 868 Michael Scharf 869 Hochschule Esslingen - University of Applied Sciences 871 EMail: michael.scharf@hs-esslingen.de