Fwd: Document categories
hardie at qualcomm.com
hardie at qualcomm.com
Tue Jun 10 15:14:42 CEST 2003
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: hardie at 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.
More information about the Problem-statement
mailing list