Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/drafts/draft_ietf_j_p/draft-ietf-poisson-ietfdoc-01.txt

Text File | 1996-11-20 | 16KB | 389 lines

Network Working Group                                        Mike O'Dell
Internet-Draft                                        UUNET Technologies
                                                           November 1996

                   A New IETF Document Classification

                     <draft-poised-ietfdoc-01.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 Request For Comments document series has defined the ARPAnet and
   later the Internet community as strongly as any other feature of the
   social fabric.  While it has served the community far beyond any
   imaginable measure of success, the recent influx of those unfamiliar
   with the culture has left it vulnerable to confusion ranging from
   misunderstanding to misrepresentation.  This document proposes a new
   family of documents which, one hopes, keeps the spirit of the RFCs
   alive while updating the packaging to be a bit more tamper-proof.
   This proposal is not made lightly, or even very willingly, but it is
   a response to a very real problem.

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



O'Dell 1.6                                                      [Page 1]

Internet-Draft        IETF Document Classification          October 1996


   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.

   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



O'Dell 1.6                                                      [Page 2]

Internet-Draft        IETF Document Classification          October 1996


   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
   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



O'Dell 1.6                                                      [Page 3]

Internet-Draft        IETF Document Classification          October 1996


   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
   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



O'Dell 1.6                                                      [Page 4]

Internet-Draft        IETF Document Classification          October 1996


   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
   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



O'Dell 1.6                                                      [Page 5]

Internet-Draft        IETF Document Classification          October 1996


   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
   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, whether 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 disappointment.   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.



O'Dell 1.6                                                      [Page 6]

Internet-Draft        IETF Document Classification          October 1996


4. Author's Address

   Mike O'Dell
   UUNET Technologies, Inc.
   3060 Williams Drive
   Fairfax, VA 22031
   voice: 703-206-5890
   fax:   [phone]
   email: [e-mail]










































O'Dell 1.6                                                      [Page 7]