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]