Internet Draft J. Loughney Document: draft-loughney-what-standards-00.txt Nokia Expires: April 2004 October 2003 Standards, What Standards? Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The current problem working group has identified problems with they way in which the IETF manages the document series. This document discusses some of the problems caused by the current state of affairs and lays out some steps to correct the problems. Loughney Expires - April 2004 [Page 1] Standards, What Standards? October 2003 Table of Contents 1. Introduction..................................................3 1.1 The Problem(s)............................................3 2. Further Analysis of Identified Problems.......................4 2.1 Few Specifications Progress Beyond Proposed Standard......4 2.2 There is no Formal Bug Reporting or Tracking System.......4 2.3 Periodic Reviews of Protocols are not Being Carried Out...4 2.4 There is no Maintenance Team Responsible for a Protocol...5 3. Additional Potential Problems.................................5 4. Potential Solutions...........................................5 4.1 Question to the Community.................................6 5. Simple Example................................................6 6. Security Considerations.......................................6 7. IANA Considerations...........................................7 References.......................................................7 Acknowledgments..................................................7 Author's Addresses...............................................7 Appendix A - A Pathological Example..............................7 Loughney Expires - April 2004 [Page 2] Standards, What Standards? October 2003 1. Introduction The IETF has produced a large (and useful) body of work. In many ways, the IETF has been a victim of its own (or at least of IP's) success. It is reasonable to expect that as standards see deployment and uses not envisioned by the original authors, bugs will be found or clarification will be needed. Additionally, as the standards with the IETF produces see wider deployment by parties outside of the IETF, the system of documentation and updating within the IETF may cause some amount of confusion. There may be different expectations of what IETF standards may mean. Vendors often implement protocols based upon drafts; proposed standards often are sufficient. Other Standards Development Organizations may require Draft Standard status, at a minimum, for referencing in their documentations. Government Agencies, however, may take the standards levels literally and assume only Full Standards can be considered as true standards. Finally, the RFC numbering scheme does not lend itself for easily tracking development on a specific protocol or protocol area. There are no inter-relation between RFC numbers, so often one must rely on the RFC Editor's search engine to find all relevant standards on a specific protocol. See Appendix A for a pathological example. 1.1 The Problem(s) The following problems are excerpted from Section 2.4 of the IETF Problem statement [PROB]. o Relatively few specifications are now progressed beyond Proposed Standard (PS) to Draft Standard (DS) level, and even fewer to Full Standard (FS). o There is no formal bug reporting or tracking system in place for IETF specifications. o The periodic review of protocols at PS and DS levels specified in [1] are not being carried out, allowing protocols to persist in these lower maturity levels for extended periods of time, whereas the process would normally expect them to progress or be relegated to Historic status. o No individual or body is given the task of 'maintaining' a specification after the original WG has closed down. Loughney Expires - April 2004 [Page 3] Standards, What Standards? October 2003 Specifications are generally only updated when a need for a new version is perceived. No attempt is normally made to correct bugs in the specification (whether they affect operation or not) and the specification is not updated to reflect parts of the specification that have fallen into disuse or were, in fact, never implemented. This is in part because the current procedures would require a standard to revert to the PS maturity level even when specification maintenance is carried out which can be demonstrated to have no or minimal effect on an existing protocol at DS or FS level. This document does not take a stand on the issue of the relevance of the current standards track, but to note that in any given moment, a standard may be on-going work to progress the document. 2. Further Analysis of Identified Problems This section looks in greater detail the affects of the problems listed in section 1. Many of these issues are interlinked or compound each other. 2.1 Few Specifications Progress Beyond Proposed Standard The IETF, as of late, does not have a good track record of moving protocols beyond Proposed Standard. In fact, the goal of most Working Groups is to produce a set of RFCs and then shut down. Working groups that do this are considered to have succeeded. There are only a handful of long-lived working groups, such as IPv6, whose charters include progressing standards beyond Proposed Standards. 2.2 There is no Formal Bug Reporting or Tracking System Bugs in a specification can be found at any point. There have been bugs found in even in Full Standards. How do we ensure the correctness in our own standards? 2.3 Periodic Reviews of Protocols are not Being Carried Out Many protocols suffer from benign neglect. The working group charged with developing the protocol has gone dormant or shut down. The principal authors of the specification may no longer be involved in the IETF. Further development of the protocol may even be officially discouraged. Other SDOs may consider extensions or modification to the protocols. This causes problems for parties interested in the technology, as it becomes unclear as to exactly what specifies a Loughney Expires - April 2004 [Page 4] Standards, What Standards? October 2003 particular protocol. Additionally, it makes it hard to track errors or update in a specification or protocol. 2.4 There is no Maintenance Team Responsible for a Protocol Specifications are generally only updated when a need for a new version is perceived. No attempt is normally made to correct bugs in the specification (whether they affect operation or not) and the specification is not updated to reflect parts of the specification that have fallen into disuse or were, in fact, never implemented. This is in part because the current procedures would require a standard to revert to the PS maturity level even when specification maintenance is carried out which can be demonstrated to have no or minimal effect on an existing protocol at DS or FS level. 3. Additional Potential Problems TBA 4. Potential Solutions It has been suggested that some standards could be given a label, for example the Foo MIB. Note that three versions of the Foo MIB have been made RFCs 4120, 4560 and 7890. RFC 4560 was a flawed attempt to do what 7890 did, which reached wide deployment before the flaw was discovered. The standard listing for "Ethernet MIB" could say: Standard last updated: July 1, 2004 Stable IETF 1 Mult Deployed Known tech recommend impl impl widely harmful RFC 4120 Y N Y Y Y N RFC 4560 Y N Y Y Y Y RFC 7890 Y Y Y N N N Draft-foo-bis N N Y N N N The IETF recommends deployment of RFC 4120. The IETF recommends implementation of RFC 7890. The IETF recommends experimentation with draft-foo-bis. The IETF recommends against implementing RFC 4560. Important errata known for RFC 4120, 4560 and 7890 are: Loughney Expires - April 2004 [Page 5] Standards, What Standards? October 2003 One could imagine a team or a stuckee in charge of gathering experience with the documents. As implementation reports and deployment experience gathers, the "scorecard" - but NOT the RFCs - would be updated. Other documents, rather than referring to a specific RFC, would, when possible, refer to the label given 4.1 Question to the Community The question is, how would the IETF document this. Would this become, in essence, something like an Applicability Statement, which would be published as an RFC? Would this be a new class of document, which would get an additional tag, something along the lines of what is done with STDs? Or would this just be information listed on a separate web page, as supplemental information? 5. Simple Example SCTP has been chosen because it is a relatively new protocol but also because the author is familiar with it. Stream Control Transmission Protocol Stable IETF 1 Mult Deployed Known tech recommend impl impl widely harmful RFC 2960 Y Y Y Y N N RFC 3309 Y Y Y Y N N Imp Guide [1] N N Y Y N N Add IP [2] N N Y Y N N PR-SCTP [3] N N Y Y N N [1] draft-ietf-tsvwg-sctpimpguide-09.txt [2] draft-ietf-tsvwg-addip-sctp-08.txt [3] draft-ietf-tsvwg-prsctp-01.txt Information References: RFC 3257 Stream Control Transmission Protocol Applicability Statement RFC 3286 An Introduction to the Stream Control Transmission Protocol (SCTP) The IETF recommends implementing RFC 2960 with the updated checksum coverage documented in RFC 3309. draft-ietf-tsvwg-sctpimpguide contains updated information found during conformance tests. 6. Security Considerations Loughney Expires - April 2004 [Page 6] Standards, What Standards? October 2003 This document in and of itself does not of itself have security implications. 7. IANA Considerations There are no IANA considerations defined in this document. References [2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. Acknowledgments The author would like to thank Harald Alvestrand for making the author the stuckee on this particular topic. The author wants to thank John Klensen for warning that there may be dragons ahead. Thanks to Spencer Dawkins for reading & commenting. Author's Addresses John Loughney Nokia Email: john.loughney@nokia.com Appendix A - A Pathological Example TCP has been a wildly successful protocol by any measure. One of the benefits of TCP has been that it has enabled interoperable services running on-top of it, irrespective of the layers below it. This success has come at a price. The following is a table, based upon searching from the RFC Editors' page on the text 'tcp' in the RFC title, with some editing. Additionally, there have been discussions on the e2e mailing list about what constitutes TCP (http://www.postel.org/pipermail/end2end-interest/). STD0007 Transmission J. Postel Sep-01- Updated STD RFC0793 Control Protocol 1981 by RFC3168 RFC3522 The Eifel R. Ludwig, M. April EXP Loughney Expires - April 2004 [Page 7] Standards, What Standards? October 2003 Detection Meyer 2003 Algorithm for TCP RFC3517 A Conservative E. Blanton, M. April PS Selective Allman, K. 2003 Acknowledgment Fall, L. Wang (SACK)-based Loss Recovery Algorithm for TCP RFC3481 TCP over Second H. Inamura, February BCP BCP0071 (2.5G) and Third Ed., G. 2003 (3G) Generation Montenegro, Wireless Ed., R. Networks Ludwig, A. Gurtov, F. Khafizov RFC3465 TCP Congestion M. Allman February EXP Control with 2003 Appropriate Byte Counting (ABC) RFC3449 TCP Performance H. December BCP BCP0069 Implications of Balakrishnan, 2002 Network Path V. Asymmetry Padmanabhan, G. Fairhurst, M. Sooriyabandara RFC3448 TCP Friendly M. Handley, S. January PS Rate Control Floyd, J. 2003 (TFRC): Protocol Padhye, J. Specification Widmer RFC3390 Increasing TCP's M. Allman, S. October Obsoletes PS Initial Window Floyd, C. 2002 RFC2414, Partridge Updates RFC2581 RFC3360 Inappropriate S. Floyd August BCP BCP0060 TCP Resets 2002 Considered Harmful Loughney Expires - April 2004 [Page 8] Standards, What Standards? October 2003 RFC3042 Enhancing TCP's M. Allman, H. January PS Loss Recovery Balakrishnan, 2001 Using Limited S. Floyd Transmit RFC2988 Computing TCP's V. Paxson, M. November PS Retransmission Allman 2000 Timer RFC2883 An Extension to S. Floyd, J. July 2000 PS the Selective Mahdavi, M. Acknowledgement Mathis, M. (SACK) Option Podolsky for TCP RFC2873 TCP Processing X. Xiao, A. June 2000 PS of the IPv4 Hannan, V. Precedence Paxson, E. Field Crabbe RFC2861 TCP Congestion M. Handley, J. June 2000 EXP Window Padhye, S. Validation Floyd RFC2760 Ongoing TCP M. Allman, February INFO Research Related Ed., S. 2000 to Satellites Dawkins, D. Glover, J. Griner, D. Tran, T. Henderson, J. Heidemann, J. Touch, H. Kruse, S. Ostermann, K. Scott, J. Semke RFC2582 The NewReno S. Floyd, T. April EXP Modification to Henderson 1999 TCP's Fast Recovery Algorithm RFC2581 TCP Congestion M. Allman, V. April Obsoletes PS Control Paxson, W. 1999 RFC2001, Stevens Updated Loughney Expires - April 2004 [Page 9] Standards, What Standards? October 2003 by RFC3390 RFC2525 Known TCP V. Paxson, M. March INFO Implementation Allman, S. 1999 Problems Dawson, W. Fenner, J. Griner, I. Heavens, K. Lahey, J. Semke, B. Volz RFC2507 IP Header M. Degermark, February PS Compression B. Nordgren, 1999 S. Pink RFC2488 Enhancing TCP M. Allman, D. January BCP BCP0028 Over Satellite Glover, L. 1999 Channels using Sanchez Standard Mechanisms RFC2416 When TCP Starts T. Shepard, C. September INFO Up With Four Partridge 1998 Packets Into Only Three Buffers RFC2415 Simulation K. Poduri, K. September INFO Studies of Nichols 1998 Increased Initial TCP Window Size RFC2414 Increasing TCP's M. Allman, S. September Obsoleted EXP Initial Window Floyd, C. 1998 by Partridge RFC3390 RFC2398 Some Testing S. Parker, C. August INFO FYI0033 Tools for TCP Schmechel 1998 Implementors RFC2151 A Primer On G. Kessler, S. June 1997 Obsoletes INFO FYI0030 Internet and Shepard RFC1739 TCP/IP Tools and Utilities RFC2147 TCP and UDP over D. Borman May 1997 Obsoleted PS Loughney Expires - April 2004 [Page 10] Standards, What Standards? October 2003 IPv6 Jumbograms by RFC2675 RFC2140 TCP Control J. Touch April INFO Block 1997 Interdependence RFC2018 TCP Selective M. Mathis, J. October Obsoletes PS Acknowledgement Mahdavi, S. 1996 RFC1072 Options Floyd, A. Romanow RFC2001 TCP Slow Start, W. Stevens January Obsoleted PS Congestion 1997 by Avoidance, Fast RFC2581 Retransmit, and Fast Recovery Algorithms RFC1792 TCP/IPX T. Sung April EXP Connection Mib 1995 Specification RFC1791 TCP And UDP Over T. Sung April EXP IPX Networks 1995 With Fixed Path MTU RFC1739 A Primer On G. Kessler, S. December Obsoleted INFO Internet and Shepard 1994 by TCP/IP Tools RFC2151 RFC1693 An Extension to T. Connolly, November EXP TCP : Partial P. Amer, P. 1994 Order Service Conrad RFC1644 T/TCP -- TCP R. Braden July 1994 Updates EXP Extensions for RFC1379 Transactions Functional Specification RFC1379 Extending TCP R. Braden November Updated INFO for Transactions 1992 by -- Concepts RFC1644 RFC1347 TCP and UDP with R. Callon June 1992 INFO Bigger Addresses (TUBA), A Simple Loughney Expires - April 2004 [Page 11] Standards, What Standards? October 2003 Proposal for Internet Addressing and Routing RFC1337 TIME-WAIT R. Braden May 1992 INFO Assassination Hazards in TCP RFC1323 TCP Extensions V. Jacobson, May 1992 Obsoletes PS for High R. Braden, D. RFC1072, Performance Borman RFC1185 RFC1273 Measurement M.F. Schwartz Nov-01- INFO Study of Changes 1991 in Service-Level Reachability in the Global TCP/IP Internet: Goals, Experimental Design, Implementation, and Policy Considerations RFC1263 TCP Extensions S. O'Malley, Oct-01- INFO Considered L.L. Peterson 1991 Harmful RFC1213 Management K. McCloghrie, Mar-01- Obsoletes STD STD0017 Information Base M.T. Rose 1991 RFC1158, for Network Updated Management of by TCP/IP-based RFC2011, internets:MIB- RFC2012, II RFC2013 RFC1195 Use of OSI IS-IS R.W. Callon Dec-01- Obsoletes PS for routing in 1990 RFC1158 TCP/IP and dual Updated environments by RFC1349 RFC1185 TCP Extension V. Jacobson, Oct-01- Obsoleted EXP for High-Speed R.T. Braden, 1990 by Paths L. Zhang RFC1323 Loughney Expires - April 2004 [Page 12] Standards, What Standards? October 2003 RFC1180 TCP/IP tutorial T.J. Jan-01- INFO Socolofsky, 1991 C.J. Kale RFC1158 Management M.T. Rose May-01- Obsoleted PS Information Base 1990 by for network RFC1213 management of TCP/IP-based internets: MIB- II RFC1156 Management K. McCloghrie, May-01- Obsoletes HIST Information Base M.T. Rose 1990 RFC1066 for network management of TCP/IP-based internets RFC1155 Structure and M.T. Rose, K. May-01- Obsoletes STANDARD STD0016 identification McCloghrie 1990 RFC1065 of management information for TCP/IP-based internets RFC1147 FYI on a Network R.H. Stine Apr-01- Obsoletes INFO Management Tool 1990 RFC1065 Catalog: Tools Obsoleted for Monitoring by and Debugging RFC1470 TCP/IP Internets and Interconnected Devices RFC1146 TCP alternate J. Zweig, C. Mar-01- Obsoletes EXP checksum Partridge 1990 RFC1145 options RFC1145 TCP alternate J. Zweig, C. Feb-01- Obsoleted EXP checksum Partridge 1990 by options RFC1146 RFC1144 Compressing V. Jacobson Feb-01- PS TCP/IP headers 1990 for low-speed Loughney Expires - April 2004 [Page 13] Standards, What Standards? October 2003 serial links RFC1110 Problem with the A.M. McKenzie Aug-01- UN TCP big window 1989 option RFC1106 TCP big window R. Fox Jun-01- UN and NAK options 1989 RFC1095 Common U.S. Warrier, Apr-01- Obsoleted UN Management L. Besaw 1989 by Information RFC1189 Services and Protocol over TCP/IP (CMOT) RFC1086 ISO-TP0 bridge J.P. Onions, Dec-01- UN between TCP and M.T. Rose 1988 X.25 RFC1085 ISO presentation M.T. Rose Dec-01- UN services on top 1988 of TCP/IP based internets RFC1078 TCP port service M. Lottor Nov-01- UN Multiplexer 1988 (TCPMUX) RFC1072 TCP extensions V. Jacobson, Oct-01- Obsoleted UN for long-delay R.T. Braden 1988 by paths RFC1323, RFC2018 RFC1066 Management K. McCloghrie, Aug-01- Obsoleted UN Information Base M.T. Rose 1988 by for network RFC1156 management of TCP/IP-based internets RFC1065 Structure and K. McCloghrie, Aug-01- Obsoleted STANDARD identification M.T. Rose 1988 by of management RFC1155 information for TCP/IP-based internets RFC1025 TCP and IP bake J. Postel Sep-01- UN Loughney Expires - April 2004 [Page 14] Standards, What Standards? October 2003 off 1987 RFC0983 ISO transport D.E. Cass, Apr-01- Obsoleted UN arrives on top M.T. Rose 1986 by of the TCP RFC1006 RFC0962 TCP-4 prime M.A. Padlipsky Nov-01- UN 1985 RFC0896 Congestion J. Nagle Jan-06- UN control in 1984 IP/TCP internetworks Loughney Expires - April 2004 [Page 15]