idnits 2.17.1 draft-scharf-tcpm-yang-tcp-01.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 : ---------------------------------------------------------------------------- ** There are 11 instances of too long lines in the document, the longest one being 114 characters in excess of 72. ** The abstract seems to contain references ([RFC4022]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 280 has weird spacing: '...Address ine...' == Line 289 has weird spacing: '...essType ine...' == Line 298 has weird spacing: '...essType ine...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 24, 2019) is 1887 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) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-36) exists of draft-ietf-netconf-netconf-client-server-08 Summary: 3 errors (**), 0 flaws (~~), 6 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 February 24, 2019 5 Expires: August 28, 2019 7 Transmission Control Protocol (TCP) YANG Model 8 draft-scharf-tcpm-yang-tcp-01 10 Abstract 12 This document specifies a base YANG model for TCP on devices that are 13 configured by network management protocols. The YANG model is 14 loosely based on the standard TCP-MIB [RFC4022]. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on August 28, 2019. 33 Copyright Notice 35 Copyright (c) 2019 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Why a YANG Model for TCP? . . . . . . . . . . . . . . . . 3 52 1.2. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 54 3. Overview of the YANG Model for TCP . . . . . . . . . . . . . 5 55 3.1. Model Design . . . . . . . . . . . . . . . . . . . . . . 5 56 3.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 6 57 4. TCP YANG Model . . . . . . . . . . . . . . . . . . . . . . . 7 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 61 7.1. Normative References . . . . . . . . . . . . . . . . . . 19 62 7.2. Informative References . . . . . . . . . . . . . . . . . 21 63 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 22 64 Appendix B. Changes compared to previous versions . . . . . . . 22 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 67 1. Introduction 69 The Transmission Control Protocol (TCP) [RFC0793] is used by several 70 control and management protocols in the Internet. Therefore, TCP is 71 implemented on network elements that can be configured via network 72 management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. 73 This document specifies a YANG data model [RFC6020][RFC7950] for 74 configuring and operating TCP on network elements that support YANG 75 data models. 77 Many protocol stacks on Internet hosts use other methods to configure 78 TCP, such as operating system configuration or policies. Such TCP 79 stacks typically cannot be configured by network management protocols 80 such as NETCONF or RESTCONF. This document only applies to network 81 elements that use YANG data models. 83 This document is related to other standardization efforts. A 84 Management Information Base (MIB) for the Transmission Control 85 Protocol (TCP) has been standardized [RFC4022], and various managed 86 network devices support the TCP-MIB. A MIB providing extended 87 statistics for TCP is also available [RFC4898]. In addition, there 88 are also MIBs for UDP [RFC4113] and SCTP [RFC3873]. 90 The document defines a YANG data model for configuration and 91 operational state of a TCP implementation. The model focuses on 92 fundamental and standard TCP functions. The model can be augmented 93 to address more advanced or implementation-specific TCP features. 95 1.1. Why a YANG Model for TCP? 97 [[Editor's node: This section shall be removed or reworded in later 98 versions of the document.]] 100 This section summarizes reasons why the specification of a YANG model 101 for TCP could be useful to maintain TCP's utility. 103 As more and more network elements can be managed by management 104 protocols such as NETCONF or RESTCONF, network elements may need a 105 YANG model for TCP stack configuration and operation. This could in 106 particular apply to network elements that support the TCP-MIB 107 [RFC4022] but migrate to management by NETCONF or RESTCONF. In such 108 cases, one option would be to translate the TCP-MIB into a YANG 109 model, for instance using the translation described in [RFC6643]. 110 However, such a translated YANG model neither allows configuration, 111 nor is the content up-to-date. For instance, the TCP-MIB refers to 112 standards that have been obsoleted. 114 Given the advantages of YANG, there are also many ongoing efforts to 115 define YANG models. An increasing number of YANG models include TCP 116 and TCP-related parameters for specific usage scenarios. Examples 117 are: 119 o TCP connection properties such as use of keep-alives can be 120 configured by [I-D.ietf-netconf-netconf-client-server]. 122 o TCP header attributes are modeled in [I-D.ietf-netmod-acl-model]. 124 o TCP-related configuration of a NAT is defined in 125 [I-D.ietf-opsawg-nat-yang]. 127 It is possible that further YANG models would include aspects of or 128 relate to TCP stack configuration. An example could be YANG models 129 for other TCP-based protocols running on network elements. Instead 130 of specifying TCP configuration separately for each use cases, a 131 better alternative may be to define a common YANG model for TCP, from 132 which definitions and objects could be reused as needed. 134 The intention of this document is to explore whether a YANG model for 135 TCP is useful, and if so, what such a model would include (and what 136 not). 138 This document targets the TCPM working group as the TCPM charter 139 includes work on "interfaces that maintain TCP's utility". The YANG 140 model deals with the network management interface of a TCP 141 implementation. The interface used for data transfer between an 142 application and the TCP stack is outside the scope of this document. 144 1.2. Open Issues 146 [[Editor's node: This section shall be removed in later versions of 147 the document.]] 149 There are many open questions on the scope of this document that need 150 discussion and community feedback: 152 o Scope: TCP stacks can typically be customized by configuration, 153 including implementation-specific internal behavior. A standard 154 YANG model should focus on fundamental TCP parameters that are 155 independent of the internals of an implementation, that are 156 available in all or most implementations, and that matter for 157 network management. This set of TCP configuration parameters 158 needs to be determined. Additional implementation-specific 159 configuration could be added by augmentation of the YANG model and 160 would not require standardization. 162 o Backward compatibility: There may be implementations that support 163 the TCP-MIB [RFC4022], possibly in addition to YANG models. In 164 such cases, one option could be to translate the TCP-MIB [RFC4022] 165 into an equivalent YANG model. The TCP-MIB is not up-to-date. 166 Additions could be needed to reflect e.g. the progress of TCP 167 standards. It is an open question whether a YANG model would need 168 "backward-compatibility" to TCP-MIB entries, and, if so, if this 169 is needed for all TCP-MIB entries. 171 o General definitions: A TCP model could perhaps include general 172 YANG type definitions and groupings for TCP. They could be reused 173 by other YANG models. Having a common definition of TCP-related 174 attributes could ensure consistency. It is an open question 175 whether definitions in a TCP model would indeed be used by other 176 YANG models. 178 o Extended statistics: It needs to be decided whether extended 179 statistics [RFC4898] would be in scope of a TCP YANG model. 181 o Suggested MIB additions: Extensions to the TCP-MIB [RFC4022] have 182 been suggested, e.g., in [RFC5482]. A YANG model could possibly 183 take into account such proposed extensions. 185 o Cross-layer functionality: The TCP configuration may have 186 dependencies on other protocols. It needs to be figured out if 187 and how this can be modelled. An example could be enabling of TCP 188 keep-alives, which should be off by default [RFC1122]. 190 o Alignment: Further discussion is needed on alignment of a TCP YANG 191 model with other transport protocols. This would include UDP and 192 SCTP. 194 o Status of [RFC4022]: Standardization of a YANG model does not 195 affect an existing MIB. As a result, updating or deprecating 196 [RFC4022] may not be necessary even if a YANG model for TCP is 197 standardized. However, more analysis is needed on how future 198 versions of this I-D would relate to or reference [RFC4022]. 200 o Implementation aspects: Implementation aspects of a YANG model for 201 TCP need further analysis. 203 o Authoring: If there is a need for similarity to the TCP-MIB, 204 authors and contributors to [RFC4022] could/should be added as 205 authors or contributors to this document. 207 2. Requirements Language 209 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 210 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 211 "OPTIONAL" in this document are to be interpreted as described in BCP 212 14 [RFC2119] [RFC8174] when, and only when, they appear in all 213 capitals, as shown here. 215 3. Overview of the YANG Model for TCP 217 [[Editor's node: This section should to be improved in follow-up 218 versions of this document.]] 220 3.1. Model Design 222 [[Editor's node: In potential follow-up versions of this document, 223 this section will discuss the design of the TCP YANG model.]] 225 A standard YANG data model for TCP should follow the Network 226 Management Datastore Architecture (NMDA) [RFC8342]. 228 The YANG model in the -00 version of this document has been 229 translated from the TCP-MIB [RFC4022] without modifications (apart 230 from removing outdated meta-data). The motivation of using the 231 standard TCP-MIB definitions as a baseline for -00 is to facilitate 232 the tracking of potential changes in later versions of this 233 specification, as far as this is needed. 235 The TCP-MIB defined in [RFC4022] consists of several objects and two 236 tables: 238 o Parameters of a TCP protocol engine. These include parameters 239 such as the retransmission algorithm in use and the retransmission 240 timeout values. 242 o Statistics of a TCP protocol engine. These include counters for 243 the number of active/passive opens, input/output segments, and 244 errors. 246 o A TCP connection table provides access to status information for 247 all TCP connections handled by a TCP protocol engine. In 248 addition, the table reports identification of the operating system 249 level processes that handle the TCP connections. 251 o A TCP listener table provides access to information about all TCP 252 listening endpoints known by a TCP protocol engine. And as with 253 the connection table, this table also reports the identification 254 of the operating system level processes that handle this listening 255 TCP endpoint. 257 The extended statistics defined in [RFC4898] have been omitted in the 258 initial version of this specification. They can be added as needed. 260 3.2. Tree Diagram 262 [[Editor's node: This section is TBD.]] 264 module: TCP-MIB 265 +--rw tcp 266 +--ro tcpRtoAlgorithm? enumeration 267 +--ro tcpRtoMin? int32 268 +--ro tcpRtoMax? int32 269 +--ro tcpMaxConn? int32 270 +--ro tcpActiveOpens? yang:counter32 271 +--ro tcpPassiveOpens? yang:counter32 272 +--ro tcpAttemptFails? yang:counter32 273 +--ro tcpEstabResets? yang:counter32 274 +--ro tcpCurrEstab? yang:gauge32 275 +--ro tcpInSegs? yang:counter32 276 +--ro tcpOutSegs? yang:counter32 277 +--ro tcpRetransSegs? yang:counter32 278 x--rw tcpConnEntry* [tcpConnLocalAddress tcpConnLocalPort tcpConnRemAddress tcpConnRemPort] 279 | x--rw tcpConnState? enumeration 280 | x--ro tcpConnLocalAddress inet:ipv4-address 281 | x--ro tcpConnLocalPort int32 282 | x--ro tcpConnRemAddress inet:ipv4-address 283 | x--ro tcpConnRemPort int32 284 +--ro tcpInErrs? yang:counter32 285 +--ro tcpOutRsts? yang:counter32 286 +--ro tcpHCInSegs? yang:counter64 287 +--ro tcpHCOutSegs? yang:counter64 288 +--rw tcpConnectionEntry* [tcpConnectionLocalAddressType tcpConnectionLocalAddress tcpConnectionLocalPort tcpConnectionRemAddressType tcpConnectionRemAddress tcpConnectionRemPort] 289 | +--ro tcpConnectionLocalAddressType inet-address:InetAddressType 290 | +--ro tcpConnectionLocalAddress inet-address:InetAddress 291 | +--ro tcpConnectionLocalPort inet-address:InetPortNumber 292 | +--ro tcpConnectionRemAddressType inet-address:InetAddressType 293 | +--ro tcpConnectionRemAddress inet-address:InetAddress 294 | +--ro tcpConnectionRemPort inet-address:InetPortNumber 295 | +--rw tcpConnectionState? enumeration 296 | +--ro tcpConnectionProcess? uint32 297 +--rw tcpListenerEntry* [tcpListenerLocalAddressType tcpListenerLocalAddress tcpListenerLocalPort] 298 +--ro tcpListenerLocalAddressType inet-address:InetAddressType 299 +--ro tcpListenerLocalAddress inet-address:InetAddress 300 +--ro tcpListenerLocalPort inet-address:InetPortNumber 301 +--ro tcpListenerProcess? uint32 303 4. TCP YANG Model 305 [[Editor's node: This section is TBD.]] 307 The following YANG module has been generated by smidump 0.4.8 using 308 the command "smidump -f yang TCP-MIB". Improvements to the 309 translated YANG model are planed for future versions of this 310 specification. The -00 version of this model is just published as a 311 baseline and to enable tracking of changes in later versions of the 312 memo. 314 file "ietf-tcp-translated@2005-02-18.yang" 315 module TCP-MIB { 317 /*** NAMESPACE / PREFIX DEFINITION ***/ 319 namespace "urn:ietf:params:xml:ns:yang:smiv2:TCP-MIB"; 320 prefix "tcp-mib"; 322 /*** LINKAGE (IMPORTS / INCLUDES) ***/ 324 import INET-ADDRESS-MIB { prefix "inet-address"; } 325 import inet-types { prefix "inet"; } 326 import yang-types { prefix "yang"; } 328 /*** META INFORMATION ***/ 330 organization 331 "TBD"; 333 contact 334 "TBD"; 336 description 337 "TBD"; 339 revision "2005-02-18" { 340 description 341 "IP version neutral revision, published as RFC 4022."; 342 } 343 revision "1994-11-01" { 344 description 345 "Initial SMIv2 version, published as RFC 2012."; 346 } 347 revision "1991-03-31" { 348 description 349 "The initial revision of this MIB module was part of 350 MIB-II."; 351 } 353 container tcp { 355 leaf tcpRtoAlgorithm { 356 type enumeration { 357 enum other { value 1; } 358 enum constant { value 2; } 359 enum rsre { value 3; } 360 enum vanj { value 4; } 361 enum rfc2988 { value 5; } 362 } 363 config false; 364 description 365 "The algorithm used to determine the timeout value used for 366 retransmitting unacknowledged octets."; 367 } 369 leaf tcpRtoMin { 370 type int32 { 371 range "0..2147483647"; 372 } 373 units "milliseconds"; 374 config false; 375 description 376 "The minimum value permitted by a TCP implementation for 377 the retransmission timeout, measured in milliseconds. 378 More refined semantics for objects of this type depend 379 on the algorithm used to determine the retransmission 380 timeout; in particular, the IETF standard algorithm 381 rfc2988(5) provides a minimum value."; 382 } 384 leaf tcpRtoMax { 385 type int32 { 386 range "0..2147483647"; 387 } 388 units "milliseconds"; 389 config false; 390 description 391 "The maximum value permitted by a TCP implementation for 392 the retransmission timeout, measured in milliseconds. 393 More refined semantics for objects of this type depend 394 on the algorithm used to determine the retransmission 395 timeout; in particular, the IETF standard algorithm 396 rfc2988(5) provides an upper bound (as part of an 397 adaptive backoff algorithm)."; 398 } 400 leaf tcpMaxConn { 401 type int32 { 402 range "-1..2147483647"; 403 } 404 config false; 405 description 406 "The limit on the total number of TCP connections the entity 407 can support. In entities where the maximum number of 408 connections is dynamic, this object should contain the 409 value -1."; 410 } 412 leaf tcpActiveOpens { 413 type yang:counter32; 414 config false; 415 description 416 "The number of times that TCP connections have made a direct 417 transition to the SYN-SENT state from the CLOSED state. 419 Discontinuities in the value of this counter are 420 indicated via discontinuities in the value of sysUpTime."; 421 } 423 leaf tcpPassiveOpens { 424 type yang:counter32; 425 config false; 426 description 427 "The number of times TCP connections have made a direct 428 transition to the SYN-RCVD state from the LISTEN state. 430 Discontinuities in the value of this counter are 431 indicated via discontinuities in the value of sysUpTime."; 432 } 434 leaf tcpAttemptFails { 435 type yang:counter32; 436 config false; 437 description 438 "The number of times that TCP connections have made a direct 439 transition to the CLOSED state from either the SYN-SENT 440 state or the SYN-RCVD state, plus the number of times that 441 TCP connections have made a direct transition to the 442 LISTEN state from the SYN-RCVD state. 444 Discontinuities in the value of this counter are 445 indicated via discontinuities in the value of sysUpTime."; 446 } 448 leaf tcpEstabResets { 449 type yang:counter32; 450 config false; 451 description 452 "The number of times that TCP connections have made a direct 453 transition to the CLOSED state from either the ESTABLISHED 454 state or the CLOSE-WAIT state. 456 Discontinuities in the value of this counter are 457 indicated via discontinuities in the value of sysUpTime."; 458 } 460 leaf tcpCurrEstab { 461 type yang:gauge32; 462 config false; 463 description 464 "The number of TCP connections for which the current state 465 is either ESTABLISHED or CLOSE-WAIT."; 466 } 468 leaf tcpInSegs { 469 type yang:counter32; 470 config false; 471 description 472 "The total number of segments received, including those 473 received in error. This count includes segments received 474 on currently established connections. 476 Discontinuities in the value of this counter are 477 indicated via discontinuities in the value of sysUpTime."; 478 } 480 leaf tcpOutSegs { 481 type yang:counter32; 482 config false; 483 description 484 "The total number of segments sent, including those on 485 current connections but excluding those containing only 486 retransmitted octets. 488 Discontinuities in the value of this counter are 489 indicated via discontinuities in the value of sysUpTime."; 490 } 492 leaf tcpRetransSegs { 493 type yang:counter32; 494 config false; 495 description 496 "The total number of segments retransmitted; that is, the 497 number of TCP segments transmitted containing one or more 498 previously transmitted octets. 500 Discontinuities in the value of this counter are 501 indicated via discontinuities in the value of sysUpTime."; 502 } 503 /* XXX table comments here XXX */ 505 list tcpConnEntry { 507 key "tcpConnLocalAddress tcpConnLocalPort 508 tcpConnRemAddress tcpConnRemPort"; 509 status deprecated; 510 description 511 "A conceptual row of the tcpConnTable containing information 512 about a particular current IPv4 TCP connection. Each row 513 of this table is transient in that it ceases to exist when 514 (or soon after) the connection makes the transition to the 515 CLOSED state."; 517 leaf tcpConnState { 518 type enumeration { 519 enum closed { value 1; } 520 enum listen { value 2; } 521 enum synSent { value 3; } 522 enum synReceived { value 4; } 523 enum established { value 5; } 524 enum finWait1 { value 6; } 525 enum finWait2 { value 7; } 526 enum closeWait { value 8; } 527 enum lastAck { value 9; } 528 enum closing { value 10; } 529 enum timeWait { value 11; } 530 enum deleteTCB { value 12; } 531 } 532 config true; 533 status deprecated; 534 description 535 "The state of this TCP connection. 537 The only value that may be set by a management station is 538 deleteTCB(12). Accordingly, it is appropriate for an agent 539 to return a `badValue' response if a management station 540 attempts to set this object to any other value. 542 If a management station sets this object to the value 543 deleteTCB(12), then the TCB (as defined in [RFC793]) of 544 the corresponding connection on the managed node is 545 deleted, resulting in immediate termination of the 546 connection. 548 As an implementation-specific option, a RST segment may be 549 sent from the managed node to the other TCP endpoint (note, 550 however, that RST segments are not sent reliably)."; 551 } 553 leaf tcpConnLocalAddress { 554 type inet:ipv4-address; 555 config false; 556 status deprecated; 557 description 558 "The local IP address for this TCP connection. In the case 559 of a connection in the listen state willing to 560 accept connections for any IP interface associated with the 561 node, the value 0.0.0.0 is used."; 562 } 564 leaf tcpConnLocalPort { 565 type int32 { 566 range "0..65535"; 567 } 568 config false; 569 status deprecated; 570 description 571 "The local port number for this TCP connection."; 572 } 574 leaf tcpConnRemAddress { 575 type inet:ipv4-address; 576 config false; 577 status deprecated; 578 description 579 "The remote IP address for this TCP connection."; 580 } 582 leaf tcpConnRemPort { 583 type int32 { 584 range "0..65535"; 585 } 586 config false; 587 status deprecated; 588 description 589 "The remote port number for this TCP connection."; 590 } 591 } 593 leaf tcpInErrs { 594 type yang:counter32; 595 config false; 596 description 597 "The total number of segments received in error (e.g., bad 598 TCP checksums). 600 Discontinuities in the value of this counter are 601 indicated via discontinuities in the value of sysUpTime."; 602 } 604 leaf tcpOutRsts { 605 type yang:counter32; 606 config false; 607 description 608 "The number of TCP segments sent containing the RST flag. 610 Discontinuities in the value of this counter are 611 indicated via discontinuities in the value of sysUpTime."; 612 } 614 leaf tcpHCInSegs { 615 type yang:counter64; 616 config false; 617 description 618 "The total number of segments received, including those 619 received in error. This count includes segments received 621 on currently established connections. This object is 622 the 64-bit equivalent of tcpInSegs. 624 Discontinuities in the value of this counter are 625 indicated via discontinuities in the value of sysUpTime."; 626 } 628 leaf tcpHCOutSegs { 629 type yang:counter64; 630 config false; 631 description 632 "The total number of segments sent, including those on 633 current connections but excluding those containing only 634 retransmitted octets. This object is the 64-bit 635 equivalent of tcpOutSegs. 637 Discontinuities in the value of this counter are 638 indicated via discontinuities in the value of sysUpTime."; 639 } 641 /* XXX table comments here XXX */ 643 list tcpConnectionEntry { 644 key "tcpConnectionLocalAddressType 645 tcpConnectionLocalAddress tcpConnectionLocalPort 646 tcpConnectionRemAddressType tcpConnectionRemAddress 647 tcpConnectionRemPort"; 648 description 649 "A conceptual row of the tcpConnectionTable containing 650 information about a particular current TCP connection. 651 Each row of this table is transient in that it ceases to 652 exist when (or soon after) the connection makes the 653 transition to the CLOSED state."; 655 leaf tcpConnectionLocalAddressType { 656 type inet-address:InetAddressType; 657 config false; 658 description 659 "The address type of tcpConnectionLocalAddress."; 660 } 662 leaf tcpConnectionLocalAddress { 663 type inet-address:InetAddress; 664 config false; 665 description 666 "The local IP address for this TCP connection. The type 667 of this address is determined by the value of 668 tcpConnectionLocalAddressType. 670 As this object is used in the index for the 671 tcpConnectionTable, implementors should be 672 careful not to create entries that would result in OIDs 673 with more than 128 subidentifiers; otherwise the information 674 cannot be accessed by using SNMPv1, SNMPv2c, or SNMPv3."; 675 } 677 leaf tcpConnectionLocalPort { 678 type inet-address:InetPortNumber; 679 config false; 680 description 681 "The local port number for this TCP connection."; 682 } 684 leaf tcpConnectionRemAddressType { 685 type inet-address:InetAddressType; 686 config false; 687 description 688 "The address type of tcpConnectionRemAddress."; 689 } 690 leaf tcpConnectionRemAddress { 691 type inet-address:InetAddress; 692 config false; 693 description 694 "The remote IP address for this TCP connection. The type 695 of this address is determined by the value of 696 tcpConnectionRemAddressType. 698 As this object is used in the index for the 699 tcpConnectionTable, implementors should be 700 careful not to create entries that would result in OIDs 701 with more than 128 subidentifiers; otherwise the information 702 cannot be accessed by using SNMPv1, SNMPv2c, or SNMPv3."; 703 } 705 leaf tcpConnectionRemPort { 706 type inet-address:InetPortNumber; 707 config false; 708 description 709 "The remote port number for this TCP connection."; 710 } 712 leaf tcpConnectionState { 713 type enumeration { 714 enum closed { value 1; } 715 enum listen { value 2; } 716 enum synSent { value 3; } 717 enum synReceived { value 4; } 718 enum established { value 5; } 719 enum finWait1 { value 6; } 720 enum finWait2 { value 7; } 721 enum closeWait { value 8; } 722 enum lastAck { value 9; } 723 enum closing { value 10; } 724 enum timeWait { value 11; } 725 enum deleteTCB { value 12; } 726 } 727 config true; 728 description 729 "The state of this TCP connection. 731 The value listen(2) is included only for parallelism to the 732 old tcpConnTable and should not be used. A connection in 733 LISTEN state should be present in the tcpListenerTable. 735 The only value that may be set by a management station is 736 deleteTCB(12). Accordingly, it is appropriate for an agent 737 to return a `badValue' response if a management station 738 attempts to set this object to any other value. 740 If a management station sets this object to the value 741 deleteTCB(12), then the TCB (as defined in [RFC793]) of 742 the corresponding connection on the managed node is 743 deleted, resulting in immediate termination of the 744 connection. 746 As an implementation-specific option, a RST segment may be 747 sent from the managed node to the other TCP endpoint (note, 748 however, that RST segments are not sent reliably)."; 749 } 751 leaf tcpConnectionProcess { 752 type uint32; 753 config false; 754 description 755 "The system's process ID for the process associated with 756 this connection, or zero if there is no such process. This 757 value is expected to be the same as HOST-RESOURCES-MIB:: 758 hrSWRunIndex or SYSAPPL-MIB::sysApplElmtRunIndex for some 759 row in the appropriate tables."; 760 } 761 } 763 /* XXX table comments here XXX */ 765 list tcpListenerEntry { 767 key "tcpListenerLocalAddressType tcpListenerLocalAddress 768 tcpListenerLocalPort"; 769 description 770 "A conceptual row of the tcpListenerTable containing 771 information about a particular TCP listener."; 773 leaf tcpListenerLocalAddressType { 774 type inet-address:InetAddressType; 775 config false; 776 description 777 "The address type of tcpListenerLocalAddress. The value 778 should be unknown (0) if connection initiations to all 779 local IP addresses are accepted."; 780 } 782 leaf tcpListenerLocalAddress { 783 type inet-address:InetAddress; 784 config false; 785 description 786 "The local IP address for this TCP connection. 788 The value of this object can be represented in three 789 possible ways, depending on the characteristics of the 790 listening application: 792 1. For an application willing to accept both IPv4 and 793 IPv6 datagrams, the value of this object must be 794 ''h (a zero-length octet-string), with the value 795 of the corresponding tcpListenerLocalAddressType 796 object being unknown (0). 798 2. For an application willing to accept only IPv4 or 799 IPv6 datagrams, the value of this object must be 800 '0.0.0.0' or '::' respectively, with 801 tcpListenerLocalAddressType representing the 802 appropriate address type. 804 3. For an application which is listening for data 805 destined only to a specific IP address, the value 806 of this object is the specific local address, with 807 tcpListenerLocalAddressType representing the 808 appropriate address type. 810 As this object is used in the index for the 811 tcpListenerTable, implementors should be 812 careful not to create entries that would result in OIDs 813 with more than 128 subidentifiers; otherwise the information 814 cannot be accessed, using SNMPv1, SNMPv2c, or SNMPv3."; 815 } 817 leaf tcpListenerLocalPort { 818 type inet-address:InetPortNumber; 819 config false; 820 description 821 "The local port number for this TCP connection."; 822 } 824 leaf tcpListenerProcess { 825 type uint32; 826 config false; 827 description 828 "The system's process ID for the process associated with 829 this listener, or zero if there is no such process. This 830 value is expected to be the same as HOST-RESOURCES-MIB:: 831 hrSWRunIndex or SYSAPPL-MIB::sysApplElmtRunIndex for some 832 row in the appropriate tables."; 833 } 834 } 835 } 837 } /* end of module TCP-MIB */ 838 840 5. IANA Considerations 842 [[Editor's node: This section will be completed in follow-up versions 843 of this document.]] 845 6. Security Considerations 847 The YANG module specified in this document defines a schema for data 848 that is designed to be accessed via network management protocols such 849 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 850 is the secure transport layer, and the mandatory-to-implement secure 851 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 852 is HTTPS, and the mandatory-to-implement secure transport is TLS 853 [RFC8446]. 855 The Network Configuration Access Control Model (NACM) [RFC8341] 856 provides the means to restrict access for particular NETCONF or 857 RESTCONF users to a preconfigured subset of all available NETCONF or 858 RESTCONF protocol operations and content. 860 7. References 862 7.1. Normative References 864 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 865 RFC 793, DOI 10.17487/RFC0793, September 1981, 866 . 868 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 869 Communication Layers", STD 3, RFC 1122, 870 DOI 10.17487/RFC1122, October 1989, 871 . 873 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 874 Requirement Levels", BCP 14, RFC 2119, 875 DOI 10.17487/RFC2119, March 1997, 876 . 878 [RFC4022] Raghunarayan, R., Ed., "Management Information Base for 879 the Transmission Control Protocol (TCP)", RFC 4022, 880 DOI 10.17487/RFC4022, March 2005, 881 . 883 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 884 the Network Configuration Protocol (NETCONF)", RFC 6020, 885 DOI 10.17487/RFC6020, October 2010, 886 . 888 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 889 and A. Bierman, Ed., "Network Configuration Protocol 890 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 891 . 893 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 894 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 895 . 897 [RFC6643] Schoenwaelder, J., "Translation of Structure of Management 898 Information Version 2 (SMIv2) MIB Modules to YANG 899 Modules", RFC 6643, DOI 10.17487/RFC6643, July 2012, 900 . 902 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 903 RFC 7950, DOI 10.17487/RFC7950, August 2016, 904 . 906 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 907 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 908 . 910 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 911 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 912 May 2017, . 914 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 915 Access Control Model", STD 91, RFC 8341, 916 DOI 10.17487/RFC8341, March 2018, 917 . 919 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 920 and R. Wilton, "Network Management Datastore Architecture 921 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 922 . 924 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 925 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 926 . 928 7.2. Informative References 930 [I-D.ietf-netconf-netconf-client-server] 931 Watsen, K., "NETCONF Client and Server Models", draft- 932 ietf-netconf-netconf-client-server-08 (work in progress), 933 October 2018. 935 [I-D.ietf-netmod-acl-model] 936 Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 937 "Network Access Control List (ACL) YANG Data Model", 938 draft-ietf-netmod-acl-model-21 (work in progress), 939 November 2018. 941 [I-D.ietf-opsawg-nat-yang] 942 Boucadair, M., Sivakumar, S., Jacquenet, C., Vinapamula, 943 S., and Q. Wu, "A YANG Module for Network Address 944 Translation (NAT) and Network Prefix Translation (NPT)", 945 draft-ietf-opsawg-nat-yang-17 (work in progress), 946 September 2018. 948 [LIBSMI] University of Braunschweig, "libsmi - A Library to Access 949 SMI MIB Information", 2014, 950 . 952 [RFC3873] Pastor, J. and M. Belinchon, "Stream Control Transmission 953 Protocol (SCTP) Management Information Base (MIB)", 954 RFC 3873, DOI 10.17487/RFC3873, September 2004, 955 . 957 [RFC4113] Fenner, B. and J. Flick, "Management Information Base for 958 the User Datagram Protocol (UDP)", RFC 4113, 959 DOI 10.17487/RFC4113, June 2005, 960 . 962 [RFC4898] Mathis, M., Heffner, J., and R. Raghunarayan, "TCP 963 Extended Statistics MIB", RFC 4898, DOI 10.17487/RFC4898, 964 May 2007, . 966 [RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", 967 RFC 5482, DOI 10.17487/RFC5482, March 2009, 968 . 970 Appendix A. Acknowledgements 972 Michael Scharf is supported by the StandICT.eu project, which is 973 funded by the European Commission under the Horizon 2020 Programme. 975 The YANG model used in version -00 of the document has been converted 976 from [RFC4022] by the LIBSMI library [LIBSMI]. 978 Appendix B. Changes compared to previous versions 980 Changes compared to draft-scharf-tcpm-yang-tcp-00 982 o Editorial improvements 984 Author's Address 986 Michael Scharf 987 Hochschule Esslingen - University of Applied Sciences 988 Flandernstr. 101 989 Esslingen 73732 990 Germany 992 Email: michael.scharf@hs-esslingen.de