idnits 2.17.1 draft-scharf-tcpm-yang-tcp-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 -- The document date (November 04, 2019) is 1635 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-03 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-17) exists of draft-ietf-idr-bgp-model-07 == Outdated reference: A later version (-26) exists of draft-ietf-taps-interface-04 Summary: 1 error (**), 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 7, 2020 Cisco Systems Inc 6 M. Jethanandani 7 VMware 8 November 04, 2019 10 YANG Model for Transmission Control Protocol (TCP) Configuration 11 draft-scharf-tcpm-yang-tcp-03 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 17 groupings for fundamental parameters that can be modified in many TCP 18 implementations. The model includes definitions from YANG Groupings 19 for TCP Client and TCP Servers (I-D.ietf-netconf-tcp-client-server). 20 The model is NMDA (RFC 8342) compliant. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 7, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 58 3. Model Overview . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Modeling Scope . . . . . . . . . . . . . . . . . . . . . 3 60 3.2. Basic TCP Configuration Parameters . . . . . . . . . . . 5 61 3.3. Model Design . . . . . . . . . . . . . . . . . . . . . . 7 62 3.4. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 8 63 3.5. Example Usage . . . . . . . . . . . . . . . . . . . . . . 8 64 4. TCP Configuration YANG Model . . . . . . . . . . . . . . . . 8 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 66 5.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 14 67 5.2. The YANG Module Names Registry . . . . . . . . . . . . . 15 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 15 71 7.2. Informative References . . . . . . . . . . . . . . . . . 17 72 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18 73 Appendix B. Changes compared to previous versions . . . . . . . 18 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 76 1. Introduction 78 The Transmission Control Protocol (TCP) [RFC0793] is used by many 79 applications in the Internet, including control and management 80 protocols. Therefore, TCP is implemented on network elements that 81 can be configured via network management protocols such as NETCONF 82 [RFC6241] or RESTCONF [RFC8040]. This document specifies a YANG 83 [RFC7950] 1.1 model for configuring TCP on network elements that 84 support YANG data models, and is Network Management Datastore 85 Architecture (NMDA) [RFC8342] compliant. This document includes 86 definitions from YANG Groupings for TCP Clients and TCP Servers 87 [I-D.ietf-netconf-tcp-client-server]. The model focuses on 88 fundamental and standard TCP functions that are widely implemented. 89 The model can be augmented to address more advanced or 90 implementation-specific TCP features. 92 Many protocol stacks on internet hosts use other methods to configure 93 TCP, such as operating system configuration or policies. Many TCP/IP 94 stacks cannot be configured by network management protocols such as 95 NETCONF [RFC6241] or RESTCONF [RFC8040] and they do not use YANG data 96 models. Yet, such TCP implementations often also have means to 97 configure the parameters listed in this document. All parameters 98 defined in this document are optional. 100 This specification is orthogonal to Management Information Base (MIB) 101 for the Transmission Control Protocol (TCP) [RFC4022]. The TCP 102 Extended Statistics MIB [RFC4898] is also available, and there are 103 MIBs for UDP Management Information Base for the User Datagram 104 Protocol (UDP) [RFC4113] and Stream Control Transmission Protocol 105 (SCTP) Management Information Base (MIB) [RFC3873]. It is possible 106 to translate a MIB into a YANG model, for instance using Translation 107 of Structure of Management Information Version 2 (SMIv2) MIB Modules 108 to YANG Modules [RFC6643]. However, this approach is not used in 109 this document, as such a translated model would not be up-to-date. 111 There are also other related YANG models. Examples are: 113 o Application protocol models may include TCP parameters, for 114 example in case of BGP YANG Model for Service Provider Networks 115 [I-D.ietf-idr-bgp-model]. 117 o TCP header attributes are modeled in other models, such as YANG 118 Data Model for Network Access Control Lists (ACLs) [RFC8519] and 119 Distributed Denial-of-Service Open Thread Signaling (DOTS) Data 120 Channel Specification [I-D.ietf-dots-data-channel]. 122 o TCP-related configuration of a NAT (e.g., NAT44, NAT64, 123 Destination NAT, ...) is defined in A YANG Module for Network 124 Address Translation (NAT) and Network Prefix Translation (NPT) 125 [RFC8512] and A YANG Data Model for Dual-Stack Lite (DS-Lite) 126 [RFC8513]. 128 2. Requirements Language 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in BCP 133 14 [RFC2119] [RFC8174] when, and only when, they appear in all 134 capitals, as shown here. 136 3. Model Overview 138 3.1. Modeling Scope 140 TCP is implemented on many different system architectures. As a 141 result, there are may different and often implementation-specific 142 ways to configure parameters of the TCP protocol engine. In 143 addition, in many TCP/IP stacks configuration exists for different 144 scopes: 146 o Global configuration: Many TCP implementations have configuration 147 parameters that affect all TCP connections. Typical examples 148 include enabling or disabling optional protocol features. 150 o Interface configuration: It can be useful to use different TCP 151 parameters on different interfaces, e.g., different device ports 152 or IP interfaces. In that case, TCP parameters can be part of the 153 interface configuration. Typical examples are the Maximum Segment 154 Size (MSS) or configuration related to hardware offloading. 156 o Connection parameters: Many implementations have means to 157 influence the behavior of each TCP connection, e.g., on the 158 programming interface used by applications. A typical example are 159 socket options in the socket API, such as disabling the Nagle 160 algorithm by TCP_NODELAY. If an application uses such an 161 interface, it is possible that the configuration of the 162 application or application protocol includes TCP-related 163 parameters. An example is the BGP YANG Model for Service Provider 164 Networks [I-D.ietf-idr-bgp-model]. 166 o Policies: Setting of TCP parameters can also be part of system 167 policies, templates, or profiles. An example would be the 168 preferences defined in the TAPS interface An Abstract Application 169 Layer Interface to Transport Services [I-D.ietf-taps-interface]. 171 There is no ground truth for setting certain TCP parameters, and 172 traditionally different implementation have used different modeling 173 approaches. For instance, one implementation may define a given 174 configuration parameter globally, while another one uses per- 175 interface settings, and both approaches work well for the 176 corresponding use cases. Also, different systems may use different 177 default values. 179 The YANG model defined in this document includes definitions from the 180 YANG Groupings for TCP Clients and TCP Servers 181 [I-D.ietf-netconf-tcp-client-server]. Similar to the base model, 182 this specification defines YANG groupings. This allows reuse of 183 these groupings in different YANG data models. It is intended that 184 these groupings will be used either standalone or for TCP-based 185 protocols as part of a stack of protocol-specific configuration 186 models. 188 In addition to configuration of the TCP protocol engine, a TCP 189 implementation typically also offers access to operational state and 190 statistics. This includes amongst others: 192 o Statistics: Counters for the number of active/passive opens, sent 193 and received segments, errors, and possibly other detailed 194 debugging information 196 o TCP connection table: Access to status information for all TCP 197 connections 199 o TCP listener table: Tnformation about all TCP listening endpoints 201 Similar to the TCP MIB [RFC4022], this document also specifies a TCP 202 connection table. 204 TODO: A future version of this document may include statistics 205 equivalent to the TCP MIB [RFC4022]: 207 o active-opens 209 o passive-opens 211 o attempt-fails 213 o establish-resets 215 o currently-established 217 o in-segments 219 o out-segments 221 o retransmitted-segments 223 o in-errors 225 o out-resets 227 3.2. Basic TCP Configuration Parameters 229 There are a number of basic system parameters that are configurable 230 on many TCP implementations, even if not all TCP implementations may 231 indeed have exactly all these settings. Also, the syntax, semantics 232 and scope (e.g., global or interface-specific) can be different in 233 different system architectures. 235 The following list of fundamental parameters considers both TCP 236 implementations on hosts and on routers: 238 o Keepalives (see also [I-D.ietf-netconf-tcp-client-server]) 239 * Idle-time (in seconds): integer 241 * Probe-interval (in seconds): integer 243 * Max-probes: integer 245 o Maximum MSS (in byte): integer 247 o FIN timeout (in seconds): integer 249 o SACK (disable/enable): boolean 251 o Timestamps (disable/enable): boolean 253 o Path MTU Discovery (disable/enable): boolean 255 o ECN 257 * Enabling (disable/passive/active): enumeration 259 TCP-AO is increasingly supported on routers and also requires 260 configuration. 262 Some other parameters are also common but not ubiquitously supported, 263 or modeled in very different ways: 265 o Delayed ACK timeout (in ms) 267 o Initial RTO value (in ms) 269 o Maximum number of retransmissions 271 o Window scaling 273 o Maximum number of connections 275 TCP can be implemented in different ways and design choices by the 276 protocol engine often affect configuration options. In a number of 277 areas there are major differences between different software 278 architectures. As a result, there are not many commonalities in the 279 corresponding configuration parameters: 281 o Window size: TCP stacks can either store window state variables 282 (such as the congestion window) in segments or in bytes. 284 o Buffer sizes: The memory management depends on the operating 285 system. As the size of buffers can vary over several orders of 286 magnitude, very different implementations exist. This typically 287 influences TCP flow control. 289 o Timers: Timer implementation is another area in which TCP stacks 290 may differ. 292 o Congestion control algorithms: Many congestion control algorithms 293 have configuration parameters, but except for fundamental 294 properties they often tie into the specific implementation. 296 This document only models fundamental system parameters that are 297 configurable on many TCP implementations, and for which the 298 configuration is reasonably similar. 300 3.3. Model Design 302 [[Editor's node: This section requires further work.]] 304 This document extends the YANG model "ietf-tcp-common" defined in 305 [I-D.ietf-netconf-tcp-client-server]. The intention is to define 306 YANG groupings for TCP parameters so that they can be used in 307 different YANG models. 309 As an example for the configuration of SACK, a YANG model could 310 import the YANG model "ietf-tcp-common" as well as the model defined 311 in this document as follows: 313 module example-tcp { 314 namespace "http://example.com/tcp"; 315 prefix tcp; 317 import ietf-tcp { 318 prefix tcp; 319 } 321 import ietf-tcp-common { 322 prefix tcpcmn; 323 } 325 container example-tcp-config { 326 description "Example TCP stack configuration"; 328 uses tcpcmn:tcp-common-grouping; 329 uses tcp:tcp-sack-grouping; 330 } 331 } 333 3.4. Tree Diagram 335 This section provides a abridged tree diagram for the YANG module 336 defined in this document. Annotations used in the diagram are 337 defined in YANG Tree Diagrams [RFC8340]. 339 module: ietf-tcp 340 +--rw tcp! 341 +--rw connections 342 ... 344 3.5. Example Usage 346 [[Editor's note: This section is TBD.]] 348 4. TCP Configuration YANG Model 350 Editor's note: How to use ietf-tcp-common as basis? For instance, is 351 the tcp-system-grouping therein needed? 353 file "ietf-tcp@2019-11-04.yang" 355 module ietf-tcp { 356 yang-version "1.1"; 357 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp"; 358 prefix "tcp"; 360 import ietf-tcp-client { 361 prefix "tcpc"; 362 } 363 import ietf-tcp-server { 364 prefix "tcps"; 365 } 366 import ietf-tcp-common { 367 prefix "tcpcmn"; 368 } 369 import ietf-inet-types { 370 prefix "inet"; 371 } 373 organization 374 "IETF TCPM Working Group"; 376 contact 377 "WG Web: 378 WG List: 380 Authors: Michael Scharf (michael.scharf at hs-esslingen dot de) 381 Vishal Murgai (vmurgai at cisco dot com) 382 Mahesh Jethanandani (mjethanandani at gmail dot com)"; 384 description 385 "This module focuses on fundamental and standard TCP functions 386 that widely implemented. The model can be augmented to address 387 more advanced or implementation specific TCP features."; 389 revision "2019-11-04" { 390 description 391 "Initial Version"; 392 reference 393 "RFC XXX, TCP Configuration."; 394 } 396 // Features 397 feature server { 398 description 399 "TCP Server configuration supported."; 400 } 402 feature client { 403 description 404 "TCP Client configuration supported."; 405 } 407 // TCP-AO Groupings 409 grouping mkt { 410 leaf options { 411 type binary; 412 description 413 "This flag indicates whether TCP options other than TCP-AO 414 are included in the MAC calculation. When options are 415 included, the content of all options, in the order present, 416 is included in the MAC, with TCP-AO's MAC field zeroed out. 417 When the options are not included, all options other than 418 TCP-AO are excluded from all MAC calculations (skipped over, 419 not zeroed). 421 Note that TCP-AO, with its MAC field zeroed out, is always 422 included in the MAC calculation, regardless of the setting 423 of this flag; this protects the indication of the MAC length 424 as well as the key ID fields (KeyID, RNextKeyID). The option 425 flag applies to TCP options in both directions 426 (incoming and outgoing segments)."; 427 reference 428 "RFC 5925: The TCP Authentication Option."; 430 } 432 leaf key-id { 433 type uint8; 434 description 435 "TBD"; 436 } 438 leaf rnext-key-id { 439 type uint8; 440 description 441 "TBD"; 442 } 443 description 444 "A Master Key Tuple (MKT) describes TCP-AO properties to be 445 associated with one or more connections."; 446 } 448 grouping ao { 449 leaf enable { 450 type boolean; 451 default "false"; 452 description 453 "Enable support of TCP-Authentication Option (TCP-AO)."; 454 } 456 leaf current-key { 457 type binary; 458 description 459 "The Master Key Tuple (MKT) currently used to authenticate 460 outgoing segments, whose SendID is inserted in outgoing 461 segments as KeyID. Incoming segments are authenticated 462 using the MKT corresponding to the segment and its TCP-AO 463 KeyID as matched against the MKT TCP connection identifier 464 and the MKT RecvID. There is only one current-key at any 465 given time on a particular connection. 467 Every TCP connection in a non-IDLE state MUST have at most 468 one current_key specified."; 469 reference 470 "RFC 5925: The TCP Authentication Option."; 471 } 473 leaf rnext-key { 474 type binary; 475 description 476 "The MKT currently preferred for incoming (received) 477 segments, whose RecvID is inserted in outgoing segments as 478 RNextKeyID. 480 Each TCP connection in a non-IDLE state MUST have at most 481 one rnext_key specified."; 482 reference 483 "RFC 5925: The TCP Authentication Option."; 484 } 486 leaf-list sne { 487 type uint32; 488 min-elements 1; 489 max-elements 2; 490 description 491 "A pair of Sequence Number Extensions (SNEs). SNEs are used 492 to prevent replay attacks. Each SNE is initialized to zero 493 upon connection establishment."; 494 reference 495 "RFC 5925: The TCP Authentication Option."; 496 } 498 leaf-list mkt { 499 type binary; 500 min-elements 1; 501 description 502 "One or more MKTs. These are the MKTs that match this 503 connection's socket pair."; 504 reference 505 "RFC 5925: The TCP Authentication Option."; 506 } 507 description 508 "Authentication Option (AO) for TCP."; 509 reference 510 "RFC 5925: The TCP Authentication Option."; 511 } 513 // TCP general configuration groupings 515 grouping tcp-mss-grouping { 516 description "Maximum Segment Size (MSS) parameters"; 518 leaf tcp-mss { 519 type uint16; 520 description 521 "Sets the max segment size for TCP connections."; 522 } 523 } // grouping tcp-mss-grouping 525 grouping tcp-mtu-grouping { 526 description "Maximum Transfer Unit (MTU) discovery parameters"; 528 leaf tcp-mtu-discovery { 529 type boolean; 530 default false; 531 description 532 "Turns path mtu discovery for TCP connections on (true) or 533 off (false)"; 534 } 535 } // grouping tcp-mtu-grouping 537 grouping tcp-sack-grouping { 538 description "Selective Acknowledgements (SACK) parameters"; 540 leaf sack-enable { 541 type boolean; 543 description 544 "Enable support of Selective Acknowledgements (SACK)"; 545 } 546 } // grouping tcp-sack-grouping 548 grouping tcp-timestamps-grouping { 549 description "Timestamp parameters"; 551 leaf timestamps-enable { 552 type boolean; 554 description 555 "Enable support of timestamps"; 556 } 557 } // grouping tcp-timestamps-grouping 559 grouping tcp-fin-timeout-grouping { 560 description "TIME WAIT timeout parameters"; 562 leaf fin-timeout { 563 type uint16; 564 units "seconds"; 565 description 566 "When a connection is closed actively, it must linger in 567 TIME-WAIT state for a time 2xMSL (Maximum Segment Lifetime). 568 This parameter sets the TIME-WAIT timeout duration in 569 seconds."; 570 } 571 } // grouping tcp-fin-timeout-grouping 573 grouping tcp-ecn-grouping { 574 description "Explicit Congestion Notification (ECN) parameters"; 576 leaf ecn-enable { 577 type enumeration { 578 enum disable; 579 enum passive; 580 enum active; 581 } 582 description 583 "Enabling of ECN."; 584 } 585 } // grouping tcp-ecn-grouping 587 // augment statements 589 container tcp { 590 presence "The container for TCP configuration."; 592 description 593 "TCP container."; 595 container connections { 596 list connection { 597 key "local-address remote-address local-port remote-port"; 599 leaf local-address { 600 type inet:ip-address; 601 description 602 "Local address that forms the connection identifier."; 603 } 605 leaf remote-address { 606 type inet:ip-address; 607 description 608 "Remote address that forms the connection identifier."; 609 } 611 leaf local-port { 612 type inet:port-number; 613 description 614 "Local TCP port that forms the connection identifier."; 615 } 617 leaf remote-port { 618 type inet:port-number; 619 description 620 "Remote TCP port that forms the connection identifier."; 622 } 624 container common { 625 uses tcpcmn:tcp-common-grouping; 626 uses ao; 627 description 628 "Common definitions of TCP configuration. This includes 629 parameters such as keepalives and idle time, that can 630 be part of either the client or server."; 631 } 633 container server { 634 if-feature server; 635 uses tcps:tcp-server-grouping; 636 description 637 "Definitions of TCP server configuration."; 638 } 640 container client { 641 if-feature client; 642 uses tcpc:tcp-client-grouping; 643 description 644 "Definitions of TCP client configuration."; 645 } 646 description 647 "Connection related parameters."; 648 } 649 description 650 "A container of all TCP connections."; 651 } 652 } 653 } 655 657 5. IANA Considerations 659 5.1. The IETF XML Registry 661 This document registers two URIs in the "ns" subregistry of the IETF 662 XML Registry [RFC3688]. Following the format in IETF XML Registry 663 [RFC3688], the following registrations are requested: 665 URI: urn:ietf:params:xml:ns:yang:ietf-tcp 666 Registrant Contact: The TCPM WG of the IETF. 667 XML: N/A, the requested URI is an XML namespace. 669 5.2. The YANG Module Names Registry 671 This document registers a YANG modules in the YANG Module Names 672 registry YANG - A Data Modeling Language [RFC6020]. Following the 673 format in YANG - A Data Modeling Language [RFC6020], the following 674 registrations are requested: 676 name: ietf-tcp 677 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp 678 prefix: tcp 679 reference: RFC XXXX 681 6. Security Considerations 683 The YANG module specified in this document defines a schema for data 684 that is designed to be accessed via network management protocols such 685 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 686 is the secure transport layer, and the mandatory-to-implement secure 687 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 688 is HTTPS, and the mandatory-to-implement secure transport is TLS 689 [RFC8446]. 691 The Network Configuration Access Control Model (NACM) [RFC8341] 692 provides the means to restrict access for particular NETCONF or 693 RESTCONF users to a preconfigured subset of all available NETCONF or 694 RESTCONF protocol operations and content. 696 7. References 698 7.1. Normative References 700 [I-D.ietf-netconf-tcp-client-server] 701 Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients 702 and TCP Servers", draft-ietf-netconf-tcp-client-server-03 703 (work in progress), October 2019. 705 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 706 RFC 793, DOI 10.17487/RFC0793, September 1981, 707 . 709 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 710 Requirement Levels", BCP 14, RFC 2119, 711 DOI 10.17487/RFC2119, March 1997, 712 . 714 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 715 DOI 10.17487/RFC3688, January 2004, 716 . 718 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 719 the Network Configuration Protocol (NETCONF)", RFC 6020, 720 DOI 10.17487/RFC6020, October 2010, 721 . 723 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 724 and A. Bierman, Ed., "Network Configuration Protocol 725 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 726 . 728 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 729 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 730 . 732 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 733 RFC 7950, DOI 10.17487/RFC7950, August 2016, 734 . 736 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 737 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 738 . 740 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 741 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 742 May 2017, . 744 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 745 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 746 . 748 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 749 Access Control Model", STD 91, RFC 8341, 750 DOI 10.17487/RFC8341, March 2018, 751 . 753 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 754 and R. Wilton, "Network Management Datastore Architecture 755 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 756 . 758 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 759 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 760 . 762 7.2. Informative References 764 [I-D.ietf-dots-data-channel] 765 Boucadair, M. and R. K, "Distributed Denial-of-Service 766 Open Threat Signaling (DOTS) Data Channel Specification", 767 draft-ietf-dots-data-channel-31 (work in progress), July 768 2019. 770 [I-D.ietf-idr-bgp-model] 771 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 772 YANG Model for Service Provider Networks", draft-ietf-idr- 773 bgp-model-07 (work in progress), October 2019. 775 [I-D.ietf-taps-interface] 776 Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., 777 Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T. 778 Pauly, "An Abstract Application Layer Interface to 779 Transport Services", draft-ietf-taps-interface-04 (work in 780 progress), July 2019. 782 [RFC3873] Pastor, J. and M. Belinchon, "Stream Control Transmission 783 Protocol (SCTP) Management Information Base (MIB)", 784 RFC 3873, DOI 10.17487/RFC3873, September 2004, 785 . 787 [RFC4022] Raghunarayan, R., Ed., "Management Information Base for 788 the Transmission Control Protocol (TCP)", RFC 4022, 789 DOI 10.17487/RFC4022, March 2005, 790 . 792 [RFC4113] Fenner, B. and J. Flick, "Management Information Base for 793 the User Datagram Protocol (UDP)", RFC 4113, 794 DOI 10.17487/RFC4113, June 2005, 795 . 797 [RFC4898] Mathis, M., Heffner, J., and R. Raghunarayan, "TCP 798 Extended Statistics MIB", RFC 4898, DOI 10.17487/RFC4898, 799 May 2007, . 801 [RFC6643] Schoenwaelder, J., "Translation of Structure of Management 802 Information Version 2 (SMIv2) MIB Modules to YANG 803 Modules", RFC 6643, DOI 10.17487/RFC6643, July 2012, 804 . 806 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 807 Vinapamula, S., and Q. Wu, "A YANG Module for Network 808 Address Translation (NAT) and Network Prefix Translation 809 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 810 . 812 [RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG 813 Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, 814 DOI 10.17487/RFC8513, January 2019, 815 . 817 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 818 "YANG Data Model for Network Access Control Lists (ACLs)", 819 RFC 8519, DOI 10.17487/RFC8519, March 2019, 820 . 822 Appendix A. Acknowledgements 824 Michael Scharf was supported by the StandICT.eu project, which is 825 funded by the European Commission under the Horizon 2020 Programme. 827 The following persons have contributed to this document by reviews: 828 Mohamed Boucadair 830 Appendix B. Changes compared to previous versions 832 Changes compared to draft-scharf-tcpm-yang-tcp-02 834 o Initial proposal of a YANG model including base configuration 835 parameters, TCP-AO configuration, and a connection list 837 o Editorial bugfixes and outdated references reported by Mohamed 838 Boucadair 840 o Additional co-author Mahesh Jethanandani 842 Changes compared to draft-scharf-tcpm-yang-tcp-01 844 o Alignment with [I-D.ietf-netconf-tcp-client-server] 846 o Removing backward-compatibility to the TCP MIB 848 o Additional co-author Vishal Murgai 850 Changes compared to draft-scharf-tcpm-yang-tcp-00 852 o Editorial improvements 854 Authors' Addresses 856 Michael Scharf 857 Hochschule Esslingen - University of Applied Sciences 858 Flandernstr. 101 859 Esslingen 73732 860 Germany 862 Email: michael.scharf@hs-esslingen.de 864 Vishal Murgai 865 Cisco Systems Inc 867 Email: vmurgai@cisco.com 869 Mahesh Jethanandani 870 VMware 872 Email: mjethanandani@gmail.com