Network Working Group Mike O'Dell Internet-Draft UUNET Technologies Expire in six months November 1996 A New IETF Document Classification 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]