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:
<insert errata here>
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]