idnits 2.17.1 draft-ietf-tcpm-undeployed-02.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC721, but the abstract doesn't seem to directly say this. It does mention RFC721 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC896, but the abstract doesn't seem to directly say this. It does mention RFC896 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC761, but the abstract doesn't seem to directly say this. It does mention RFC761 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC675, but the abstract doesn't seem to directly say this. It does mention RFC675 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC879, but the abstract doesn't seem to directly say this. It does mention RFC879 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC813, but the abstract doesn't seem to directly say this. It does mention RFC813 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC816, but the abstract doesn't seem to directly say this. It does mention RFC816 though, so this could be OK. -- The draft header indicates that this document updates RFC7414, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: o RFC 1078 U: "TCP Port Service Multiplexer (TCPMUX)" [RFC1078]: this proposal SHOULD not longer recommended for use for the following reason: == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: o RFC 6013 E: "TCP Cookie Transactions (TCPCT)" [RFC6013]: although RFC 6013 was published in 2011, RFC 6013 SHOULD not longer recommended for use for the following reason: -- The document date (July 29, 2015) is 3165 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 675 (Obsoleted by RFC 7805) ** Obsolete normative reference: RFC 721 (Obsoleted by RFC 7805) ** Obsolete normative reference: RFC 761 (Obsoleted by RFC 793, RFC 7805) ** Obsolete normative reference: RFC 813 (Obsoleted by RFC 7805) ** Obsolete normative reference: RFC 816 (Obsoleted by RFC 7805) ** Obsolete normative reference: RFC 879 (Obsoleted by RFC 7805, RFC 9293) ** Obsolete normative reference: RFC 896 (Obsoleted by RFC 7805) ** Obsolete normative reference: RFC 1078 (Obsoleted by RFC 7805) ** Obsolete normative reference: RFC 6013 (Obsoleted by RFC 7805) == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcp-edo-01 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 6691 (Obsoleted by RFC 9293) Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor Extensions (TCPM) WG A. Zimmermann 3 Internet-Draft NetApp, Inc. 4 Obsoletes: 675 721 761 813 816 879 896 W. Eddy 5 1078 6013 (if approved) MTI Systems 6 Updates: 7414 (if approved) L. Eggert 7 Intended status: Informational NetApp, Inc. 8 Expires: January 30, 2016 July 29, 2015 10 Moving Outdated TCP Extensions and TCP-related Documents to 11 Historic and Informational Status 12 draft-ietf-tcpm-undeployed-02 14 Abstract 16 This document reclassifies several TCP extensions and TCP-related 17 documents that have either been superseded, never seen widespread 18 use, or are no longer recommended for use to Historic status. The 19 affected RFCs are RFC 675, RFC 721, RFC 761, RFC 813, RFC 816, RFC 20 879, RFC 896, RFC 1078, and RFC 6013. Additionally, it reclassifies 21 RFC 700, RFC 794, RFC 814, RFC 817, RFC 872, RFC 889, RFC 964, and 22 RFC 1071 to Informational status. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 30, 2016. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 1. Introduction 58 TCP has a long history. Over time, many RFCs have accumulated that 59 describe aspects of the TCP protocol, implementation, and extensions. 60 Some of these have become superseded, are no longer recommended for 61 use, or simply have never seen widespread use, respectively 62 deployment. 64 Section 6 and 7.1 of the TCP Roadmap document [RFC7414] already 65 classify a number of TCP extensions as "historic" and describes the 66 reasons for doing so, but it does not instruct the RFC Editor to 67 change the status of these RFCs in the RFC database. 69 The purpose of this document is to do just that. In addition, it 70 moves all remaining TCP-related documents of the TCP Roadmap document 71 with an "unknown" status either to Historic or Informational. 73 2. Terminology 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. These 78 words only have such normative significance when in ALL CAPS, not 79 when in lower case. 81 3. RFC Editor Considerations 83 The following two sections give a short justification, why a specific 84 TCP extension or a TCP-related document should be moved to Historic 85 or Informational. In addition, a letter code after an RFC number 86 indicates from what category in the RFC series a particular RFC is 87 changed to Historic or Informational status (see BCP 9 [RFC2026] for 88 explanation of these categories): 90 S - Standards Track (Proposed Standard, Draft Standard, or 91 Internet Standard) 93 E - Experimental 95 I - Informational 96 H - Historic 98 B - Best Current Practice 100 U - Unknown (not formally defined) 102 For the content of the documents itself, the reader is referred 103 either to the corresponding RFC or, for a brief description, to the 104 TCP Roadmap document [RFC7414]. 106 3.1. Moving to Historic Status 108 The RFC Editor is requested to change the status of the following 109 RFCs to Historic [RFC2026]: 111 o RFC 675 U: "Specification of Internet Transmission Control 112 Program" [RFC0675]: this document is replaced by final TCP 113 specification [RFC0793]. 115 o RFC 721 U: "Out-of-Band Control Signals in a Host-to-Host 116 Protocol" [RFC0721]: this proposal is not incorporated into the 117 final TCP specification [RFC0793]. 119 o RFC 761 U: "DoD standard Transmission Control Protocol" [RFC0761]: 120 this document is replaced by final TCP specification [RFC0793]. 122 o RFC 813 U: "Window and Acknowledgement Strategy in TCP" [RFC0813]: 123 this document is incorporated into RFC 1122 [RFC1122]. 125 o RFC 816 U: "Fault Isolation and Recovery" [RFC0816]: this document 126 is incorporated into RFC 1122 [RFC1122] and RFC 5461 [RFC5461]. 128 o RFC 879 U: "The TCP Maximum Segment Size and Related Topics" 129 [RFC0879]: this document is incorporated into RFC 1122 [RFC1122] 130 and RFC 6691 [RFC6691]. 132 o RFC 896 U: "Congestion Control in IP/TCP Internetworks" [RFC0896]: 133 this document is incorporated into RFC 1122 [RFC1122] and RFC 6633 134 [RFC6633]. 136 o RFC 1078 U: "TCP Port Service Multiplexer (TCPMUX)" [RFC1078]: 137 this proposal SHOULD not longer recommended for use for the 138 following reason: 140 * RFC 1078 destroys the semantics of TCP connection 141 establishment. 143 * RFC 1078 requires all new connections to be received on a 144 single port, which limits the number of connections between two 145 machines and raises security concerns. 146 * There exist no known client side deployment of RFC 1078. 148 o RFC 6013 E: "TCP Cookie Transactions (TCPCT)" [RFC6013]: although 149 RFC 6013 was published in 2011, RFC 6013 SHOULD not longer 150 recommended for use for the following reason: 152 * There exist no known wide deployment and use of RFC 6013. 153 * RFC 6013 uses experimental TCP option codepoints, which 154 prohibits a large-scale deployment. 155 * RFC 7413 [RFC7413] and [I-D.ietf-tcpm-tcp-edo] are alternatives 156 to RFC 6013, which have relatively more "rough consensus and 157 running code" behind them. 159 3.2. Moving to Informational Status 161 The RFC Editor is requested to change the status of the following 162 RFCs to Informational [RFC2026]: 164 o RFC 700 U: "A Protocol Experiment" [RFC0700]: this document 165 presents a field report about the deployment of a very early 166 version of TCP. 168 o RFC 794 U: "PRE-EMPTION" [RFC0794]: this document clarifies that 169 operating systems need to manage their limited resources, which 170 may include TCP connection state. 172 o RFC 814 U: "Name, Addresses, Ports, and Routes" [RFC0814]: this 173 document gives suggestions and guidance for designing tables and 174 algorithms to keep track of various identifiers within a TCP/IP 175 implementation. 177 o RFC 817 U: "Modularity and Efficiency in Protocol Implementation" 178 [RFC0817]: this document contains general implementation 179 suggestions. 181 o RFC 872 U: "TCP-on-a-LAN" [RFC0872]: this document concludes that 182 the sometimes expressed fear that using TCP on a local net is a 183 bad idea is unfounded. 185 o RFC 889 U: "Internet Delay Experiments" [RFC0889]: this document 186 is a status report about experiments concerning the TCP 187 retransmission timeout calculation. 189 o RFC 964 U: "Some Problems with the Specification of the Military 190 Standard Transmission Control Protocol" [RFC0964]: this document 191 points out several specification bugs in the US Military's MIL- 192 STD-1778 document, which was intended as a successor to RFC 793 193 [RFC0793]. 195 o RFC 1071 U: "Computing the Internet Checksum" [RFC1071]: this 196 document lists a number of implementation techniques for 197 efficiently computing the Internet checksum. 199 4. IANA Considerations 201 None of the documents moved to Historic or Informational status had 202 TCP options numbers assigned. Therefore no IANA action is required 203 for them. 205 5. Security Considerations 207 This document introduces no new security considerations. Each RFC 208 listed in this document attempts to address the security 209 considerations of the specification it contains. 211 6. Acknowledgments 213 The authors thank John Leslie, Pasi Sarolahti, Richard Scheffenegger, 214 Martin Stiemerling, and Joe Touch for their contributions. 216 Alexander Zimmermann and Lars Eggert have received funding from the 217 European Union's Horizon 2020 research and innovation program 218 2014-2018 under grant agreement No. 644866 (SSICLOPS). This document 219 reflects only the authors' views and the European Commission is not 220 responsible for any use that may be made of the information it 221 contains. 223 7. References 225 7.1. Normative References 227 [RFC0675] Cerf, V., Dalal, Y., and C. Sunshine, "Specification of 228 Internet Transmission Control Program", RFC 675, December 229 1974. 231 [RFC0700] Mader, E., Plummer, W., and R. Tomlinson, "Protocol 232 experiment", RFC 700, August 1974. 234 [RFC0721] Garlick, L., "Out-of-Band Control Signals in a Host-to- 235 Host Protocol", RFC 721, September 1976. 237 [RFC0761] Postel, J., "DoD standard Transmission Control Protocol", 238 RFC 761, January 1980. 240 [RFC0794] Cerf, V., "Pre-emption", RFC 794, September 1981. 242 [RFC0813] Clark, D., "Window and Acknowledgement Strategy in TCP", 243 RFC 813, July 1982. 245 [RFC0814] Clark, D., "Name, addresses, ports, and routes", RFC 814, 246 July 1982. 248 [RFC0816] Clark, D., "Fault isolation and recovery", RFC 816, July 249 1982. 251 [RFC0817] Clark, D., "Modularity and efficiency in protocol 252 implementation", RFC 817, July 1982. 254 [RFC0872] Padlipsky, M., "TCP-on-a-LAN", RFC 872, September 1982. 256 [RFC0879] Postel, J., "TCP maximum segment size and related topics", 257 RFC 879, November 1983. 259 [RFC0889] Mills, D., "Internet delay experiments", RFC 889, December 260 1983. 262 [RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks", 263 RFC 896, January 1984. 265 [RFC0964] Sidhu, D. and T. Blumer, "Some problems with the 266 specification of the Military Standard Transmission 267 Control Protocol", RFC 964, November 1985. 269 [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, 270 "Computing the Internet checksum", RFC 1071, September 271 1988. 273 [RFC1078] Lottor, M., "TCP port service Multiplexer (TCPMUX)", RFC 274 1078, November 1988. 276 [RFC6013] Simpson, W., "TCP Cookie Transactions (TCPCT)", RFC 6013, 277 January 2011. 279 7.2. Informative References 281 [I-D.ietf-tcpm-tcp-edo] 282 Touch, J. and W. Eddy, "TCP Extended Data Offset Option", 283 draft-ietf-tcpm-tcp-edo-01 (work in progress), October 284 2014. 286 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 287 793, September 1981. 289 [RFC1122] Braden, R., "Requirements for Internet Hosts - 290 Communication Layers", STD 3, RFC 1122, October 1989. 292 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 293 3", BCP 9, RFC 2026, October 1996. 295 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 296 Requirement Levels", BCP 14, RFC 2119, March 1997. 298 [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, 299 February 2009. 301 [RFC6633] Gont, F., "Deprecation of ICMP Source Quench Messages", 302 RFC 6633, May 2012. 304 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 305 RFC 6691, July 2012. 307 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 308 Fast Open", December 2014. 310 [RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. 311 Zimmermann, "A Roadmap for Transmission Control Protocol 312 (TCP) Specification Documents", December 2014. 314 Authors' Addresses 316 Alexander Zimmermann 317 NetApp, Inc. 318 Sonnenallee 1 319 Kirchheim 85551 320 Germany 322 Phone: +49 89 900594712 323 Email: alexander.zimmermann@netapp.com 325 Wesley M. Eddy 326 MTI Systems 327 Suite 170, 18013 Cleveland Parkway 328 Cleveland, OH 44135 330 Phone: 216-433-6682 331 Email: wes@mti-systems.com 332 Lars Eggert 333 NetApp, Inc. 334 Sonnenallee 1 335 Kirchheim 85551 336 Germany 338 Phone: +49 89 900594306 339 Email: lars@netapp.com