idnits 2.17.1 draft-ietf-tcpm-yang-tcp-00.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 date (October 29, 2020) is 1274 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-08 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) == 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-09 Summary: 2 errors (**), 0 flaws (~~), 4 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: May 2, 2021 6 M. Jethanandani 7 Kloud Services 8 October 29, 2020 10 YANG Model for Transmission Control Protocol (TCP) Configuration 11 draft-ietf-tcpm-yang-tcp-00 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 May 2, 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 . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Modeling Scope . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 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 has a narrow scope 92 and focuses on fundamental TCP functions and basic statistics. The 93 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 the Management Information Base 105 (MIB) for the Transmission Control Protocol (TCP) [RFC4022]. The 106 basic statistics defined in this document follow the model of the TCP 107 MIB. An TCP Extended Statistics MIB [RFC4898] is also available, but 108 this document does not cover such extended statistics. It is 109 possible also to translate a MIB into a YANG model, for instance 110 using Translation of Structure of Management Information Version 2 111 (SMIv2) MIB Modules to YANG Modules [RFC6643]. However, this 112 approach is not used in this document, as such a translated model 113 would not be up-to-date. 115 There are other existing TCP-related YANG models, which are othogonal 116 to this specification. Examples are: 118 o TCP header attributes are modeled in other models, such as YANG 119 Data Model for Network Access Control Lists (ACLs) [RFC8519] and 120 Distributed Denial-of-Service Open Thread Signaling (DOTS) Data 121 Channel Specification [I-D.ietf-dots-data-channel]. 123 o TCP-related configuration of a NAT (e.g., NAT44, NAT64, 124 Destination NAT, ...) is defined in A YANG Module for Network 125 Address Translation (NAT) and Network Prefix Translation (NPT) 126 [RFC8512] and A YANG Data Model for Dual-Stack Lite (DS-Lite) 127 [RFC8513]. 129 2. Requirements Language 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 133 "OPTIONAL" in this document are to be interpreted as described in BCP 134 14 [RFC2119] [RFC8174] when, and only when, they appear in all 135 capitals, as shown here. 137 2.1. Note to RFC Editor 139 This document uses several placeholder values throughout the 140 document. Please replace them as follows and remove this note before 141 publication. 143 RFC XXXX, where XXXX is the number assigned to this document at the 144 time of publication. 146 2020-10-29 with the actual date of the publication of this document. 148 3. Model Overview 150 3.1. Modeling Scope 152 TCP is implemented on many different system architectures. As a 153 result, there are may different and often implementation-specific 154 ways to configure parameters of the TCP protocol engine. In 155 addition, in many TCP/IP stacks configuration exists for different 156 scopes: 158 o Global configuration: Many TCP implementations have configuration 159 parameters that affect all TCP connections. Typical examples 160 include enabling or disabling optional protocol features. 162 o Interface configuration: It can be useful to use different TCP 163 parameters on different interfaces, e.g., different device ports 164 or IP interfaces. In that case, TCP parameters can be part of the 165 interface configuration. Typical examples are the Maximum Segment 166 Size (MSS) or configuration related to hardware offloading. 168 o Connection parameters: Many implementations have means to 169 influence the behavior of each TCP connection, e.g., on the 170 programming interface used by applications. A typical example are 171 socket options in the socket API, such as disabling the Nagle 172 algorithm by TCP_NODELAY. If an application uses such an 173 interface, it is possible that the configuration of the 174 application or application protocol includes TCP-related 175 parameters. An example is the BGP YANG Model for Service Provider 176 Networks [I-D.ietf-idr-bgp-model]. 178 o Policies: Setting of TCP parameters can also be part of system 179 policies, templates, or profiles. An example would be the 180 preferences defined in An Abstract Application Layer Interface to 181 Transport Services [I-D.ietf-taps-interface]. 183 As a result, there is no ground truth for setting certain TCP 184 parameters, and traditionally different TCP implementation have used 185 different modeling approaches. For instance, one implementation may 186 define a given configuration parameter globally, while another one 187 uses per-interface settings, and both approaches work well for the 188 corresponding use cases. Also, different systems may use different 189 default values. In addition, TCP can be implemented in different 190 ways and design choices by the protocol engine often affect 191 configuration options. 193 Nonetheless, a number of TCP stack parameters require configuration 194 by YANG models. This document therefore defines a minimal YANG model 195 with fundamental parameters directly following from TCP standards. 197 An important use case is the TCP configuration on network elements 198 such as routers, which often use YANG data models. The model 199 therefore specifies TCP parameters that are important on such TCP 200 stacks. A typical example is the support of TCP-AO [RFC5925]. TCP- 201 AO is increasingly supported on routers to secure routing protocols 202 such as BGP. In that case, TCP-AO configuration is required on 203 routers. 205 Given an installed base, the model also allows enabling of the legacy 206 TCP MD5 [RFC2385] signature option. As the TCP MD5 signature option 207 is obsoleted by TCP-AO, it is strongly RECOMMENDED to use TCP-AO. 209 Similar to the TCP MIB [RFC4022], this document also specifies basic 210 statistics and a TCP connection table. 212 o Statistics: Counters for the number of active/passive opens, sent 213 and received segments, errors, and possibly other detailed 214 debugging information 216 o TCP connection table: Access to status information for all TCP 217 connections 219 This allows implementations of TCP MIB [RFC4022] to migrate to the 220 YANG model defined in this memo. 222 3.2. Model Design 224 The YANG model defined in this document includes definitions from the 225 YANG Groupings for TCP Clients and TCP Servers 226 [I-D.ietf-netconf-tcp-client-server]. Similar to that model, this 227 specification defines YANG groupings. This allows reuse of these 228 groupings in different YANG data models. It is intended that these 229 groupings will be used either standalone or for TCP-based protocols 230 as part of a stack of protocol-specific configuration models. An 231 example could be the BGP YANG Model for Service Provider Networks 232 [I-D.ietf-idr-bgp-model]. 234 3.3. Tree Diagram 236 This section provides a abridged tree diagram for the YANG module 237 defined in this document. Annotations used in the diagram are 238 defined in YANG Tree Diagrams [RFC8340]. 240 module: ietf-tcp 241 +--rw tcp! 242 +--rw connections 243 | ... 244 +--rw server {server}? 245 | ... 246 +--rw client {client}? 247 | ... 248 +--ro statistics {statistics}? 249 ... 251 4. TCP YANG Model 253 file "ietf-tcp@2020-10-29.yang" 255 module ietf-tcp { 256 yang-version "1.1"; 257 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp"; 258 prefix "tcp"; 260 import ietf-yang-types { 261 prefix "yang"; 262 reference 263 "RFC 6991: Common YANG Data Types."; 264 } 265 import ietf-tcp-client { 266 prefix "tcpc"; 267 } 268 import ietf-tcp-server { 269 prefix "tcps"; 270 } 271 import ietf-tcp-common { 272 prefix "tcpcmn"; 273 } 274 import ietf-inet-types { 275 prefix "inet"; 276 } 278 organization 279 "IETF TCPM Working Group"; 281 contact 282 "WG Web: 283 WG List: 285 Authors: Michael Scharf (michael.scharf at hs-esslingen dot de) 286 Vishal Murgai (vmurgai at gmail dot com) 287 Mahesh Jethanandani (mjethanandani at gmail dot com)"; 289 description 290 "This module focuses on fundamental and standard TCP functions 291 that widely implemented. The model can be augmented to address 292 more advanced or implementation specific TCP features."; 294 revision "2020-10-29" { 295 description 296 "Initial Version"; 297 reference 298 "RFC XXX, TCP Configuration."; 299 } 301 // Features 302 feature server { 303 description 304 "TCP Server configuration supported."; 305 } 307 feature client { 308 description 309 "TCP Client configuration supported."; 310 } 312 feature statistics { 313 description 314 "This implementation supports statistics reporting."; 315 } 317 // TCP-AO Groupings 319 grouping ao { 320 leaf enable-ao { 321 type boolean; 322 default "false"; 323 description 324 "Enable support of TCP-Authentication Option (TCP-AO)."; 325 } 327 leaf send-id { 328 type uint8 { 329 range "0..255"; 331 } 332 must "../enable-ao = 'true'"; 333 description 334 "The SendID is inserted as the KeyID of the TCP-AO option 335 of outgoing segments."; 336 reference 337 "RFC 5925: The TCP Authentication Option."; 338 } 340 leaf recv-id { 341 type uint8 { 342 range "0..255"; 343 } 344 must "../enable-ao = 'true'"; 345 description 346 "The RecvID is matched against the TCP-AO KeyID of incoming 347 segments."; 348 reference 349 "RFC 5925: The TCP Authentication Option."; 350 } 352 leaf include-tcp-options { 353 type boolean; 354 must "../enable-ao = 'true'"; 355 description 356 "Include TCP options in HMAC calculation."; 357 } 359 leaf accept-ao-mismatch { 360 type boolean; 361 must "../enable-ao = 'true'"; 362 description 363 "Accept packets with HMAC mismatch."; 364 } 365 description 366 "Authentication Option (AO) for TCP."; 367 reference 368 "RFC 5925: The TCP Authentication Option."; 369 } 371 // MD5 grouping 373 grouping md5 { 374 description 375 "Grouping for use in authenticating TCP sessions using MD5."; 376 reference 377 "RFC 2385: Protection of BGP Sessions via the TCP MD5 378 Signature."; 380 leaf enable-md5 { 381 type boolean; 382 default "false"; 383 description 384 "Enable support of MD5 to authenticate a TCP session."; 385 } 386 } 388 // TCP configuration 390 container tcp { 391 presence "The container for TCP configuration."; 393 description 394 "TCP container."; 396 container connections { 397 list connection { 398 key "local-address remote-address local-port remote-port"; 400 leaf local-address { 401 type inet:ip-address; 402 description 403 "Local address that forms the connection identifier."; 404 } 406 leaf remote-address { 407 type inet:ip-address; 408 description 409 "Remote address that forms the connection identifier."; 410 } 412 leaf local-port { 413 type inet:port-number; 414 description 415 "Local TCP port that forms the connection identifier."; 416 } 418 leaf remote-port { 419 type inet:port-number; 420 description 421 "Remote TCP port that forms the connection identifier."; 422 } 424 container common { 425 uses tcpcmn:tcp-common-grouping; 427 choice authentication { 428 case ao { 429 uses ao; 430 description 431 "Use TCP-AO to secure the connection."; 432 } 434 case md5 { 435 uses md5; 436 description 437 "Use TCP-MD5 to secure the connection."; 438 } 439 description 440 "Choice of how to secure the TCP connection."; 441 } 442 description 443 "Common definitions of TCP configuration. This includes 444 parameters such as how to secure the connection, 445 that can be part of either the client or server."; 446 } 447 description 448 "Connection related parameters."; 449 } 450 description 451 "A container of all TCP connections."; 452 } 454 container server { 455 if-feature server; 456 uses tcps:tcp-server-grouping; 457 description 458 "Definitions of TCP server configuration."; 459 } 461 container client { 462 if-feature client; 463 uses tcpc:tcp-client-grouping; 464 description 465 "Definitions of TCP client configuration."; 466 } 468 container statistics { 469 if-feature statistics; 470 config false; 472 leaf active-opens { 473 type yang:counter32; 474 description 475 "The number of times that TCP connections have made a direct 476 transition to the SYN-SENT state from the CLOSED state."; 477 } 479 leaf passive-opens { 480 type yang:counter32; 481 description 482 "The number of times TCP connections have made a direct 483 transition to the SYN-RCVD state from the LISTEN state."; 484 } 486 leaf attempt-fails { 487 type yang:counter32; 488 description 489 "The number of times that TCP connections have made a direct 490 transition to the CLOSED state from either the SYN-SENT 491 state or the SYN-RCVD state, plus the number of times that 492 TCP connections have made a direct transition to the 493 LISTEN state from the SYN-RCVD state."; 494 } 496 leaf establish-resets { 497 type yang:counter32; 498 description 499 "The number of times that TCP connections have made a direct 500 transition to the CLOSED state from either the ESTABLISHED 501 state or the CLOSE-WAIT state."; 502 } 504 leaf currently-established { 505 type yang:gauge32; 506 description 507 "The number of TCP connections for which the current state 508 is either ESTABLISHED or CLOSE-WAIT."; 509 } 511 leaf in-segments { 512 type yang:counter64; 513 description 514 "The total number of segments received, including those 515 received in error. This count includes segments received 516 on currently established connections."; 517 } 519 leaf out-segments { 520 type yang:counter64; 521 description 522 "The total number of segments sent, including those on 523 current connections but excluding those containing only 524 retransmitted octets."; 525 } 527 leaf retransmitted-segments { 528 type yang:counter32; 529 description 530 "The total number of segments retransmitted; that is, the 531 number of TCP segments transmitted containing one or more 532 previously transmitted octets."; 533 } 535 leaf in-errors { 536 type yang:counter32; 537 description 538 "The total number of segments received in error (e.g., bad 539 TCP checksums)."; 540 } 542 leaf out-resets { 543 type yang:counter32; 544 description 545 "The number of TCP segments sent containing the RST flag."; 546 } 548 action reset { 549 description 550 "Reset statistics action command."; 551 input { 552 leaf reset-at { 553 type yang:date-and-time; 554 description 555 "Time when the reset action needs to be 556 executed."; 557 } 558 } 559 output { 560 leaf reset-finished-at { 561 type yang:date-and-time; 562 description 563 "Time when the reset action command completed."; 564 } 565 } 566 } 567 description 568 "Statistics across all connections."; 569 } 570 } 571 } 572 574 5. IANA Considerations 576 5.1. The IETF XML Registry 578 This document registers two URIs in the "ns" subregistry of the IETF 579 XML Registry [RFC3688]. Following the format in IETF XML Registry 580 [RFC3688], the following registrations are requested: 582 URI: urn:ietf:params:xml:ns:yang:ietf-tcp 583 Registrant Contact: The TCPM WG of the IETF. 584 XML: N/A, the requested URI is an XML namespace. 586 5.2. The YANG Module Names Registry 588 This document registers a YANG modules in the YANG Module Names 589 registry YANG - A Data Modeling Language [RFC6020]. Following the 590 format in YANG - A Data Modeling Language [RFC6020], the following 591 registrations are requested: 593 name: ietf-tcp 594 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp 595 prefix: tcp 596 reference: RFC XXXX 598 6. Security Considerations 600 The YANG module specified in this document defines a schema for data 601 that is designed to be accessed via network management protocols such 602 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 603 is the secure transport layer, and the mandatory-to-implement secure 604 transport is Secure Shell (SSH) described in Using the NETCONF 605 protocol over SSH [RFC6242]. The lowest RESTCONF layer is HTTPS, and 606 the mandatory-to-implement secure transport is TLS [RFC8446]. 608 The Network Configuration Access Control Model (NACM) [RFC8341] 609 provides the means to restrict access for particular NETCONF or 610 RESTCONF users to a preconfigured subset of all available NETCONF or 611 RESTCONF protocol operations and content. 613 7. References 615 7.1. Normative References 617 [I-D.ietf-netconf-tcp-client-server] 618 Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients 619 and TCP Servers", draft-ietf-netconf-tcp-client-server-08 620 (work in progress), August 2020. 622 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 623 RFC 793, DOI 10.17487/RFC0793, September 1981, 624 . 626 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 627 Requirement Levels", BCP 14, RFC 2119, 628 DOI 10.17487/RFC2119, March 1997, 629 . 631 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 632 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 633 1998, . 635 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 636 DOI 10.17487/RFC3688, January 2004, 637 . 639 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 640 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 641 June 2010, . 643 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 644 the Network Configuration Protocol (NETCONF)", RFC 6020, 645 DOI 10.17487/RFC6020, October 2010, 646 . 648 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 649 and A. Bierman, Ed., "Network Configuration Protocol 650 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 651 . 653 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 654 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 655 . 657 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 658 RFC 7950, DOI 10.17487/RFC7950, August 2016, 659 . 661 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 662 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 663 . 665 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 666 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 667 May 2017, . 669 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 670 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 671 . 673 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 674 Access Control Model", STD 91, RFC 8341, 675 DOI 10.17487/RFC8341, March 2018, 676 . 678 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 679 and R. Wilton, "Network Management Datastore Architecture 680 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 681 . 683 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 684 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 685 . 687 7.2. Informative References 689 [I-D.ietf-dots-data-channel] 690 Boucadair, M. and T. Reddy.K, "Distributed Denial-of- 691 Service Open Threat Signaling (DOTS) Data Channel 692 Specification", draft-ietf-dots-data-channel-31 (work in 693 progress), July 2019. 695 [I-D.ietf-idr-bgp-model] 696 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 697 YANG Model for Service Provider Networks", draft-ietf-idr- 698 bgp-model-09 (work in progress), June 2020. 700 [I-D.ietf-taps-interface] 701 Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., 702 Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T. 703 Pauly, "An Abstract Application Layer Interface to 704 Transport Services", draft-ietf-taps-interface-09 (work in 705 progress), July 2020. 707 [RFC4022] Raghunarayan, R., Ed., "Management Information Base for 708 the Transmission Control Protocol (TCP)", RFC 4022, 709 DOI 10.17487/RFC4022, March 2005, 710 . 712 [RFC4898] Mathis, M., Heffner, J., and R. Raghunarayan, "TCP 713 Extended Statistics MIB", RFC 4898, DOI 10.17487/RFC4898, 714 May 2007, . 716 [RFC6643] Schoenwaelder, J., "Translation of Structure of Management 717 Information Version 2 (SMIv2) MIB Modules to YANG 718 Modules", RFC 6643, DOI 10.17487/RFC6643, July 2012, 719 . 721 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 722 Vinapamula, S., and Q. Wu, "A YANG Module for Network 723 Address Translation (NAT) and Network Prefix Translation 724 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 725 . 727 [RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG 728 Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, 729 DOI 10.17487/RFC8513, January 2019, 730 . 732 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 733 "YANG Data Model for Network Access Control Lists (ACLs)", 734 RFC 8519, DOI 10.17487/RFC8519, March 2019, 735 . 737 Appendix A. Acknowledgements 739 Michael Scharf was supported by the StandICT.eu project, which is 740 funded by the European Commission under the Horizon 2020 Programme. 742 The following persons have contributed to this document by reviews: 743 Mohamed Boucadair 745 Appendix B. Changes compared to previous versions 747 Changes compared to draft-scharf-tcpm-yang-tcp-04 749 o Removed congestion control 751 o Removed global stack parameters 753 Changes compared to draft-scharf-tcpm-yang-tcp-03 755 o Updated TCP-AO grouping 757 o Added congestion control 759 Changes compared to draft-scharf-tcpm-yang-tcp-02 760 o Initial proposal of a YANG model including base configuration 761 parameters, TCP-AO configuration, and a connection list 763 o Editorial bugfixes and outdated references reported by Mohamed 764 Boucadair 766 o Additional co-author Mahesh Jethanandani 768 Changes compared to draft-scharf-tcpm-yang-tcp-01 770 o Alignment with [I-D.ietf-netconf-tcp-client-server] 772 o Removing backward-compatibility to the TCP MIB 774 o Additional co-author Vishal Murgai 776 Changes compared to draft-scharf-tcpm-yang-tcp-00 778 o Editorial improvements 780 Appendix C. Examples 782 C.1. Keepalive Configuration 784 This particular example demonstrates how both a particular connection 785 can be configured for keepalives. 787 788 793 794 796 797 798 192.168.1.1 799 192.168.1.2 800 1025 801 80 802 803 804 5 805 5 806 10 807 808 809 810 811 817 818 192.168.1.1 819 820 821 192.168.1.2 822 823 824 826 Authors' Addresses 828 Michael Scharf 829 Hochschule Esslingen - University of Applied Sciences 830 Flandernstr. 101 831 Esslingen 73732 832 Germany 834 Email: michael.scharf@hs-esslingen.de 835 Vishal Murgai 837 Email: vmurgai@gmail.com 839 Mahesh Jethanandani 840 Kloud Services 842 Email: mjethanandani@gmail.com