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