idnits 2.17.1 draft-ietf-netconf-tcp-client-server-03.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 195 has weird spacing: '...nterval uin...' == Line 200 has weird spacing: '...nterval uin...' == Line 369 has weird spacing: '...address ine...' == Line 376 has weird spacing: '...nterval uin...' == Line 559 has weird spacing: '...address ine...' == (1 more instance...) -- The document date (October 18, 2019) is 1645 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 170, but not defined == Missing Reference: 'RFC793bis' is mentioned on line 132, 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: April 20, 2020 Hochschule Esslingen 6 October 18, 2019 8 YANG Groupings for TCP Clients and TCP Servers 9 draft-ietf-netconf-tcp-client-server-03 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 "2019-10-18" --> 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 April 20, 2020. 50 Copyright Notice 52 Copyright (c) 2019 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 96 1. Introduction 98 This document defines three YANG 1.1 [RFC7950] modules: the first 99 defines a grouping for configuring a generic TCP client, the second 100 defines a grouping for configuring a generic TCP server, and the 101 third defines a grouping common to the TCP clients and TCP servers. 103 It is intended that these groupings will be used either standalone, 104 for TCP-based protocols, as part of a stack of protocol-specific 105 configuration models. For instance, these groupings could help 106 define the configuration module for SSH, TLS, or HTTP based 107 applications. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in BCP 114 14 [RFC2119] [RFC8174] when, and only when, they appear in all 115 capitals, as shown here. 117 3. The TCP Common Model 119 3.1. Model Scope 121 This document defines a common "grouping" statement for basic TCP 122 connection parameters that matter to applications. In some TCP 123 stacks, such parameters can also directly be set by an application 124 using system calls, such as the socket API. The base YANG model in 125 this document focuses on modeling TCP keep-alives. This base model 126 can be extended as needed. 128 3.2. Usage Guidelines for Configuring TCP Keep-Alives 130 Network stacks may include "keep-alives" in their TCP 131 implementations, although this practice is not universally accepted. 132 If keep-alives are included, [RFC1122] [RFC793bis] mandates that the 133 application MUST be able to turn them on or off for each TCP 134 connection, and that they MUST default to off. 136 Keep-alive mechanisms exist in many protocols. Depending on the 137 protocol stack, TCP keep-alives may only be one out of several 138 alternatives. Which mechanism to use depends on the use case and 139 application requirements. If keep-alives are needed by an 140 application, it is RECOMMENDED that the aliveness check happens at 141 the highest protocol layer possible that is meaningful to the 142 application, in order to maximize the depth of the aliveness check. 144 [[TODO: Further guidance on keep-alives is provided in draft-xyz- 145 tsvwg-... ]] 147 A TCP keep-alive mechanism should only be invoked in server 148 applications that might otherwise hang indefinitely and consume 149 resources unnecessarily if a client crashes or aborts a connection 150 during a network failure [RFC1122]. TCP keep-alives may consume 151 significant resources both in the network and in endpoints (e.g., 152 battery power). In addition, frequent keep-alives risk network 153 congestion. The higher the frequency of keep-alives, the higher the 154 overhead. 156 Given the cost of keep-alives, parameters have to be configured 157 carefully: 159 o The default idle interval (leaf "idle-time") MUST default to no 160 less than two hours, i.e., 7200 seconds [RFC1122]. A lower value 161 MAY be configured, but keep-alive messages SHOULD NOT be 162 transmitted more frequently than once every 15 seconds. Longer 163 intervals SHOULD be used when possible. 165 o The maximum number of sequential keep-alive probes that can fail 166 (leaf "max-probes") trades off responsiveness and robustness 167 against packet loss. ACK segments that contain no data are not 168 reliably transmitted by TCP. Consequently, if a keep-alive 169 mechanism is implemented it MUST NOT interpret failure to respond 170 to any specific probe as a dead connection [RFC1122]. Typically a 171 single-digit number should suffice. 173 o TCP implementations may include a parameter for the number of 174 seconds between TCP keep-alive probes (leaf "probe-interval"). In 175 order to avoid congestion, the time interval between probes MUST 176 NOT be smaller than one second. Significantly longer intervals 177 SHOULD be used. It is important to note that keep-alive probes 178 (or replies) can get dropped due to network congestion. Sending 179 further probe messages into a congested path after a short 180 interval, without backing off timers, could cause harm and result 181 in a congestion collapse. Therefore it is essential to pick a 182 large, conservative value for this interval. 184 3.3. Tree Diagram 186 This section provides a tree diagram [RFC8340] for the "ietf-tcp- 187 common" module. 189 module: ietf-tcp-common 191 grouping tcp-common-grouping 192 +-- keepalives! {keepalives-supported}? 193 +-- idle-time uint16 194 +-- max-probes uint16 195 +-- probe-interval uint16 196 grouping tcp-connection-grouping 197 +-- keepalives! {keepalives-supported}? 198 +-- idle-time uint16 199 +-- max-probes uint16 200 +-- probe-interval uint16 202 3.4. Example Usage 204 This section presents an example showing the tcp-common-grouping 205 populated with some data. 207 208 209 15 210 3 211 30 212 213 215 3.5. YANG Module 217 The ietf-tcp-common YANG module references [RFC6991]. 219 file "ietf-tcp-common@2019-10-18.yang" 221 module ietf-tcp-common { 222 yang-version 1.1; 223 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-common"; 224 prefix tcpcmn; 226 organization 227 "IETF NETCONF (Network Configuration) Working Group and the 228 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group"; 230 contact 231 "WG Web: 232 233 WG List: 234 235 Authors: Kent Watsen 236 Michael Scharf 237 "; 239 description 240 "This module defines reusable groupings for TCP commons that 241 can be used as a basis for specific TCP common instances. 243 Copyright (c) 2019 IETF Trust and the persons identified 244 as authors of the code. All rights reserved. 246 Redistribution and use in source and binary forms, with 247 or without modification, is permitted pursuant to, and 248 subject to the license terms contained in, the Simplified 249 BSD License set forth in Section 4.c of the IETF Trust's 250 Legal Provisions Relating to IETF Documents 251 (https://trustee.ietf.org/license-info). 253 This version of this YANG module is part of RFC XXXX 254 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 255 itself for full legal notices.; 257 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 258 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 259 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 260 are to be interpreted as described in BCP 14 (RFC 2119) 261 (RFC 8174) when, and only when, they appear in all 262 capitals, as shown here."; 264 revision 2019-10-18 { 265 description 266 "Initial version"; 267 reference 268 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers"; 269 } 271 // Features 272 feature keepalives-supported { 273 description 274 "Indicates that keepalives are supported."; 275 } 277 // Groupings 279 grouping tcp-common-grouping { 280 description 281 "A reusable grouping for configuring TCP parameters common 282 to TCP connections as well as the operating system as a 283 whole."; 284 container keepalives { 285 if-feature "keepalives-supported"; 286 presence "Indicates that keepalives are enabled."; 287 description 288 "Configures the keep-alive policy, to proactively test the 289 aliveness of the TCP peer. An unresponsive TCP peer is 290 dropped after approximately (idle-time + max-probes 291 * probe-interval) seconds."; 292 leaf idle-time { 293 type uint16 { 294 range "1..max"; 295 } 296 units "seconds"; 297 mandatory true; 298 description 299 "Sets the amount of time after which if no data has been 300 received from the TCP peer, a TCP-level probe message 301 will be sent to test the aliveness of the TCP peer. 302 Two hours (7200 seconds) is safe value, per RFC 1122."; 303 reference 304 "RFC 1122: 305 Requirements for Internet Hosts -- Communication Layers"; 306 } 307 leaf max-probes { 308 type uint16 { 309 range "1..max"; 310 } 311 mandatory true; 312 description 313 "Sets the maximum number of sequential keep-alive probes 314 that can fail to obtain a response from the TCP peer 315 before assuming the TCP peer is no longer alive."; 316 } 317 leaf probe-interval { 318 type uint16 { 319 range "1..max"; 320 } 321 units "seconds"; 322 mandatory true; 323 description 324 "Sets the time interval between failed probes. The interval 325 SHOULD be significantly longer than one second in order to 326 avoid harm on a congested link."; 327 } 328 } // container keepalives 329 } // grouping tcp-common-grouping 331 grouping tcp-connection-grouping { 332 description 333 "A reusable grouping for configuring TCP parameters common 334 to TCP connections."; 335 uses tcp-common-grouping; 336 } 338 /* 339 The following is for a future bis... 340 This comment is here now so as support discussion with TCPM. 341 This comment will be removed before publication. 343 Should future system-level parameters be defined as a 344 grouping or a container? 346 grouping tcp-system-grouping { 347 description 348 "A reusable grouping for configuring TCP parameters common 349 to the operating system as a whole."; 351 // currently just a placeholder 352 } 353 */ 355 } 357 359 4. The TCP Client Model 361 4.1. Tree Diagram 363 This section provides a tree diagram [RFC8340] for the "ietf-tcp- 364 client" module. 366 module: ietf-tcp-client 368 grouping tcp-client-grouping 369 +-- remote-address inet:host 370 +-- remote-port? inet:port-number 371 +-- local-address? inet:ip-address {local-binding-supported}? 372 +-- local-port? inet:port-number {local-binding-supported}? 373 +-- keepalives! {keepalives-supported}? 374 +-- idle-time uint16 375 +-- max-probes uint16 376 +-- probe-interval uint16 378 4.2. Example Usage 380 This section presents an example showing the tcp-client-grouping 381 populated with some data. 383 384 www.example.com 385 443 386 0.0.0.0 387 0 388 389 15 390 3 391 30 392 393 395 4.3. YANG Module 397 The ietf-tcp-client YANG module references [RFC6991]. 399 file "ietf-tcp-client@2019-10-18.yang" 401 module ietf-tcp-client { 402 yang-version 1.1; 403 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-client"; 404 prefix tcpc; 406 import ietf-inet-types { 407 prefix inet; 408 reference 409 "RFC 6991: Common YANG Data Types"; 410 } 412 import ietf-tcp-common { 413 prefix tcpcmn; 414 reference 415 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers"; 416 } 418 organization 419 "IETF NETCONF (Network Configuration) Working Group and the 420 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group"; 422 contact 423 "WG Web: 424 425 WG List: 426 427 Authors: Kent Watsen 428 Michael Scharf 429 "; 431 description 432 "This module defines reusable groupings for TCP clients that 433 can be used as a basis for specific TCP client instances. 435 Copyright (c) 2019 IETF Trust and the persons identified 436 as authors of the code. All rights reserved. 438 Redistribution and use in source and binary forms, with 439 or without modification, is permitted pursuant to, and 440 subject to the license terms contained in, the Simplified 441 BSD License set forth in Section 4.c of the IETF Trust's 442 Legal Provisions Relating to IETF Documents 443 (https://trustee.ietf.org/license-info). 445 This version of this YANG module is part of RFC XXXX 446 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 447 itself for full legal notices.; 449 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 450 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 451 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 452 are to be interpreted as described in BCP 14 (RFC 2119) 453 (RFC 8174) when, and only when, they appear in all 454 capitals, as shown here."; 456 revision 2019-10-18 { 457 description 458 "Initial version"; 459 reference 460 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers"; 461 } 463 // Features 465 feature local-binding-supported { 466 description 467 "Indicates that the server supports configuring local 468 bindings (i.e., the local address and local port) for 469 TCP clients."; 470 } 472 feature tcp-client-keepalives { 473 description 474 "Per socket TCP keepalive parameters are configurable for 475 TCP clients on the server implementing this feature."; 476 } 478 // Groupings 480 grouping tcp-client-grouping { 481 description 482 "A reusable grouping for configuring a TCP client. 484 Note that this grouping uses fairly typical descendent 485 node names such that a stack of 'uses' statements will 486 have name conflicts. It is intended that the consuming 487 data model will resolve the issue (e.g., by wrapping 488 the 'uses' statement in a container called 489 'tcp-client-parameters'). This model purposely does 490 not do this itself so as to provide maximum flexibility 491 to consuming models."; 493 leaf remote-address { 494 type inet:host; 495 mandatory true; 496 description 497 "The IP address or hostname of the remote peer to 498 establish a connection with. If a domain name is 499 configured, then the DNS resolution should happen on 500 each connection attempt. If the DNS resolution 501 results in multiple IP addresses, the IP addresses 502 are tried according to local preference order until 503 a connection has been established or until all IP 504 addresses have failed."; 505 } 506 leaf remote-port { 507 type inet:port-number; 508 default "0"; 509 description 510 "The IP port number for the remote peer to establish a 511 connection with. An invalid default value (0) is used 512 (instead of 'mandatory true') so that as application 513 level data model may 'refine' it with an application 514 specific default port number value."; 515 } 516 leaf local-address { 517 if-feature "local-binding-supported"; 518 type inet:ip-address; 519 description 520 "The local IP address/interface (VRF?) to bind to for when 521 connecting to the remote peer. INADDR_ANY ('0.0.0.0') or 522 INADDR6_ANY ('0:0:0:0:0:0:0:0' a.k.a. '::') MAY be used to 523 explicitly indicate the implicit default, that the server 524 can bind to any IPv4 or IPv6 addresses, respectively."; 525 } 526 leaf local-port { 527 if-feature "local-binding-supported"; 528 type inet:port-number; 529 default "0"; 530 description 531 "The local IP port number to bind to for when connecting 532 to the remote peer. The port number '0', which is the 533 default value, indicates that any available local port 534 number may be used."; 535 } 536 uses tcpcmn:tcp-connection-grouping { 537 augment "keepalives" { 538 if-feature "tcp-client-keepalives"; 539 description 540 "Add an if-feature statement so that implementations 541 can choose to support TCP client keepalives."; 542 } 543 } 544 } 545 } 547 549 5. The TCP Server Model 551 5.1. Tree Diagram 553 This section provides a tree diagram [RFC8340] for the "ietf-tcp- 554 server" module. 556 module: ietf-tcp-server 558 grouping tcp-server-grouping 559 +-- local-address inet:ip-address 560 +-- local-port? inet:port-number 561 +-- keepalives! {keepalives-supported}? 562 +-- idle-time uint16 563 +-- max-probes uint16 564 +-- probe-interval uint16 566 5.2. Example Usage 568 This section presents an example showing the tcp-server-grouping 569 populated with some data. 571 572 10.20.30.40 573 7777 574 575 15 576 3 577 30 578 579 581 5.3. YANG Module 583 The ietf-tcp-server YANG module references [RFC6991]. 585 file "ietf-tcp-server@2019-10-18.yang" 587 module ietf-tcp-server { 588 yang-version 1.1; 589 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-server"; 590 prefix tcps; 592 import ietf-inet-types { 593 prefix inet; 594 reference 595 "RFC 6991: Common YANG Data Types"; 596 } 598 import ietf-tcp-common { 599 prefix tcpcmn; 600 reference 601 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers"; 602 } 604 organization 605 "IETF NETCONF (Network Configuration) Working Group and the 606 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group"; 608 contact 609 "WG Web: 610 611 WG List: 612 613 Authors: Kent Watsen 614 Michael Scharf 615 "; 617 description 618 "This module defines reusable groupings for TCP servers that 619 can be used as a basis for specific TCP server instances. 621 Copyright (c) 2019 IETF Trust and the persons identified 622 as authors of the code. All rights reserved. 624 Redistribution and use in source and binary forms, with 625 or without modification, is permitted pursuant to, and 626 subject to the license terms contained in, the Simplified 627 BSD License set forth in Section 4.c of the IETF Trust's 628 Legal Provisions Relating to IETF Documents 629 (https://trustee.ietf.org/license-info). 631 This version of this YANG module is part of RFC XXXX 632 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 633 itself for full legal notices.; 635 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 636 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 637 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 638 are to be interpreted as described in BCP 14 (RFC 2119) 639 (RFC 8174) when, and only when, they appear in all 640 capitals, as shown here."; 642 revision 2019-10-18 { 643 description 644 "Initial version"; 645 reference 646 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers"; 647 } 649 // Features 651 feature tcp-server-keepalives { 652 description 653 "Per socket TCP keepalive parameters are configurable for 654 TCP servers on the server implementing this feature."; 655 } 657 // Groupings 659 grouping tcp-server-grouping { 660 description 661 "A reusable grouping for configuring a TCP server. 663 Note that this grouping uses fairly typical descendent 664 node names such that a stack of 'uses' statements will 665 have name conflicts. It is intended that the consuming 666 data model will resolve the issue (e.g., by wrapping 667 the 'uses' statement in a container called 668 'tcp-server-parameters'). This model purposely does 669 not do this itself so as to provide maximum flexibility 670 to consuming models."; 671 leaf local-address { 672 type inet:ip-address; 673 mandatory true; 674 description 675 "The local IP address to listen on for incoming 676 TCP client connections. INADDR_ANY (0.0.0.0) or 677 INADDR6_ANY (0:0:0:0:0:0:0:0 a.k.a. ::) MUST be 678 used when the server is to listen on all IPv4 or 679 IPv6 addresses, respectively."; 680 } 681 leaf local-port { 682 type inet:port-number; 683 default "0"; 684 description 685 "The local port number to listen on for incoming TCP 686 client connections. An invalid default value (0) 687 is used (instead of 'mandatory true') so that an 688 application level data model may 'refine' it with 689 an application specific default port number value."; 690 } 691 uses tcpcmn:tcp-connection-grouping { 692 augment "keepalives" { 693 if-feature "tcp-server-keepalives"; 694 description 695 "Add an if-feature statement so that implementations 696 can choose to support TCP server keepalives."; 697 } 698 } 699 } 700 } 702 704 6. Security Considerations 706 The YANG modules defined in this document are designed to be accessed 707 via YANG based management protocols, such as NETCONF [RFC6241] and 708 RESTCONF [RFC8040]. Both of these protocols have mandatory-to- 709 implement secure transport layers (e.g., SSH, TCP) with mutual 710 authentication. 712 The NETCONF access control model (NACM) [RFC8341] provides the means 713 to restrict access for particular users to a pre-configured subset of 714 all available protocol operations and content. 716 Since the modules defined in this document only define groupings, 717 these considerations are primarily for the designers of other modules 718 that use these groupings. 720 There are a number of data nodes defined in the YANG modules that are 721 writable/creatable/deletable (i.e., config true, which is the 722 default). These data nodes may be considered sensitive or vulnerable 723 in some network environments. Write operations (e.g., edit-config) 724 to these data nodes without proper protection can have a negative 725 effect on network operations. These are the subtrees and data nodes 726 and their sensitivity/vulnerability: 728 None of the writable/creatable/deletable data nodes in 729 the YANG modules defined in this document are considered more 730 sensitive or vulnerable then standard configuration. 732 Some of the readable data nodes in the YANG modules may be considered 733 sensitive or vulnerable in some network environments. It is thus 734 important to control read access (e.g., via get, get-config, or 735 notification) to these data nodes. These are the subtrees and data 736 nodes and their sensitivity/vulnerability: 738 None of the readable data nodes in the YANG modules 739 defined in this document are considered more sensitive or vulnerable 740 then standard configuration. 742 This document does not define any RPC actions and hence this section 743 does not consider the security of RPCs. 745 7. IANA Considerations 747 7.1. The IETF XML Registry 749 This document registers two URIs in the "ns" subregistry of the IETF 750 XML Registry [RFC3688]. Following the format in [RFC3688], the 751 following registrations are requested: 753 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-client 754 Registrant Contact: The NETCONF WG of the IETF. 755 XML: N/A, the requested URI is an XML namespace. 757 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-server 758 Registrant Contact: The NETCONF WG of the IETF. 759 XML: N/A, the requested URI is an XML namespace. 761 7.2. The YANG Module Names Registry 763 This document registers two YANG modules in the YANG Module Names 764 registry [RFC6020]. Following the format in [RFC6020], the following 765 registrations are requested: 767 name: ietf-tcp-common 768 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-common 769 prefix: tcpcmn 770 reference: RFC XXXX 772 name: ietf-tcp-client 773 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-client 774 prefix: tcpc 775 reference: RFC XXXX 777 name: ietf-tcp-server 778 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-server 779 prefix: tcps 780 reference: RFC XXXX 782 8. References 784 8.1. Normative References 786 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 787 Requirement Levels", BCP 14, RFC 2119, 788 DOI 10.17487/RFC2119, March 1997, 789 . 791 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 792 the Network Configuration Protocol (NETCONF)", RFC 6020, 793 DOI 10.17487/RFC6020, October 2010, 794 . 796 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 797 RFC 6991, DOI 10.17487/RFC6991, July 2013, 798 . 800 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 801 RFC 7950, DOI 10.17487/RFC7950, August 2016, 802 . 804 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 805 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 806 May 2017, . 808 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 809 Access Control Model", STD 91, RFC 8341, 810 DOI 10.17487/RFC8341, March 2018, 811 . 813 8.2. Informative References 815 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 816 DOI 10.17487/RFC3688, January 2004, 817 . 819 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 820 and A. Bierman, Ed., "Network Configuration Protocol 821 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 822 . 824 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 825 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 826 . 828 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 829 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 830 . 832 Appendix A. Change Log 834 A.1. 00 to 01 836 o Added 'local-binding-supported' feature to TCP-client model. 838 o Added 'keepalives-supported' feature to TCP-common model. 840 o Added 'external-endpoint-values' container and 'external- 841 endpoints' feature to TCP-server model. 843 A.2. 01 to 02 845 o Removed the 'external-endpoint-values' container and 'external- 846 endpoints' feature from the TCP-server model. 848 A.3. 02 to 03 850 o Moved the common model section to be before the client and server 851 specific sections. 853 o Added sections "Model Scope" and "Usage Guidelines for Configuring 854 TCP Keep-Alives" to the common model section. 856 Authors' Addresses 858 Kent Watsen 859 Watsen Networks 861 EMail: kent+ietf@watsen.net 863 Michael Scharf 864 Hochschule Esslingen - University of Applied Sciences 866 EMail: michael.scharf@hs-esslingen.de