idnits 2.17.1 draft-scharf-tcpm-yang-tcp-05.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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 7, 2020) is 1381 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-26) exists of draft-ietf-netconf-tcp-client-server-06 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-17) exists of draft-ietf-idr-bgp-model-09 == Outdated reference: A later version (-26) exists of draft-ietf-taps-interface-06 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCPM M. Scharf 3 Internet-Draft Hochschule Esslingen 4 Intended status: Standards Track V. Murgai 5 Expires: January 8, 2021 6 M. Jethanandani 7 Kloud Services 8 July 7, 2020 10 YANG Model for Transmission Control Protocol (TCP) Configuration 11 draft-scharf-tcpm-yang-tcp-05 13 Abstract 15 This document specifies a YANG model for TCP on devices that are 16 configured by network management protocols. The YANG model defines a 17 container for all TCP connections and groupings of some of the 18 parameters that can be imported and used in TCP implementations or by 19 other models that need to configure TCP parameters. The model 20 includes definitions from YANG Groupings for TCP Client and TCP 21 Servers (I-D.ietf-netconf-tcp-client-server). The model is NMDA (RFC 22 8342) compliant. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 8, 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Note to RFC Editor . . . . . . . . . . . . . . . . . . . 3 61 3. Model Overview . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Modeling Scope . . . . . . . . . . . . . . . . . . . . . 3 63 3.2. Model Design . . . . . . . . . . . . . . . . . . . . . . 5 64 3.3. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 6 65 4. TCP YANG Model . . . . . . . . . . . . . . . . . . . . . . . 6 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 67 5.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 13 68 5.2. The YANG Module Names Registry . . . . . . . . . . . . . 13 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 72 7.2. Informative References . . . . . . . . . . . . . . . . . 15 73 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16 74 Appendix B. Changes compared to previous versions . . . . . . . 16 75 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 17 76 C.1. Keepalive Configuration . . . . . . . . . . . . . . . . . 17 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 79 1. Introduction 81 The Transmission Control Protocol (TCP) [RFC0793] is used by many 82 applications in the Internet, including control and management 83 protocols. Therefore, TCP is implemented on network elements that 84 can be configured via network management protocols such as NETCONF 85 [RFC6241] or RESTCONF [RFC8040]. This document specifies a YANG 86 [RFC7950] 1.1 model for configuring TCP on network elements that 87 support YANG data models, and is Network Management Datastore 88 Architecture (NMDA) [RFC8342] compliant. This module defines a 89 container for TCP connection, and includes definitions from YANG 90 Groupings for TCP Clients and TCP Servers 91 [I-D.ietf-netconf-tcp-client-server]. The model focuses on 92 fundamental and standard TCP functions that are widely implemented. 93 The model can be augmented or updated to address more advanced or 94 implementation-specific TCP features in the future. 96 Many protocol stacks on Internet hosts use other methods to configure 97 TCP, such as operating system configuration or policies. Many TCP/IP 98 stacks cannot be configured by network management protocols such as 99 NETCONF [RFC6241] or RESTCONF [RFC8040]. Moreover, many existing 100 TCP/IP stacks do not use YANG data models. Such TCP implementations 101 often have other means to configure the parameters listed in this 102 document, which are outside the scope of this document. 104 This specification is orthogonal to Management Information Base (MIB) 105 for the Transmission Control Protocol (TCP) [RFC4022]. The TCP 106 Extended Statistics MIB [RFC4898] is also available. It is possible 107 to translate a MIB into a YANG model, for instance using Translation 108 of Structure of Management Information Version 2 (SMIv2) MIB Modules 109 to YANG Modules [RFC6643]. However, this approach is not used in 110 this document, as such a translated model would not be up-to-date. 112 2. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described in BCP 117 14 [RFC2119] [RFC8174] when, and only when, they appear in all 118 capitals, as shown here. 120 2.1. Note to RFC Editor 122 This document uses several placeholder values throughout the 123 document. Please replace them as follows and remove this note before 124 publication. 126 RFC XXXX, where XXXX is the number assigned to this document at the 127 time of publication. 129 2020-07-07 with the actual date of the publication of this document. 131 3. Model Overview 133 3.1. Modeling Scope 135 TCP is implemented on many different system architectures. As a 136 result, there are may different and often implementation-specific 137 ways to configure parameters of the TCP protocol engine. In 138 addition, in many TCP/IP stacks configuration exists for different 139 scopes: 141 o Global configuration: Many TCP implementations have configuration 142 parameters that affect all TCP connections. Typical examples 143 include enabling or disabling optional protocol features. 145 o Interface configuration: It can be useful to use different TCP 146 parameters on different interfaces, e.g., different device ports 147 or IP interfaces. In that case, TCP parameters can be part of the 148 interface configuration. Typical examples are the Maximum Segment 149 Size (MSS) or configuration related to hardware offloading. 151 o Connection parameters: Many implementations have means to 152 influence the behavior of each TCP connection, e.g., on the 153 programming interface used by applications. A typical example are 154 socket options in the socket API, such as disabling the Nagle 155 algorithm by TCP_NODELAY. If an application uses such an 156 interface, it is possible that the configuration of the 157 application or application protocol includes TCP-related 158 parameters. An example is the BGP YANG Model for Service Provider 159 Networks [I-D.ietf-idr-bgp-model]. 161 o Policies: Setting of TCP parameters can also be part of system 162 policies, templates, or profiles. An example would be the 163 preferences defined in the TAPS interface An Abstract Application 164 Layer Interface to Transport Services [I-D.ietf-taps-interface]. 166 As a result, there is no ground truth for setting certain TCP 167 parameters, and traditionally different TCP implementation have used 168 different modeling approaches. For instance, one implementation may 169 define a given configuration parameter globally, while another one 170 uses per-interface settings, and both approaches work well for the 171 corresponding use cases. Also, different systems may use different 172 default values. 174 In addition, TCP can be implemented in different ways and design 175 choices by the protocol engine often affect configuration options. 176 In a number of areas there are known differences between different 177 TCP stack architectures. This includes amongst others: 179 o Window size: TCP stacks can either store window state variables 180 (such as the congestion window) in segments or in bytes. 182 o Buffer sizes: The memory management depends on the operating 183 system. As the size of buffers can vary over several orders of 184 magnitude, very different implementations exist. This typically 185 influences TCP flow control. 187 o Timers: Timer implementation is another area in which TCP stacks 188 may differ. 190 Nonetheless, there are a number of basic system parameters that are 191 configurable on many TCP implementations, even if not all TCP 192 implementations may indeed have all these settings, and even if there 193 are differences regarding syntax and semantics. This document 194 focuses on modeling such basic parameters directly following from 195 standards. 197 In addition to configuration of the TCP protocol engine, a TCP 198 implementation typically also offers access to operational state and 199 statistics. This includes amongst others: 201 o Statistics: Counters for the number of active/passive opens, sent 202 and received segments, errors, and possibly other detailed 203 debugging information 205 o TCP connection table: Access to status information for all TCP 206 connections 208 o TCP listener table: Information about all TCP listening endpoints 210 3.2. Model Design 212 This document models fundamental system parameters that are 213 configurable on many TCP implementations, and for which the 214 configuration is reasonably similar. Similar to the TCP MIB 215 [RFC4022], this document also specifies a TCP connection table. This 216 enables both global and connection-specific TCP configuration. 218 An important use case is the TCP configuration on network elements 219 such as routers, which often use YANG data models. The model 220 therefore specifies TCP parameters that are important on such TCP 221 stacks. A typical example is the support of TCP-AO [RFC5925]. TCP- 222 AO is increasingly supported on routers and it requires 223 configuration. 225 The YANG model defined in this document includes definitions from the 226 YANG Groupings for TCP Clients and TCP Servers 227 [I-D.ietf-netconf-tcp-client-server]. Similar to that model, this 228 specification defines YANG groupings. This allows reuse of these 229 groupings in different YANG data models. It is intended that these 230 groupings will be used either standalone or for TCP-based protocols 231 as part of a stack of protocol-specific configuration models. An 232 example could be the BGP YANG Model for Service Provider Networks 233 [I-D.ietf-idr-bgp-model]. 235 There are also other existing TCP-related YANG models, which are 236 othogonal to this specification. Examples are: 238 o TCP header attributes are modeled in other models, such as YANG 239 Data Model for Network Access Control Lists (ACLs) [RFC8519] and 240 Distributed Denial-of-Service Open Thread Signaling (DOTS) Data 241 Channel Specification [I-D.ietf-dots-data-channel]. 243 o TCP-related configuration of a NAT (e.g., NAT44, NAT64, 244 Destination NAT, ...) is defined in A YANG Module for Network 245 Address Translation (NAT) and Network Prefix Translation (NPT) 246 [RFC8512] and A YANG Data Model for Dual-Stack Lite (DS-Lite) 247 [RFC8513]. 249 3.3. Tree Diagram 251 This section provides a abridged tree diagram for the YANG module 252 defined in this document. Annotations used in the diagram are 253 defined in YANG Tree Diagrams [RFC8340]. 255 module: ietf-tcp 256 +--rw tcp! 257 +--rw connections 258 | ... 259 +--rw server {server}? 260 | ... 261 +--rw client {client}? 262 | ... 263 +--ro statistics {statistics}? 264 ... 266 4. TCP YANG Model 268 file "ietf-tcp@2020-07-07.yang" 270 module ietf-tcp { 271 yang-version "1.1"; 272 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp"; 273 prefix "tcp"; 275 import ietf-yang-types { 276 prefix "yang"; 277 reference 278 "RFC 6991: Common YANG Data Types."; 279 } 280 import ietf-tcp-client { 281 prefix "tcpc"; 282 } 283 import ietf-tcp-server { 284 prefix "tcps"; 285 } 286 import ietf-tcp-common { 287 prefix "tcpcmn"; 289 } 290 import ietf-inet-types { 291 prefix "inet"; 292 } 294 organization 295 "IETF TCPM Working Group"; 297 contact 298 "WG Web: 299 WG List: 301 Authors: Michael Scharf (michael.scharf at hs-esslingen dot de) 302 Vishal Murgai (vmurgai at gmail dot com) 303 Mahesh Jethanandani (mjethanandani at gmail dot com)"; 305 description 306 "This module focuses on fundamental and standard TCP functions 307 that widely implemented. The model can be augmented to address 308 more advanced or implementation specific TCP features."; 310 revision "2020-07-07" { 311 description 312 "Initial Version"; 313 reference 314 "RFC XXX, TCP Configuration."; 315 } 317 // Features 318 feature server { 319 description 320 "TCP Server configuration supported."; 321 } 323 feature client { 324 description 325 "TCP Client configuration supported."; 326 } 328 feature statistics { 329 description 330 "This implementation supports statistics reporting."; 331 } 333 // TCP-AO Groupings 335 grouping ao { 336 leaf enable-ao { 337 type boolean; 338 default "false"; 339 description 340 "Enable support of TCP-Authentication Option (TCP-AO)."; 341 } 343 leaf send-id { 344 type uint8 { 345 range "0..255"; 346 } 347 must "../enable-ao = 'true'"; 348 description 349 "The SendID is inserted as the KeyID of the TCP-AO option 350 of outgoing segments."; 351 reference 352 "RFC 5925: The TCP Authentication Option."; 353 } 355 leaf recv-id { 356 type uint8 { 357 range "0..255"; 358 } 359 must "../enable-ao = 'true'"; 360 description 361 "The RecvID is matched against the TCP-AO KeyID of incoming 362 segments."; 363 reference 364 "RFC 5925: The TCP Authentication Option."; 365 } 367 leaf include-tcp-options { 368 type boolean; 369 must "../enable-ao = 'true'"; 370 description 371 "Include TCP options in HMAC calculation."; 372 } 374 leaf accept-ao-mismatch { 375 type boolean; 376 must "../enable-ao = 'true'"; 377 description 378 "Accept packets with HMAC mismatch."; 379 } 380 description 381 "Authentication Option (AO) for TCP."; 382 reference 383 "RFC 5925: The TCP Authentication Option."; 384 } 385 // MD5 grouping 387 grouping md5 { 388 description 389 "Grouping for use in authenticating TCP sessions using MD5."; 390 reference 391 "RFC 2385: Protection of BGP Sessions via the TCP MD5 392 Signature."; 394 leaf enable-md5 { 395 type boolean; 396 default "false"; 397 description 398 "Enable support of MD5 to authenticate a TCP session."; 399 } 400 } 402 // TCP configuration 404 container tcp { 405 presence "The container for TCP configuration."; 407 description 408 "TCP container."; 410 container connections { 411 list connection { 412 key "local-address remote-address local-port remote-port"; 414 leaf local-address { 415 type inet:ip-address; 416 description 417 "Local address that forms the connection identifier."; 418 } 420 leaf remote-address { 421 type inet:ip-address; 422 description 423 "Remote address that forms the connection identifier."; 424 } 426 leaf local-port { 427 type inet:port-number; 428 description 429 "Local TCP port that forms the connection identifier."; 430 } 432 leaf remote-port { 433 type inet:port-number; 434 description 435 "Remote TCP port that forms the connection identifier."; 436 } 438 container common { 439 uses tcpcmn:tcp-common-grouping; 441 choice authentication { 442 case ao { 443 uses ao; 444 description 445 "Use TCP-AO to secure the connection."; 446 } 448 case md5 { 449 uses md5; 450 description 451 "Use TCP-MD5 to secure the connection."; 452 } 453 description 454 "Choice of how to secure the TCP connection."; 455 } 456 description 457 "Common definitions of TCP configuration. This includes 458 parameters such as how to secure the connection, 459 that can be part of either the client or server."; 460 } 461 description 462 "Connection related parameters."; 463 } 464 description 465 "A container of all TCP connections."; 466 } 468 container server { 469 if-feature server; 470 uses tcps:tcp-server-grouping; 471 description 472 "Definitions of TCP server configuration."; 473 } 475 container client { 476 if-feature client; 477 uses tcpc:tcp-client-grouping; 478 description 479 "Definitions of TCP client configuration."; 480 } 481 container statistics { 482 if-feature statistics; 483 config false; 485 leaf active-opens { 486 type yang:counter32; 487 description 488 "The number of times that TCP connections have made a direct 489 transition to the SYN-SENT state from the CLOSED state."; 490 } 492 leaf passive-opens { 493 type yang:counter32; 494 description 495 "The number of times TCP connections have made a direct 496 transition to the SYN-RCVD state from the LISTEN state."; 497 } 499 leaf attempt-fails { 500 type yang:counter32; 501 description 502 "The number of times that TCP connections have made a direct 503 transition to the CLOSED state from either the SYN-SENT 504 state or the SYN-RCVD state, plus the number of times that 505 TCP connections have made a direct transition to the 506 LISTEN state from the SYN-RCVD state."; 507 } 509 leaf establish-resets { 510 type yang:counter32; 511 description 512 "The number of times that TCP connections have made a direct 513 transition to the CLOSED state from either the ESTABLISHED 514 state or the CLOSE-WAIT state."; 515 } 517 leaf currently-established { 518 type yang:gauge32; 519 description 520 "The number of TCP connections for which the current state 521 is either ESTABLISHED or CLOSE-WAIT."; 522 } 524 leaf in-segments { 525 type yang:counter64; 526 description 527 "The total number of segments received, including those 528 received in error. This count includes segments received 529 on currently established connections."; 530 } 532 leaf out-segments { 533 type yang:counter64; 534 description 535 "The total number of segments sent, including those on 536 current connections but excluding those containing only 537 retransmitted octets."; 538 } 540 leaf retransmitted-segments { 541 type yang:counter32; 542 description 543 "The total number of segments retransmitted; that is, the 544 number of TCP segments transmitted containing one or more 545 previously transmitted octets."; 546 } 548 leaf in-errors { 549 type yang:counter32; 550 description 551 "The total number of segments received in error (e.g., bad 552 TCP checksums)."; 553 } 555 leaf out-resets { 556 type yang:counter32; 557 description 558 "The number of TCP segments sent containing the RST flag."; 559 } 561 action reset { 562 description 563 "Reset statistics action command."; 564 input { 565 leaf reset-at { 566 type yang:date-and-time; 567 description 568 "Time when the reset action needs to be 569 executed."; 570 } 571 } 572 output { 573 leaf reset-finished-at { 574 type yang:date-and-time; 575 description 576 "Time when the reset action command completed."; 578 } 579 } 580 } 581 description 582 "Statistics across all connections."; 583 } 584 } 585 } 587 589 5. IANA Considerations 591 5.1. The IETF XML Registry 593 This document registers two URIs in the "ns" subregistry of the IETF 594 XML Registry [RFC3688]. Following the format in IETF XML Registry 595 [RFC3688], the following registrations are requested: 597 URI: urn:ietf:params:xml:ns:yang:ietf-tcp 598 Registrant Contact: The TCPM WG of the IETF. 599 XML: N/A, the requested URI is an XML namespace. 601 5.2. The YANG Module Names Registry 603 This document registers a YANG modules in the YANG Module Names 604 registry YANG - A Data Modeling Language [RFC6020]. Following the 605 format in YANG - A Data Modeling Language [RFC6020], the following 606 registrations are requested: 608 name: ietf-tcp 609 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp 610 prefix: tcp 611 reference: RFC XXXX 613 6. Security Considerations 615 The YANG module specified in this document defines a schema for data 616 that is designed to be accessed via network management protocols such 617 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 618 is the secure transport layer, and the mandatory-to-implement secure 619 transport is Secure Shell (SSH) described in Using the NETCONF 620 protocol over SSH [RFC6242]. The lowest RESTCONF layer is HTTPS, and 621 the mandatory-to-implement secure transport is TLS [RFC8446]. 623 The Network Configuration Access Control Model (NACM) [RFC8341] 624 provides the means to restrict access for particular NETCONF or 625 RESTCONF users to a preconfigured subset of all available NETCONF or 626 RESTCONF protocol operations and content. 628 7. References 630 7.1. Normative References 632 [I-D.ietf-netconf-tcp-client-server] 633 Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients 634 and TCP Servers", draft-ietf-netconf-tcp-client-server-06 635 (work in progress), June 2020. 637 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 638 RFC 793, DOI 10.17487/RFC0793, September 1981, 639 . 641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 642 Requirement Levels", BCP 14, RFC 2119, 643 DOI 10.17487/RFC2119, March 1997, 644 . 646 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 647 DOI 10.17487/RFC3688, January 2004, 648 . 650 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 651 the Network Configuration Protocol (NETCONF)", RFC 6020, 652 DOI 10.17487/RFC6020, October 2010, 653 . 655 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 656 and A. Bierman, Ed., "Network Configuration Protocol 657 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 658 . 660 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 661 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 662 . 664 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 665 RFC 7950, DOI 10.17487/RFC7950, August 2016, 666 . 668 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 669 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 670 . 672 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 673 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 674 May 2017, . 676 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 677 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 678 . 680 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 681 Access Control Model", STD 91, RFC 8341, 682 DOI 10.17487/RFC8341, March 2018, 683 . 685 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 686 and R. Wilton, "Network Management Datastore Architecture 687 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 688 . 690 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 691 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 692 . 694 7.2. Informative References 696 [I-D.ietf-dots-data-channel] 697 Boucadair, M. and T. Reddy.K, "Distributed Denial-of- 698 Service Open Threat Signaling (DOTS) Data Channel 699 Specification", draft-ietf-dots-data-channel-31 (work in 700 progress), July 2019. 702 [I-D.ietf-idr-bgp-model] 703 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 704 YANG Model for Service Provider Networks", draft-ietf-idr- 705 bgp-model-09 (work in progress), June 2020. 707 [I-D.ietf-taps-interface] 708 Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., 709 Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T. 710 Pauly, "An Abstract Application Layer Interface to 711 Transport Services", draft-ietf-taps-interface-06 (work in 712 progress), March 2020. 714 [RFC4022] Raghunarayan, R., Ed., "Management Information Base for 715 the Transmission Control Protocol (TCP)", RFC 4022, 716 DOI 10.17487/RFC4022, March 2005, 717 . 719 [RFC4898] Mathis, M., Heffner, J., and R. Raghunarayan, "TCP 720 Extended Statistics MIB", RFC 4898, DOI 10.17487/RFC4898, 721 May 2007, . 723 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 724 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 725 June 2010, . 727 [RFC6643] Schoenwaelder, J., "Translation of Structure of Management 728 Information Version 2 (SMIv2) MIB Modules to YANG 729 Modules", RFC 6643, DOI 10.17487/RFC6643, July 2012, 730 . 732 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 733 Vinapamula, S., and Q. Wu, "A YANG Module for Network 734 Address Translation (NAT) and Network Prefix Translation 735 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 736 . 738 [RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG 739 Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, 740 DOI 10.17487/RFC8513, January 2019, 741 . 743 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 744 "YANG Data Model for Network Access Control Lists (ACLs)", 745 RFC 8519, DOI 10.17487/RFC8519, March 2019, 746 . 748 Appendix A. Acknowledgements 750 Michael Scharf was supported by the StandICT.eu project, which is 751 funded by the European Commission under the Horizon 2020 Programme. 753 The following persons have contributed to this document by reviews: 754 Mohamed Boucadair 756 Appendix B. Changes compared to previous versions 758 Changes compared to draft-scharf-tcpm-yang-tcp-04 760 o Removed congestion control 762 o Removed global stack parameters 764 Changes compared to draft-scharf-tcpm-yang-tcp-03 766 o Updated TCP-AO grouping 767 o Added congestion control 769 Changes compared to draft-scharf-tcpm-yang-tcp-02 771 o Initial proposal of a YANG model including base configuration 772 parameters, TCP-AO configuration, and a connection list 774 o Editorial bugfixes and outdated references reported by Mohamed 775 Boucadair 777 o Additional co-author Mahesh Jethanandani 779 Changes compared to draft-scharf-tcpm-yang-tcp-01 781 o Alignment with [I-D.ietf-netconf-tcp-client-server] 783 o Removing backward-compatibility to the TCP MIB 785 o Additional co-author Vishal Murgai 787 Changes compared to draft-scharf-tcpm-yang-tcp-00 789 o Editorial improvements 791 Appendix C. Examples 793 C.1. Keepalive Configuration 795 This particular example demonstrates how both a particular connection 796 can be configured for keepalives. 798 799 804 805 807 808 809 192.168.1.1 810 192.168.1.2 811 1025 812 80 813 814 815 5 816 5 817 10 818 819 820 821 822 828 829 192.168.1.1 830 831 832 192.168.1.2 833 834 835 837 Authors' Addresses 839 Michael Scharf 840 Hochschule Esslingen - University of Applied Sciences 841 Flandernstr. 101 842 Esslingen 73732 843 Germany 845 Email: michael.scharf@hs-esslingen.de 846 Vishal Murgai 848 Email: vmurgai@gmail.com 850 Mahesh Jethanandani 851 Kloud Services 853 Email: mjethanandani@gmail.com