[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
Network Working Group                                           T. Hardie
Internet-Draft                                             Qualcomm, Inc.
                                                                June 2003


                 A proposal describing categories of IETF documents:
                      unbaked, baking, baked, eaten, and boiled.
                     draft-hardie-category-descriptions-00.txt

Status of this Memo

    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026.

    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.



Copyright Notice

    Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

    Over time, the document series associated with the IETF has grown
    and changed.  One such change is the increase in the use of
    secondary markers to identify when documents fit specific
    categories and, especially, when they are or are not the product
    of specific IETF processes.  The author believes that these
    secondary markers have largely failed but that the distinctions
    they were meant to draw remain valuable.  A new set of category
    labels is proposed to re-emphasize these distinctions.  The formal
    categories proposed are Internet Note, Candidate Specification,
    Proposed IETF Standard, Confirmed IETF Standard, and External
    Internet Engineering Document.  These may be informally understood
    as ideas which are unbaked, baking, baked, eaten, and boiled.

1. Introduction.

   In recent discussions of reform in the IETF, a consensus seems to
   be emerging that the fundamental categories used by long time IETF
   participants to understand the document series remain valuable, but
   that the indicators used to delineate those categories have ceased
   to be sufficient as markers for those outside the process.  To test
   that consensus, the author has put together this very flammable
   straw proposal to determine whether there is agreement on the
   categories underneath today's terms.  A set of entirely disposable
   formal names is also proposed, for the benefit of those who would
   otherwise feel hungry when entering the discussion.  Note that the
   term RFC is not used in either the formal or informal names; this
   does not imply anything about the author's view of the RFC series,
   but reflects the authors attempt to get at the categories underlying
   the current series.

2. Unbaked/Internet Note.

   The community needs a document series which has a very low barrier
   to entry and which can be used to float ideas, make proposals,
   comment on existing specifications, or carry on a public dialog
   on some topic of interest to the community.  This function
   is currently carried out in the Internet Drafts series, with a
   common secondary marker of draft-<author's name>.

3. Baking/Candidate Specification.

   The community needs a document series for those items which it has
   taken on as candidates for IETF specifications.  These documents
   might be the product of working groups or they might be the product
   of some other IETF standards process.  This function is currently
   carried out in the Internet Drafts series, commonly using a a
   secondary marker of draft-ietf, draft-iab, or draft-irtf.  The
   author personally believes that making Candidate Specifications
   archival would be valuable for the community, as it would increase
   the ability of engineers working on related problems to identify
   work already attempted within the IETF and would eliminate the
   temptation to publish imperfect work through other channels in
   order to retain a record of it.

4. Baked/Proposed IETF Standard.

   The community needs a category to identify those specifications
   which it believes are reasonably complete.  Documents in this
   category would still be subject to update or abandonment if
   experience with implementation or deployment showed flaws in the
   original design or specification.  Nominally, this maps to current
   standards track documents, with a secondary marker of "Proposed
   Standard".  In practice, the bar for the current category has been
   raised through experience that specifications rarely move beyond
   it, which has created a self-fulfilling prophecy for later
   documents advancing.  In the author's opinion, supporting documents
   for specifications (e.g. requirements documents) and documents
   describing best current practices belong in this category, as
   the community considers them "baked" when published.

5. Eaten/Confirmed IETF Standard.

   The informal name for this category derives from the phrase "eating
   one's own dog food" which means to use one's own product.
   Substantively, it means that the community has used this
   specification and found it good.  This maps onto the current
   standards track with secondary markers of "Draft Standard" and
   "Full standard".  The author personally believes that the collapse
   of those categories to a single category is appropriate and
   in line with the emerging consensus.

6. Boiled/External Internet Engineering Document.

   The community needs an archival document series for technnically
   reviewed documents which relate to the work of Internet engineering
   but do not fit into the current set of IETF standards.  These
   documents might describe proposed experiments, indicate the results
   of experiments conducted, describe alternate views of engineering
   trade-offs made by a working group or other IETF standards process,
   contain reflections on existing protocols, or, indeed, take on any
   other task within the broader discipline of Internet Engineering.
   This category maps broadly onto the current "Informational" and
   "Experimental" categories of RFCs, with the caveat that some
   documents currently using those markers are actually supporting
   documents for the standards in the categories "baked" or "eaten".

7. Conclusions.

   The author does not know when to let go of a metaphor.  Other than
   that, this document is not meant to draw conclusions, but to elicit
   comments on whether there is a broader agreement on the underlying
   categories currently understood by the IETF community.

8. IANA Considerations.

   There are no IANA actions described in this document.

9. Security Considerations.

   Were the community to change formal category names for its document
   series, it would need to ensure that this did not create an opportunity
   for a generalized "downgrade attack", through confusion over the
   new categories.

10. Normative References

Bradner, Scott. "Internet Standards Process -- Revision 3".  RFC2026.

11. Non-Normative References

None.

12. Acknowledgements.

   Leslie Daigle supplied the original "baked, unbaked, baking, and boiled"
   formulation, which the author then augmented and beat to death.

13. Authors' Addresses

    Ted Hardie
    Qualcomm, Inc.
    675 Campbell Technology Parkway
    Suite 200
    Campbell, CA
    U.S.A.

    EMail: hardie@qualcomm.com


Full Copyright Statement


    Copyright (C) The Internet Society (2003).  All Rights Reserved.

    This document and translations of it may be copied and furnished to
    others, and derivative works that comment on or otherwise explain it
    or assist in its implementation may be prepared, copied, published
    and distributed, in whole or in part, without restriction of any
    kind, provided that the above copyright notice and this paragraph are
    included on all such copies and derivative works.  However, this
    document itself may not be modified in any way, such as by removing
    the copyright notice or references to the Internet Society or other
    Internet organizations, except as needed for the purpose of
    developing Internet standards in which case the procedures for
    copyrights defined in the Internet Standards process must be
    followed, or as required to translate it into languages other than
    English.

    The limited permissions granted above are perpetual and will not be
    revoked by the Internet Society or its successors or assigns.

    This document and the information contained herein is provided on an
    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

    Funding for the RFC Editor function is currently provided by the
    Internet Society.