One document matched: draft-loughney-what-standards-01.txt
Differences from draft-loughney-what-standards-00.txt
Internet Draft J. Loughney
Document: draft-loughney-what-standards-01.txt Nokia
Expires: August 2004 February 2004
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
This document proposes a split between the RFC number of a
specification and the label for a protocol or protocol set. The
Problem Working Group identified problems with the way in which the
IETF manages the document series. This document discusses some of
the problems caused by the current state of affairs and suggests
some improvements.
Loughney Expires - August 2004 [Page 1]
Standards, What Standards? February 2004
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. Suggested Solution............................................5
3.1 Mock Example..............................................5
3.2 Open Issues...............................................6
4. Simple Example Based on an Existing Standard..................6
5. Security Considerations.......................................7
6. IANA Considerations...........................................7
References.......................................................7
Acknowledgments..................................................7
Author's Addresses...............................................7
Appendix A - A Pathological Example..............................7
Loughney Expires - August 2004 [Page 2]
Standards, What Standards? February 2004
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; a
proposed standard is seen as adequate enough for ensuring
interoperability; any bugs found in the specification can be
handled by code updates. 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
isn't any relationship 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.
Loughney Expires - August 2004 [Page 3]
Standards, What Standards? February 2004
o No individual or body is given the task of 'maintaining'
a specification after the original WG has closed down.
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.
Loughney Expires - August 2004 [Page 4]
Standards, What Standards? February 2004
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
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. Suggested Solution
This document proposes a simple solution that provides a label for
a specification that is separate from the RFC Number. This label
should be the protocol name.
This document would authorize an additional link on the IETF main
page, which would provide a link to the listing of specification
labels.
3.1 Mock Example
In this section we provide a fictitious example, known as 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 specification label 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.
Loughney Expires - August 2004 [Page 5]
Standards, What Standards? February 2004
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>
One could imagine a team or an appointed expert 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 protocol label.
3.2 Open Issues
In order to populate the label system work, there would need to be
a web location for this registry. This would require some amount
of work on the IETF Secretariat's part. In addition, experts and/or
maintenance teams would need to be formed. Most likely document
authors and work group chairs would be possible candidates. A
reasonable proposal would be to have an expert or set of experts
for specific protocols appointed by Area Directors, at least in a
trial phase.
One should note that the IETF already has a precedent set for
protocol experts in the form of IANA designated experts.
A reasonable next step would be to produce a web-based example
based upon this proposal.
4. Simple Example Based on an Existing Standard
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-10.txt
Loughney Expires - August 2004 [Page 6]
Standards, What Standards? February 2004
[2] draft-ietf-tsvwg-addip-sctp-08.txt
[3] draft-ietf-tsvwg-prsctp-03.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.
5. Security Considerations
This document in and of itself does not of itself have security
implications.
6. IANA Considerations
Currently there are no IANA implications. However, should this
solution be deployed, there may be a need to link the specification
label with the IANA registry for a particular protocol.
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 'designated expert' on this particular topic. The
author wants to thank John Klensen for warning that there may be
dragons ahead. Thanks to Spencer Dawkins, Jordi Palet Martinez,
Keith Moore and Mike Pierce for reading & commenting.
Author's Addresses
John Loughney
Nokia
Email: john.loughney@nokia.com
Appendix A - A Pathological Example
Loughney Expires - August 2004 [Page 7]
Standards, What Standards? February 2004
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.
For example there have been discussions on the e2e mailing list
about what is TCP (http://www.postel.org/pipermail/end2end-
interest/). This has resulted in a new working group being formed
to, essentially, clean up the set of TCP standards.
Using the RFC Editor's page, (http://www.rfc-editor.org/cgi-
bin/rfcsearch.pl), my first search retured: "Based on your search
of [tcp] in the Title field 93 matches were found." Then, a second
search: "Based on your search of [Transmission Control Protocol] in
the Title field 13 matches were found." This points to a fact that
there are a large number of RFCs at least partly related to TCP.
Loughney Expires - August 2004 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 09:59:34 |