idnits 2.17.1 draft-scharf-tcpm-yang-tcp-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 24, 2020) is 1520 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-05 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: August 27, 2020 Cisco Systems Inc 6 M. Jethanandani 7 VMware 8 February 24, 2020 10 YANG Model for Transmission Control Protocol (TCP) Configuration 11 draft-scharf-tcpm-yang-tcp-04 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 fundamental 18 parameters that can be imported and used in many TCP implementations. 19 The model includes definitions from YANG Groupings for TCP Client and 20 TCP Servers (I-D.ietf-netconf-tcp-client-server). The model is NMDA 21 (RFC 8342) compliant. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 27, 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 59 3. Model Overview . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.1. Modeling Scope . . . . . . . . . . . . . . . . . . . . . 3 61 3.2. Model Design . . . . . . . . . . . . . . . . . . . . . . 5 62 3.3. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 5 63 4. TCP Configuration YANG Model . . . . . . . . . . . . . . . . 6 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 65 5.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 17 66 5.2. The YANG Module Names Registry . . . . . . . . . . . . . 17 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 18 70 7.2. Informative References . . . . . . . . . . . . . . . . . 19 71 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20 72 Appendix B. Changes compared to previous versions . . . . . . . 20 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 75 1. Introduction 77 The Transmission Control Protocol (TCP) [RFC0793] is used by many 78 applications in the Internet, including control and management 79 protocols. Therefore, TCP is implemented on network elements that 80 can be configured via network management protocols such as NETCONF 81 [RFC6241] or RESTCONF [RFC8040]. This document specifies a YANG 82 [RFC7950] 1.1 model for configuring TCP on network elements that 83 support YANG data models, and is Network Management Datastore 84 Architecture (NMDA) [RFC8342] compliant. This module defines a 85 container for TCP connection, and includes definitions from YANG 86 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]. Moreover, many existing 96 TCP/IP stacks do not use YANG data models. Such TCP implementations 97 often have other means to configure the parameters listed in this 98 document, which are outside the scope of this document. 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. It is possible 103 to translate a MIB into a YANG model, for instance using Translation 104 of Structure of Management Information Version 2 (SMIv2) MIB Modules 105 to YANG Modules [RFC6643]. However, this approach is not used in 106 this document, as such a translated model would not be up-to-date. 108 2. Requirements Language 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in BCP 113 14 [RFC2119] [RFC8174] when, and only when, they appear in all 114 capitals, as shown here. 116 3. Model Overview 118 3.1. Modeling Scope 120 TCP is implemented on many different system architectures. As a 121 result, there are may different and often implementation-specific 122 ways to configure parameters of the TCP protocol engine. In 123 addition, in many TCP/IP stacks configuration exists for different 124 scopes: 126 o Global configuration: Many TCP implementations have configuration 127 parameters that affect all TCP connections. Typical examples 128 include enabling or disabling optional protocol features. 130 o Interface configuration: It can be useful to use different TCP 131 parameters on different interfaces, e.g., different device ports 132 or IP interfaces. In that case, TCP parameters can be part of the 133 interface configuration. Typical examples are the Maximum Segment 134 Size (MSS) or configuration related to hardware offloading. 136 o Connection parameters: Many implementations have means to 137 influence the behavior of each TCP connection, e.g., on the 138 programming interface used by applications. A typical example are 139 socket options in the socket API, such as disabling the Nagle 140 algorithm by TCP_NODELAY. If an application uses such an 141 interface, it is possible that the configuration of the 142 application or application protocol includes TCP-related 143 parameters. An example is the BGP YANG Model for Service Provider 144 Networks [I-D.ietf-idr-bgp-model]. 146 o Policies: Setting of TCP parameters can also be part of system 147 policies, templates, or profiles. An example would be the 148 preferences defined in the TAPS interface An Abstract Application 149 Layer Interface to Transport Services [I-D.ietf-taps-interface]. 151 As a result, there is no ground truth for setting certain TCP 152 parameters, and traditionally different TCP implementation have used 153 different modeling approaches. For instance, one implementation may 154 define a given configuration parameter globally, while another one 155 uses per-interface settings, and both approaches work well for the 156 corresponding use cases. Also, different systems may use different 157 default values. 159 In addition, TCP can be implemented in different ways and design 160 choices by the protocol engine often affect configuration options. 161 In a number of areas there are known differences between different 162 TCP stack architectures. This includes amongst others: 164 o Window size: TCP stacks can either store window state variables 165 (such as the congestion window) in segments or in bytes. 167 o Buffer sizes: The memory management depends on the operating 168 system. As the size of buffers can vary over several orders of 169 magnitude, very different implementations exist. This typically 170 influences TCP flow control. 172 o Timers: Timer implementation is another area in which TCP stacks 173 may differ. 175 Nonetheless, there are a number of basic system parameters that are 176 configurable on many TCP implementations, even if not all TCP 177 implementations may indeed have all these settings, and even if there 178 are differences regarding syntax and semantics. This document 179 focuses on modeling such basic parameters directly following from 180 standards. 182 In addition to configuration of the TCP protocol engine, a TCP 183 implementation typically also offers access to operational state and 184 statistics. This includes amongst others: 186 o Statistics: Counters for the number of active/passive opens, sent 187 and received segments, errors, and possibly other detailed 188 debugging information 190 o TCP connection table: Access to status information for all TCP 191 connections 193 o TCP listener table: Information about all TCP listening endpoints 195 3.2. Model Design 197 This document models fundamental system parameters that are 198 configurable on many TCP implementations, and for which the 199 configuration is reasonably similar. Similar to the TCP MIB 200 [RFC4022], this document also specifies a TCP connection table. This 201 enables both global and connection-specific TCP configuration. 203 An important use case is the TCP configuration on network elements 204 such as routers, which often use YANG data models. The model 205 therefore specifies TCP parameters that are important on such TCP 206 stacks. A typical example is the support of TCP-AO [RFC5925]. TCP- 207 AO is increasingly supported on routers and it requires 208 configuration. 210 The YANG model defined in this document includes definitions from the 211 YANG Groupings for TCP Clients and TCP Servers 212 [I-D.ietf-netconf-tcp-client-server]. Similar to that model, this 213 specification defines YANG groupings. This allows reuse of these 214 groupings in different YANG data models. It is intended that these 215 groupings will be used either standalone or for TCP-based protocols 216 as part of a stack of protocol-specific configuration models. An 217 example could be the BGP YANG Model for Service Provider Networks 218 [I-D.ietf-idr-bgp-model]. 220 There are also other existing TCP-related YANG models, which are 221 othogonal to this specification. Examples are: 223 o TCP header attributes are modeled in other models, such as YANG 224 Data Model for Network Access Control Lists (ACLs) [RFC8519] and 225 Distributed Denial-of-Service Open Thread Signaling (DOTS) Data 226 Channel Specification [I-D.ietf-dots-data-channel]. 228 o TCP-related configuration of a NAT (e.g., NAT44, NAT64, 229 Destination NAT, ...) is defined in A YANG Module for Network 230 Address Translation (NAT) and Network Prefix Translation (NPT) 231 [RFC8512] and A YANG Data Model for Dual-Stack Lite (DS-Lite) 232 [RFC8513]. 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 global 245 | ... 246 +--ro statistics {statistics}? 247 ... 249 4. TCP Configuration YANG Model 251 Editor's note: How to use ietf-tcp-common as basis? For instance, is 252 the tcp-system-grouping therein needed? 254 file "ietf-tcp@2020-02-22.yang" 256 module ietf-tcp { 257 yang-version "1.1"; 258 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp"; 259 prefix "tcp"; 261 import ietf-yang-types { 262 prefix "yang"; 263 reference 264 "RFC 6991: Common YANG Data Types."; 265 } 266 import ietf-tcp-client { 267 prefix "tcpc"; 268 } 269 import ietf-tcp-server { 270 prefix "tcps"; 271 } 272 import ietf-tcp-common { 273 prefix "tcpcmn"; 274 } 275 import ietf-inet-types { 276 prefix "inet"; 277 } 279 organization 280 "IETF TCPM Working Group"; 282 contact 283 "WG Web: 284 WG List: 286 Authors: Michael Scharf (michael.scharf at hs-esslingen dot de) 287 Vishal Murgai (vmurgai at cisco dot com) 288 Mahesh Jethanandani (mjethanandani at gmail dot com)"; 290 description 291 "This module focuses on fundamental and standard TCP functions 292 that widely implemented. The model can be augmented to address 293 more advanced or implementation specific TCP features."; 295 revision "2020-02-22" { 296 description 297 "Initial Version"; 298 reference 299 "RFC XXX, TCP Configuration."; 300 } 302 // Features 303 feature server { 304 description 305 "TCP Server configuration supported."; 306 } 308 feature client { 309 description 310 "TCP Client configuration supported."; 311 } 313 feature statistics { 314 description 315 "This implementation supports statistics reporting."; 316 } 318 // TCP-AO Groupings 320 grouping mkt { 321 leaf options { 322 type binary; 323 description 324 "This flag indicates whether TCP options other than TCP-AO 325 are included in the MAC calculation. When options are 326 included, the content of all options, in the order present, 327 is included in the MAC, with TCP-AO's MAC field zeroed out. 328 When the options are not included, all options other than 329 TCP-AO are excluded from all MAC calculations (skipped over, 330 not zeroed). 332 Note that TCP-AO, with its MAC field zeroed out, is always 333 included in the MAC calculation, regardless of the setting 334 of this flag; this protects the indication of the MAC length 335 as well as the key ID fields (KeyID, RNextKeyID). The option 336 flag applies to TCP options in both directions 337 (incoming and outgoing segments)."; 338 reference 339 "RFC 5925: The TCP Authentication Option."; 340 } 342 leaf key-id { 343 type uint8; 344 description 345 "An unsigned 1-byte field indicating the Master Key Tuple 346 (MKT) used to generate the traffic keys that were used to 347 generate the MAC that authenticates this segment."; 348 reference 349 "RFC 5925: The TCP Authentication Option."; 350 } 352 leaf rnext-key-id { 353 type uint8; 354 description 355 "An unsigned 1-byte field indicating the MKT that is 356 ready at the sender to be used to authenticate received 357 segments, i.e., the desired 'receive next' key ID."; 358 } 359 description 360 "A Master Key Tuple (MKT) describes TCP-AO properties to be 361 associated with one or more connections."; 362 } 364 grouping ao { 365 leaf enable-ao { 366 type boolean; 367 default "false"; 368 description 369 "Enable support of TCP-Authentication Option (TCP-AO)."; 370 } 372 leaf send-id { 373 type uint8 { 374 range "0..255"; 375 } 376 must "../enable-ao = 'true'"; 377 description 378 "The SendID is inserted as the KeyID of the TCP-AO option 379 of outgoing segments."; 380 reference 381 "RFC 5925: The TCP Authentication Option."; 382 } 383 leaf recv-id { 384 type uint8 { 385 range "0..255"; 386 } 387 must "../enable-ao = 'true'"; 388 description 389 "The RecvID is matched against the TCP-AO KeyID of incoming 390 segments."; 391 reference 392 "RFC 5925: The TCP Authentication Option."; 393 } 395 leaf include-tcp-options { 396 type boolean; 397 must "../enable-ao = 'true'"; 398 description 399 "Include TCP options in HMAC calculation."; 400 } 402 leaf accept-ao-mismatch { 403 type boolean; 404 must "../enable-ao = 'true'"; 405 description 406 "Accept packets with HMAC mismatch."; 407 } 408 description 409 "Authentication Option (AO) for TCP."; 410 reference 411 "RFC 5925: The TCP Authentication Option."; 412 } 414 grouping md5 { 415 description 416 "Grouping for use in authenticating TCP sessions using MD5."; 417 reference 418 "RFC 2385: Protection of BGP Sessions via the TCP MD5 419 Signature."; 421 leaf enable-md5 { 422 type boolean; 423 default "false"; 424 description 425 "Enable support of MD5 to authenticate a TCP session."; 426 } 427 } 429 // Congestion control 430 identity congestion-control-algorithm { 431 description 432 "Base identity from which all congestion control 433 algorithms are derived."; 434 } 436 identity reno { 437 base congestion-control-algorithm; 438 description 439 "Standard TCP congestion control referred to as 440 'Reno algorithm'"; 441 reference 442 "RFC 5681: TCP Congestion Control"; 443 } 445 identity new-reno { 446 base congestion-control-algorithm; 447 description 448 "NewReno modification to TCP's fast recovery algorithm"; 449 reference 450 "RFC 6582: The NewReno Modification to TCP's Fast Recovery 451 Algorithm"; 452 } 454 identity ledbat { 455 base congestion-control-algorithm; 456 description 457 "Low Extra Delay Background Transport (LEDBAT) 458 congestion control"; 459 reference 460 "RFC 6817: Low Extra Delay Background Transport (LEDBAT)"; 461 } 463 identity dctcp { 464 base congestion-control-algorithm; 465 description 466 "TCP Congestion Control for Data Centers (DCTCP) 467 congestion control"; 468 reference 469 "RFC 8257: Data Center TCP (DCTCP): TCP Congestion 470 Control for Data Centers"; 471 } 473 identity cubic { 474 base congestion-control-algorithm; 475 description 476 "CUBIC congestion control"; 477 reference 478 "RFC 8312: CUBIC for Fast Long-Distance Networks"; 479 } 481 grouping tcp-global { 482 description 483 "Important global TCP stack parameters."; 484 leaf mss-max { 485 type uint16; 486 description 487 "Sets the max segment size for TCP connections."; 488 reference 489 "RFC 1122: Requirements for Internet Hosts -- Communication 490 Layers"; 491 } 493 leaf mtu-discovery-enable { 494 type boolean; 495 description 496 "Turns path mtu discovery for TCP connections on (true) or 497 off (false)"; 498 reference 499 "RFC 4821: Packetization Layer Path MTU Discovery"; 500 } 502 leaf sack-enable { 503 type boolean; 504 description 505 "Enable negotiation of Selective Acknowledgements (SACK)"; 506 reference 507 "RFC 2018: TCP Selective Acknowledgment Options"; 508 } 510 leaf timestamps-enable { 511 type boolean; 512 description 513 "Enable negotiation of timestamps"; 514 reference 515 "RFC 7323: TCP Extensions for High Performance"; 516 } 518 leaf window-scale-enable { 519 type boolean; 520 description 521 "Enable negotiation of receive window scaling"; 522 reference 523 "RFC 7323: TCP Extensions for High Performance"; 524 } 525 leaf ecn-enable { 526 type enumeration { 527 enum disable; 528 enum passive; 529 enum active; 530 } 531 description 532 "Enabling of Explicit Congestion Notification (ECN)."; 533 reference 534 "RFC 3168: The Addition of Explicit Congestion 535 Notification (ECN) to IP"; 536 } 538 leaf fin-timeout { 539 type uint16; 540 units "seconds"; 541 description 542 "When a connection is closed actively, it must linger in 543 TIME-WAIT state for a time 2xMSL (Maximum Segment Lifetime). 544 This parameter sets the TIME-WAIT timeout duration in 545 seconds."; 546 reference 547 "RFC 793: Transmission Control Protocol"; 548 } 550 leaf congestion-control-default { 551 type identityref { 552 base congestion-control-algorithm; 553 } 554 description 555 "This parameter selects the congestion control algorithm that 556 is used by default for new TCP connections. The default may 557 be overridden per connection by means outside the scope of 558 this model (e.g., via the Sockets API)."; 559 reference 560 "RFC 2914: Congestion Control Principles"; 561 } 562 } 564 // TCP configuration 566 container tcp { 567 presence "The container for TCP configuration."; 569 description 570 "TCP container."; 572 container connections { 573 list connection { 574 key "local-address remote-address local-port remote-port"; 576 leaf local-address { 577 type inet:ip-address; 578 description 579 "Local address that forms the connection identifier."; 580 } 582 leaf remote-address { 583 type inet:ip-address; 584 description 585 "Remote address that forms the connection identifier."; 586 } 588 leaf local-port { 589 type inet:port-number; 590 description 591 "Local TCP port that forms the connection identifier."; 592 } 594 leaf remote-port { 595 type inet:port-number; 596 description 597 "Remote TCP port that forms the connection identifier."; 598 } 600 container common { 601 uses tcpcmn:tcp-common-grouping; 603 leaf congestion-control { 604 type identityref { 605 base congestion-control-algorithm; 606 } 607 config false; 608 description 609 "Type of the actually used TCP congestion control 610 algorithm. It may be different from the default 611 algorithm, for instance, if an application has 612 explicitly selected an algorithm."; 613 reference "RFC 2914: Congestion Control Principles"; 614 } 616 choice authentication { 617 case ao { 618 uses ao; 619 description 620 "Use TCP-AO to secure the connection."; 622 } 624 case md5 { 625 uses md5; 626 description 627 "Use TCP-MD5 to secure the connection."; 628 } 629 description 630 "Choice of how to secure the TCP connection."; 631 } 632 leaf tcp-nodelay { 633 type boolean; 634 config false; 635 description 636 "Disabling of the 'Nagle algorithm'."; 637 } 638 description 639 "Common definitions of TCP configuration. This includes 640 parameters such as how to secure the connection, 641 keepalives and idle time, that can be part of either 642 the client or server."; 643 } 645 container server { 646 if-feature server; 647 uses tcps:tcp-server-grouping; 648 description 649 "Definitions of TCP server configuration."; 650 } 652 container client { 653 if-feature client; 654 uses tcpc:tcp-client-grouping; 655 description 656 "Definitions of TCP client configuration."; 657 } 658 description 659 "Connection related parameters."; 660 } 661 description 662 "A container of all TCP connections."; 663 } 665 container global { 666 uses tcp-global; 667 description 668 "Parameters affecting all TCP connections"; 669 } 670 container statistics { 671 if-feature statistics; 672 config false; 674 leaf active-opens { 675 type yang:counter32; 676 description 677 "The number of times that TCP connections have made a direct 678 transition to the SYN-SENT state from the CLOSED state."; 679 } 681 leaf passive-opens { 682 type yang:counter32; 683 description 684 "The number of times TCP connections have made a direct 685 transition to the SYN-RCVD state from the LISTEN state."; 686 } 688 leaf attempt-fails { 689 type yang:counter32; 690 description 691 "The number of times that TCP connections have made a direct 692 transition to the CLOSED state from either the SYN-SENT 693 state or the SYN-RCVD state, plus the number of times that 694 TCP connections have made a direct transition to the 695 LISTEN state from the SYN-RCVD state."; 696 } 698 leaf establish-resets { 699 type yang:counter32; 700 description 701 "The number of times that TCP connections have made a direct 702 transition to the CLOSED state from either the ESTABLISHED 703 state or the CLOSE-WAIT state."; 704 } 706 leaf currently-established { 707 type yang:gauge32; 708 description 709 "The number of TCP connections for which the current state 710 is either ESTABLISHED or CLOSE-WAIT."; 711 } 713 leaf in-segments { 714 type yang:counter32; 715 description 716 "The total number of segments received, including those 717 received in error. This count includes segments received 718 on currently established connections."; 719 } 721 leaf out-segments { 722 type yang:counter32; 723 description 724 "The total number of segments sent, including those on 725 current connections but excluding those containing only 726 retransmitted octets."; 727 } 729 leaf retransmitted-segments { 730 type yang:counter32; 731 description 732 "The total number of segments retransmitted; that is, the 733 number of TCP segments transmitted containing one or more 734 previously transmitted octets."; 735 } 737 leaf in-errors { 738 type yang:counter32; 739 description 740 "The total number of segments received in error (e.g., bad 741 TCP checksums)."; 742 } 744 leaf out-resets { 745 type yang:counter32; 746 description 747 "The number of TCP segments sent containing the RST flag."; 748 } 750 action reset { 751 description 752 "Reset statistics action command."; 753 input { 754 leaf reset-at { 755 type yang:date-and-time; 756 description 757 "Time when the reset action needs to be 758 executed."; 759 } 760 } 761 output { 762 leaf reset-finished-at { 763 type yang:date-and-time; 764 description 765 "Time when the reset action command completed."; 767 } 768 } 769 } 770 description 771 "Statistics across all connections."; 772 } 773 } 774 } 776 778 5. IANA Considerations 780 5.1. The IETF XML Registry 782 This document registers two URIs in the "ns" subregistry of the IETF 783 XML Registry [RFC3688]. Following the format in IETF XML Registry 784 [RFC3688], the following registrations are requested: 786 URI: urn:ietf:params:xml:ns:yang:ietf-tcp 787 Registrant Contact: The TCPM WG of the IETF. 788 XML: N/A, the requested URI is an XML namespace. 790 5.2. The YANG Module Names Registry 792 This document registers a YANG modules in the YANG Module Names 793 registry YANG - A Data Modeling Language [RFC6020]. Following the 794 format in YANG - A Data Modeling Language [RFC6020], the following 795 registrations are requested: 797 name: ietf-tcp 798 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp 799 prefix: tcp 800 reference: RFC XXXX 802 6. Security Considerations 804 The YANG module specified in this document defines a schema for data 805 that is designed to be accessed via network management protocols such 806 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 807 is the secure transport layer, and the mandatory-to-implement secure 808 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 809 is HTTPS, and the mandatory-to-implement secure transport is TLS 810 [RFC8446]. 812 The Network Configuration Access Control Model (NACM) [RFC8341] 813 provides the means to restrict access for particular NETCONF or 814 RESTCONF users to a preconfigured subset of all available NETCONF or 815 RESTCONF protocol operations and content. 817 7. References 819 7.1. Normative References 821 [I-D.ietf-netconf-tcp-client-server] 822 Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients 823 and TCP Servers", draft-ietf-netconf-tcp-client-server-03 824 (work in progress), October 2019. 826 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 827 RFC 793, DOI 10.17487/RFC0793, September 1981, 828 . 830 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 831 Requirement Levels", BCP 14, RFC 2119, 832 DOI 10.17487/RFC2119, March 1997, 833 . 835 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 836 DOI 10.17487/RFC3688, January 2004, 837 . 839 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 840 the Network Configuration Protocol (NETCONF)", RFC 6020, 841 DOI 10.17487/RFC6020, October 2010, 842 . 844 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 845 and A. Bierman, Ed., "Network Configuration Protocol 846 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 847 . 849 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 850 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 851 . 853 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 854 RFC 7950, DOI 10.17487/RFC7950, August 2016, 855 . 857 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 858 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 859 . 861 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 862 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 863 May 2017, . 865 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 866 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 867 . 869 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 870 Access Control Model", STD 91, RFC 8341, 871 DOI 10.17487/RFC8341, March 2018, 872 . 874 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 875 and R. Wilton, "Network Management Datastore Architecture 876 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 877 . 879 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 880 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 881 . 883 7.2. Informative References 885 [I-D.ietf-dots-data-channel] 886 Boucadair, M. and T. Reddy.K, "Distributed Denial-of- 887 Service Open Threat Signaling (DOTS) Data Channel 888 Specification", draft-ietf-dots-data-channel-31 (work in 889 progress), July 2019. 891 [I-D.ietf-idr-bgp-model] 892 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 893 YANG Model for Service Provider Networks", draft-ietf-idr- 894 bgp-model-07 (work in progress), October 2019. 896 [I-D.ietf-taps-interface] 897 Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., 898 Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T. 899 Pauly, "An Abstract Application Layer Interface to 900 Transport Services", draft-ietf-taps-interface-05 (work in 901 progress), November 2019. 903 [RFC4022] Raghunarayan, R., Ed., "Management Information Base for 904 the Transmission Control Protocol (TCP)", RFC 4022, 905 DOI 10.17487/RFC4022, March 2005, 906 . 908 [RFC4898] Mathis, M., Heffner, J., and R. Raghunarayan, "TCP 909 Extended Statistics MIB", RFC 4898, DOI 10.17487/RFC4898, 910 May 2007, . 912 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 913 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 914 June 2010, . 916 [RFC6643] Schoenwaelder, J., "Translation of Structure of Management 917 Information Version 2 (SMIv2) MIB Modules to YANG 918 Modules", RFC 6643, DOI 10.17487/RFC6643, July 2012, 919 . 921 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 922 Vinapamula, S., and Q. Wu, "A YANG Module for Network 923 Address Translation (NAT) and Network Prefix Translation 924 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 925 . 927 [RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG 928 Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, 929 DOI 10.17487/RFC8513, January 2019, 930 . 932 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 933 "YANG Data Model for Network Access Control Lists (ACLs)", 934 RFC 8519, DOI 10.17487/RFC8519, March 2019, 935 . 937 Appendix A. Acknowledgements 939 Michael Scharf was supported by the StandICT.eu project, which is 940 funded by the European Commission under the Horizon 2020 Programme. 942 The following persons have contributed to this document by reviews: 943 Mohamed Boucadair 945 Appendix B. Changes compared to previous versions 947 Changes compared to draft-scharf-tcpm-yang-tcp-02 949 o Initial proposal of a YANG model including base configuration 950 parameters, TCP-AO configuration, and a connection list 952 o Editorial bugfixes and outdated references reported by Mohamed 953 Boucadair 955 o Additional co-author Mahesh Jethanandani 956 Changes compared to draft-scharf-tcpm-yang-tcp-01 958 o Alignment with [I-D.ietf-netconf-tcp-client-server] 960 o Removing backward-compatibility to the TCP MIB 962 o Additional co-author Vishal Murgai 964 Changes compared to draft-scharf-tcpm-yang-tcp-00 966 o Editorial improvements 968 Authors' Addresses 970 Michael Scharf 971 Hochschule Esslingen - University of Applied Sciences 972 Flandernstr. 101 973 Esslingen 73732 974 Germany 976 Email: michael.scharf@hs-esslingen.de 978 Vishal Murgai 979 Cisco Systems Inc 981 Email: vmurgai@cisco.com 983 Mahesh Jethanandani 984 VMware 986 Email: mjethanandani@gmail.com