Internet-Draft M. Wasserman Document: draft-wasserman-wg-process-00.txt Wind River Expires: December 2003 June 2003 Working Group Document Process Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [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 document describes a process that IETF working groups may use to produce documents. It defines terminology and process stages that may prove useful as we attempt to improve our WG processes. This document may also help new or struggling WG chairs to understanding how to control the flow and quality of their WG's output. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. M. Wasserman Expires December 2003 1 Working Group Document Process June 2003 Table of Contents Status of this Memo...............................................1 Abstract..........................................................1 Copyright Notice..................................................1 Table of Contents.................................................2 1 Introduction..............................................3 2 The Working Group Document Process........................3 2.1 Initial Submission........................................3 2.2 Author Refinement.........................................4 2.3 WG Acceptance.............................................4 2.4 Editor Selection..........................................5 2.5 Working Group Refinement..................................5 2.6 Working Group Last Call...................................6 3 Security Considerations...................................6 4 Informative References....................................7 5 Acknowledgements..........................................7 6 Editor's Contact Information..............................7 M. Wasserman Expires December 2003 2 Working Group Document Process June 2003 1 Introduction This document describes a process that IETF working groups may use to produce a WG document. The process described in this document includes several discrete stages. For each stage, there is a brief description and an explanation of the exit criteria for that stage. It is hoped that this document will serve two major purposes: - Provide useful terminology and a useful framework for discussing improvements to WG processes. - Give new or struggling WG chairs a better understanding of the process, and how they can use it to control the flow and quality of WG output. This document is intended to offer information and suggestions regarding WG document processes. It does not mandate any particular behavior for WGs or WG chairs, and WG chairs should feel free to skip, modify or ignore any or all of this process for their individual WGs. 2 The Working Group Document Process This document describes the production of a single WG document as a six step process. At any given time, a WG may have several documents underway at different stages of the process. 2.1 Initial Submission This stage is entered when someone (the "author") proposes an idea for a work item to an IETF WG. The work item may be submitted via e-mail, or at a WG meeting. A typical initial submission will be submitted as an individual Internet-draft (I-D), authored by one or more WG participants. However, it is possible that an initial submission could take another form, such as a detailed e-mail message, a presentation at a WG meeting, a charter item assigned by the AD, or an I-D transferred from another WG. EXIT: Before a work item can exit the Initial Submission stage, the chair(s) must determine, based on their judgement, that the work item fits within the scope of the WG charter. If a submitted item does fit within the charter, a WG chair has three choices: - Reject the work item. - Suggest that the work item should be undertaken in a different WG, and work with the appropriate AD(s) and the chair(s) of that WG to transfer the work item. - Discuss a charter update with the AD, to expand the charter of this WG to include the new work item. Although some WGs allow brief presentation slots for new ideas, a work item should successfully exit the Initial Submission phase before significant WG resources, such as long/preferred M. Wasserman Expires December 2003 3 Working Group Document Process June 2003 presentation slots or lengthy mailing list discussions are applied to the work item. 2.2 Author Refinement When a new idea or draft is first submitted to a WG, it is common for the WG to provide feedback. It is also possible that the idea was submitted in some form other than an I-D, in which case the author will need to write an I-D. During this stage, change control for the document lies completely with the author(s). Author(s) are encouraged not to submit a document for WG acceptance until they are ready to give up change control of the document to the WG, via an editor chosen by the WG chair(s). EXIT: A document exits the Author Refinement stage when it is has been published as an I-D, and the author(s) and the WG chair(s) believe that the document is ready for consideration as a WG document. Note: A document may go through several cycles of author refinement, before the author(s) or the WG chair(s) believe that it is ready for WG acceptance. 2.3 WG Acceptance In this stage, the WG is asked to accept a document as a WG document. The WG chair(s) control this process, and should make sure that all of the criteria are met before the work item is published as a WG document. EXIT: For a document to successfully exit the WG acceptance stage, the WG chair must determine that the new work item meets all of the following criteria: - The work item fits within the WG charter (in the opinion of the chairs). This should always be the case, since the work item was accepted as an Initial Submission. - There is significant support for this work item from the working group, including: - People with expertise in all applicable areas who are willing to invest time to review the document, provide feedback, etc. - Probable (or current) implementors, if applicable. - The document has been accepted as a work item by a rough consensus of the WG. - This should reflect WG belief that the document is taking the correct approach and would be a good starting place for a WG product. M. Wasserman Expires December 2003 4 Working Group Document Process June 2003 - The work item corresponds to existing goals/milestones in the charter. If a corresponding milestone does not already exist, the chair should obtain AD approval to add a milestone before accepting the work item as a WG document. Note: A document should not be accepted without sufficient WG support. In other words, silence does not indicate consent to accept the document. Once the work item has been accepted as a WG document, it should be published as WG I-D. 2.4 Editor Selection After a document is accepted by the WG, the WG chair(s) should choose an editor for the document. Although the editor is typically one of the original document authors, WG chairs are encouraged to make a careful decision at this point. The editor should meet the following criteria: - Have the time and interest to drive the work to completion consistent with the charter milestones. - Be willing to set aside his own personal agenda, and modify the document solely based on WG consensus. - Have the communications skills and patience to deal with the WG and IESG review cycles. - Have sufficient English-language skills to produce a clear, high-quality document. In addition to choosing the original editor for the document, WG chair(s) are also empowered to replace non-performing editors as needed. EXIT: The document exits the Editor Selection stage when the editor is chosen and announced to the WG. 2.5 Working Group Refinement During this stage, the original author(s) no longer have change control over the document. The WG has change control, and it is the editor's job to update the document to match the consensus of the WG. In many cases, WG consensus may be obvious from WG mailing list or meeting discussion. Editors should also drive discussion of open issues in an effort to achieve consensus on the document contents. In any situation where WG consensus is not clear to the editor, the editor should ask the WG chair(s) to make a consensus call. During this stage, all technical issues and proposed changes must be openly discussed on the WG mailing list and/or in WG meetings. All changes must be reviewed on the mailing list. During this M. Wasserman Expires December 2003 5 Working Group Document Process June 2003 phase, silence from the WG will be interpreted as consent to make the changes posted by the editor or WG chair(s). EXIT: A document exits the WG Refinement stage when the editor and the WG chair(s) believe that the document reflects the consensus of the WG and is ready for publication. In other words, an I-D has been published that is: - Clear and technically sound. - Sufficiently useful to warrant publication at the proposed level. - Compliant with I-D nits and RFC editor requirements. - Compliant with any other requirements for publication at the proposed level, as defined in RFCs 2026 or 2418 [RFC2026, RFC 2418]. At the exit from the WG Refinement stage, the WG chair(s) will issue a WG last call for publication of the document. 2.6 Working Group Last Call The Working Group Last Call stage lasts for at least two weeks. During this period, WG members are encouraged to comment, positively or negatively, about whether they believe that the document is ready for IESG submission in its current form. If technical issues are found at this stage that will require substantive changes to the document, the document may be returned to the WG Refinement stage. EXIT: To exit WG Last Call, a version of the document must exist in the I-D director that has been reviewed and actively supported by a significant number of people, including experts in all of the applicable areas. There should be rough WG consensus that the document meets all of the quality criteria defined for exit from the WG Refinement stage. At this stage, silence should not be interpreted as support for the document. It is up to the WG chair(s) to judge whether a document has sufficient support to be submitted to the IESG. After this stage, if IESG or IETF feedback is received that requires substantive changes to the document, the document may return to the WG Refinement stage. 3 Security Considerations This document defines terminology and concepts related to a process that IETF WGs may use to produce documents. Although the quality of the WG processes may have an affect on the quality of the IETF's security-related work, there are no specific security-related issues raised in this document. M. Wasserman Expires December 2003 6 Working Group Document Process June 2003 4 Informative References [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", RFC 2026, BCP9, October 1996 [RFC2418] S. Bradner, "IETF Working Group Guidelines and Procedures", RFC 2418, BCP 25, September 1998 5 Acknowledgements The contents of this document are largely based on information from WG chairs training. The author would like to thank all of the people who have provided feedback on the training sessions -- your inputs also helped to improve this document. I'd also like to thank my "responsible ADs": Bert Wijnen, Randy Bush and Thomas Narten, who have all taught me a great deal. 6 Editor's Contact Information Comments or questions regarding this document should be sent to: Margaret Wasserman Wind River 10 Tara Blvd., Suite 330 Phone: (603) 897-2067 Nashua, NH 03062 USA Email: mrw@windriver.com M. Wasserman Expires December 2003 7 Working Group Document Process June 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. M. Wasserman Expires December 2003 8 M. Wasserman Expires December 2003 9