NEWTRK Working Group Spencer Dawkins INTERNET DRAFT MCSR Labs 24 March 2004 Charles E. Perkins Nokia Research Center Dave Crocker Brandenburg InternetWorking Working Group Snapshot (WGS) draft-dawkins-newtrk-wgs-00.txt STATUS OF THIS MEMO This document is a submission to the Solutions Mailing List, which is not an official mailing list of the Internet Engineering Task Force, but is the best place weÆve found to discuss process change proposals. Comments should be submitted to the solutions@alvestrand.no mailing list. Distribution of this memo is unlimited. 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. ABSTRACT This proposal defines an optional label that can be affixed to an Internet-Draft, for working group internal synchronization. It is pointedly not an IETF standards label. Rather it is an optional part of the working group evelopment process, permitting the working group to synchronize on a particular version of a draft. 1. INTRODUCTION Working group document development often requires coordination among participants and coordination with those outside the working group, such as external reviewers and developers of test implementations. Currently, working groups have no way to formally mark these events, to ensure that the correct version of the document is used. Current difficulties include: * The version of the specification that is used may be immature, and may change markedly between revisions. This can cause confusion about the choice of version subject to common review, testing, or the like. * Different implementers may choose different revisions of the specification as a basis for development. * The "running code" component of the IETF culture clearly means that it is good to base a standard on implementation history. The implementation results need to be discussed and documented in order for this history to have its greatest value. Discussion venue: Online discussion of this draft should take place on the newtrk@lists.uoregon.edu mailing list. 2. WORKING GROUP SNAPSHOT (WGS) Working Group Snapshot (WGS) is an optional label that can be affixed to an Internet-Draft, for working group internal synchronization. It is pointedly not an IETF standards label. Rather it is an optional part of the working group evelopment process, permitting the working group to synchronize on a particular version of a draft. WGS can be assigned for any use the a working group finds helpful. Example uses include: * Marking which version of a working group document is now felt to be appropriate for reviewing * Marking the end of an iterative specification burst, to focus discussion or testing on a particular version * Defining a charter milestone for particular document writing efforts * Marking a final working group stage, such as assigning the label as part of a working group Last Call. A WGS is an Internet-Draft that achieves "rough consensus" based on a Working Group Last Call. A working group may assign WGS status at any time, for any of its working group Internet-Drafts. The document is subject to all normal I-D rules. When a WGS specification needs more time, active effort on it will usually result in changes to the specification being needed, with a resulting new version of the document, and (possibly) another working group decision to assign it WGS status. COMMENT: This label augments the current situation with I- Ds. It imposes minimal delay and it permits participants, reviewers, vendors and others to be better . The label makes clear that the specification is a WG product, not an IETF product, and it does not imply long-term stability to the specification. The use of a non-archival version (I-D) should encourage folks to revise and progress the specification. COMMENT: It is worth considering extending the I-D time- limit to 9 months. This will be more convenient for WGS documents -- for example, it provides two full IETF meeting cycles -- and will have no substantive effect on other I-Ds. 3. FORMAL EDITING CHANGES This proposal would be put into effect by making the following formal changes to official IETF process and procedures specifications. Specifically: * Add text to the end of section 7.2 of [GUIDE], according to text provided later in this section * Perform other edits required for consistency 3.1. [RFC2418-7.2] Internet-Drafts (I-D) A working group may wish to synchronize its activities according to particular versions of its Internet-Drafts. The label "Working Group Snapshot" (WGS) may be affixed to an Internet-Draft, for this purpose. The label does not indicate that the Internet Draft is ready for widespread deployment. A WGS is an Internet-Draft that achieves "rough consensus" based on a Working Group Last Call. A working group may assign WGS status at any time, for any of its working group Internet-Drafts. The document is subject to all normal I-D rules, except that the time before deletion is extended to be 9 months. 4. DISCUSSION This proposal defines a new label for use with Internet-Drafts, within working groups. The suggested scheme has a label that represent: WGS: Working group project management milestone Simplistically this means that WGS is the goal for working group internal coordination. This proposal adds to the concept of of "working group document", by enabling working groups to label stages of internal specification efforts. In particular, this will permit working group participants, and the rest of industry, to coordinate their development and testing efforts. However working group documents need to be kept formally fluid (unstable) in case major changes are needed. This is accomplished by giving the specification no formal IETF-wide status and by not publishing it as an RFC. If folks want to record the specification for posterity, even if itÆs not acceptable as a Proposed Standard, then they can issue it as an Informational RFC. Working groups are provided a formal and public means of circulating their work for technical evaluation, before it is complete. The process to achieve this is streamlined, which is balanced by imparting no IETF-wide status to the document and issuing it only through the non-archival Internet-Drafts process. 5. SECURITY CONSIDERATIONS This document contains no text with security issues, except perhaps the security of the IETF standards process. 6. REFERENCES Informative [BRAD] Bradner, S., "An Idea for an Alternate IETF Standards Track", draft-bradner-ietf-stds-trk- 00.txt, July 2003. [DAWK] Dawkins, S., C. E. Perkins, "Two Stage Standardization Approach", draft-dawkins-pstmt- twostage-00.txt [STD] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. Normative [GUIDE] Bradner, S., "Working Group Guidelines", RFC 2418, September 1998 7. AUTHOR CONTACT INFORMATION Spencer Dawkins Mobile Communications and Security Research Labs 1547 Rivercrest Blvd. Allen, TX 75002 Email: spencer@mcsr-labs.org Phone: +1.214.755.3870 Charles E. Perkins Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 Email: charles.perkins@nokia.com Phone: +1.650.625.2986 Fax: +1.650.625.2502 Dave Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA 94086 Email: dcrocker@brandenburg.com Tel: +1.408.246.8253