Subject: Fwd: Document categories

From: [email-masked]
Date: Tue, 10 Jun 2003 14:14:42 -0700

Howdy,
	I've sent the draft included below to the drafts
editor, but since Charlie just brought the issue up again,
I thought I would go ahead and send it along.  I think
the question to the group is:  do these categories map
the ideas _underlying_ our current document series?
if so, do the current methods of marking the document
series reflect these categories well enough a) for
  IETF participants b) for those using IETF output?
If not, what are the categories underlying the document
series?
	I agree with Charlie that this might not be
the best place to discuss this issue, but I'm not sure
where else to take the discussion.  If the chairs wish
to ask that it move elsewhere, I will comply.
	Also, to reinforce a point made in the draft,
the names used for these categories (both informal
and formal) avoid the term RFC not because I am trying
to comment on the RFC series, but because I want to
get at the categories below the surface.
			regards,
				Ted Hardie

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 technically
    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: [email-masked]

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.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Jun 2003 11:15:53 +0200

Well, I think we have the problem that we don't really
know the difference between baked, eaten and boiled
in enough detail to be operationally useful. The running
code proof of that is that most specs stay at 'baked'
status.

I'm not allowed to mention on this list that my preferred
solution is to abolish the distinction between them,
as being useless in practice.

   Brian