Network Working Group Mike O'Dell
Internet-Draft UUNET Technologies
Expire in six months November 1996
A New IETF Document Classification
<draft-ietf-poisson-ietfdoc-00.txt>
Status of this Memo
This document is an Internet-Draft. 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.''
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
The Simple Record Framing Protocol (SRFP) is designed to provide a
common, light-weight protocol for sending record-structured data of
possibly indeterminate size over a reliable (TCP) connection. It is
designed to be a "nickel's worth of presentation layer" which can be
incorporated into a simple library to prevent reinvention of wheels.
1.0 Introduction
At IETF-31, I held a number of conversations with members of the IETF
regarding the level of confusion surrounding the current single-track
document series. A number of problems came up, but several got
special mention.
Instances of willful misrepresentation as to the standards status of
various protocols have started to appear, and every indication is
that these will continue and worsen because of how difficult it is to
actually KNOW which documents constitute standards and which ones do
not. Even knowledgeable IETF cannot tell you which documents are
which without digging through the latest "official documents RFC",
assuming they can find THAT document.
O'Dell 1.4 [Page 1]
Internet-Draft IETF Document Classification October 1996
This problem is particularly acute when trying to write procurement
specifications citing Internet Technology. Very well-intentioned
people are routinely mis-specifying the technology because it is
essentially impossible to keep track of what is what across all the
areas where work is proceeding. It would be of considerable value
for a new structure to make it easy to cite "the latest version of
the standard spec" by default.
Compounding the problem is that it is extremely difficult to track
which documents are still pre-standard, and at what level they
currently reside and what further action is required to make them
standards.
While it is probably advantageous for some that the existing single-
track of documents continue as the status quo, it is a grave
disservice to our general constituency. In any proposed
rearrangement, there are a number of important notions which must be
captured lest we lose part of our culture.
The single most important is "publish anything, one way or another."
The Internet community has a fierce reverence for the free exchange
of ideas and it is vitally important that any proposed scheme still
afford publication in an archival series for any document of
minimally-adequate quality. Moreover, it should be a series with
considerable traffic and intellectual content so there is not stigma
attached to such publication.
The second most important is that official, full Standards should be
easily identified, and non-standards equally easily identified. The
standards process is an arduous process exactly to ensure quality,
and if just anyone can assert something is "a standard", and it is
not crystal clear how to know whether the claim is true, then
"standard" status becomes devalued, if not worthless.
Thirdly, the system must provide for reliable archival recording of
the business of the IETF. We have a long history which has been
recorded with considerable accuracy (at least in some areas) and the
value of that historical record is hard to over-estimate. Therefore,
any proposed reorganization must include explicit provisions for
archival retention.
And finally, the system must deal with change. A standard is
promulgated, it serves the community for some period of time, but
eventually it is eclipsed by new technology and experience. There
comes a time when a document's status must be rescinded. When this
happens, the document must lose any official standing it has, but
this must happen in such a way that the historical contents are not
misplaced, nor its place in history lost. In some ways, this is an
O'Dell 1.4 [Page 2]
Internet-Draft IETF Document Classification October 1996
elaboration on the requirement for archival retention of the
intellectual output of the IETF, but the implications are far-
reaching and deserved specific attention.
So, after thinking about the conversations and concerns voiced by
both new and old IETF members, and in consideration of the important
constraints above, what follows is a proposed new structure for IETF
documents. Note that ALL of the series are archival - all are
retained forever, and while documents may move between them, if the
contents are vacated in one series, a place-holder edition records
the move and retains the original edition's place in history.
2. A New IETF Document Classification System
The goal is to make the status of documents and their associated
"weight" clear and unambiguous, and to ensure that others do not mark
other documents in a manner meant to intentionally confuse. Further,
the IETF values it's tradition of allowing anyone to publish a
document descriptive of some work, so the document taxonomy will make
specific allowances for this.
2.1 The Standards Track
We must have a distinguishing mark which must be protected vigorously
with nasty letters and litigation where necessary This mark
identifies full Internet standards which have successfully completed
their navigation of the standards process. These documents will bear
the identifier:
"Global Internet Standard" (Registered Trademark)
This mark should be registered by the ISOC and its exclusive use
assigned to the IETF.
This mark will appear on the cover page of ONLY those documents which
have reached Full Internet Standard status (in current nomenclature).
A GIS is not just a single document, but a cluster of the baseline
protocols specifications, applicability statements, engineering and
operations guidelines documents. Clustering a standard with the
supporting documents makes a very strong statement that a standard is
not complete without it's applicability statement, and that any
assertion of compliance with standard a standard includes ALL the
documents included in in the cluster.
Because of clustering, the denotation of standards is somewhat
complex; it must allow for the base protocol spec, the applicability
statement, engineering and operations guidelines, etc. It is
O'Dell 1.4 [Page 3]
Internet-Draft IETF Document Classification October 1996
therefore important that the "standard" reference this cluster as a
unit to make it clear that compliance involves meeting all the
relevant requirements in all the documents. Therefore, I propose a
numbering structure which is sufficiently rich but not overly
complex.
When a "new standard" advances to GIS, a GIS Identifier is assigned,
and the entirety of the standard is then known as GIS-XY. where X is
a letter sequence and Y is a number identifying the major edition.
The first edition is "1". In standard usage, omitting the Y implies
"the most current version", so GIS-X means the latest edition. this
is primarily of use in statements of compliance requirements.
The subdocuments of the standard are then designated GIS-XY.1, GIS-
XY.2, GIS-XY.3, etc. Each subdocument may have revisions (the first
version is always .a): DIS-XY.1a, DIS-XY.1b etc.
The goal behind this machinery is to make a standard have a unique,
time-invariant identifier for the life of the standard. this means
that someone can cite GIS-TCP and unambiguously reference the most
current TCP standard without having to track RFC numbers
One major source of confusion is documents which are only partially
through the standards process. To make it very clear where a draft
stands in its progress to a GIS, two DRAFT classes, named Stage-1
Draft and Stage-2 Draft will be created to specifically indicate that
a draft has made specific progress in standardization, but that it is
NOT yet a full standard. A standardized cover page will warn readers
that the documents are NOT yet standards. While it is important for
preliminary and advanced prototype implementations to be able to
claim compliance with Stage-1 and Stage-2 Drafts, the
implementations may NOT claim such performance as being in compliance
with a standard based on a document in this stage of advancement.
2.2 Rescinded Documents, especially Internet Standards
In the event a standard is rescinded, one final edition will be
registered for all the constituent documents which contains one
paragraph of text states that this standard is rescinded and is not
longer appropriate for Internet operation or implementation. The
designation of the standard is then changed from GIS to RD-GIS (with
the rest of the identifier remaining the same) and the place-holder
with the RD-GIS designation REMAINS in the list of authorized Global
Internet Standards. The full textual record of the standard is then
moved, with the RD-GIS designation, to the Rescinded Document
Archive.
For non-GIS documents, in the event the author or the IESG wishes to
O'Dell 1.4 [Page 4]
Internet-Draft IETF Document Classification October 1996
rescind a document from a document series, a similar placeholder
page with the RD- designation prefix attached to the document
designator replaces the body of the text in the series archive, while
the textual record with the RD-designator moves to the Rescinded
Document archive.
2.3 Internet Notes
These serve the purpose of the current Informational and general RFCs
and serves as the catch-all for allowing anyone to get anything
published. They all must carry a cover page identifying them as an
Internet Memo and specifically stating they have no official
standards value at all and represent only the views of the authors.
2.4 Experimental Notes
A series designed to replace the existing "experimental RFC" and also
carrying a required cover page indicating the experimental nature of
what is described therein and specifically disavowing standards
value. They are explicitly more speculative or report results of
experimental efforts.
The continuing need for an experimental classification, distinct from
General Notes, should probably be examined quite carefully.
2.5 Internet Operations Bulletins
A special vehicle for notifying the users and operators of the
Internet of situations or events which have some significant bearing
on the ongoing operations of the Global Internet. they will be
posted to a mailing list, but will also be directly mailed to the
technical contact of record for all registered AS numbers. Those
technical contacts are further encouraged to consider forwarding IOBs
to their customers if the AS belongs to an ISP.
An IOB may be issued in concert with organizations such as IEPG,
or CERT and must be approved by at least the Operations Area ADs and
ideally originated in a WG (but this can be suspended in
extraordinary circumstances).
The IOB represents a new level of communication between the IETF and
the actual operators and users of the Internet, one that has been
needed for a long time but for some reason has not appeared.
2.6 Best Current Practices
The BCP series has provoked much argument over various pedantic
interpretations of all three words in the title The title was
O'Dell 1.4 [Page 5]
Internet-Draft IETF Document Classification October 1996
deliberately chosen to be somewhat ambiguous, exactly like most RFCs
do not, in fact, solicit comments.
The spirit of the BCP is that it describes either the best we we know
to do something, wether or not we are currently doing that way (and
hence would ideally influence future deployment), or it documents
what we are doing, whether or not we can imagine a better way to do
it.
This is a delicate balancing act between the pragmatism of actual
engineering experience and carefully considered advice about how we
should try to move forward. There is no single interpretation of
these three words "in vacuo" which is correct, nor is that intended.
This is explicitly a value judgement, reached by community consensus,
applied to what are often very murky operational realities.
People striving for a protocol-like formal interpretation in these
matters are doomed to disapointment. This in no way diminishes the
value of this document series.
2.7 Working Papers
This is the new name for the current Internet Draft documents. We
continue the notion that WPs cannot be cited, except for purely
historical reasons, or in a companion, contemporaneous WP.
We propose that WPs be archived permanently as the other documents.
WPs already have version numbers, so it should not be confusing to
maintain an archive. We further suggest that a name with a null
sequence number (or possible a zero sequence number) always refer to
the most current version.
There should be two primary directories for WP documents: "Current"
and "Expired". As WPs expire, they move from Current to the Expired
archive for historical record.
3. Conclusion
This document series model address some of the pressing problems
faced with the RFC series, but at the same time retains the spirit of
the original series, except in name. That name has served well, but
it is time to retire the jersey.
4. Author's Address
Mike O'Dell
UUNET Technologies, Inc.
3060 Williams Drive
O'Dell 1.4 [Page 6]
Internet-Draft IETF Document Classification October 1996
Fairfax, VA 22031
voice: 703-206-5890
fax: 703-206-5471
email: mo@uu.net
O'Dell 1.4 [Page 7]
