Network Working Group M. Wasserman Internet-Draft Nokia Expires: April 18, 2004 October 19, 2003 Updates to RFC 2418 to Increase the Authority and Responsibility of Working Group Chairs draft-wasserman-rfc2418-update-00.txt Status of this Memo 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. This Internet-Draft will expire on April 18, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document contains several updates to RFC 2418 designed to give more responsibility and authority to IETF Working Group Chairs. In particular, Working Group Chairs are given the responsibility of ensuring the technical quality, completeness and suitability of work produced by their Working Groups, and the authority to refuse to advance any work that does not meet the acceptance criteria for its proposed publication level. The importance of meeting minutes is emphasized, and Working Group chairs are also given more responsibility and authority for the management of working group mailing list discussions. Status of this Document Wasserman Expires April 18, 2004 [Page 1] Internet-Draft Updates to RFC 2418 October 2003 This document is not intended to be published as an RFC in its current form. If the community agrees to make these changes, then an updated version of RFC 2418 that reflects these changes should be produced. Wasserman Expires April 18, 2004 [Page 2] Internet-Draft Updates to RFC 2418 October 2003 1. Introduction This document suggests several specific changes to the "IETF Working Group Guidelines and Procedures" described in RFC 2418 [2]. These changes give WG chairs the responsibility to ensure the technical quality, completeness and relevance of work that is produced by their Working Groups, as well as the authority to refuse to advance any work that does not meet the acceptance criteria for the intended publication level, as described in sections 4.1 and 4.2 of RFC 2026 [1]. Changes are also described that will emphasize the importance of WG minutes and clarify what those minutes should contain. This document also gives WG chairs the authority to deal directly with disruptive behaviour on WG mailing lists. In particular, chairs are authorized to revoke mailing list posting priveleges, after consultation with the responsible AD, rather than requesting IESG action. These changes are presented in the OLD/NEW format used to send document changes to the RFC editor. Text in the OLD section will be replaced by text in the corresponding NEW section. It is not expected that this document will be published as an RFC in its current form, or that this input will be forwarded to the RFC editor in this form. Once we have reached consensus on a set of changes to RFC 2418, a complete RFC 2418 update I-D should be submitted that reflects those changes, and published in accordance with the usual IETF document processes. Wasserman Expires April 18, 2004 [Page 3] Internet-Draft Updates to RFC 2418 October 2003 2. Changes to Section 6.1, WG Chair This is one of several changes related to giving WG chairs more authority to ensure document quality. In particular, the WG Chair is responsible for ensuring that WG documents receive adequate expert review during document development, that they meet the acceptance criteria for their intended publication level, and that the meet all other criteria for document quality provided by the RFC editor or the IESG. OLD Document development Working groups produce documents and documents need authors. The Chair must make sure that authors of WG documents incorporate changes as agreed to by the WG (see section 6.3). NEW Document development Working groups produce documents and documents need editors. The Chair must make sure that editors of WG documents incorporate changes as agreed to by the WG (see section 6.3). Document editors are selected by the WG Chair, and may be replaced by the WG Chair if they are, in the opinion of the Chair, inadequately responsive to the rough consensus of the WG. Document quality The WG Chair is responsible for ensuring that a WG document is of sufficient quality before submitting that document for IESG review. In particular, the WG Chair must ensure that WG documents are adequately reviewed by reviewers with expertise in all applicable areas, that they meet the document publication criteria described in sections 4.1 and 4.2 of RFC 2026 [1], and that they meet any publication requirements provided by the RFC Editor or the IESG. Wasserman Expires April 18, 2004 [Page 4] Internet-Draft Updates to RFC 2418 October 2003 3. Changes to Section 7.4, Working Group Last-Call This is another change related to the increased authority of WG chairs regarding document quality. In particular, the WG Chair should not send a document to the IESG until there is WG consensus to do so AND the WG Chair believes that the document meets the quality criteria defined above. OLD When a WG decides that a document is ready for publication it may be submitted to the IESG for consideration. NEW When a WG decides that a document is ready for publication, and the WG Chair believes that the document meets the document quality criteria described in section 6.1, the WG chair may submit the document to the IESG for consideration. Wasserman Expires April 18, 2004 [Page 5] Internet-Draft Updates to RFC 2418 October 2003 4. Changes to Section 7.5, Submission of documents This is another change related to giving WG chairs more authority to ensure document quality. In particular, the chair is responsible for ensuring that a document meets the quality criteria described above before advancing the document. OLD Once that a WG has determined at least rough consensus exists within the WG for the advancement of a document the following must be done: NEW When a WG Chair has determined that rough consensus exists within the WG for the advancement of a document and the Chair believes that the document meets the criteria for document quality defined in section 6.1, the following must be done: Wasserman Expires April 18, 2004 [Page 6] Internet-Draft Updates to RFC 2418 October 2003 5. Changes to Section 6.3, Document Editor This change is indirectly related to increasing the authority of WG Chairs in the area of document quality. In situations where the WG Chair will have more authority over when a document is, or is not, progressed, it is even more important that a single person does not serve in both the WG Chair and Document Editor roles for a single document. OLD As a general practice, the Working Group Chair and Document Editor positions are filled by different individuals to help ensure that the resulting documents accurately reflect the consensus of the working group and that all processes are followed. NEW It is important that the Working Group Chair and Document Editor positions are filled by different individuals to help ensure that the resulting documents accurately reflect the consensus of the working group and that all processes are followed. In particular, WG Chairs should not serve in a quality assurance role for their own work. Also, having the WG Chair role and the Document Editor role be filled by the same person removes one level of appeal when WG members do not agree with the decision of the Document Editor. In many cases, a WG may have more than one WG Chair, and if one WG Chair serves as the Document Editor for a WG document, the other WG Chair(s) may serve as the WG Chair(s) for that document. In those cases, the role of each WG Chair should be made clear to the entire WG. In rare cases, perhaps due to a role change, a lone WG Chair may serve as a Document Editor for a WG document, but that situation should be avoided when possible, and corrected as quickly as practical. Wasserman Expires April 18, 2004 [Page 7] Internet-Draft Updates to RFC 2418 October 2003 6. Changes to Section 3, Working Group Operation Changes will be made to this section to emphasize the importance of WG meeting minutes, to make it clear that minutes should be reviewed by the WG before publication, and to clarify the contents and purpose of WG meeting minutes. OLD All working group sessions (including those held outside of the IETF meetings) shall be reported by making minutes available. These minutes should include the agenda for the session, an account of the discussion including any decisions made, and a list of attendees. The Working Group Chair is responsible for insuring that session minutes are written and distributed, though the actual task may be performed by someone designated by the Working Group Chair. The minutes shall be submitted in printable ASCII text for publication in the IETF Proceedings, and for posting in the IETF Directories and are to be sent to: minutes@ietf.org 3.2. Session venue NEW 3.2. Documentation of activity All working group sessions (including those held outside of the IETF meetings) shall be reported by making minutes available. Clear, archived documentation of WG activity, particularly of face-to-face WG meetings, is an important contribution to the Working Group's efforts. Working Group meeting minutes must contain the agenda of the session, and a summary of the discussions. The minutes must clearly document any rough consensus that is reached during the meeting (which will also be confirmed on the WG mailing list), and the minutes must also record any action items assigned to individuals, with names and expected completion dates accurately recorded. Meeting minutes may also include a detailed record of the discussion or any other material that is relevant to understanding what was presented or discussed at the meeting. WG minutes are useful in many situations -- WG participants who are unable to attend the WG meeting can use meeting minutes to determine what was discussed, future chairs (of the same WG) may use meeting minutes to determine what has been discussed and decided in the past, meeting minutes may be important input in appeal proceedings, and the WG may refer to meeting minutes when they reconsider WG decisions. Wasserman Expires April 18, 2004 [Page 8] Internet-Draft Updates to RFC 2418 October 2003 Meeting minutes are a critical record of Working Group activity, and should be detailed enough to be useful for these purposes. Meeting minutes should be produced in a timely fashion, circulated and confirmed on the WG mailing list, and delivered to the IETF Proceedings Editor (at minutes@ietf.org) by the applicable deadline. The WG Chair is ultimately responsible for ensuring that accurate and complete meeting minutes are produced, but this work may be delegated to someone else, such as a WG Secretary. 3.3. Session venue OLD 3.3. Session management NEW 3.4. Session management OLD 3.4. Contention and appeals NEW 3.5. Contention and appeals Wasserman Expires April 18, 2004 [Page 9] Internet-Draft Updates to RFC 2418 October 2003 7. Changes to Section 3.2, Session Venue The changes in this section are intended to give WG Chairs, with the agreement of their AD, the authority to revoke the posting priveleges of disrputive individuals. This should allow us to take more timely action to prevent WG disruption. OLD As with face-to-face sessions occasionally one or more individuals may engage in behavior on a mailing list which disrupts the WG's progress. In these cases the Chair should attempt to discourage the behavior by communication directly with the offending individual rather than on the open mailing list. If the behavior persists then the Chair must involve the Area Director in the issue. As a last resort and after explicit warnings, the Area Director, with the approval of the IESG, may request that the mailing list maintainer block the ability of the offending individual to post to the mailing list. (If the mailing list software permits this type of operation.) Even if this is done, the individual must not be prevented from receiving messages posted to the list. Other methods of mailing list control may be considered but must be approved by the AD(s) and the IESG. NEW As with face-to-face sessions occasionally one or more individuals may engage in behavior on a mailing list which disrupts the WG's progress. In these cases the Chair(s) should attempt to discourage the behavior by communicating directly with the offending individual rather than on the open mailing list. If the behavior persists then the Chair(s) must send at least one public warning on the mailing list. As a last resort and after explicit warnings, the WG Chair(s), with the approval of the Area Director, may request that the mailing list maintainer block the ability of the offending individual to post to the mailing list. Even if this is done, the individual must not be prevented from receiving messages posted to the list. Other methods of mailing list control may be considered but must be approved by the AD(s) and the IESG. Wasserman Expires April 18, 2004 [Page 10] Internet-Draft Updates to RFC 2418 October 2003 8. Security Considerations This section is taken directly from RFC 2418, and would remain unchanged in the new document. Documents describing IETF processes, such as this one, do not have an impact on the security of the network infrastructure or of Internet applications. It should be noted that all IETF working groups are required to examine and understand the security implications of any technology they develop. This analysis must be included in any resulting RFCs in a Security Considerations section. Note that merely noting a significant security hole is no longer sufficient. IETF developed technologies should not add insecurity to the environment in which they are run. Wasserman Expires April 18, 2004 [Page 11] Internet-Draft Updates to RFC 2418 October 2003 9. Acknowledgements Thanks to the following people who have provided feedback on this document: Harald Alvestrand, Scott Bradner, Brian Carpenter, Leslie Daigle, John Loughney. This document was written using the xml2rfc tool described in RFC 2629 [3]. Wasserman Expires April 18, 2004 [Page 12] Internet-Draft Updates to RFC 2418 October 2003 Normative References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998. Wasserman Expires April 18, 2004 [Page 13] Internet-Draft Updates to RFC 2418 October 2003 Informative References [3] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. Author's Address Margaret Wasserman Nokia 5 Wayside Road Burlington, MA 01803 US Phone: +1 781 993 4900 EMail: margaret.wasserman@nokia.com URI: http://www.nokia.com/ Wasserman Expires April 18, 2004 [Page 14] Internet-Draft Updates to RFC 2418 October 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 Wasserman Expires April 18, 2004 [Page 15] Internet-Draft Updates to RFC 2418 October 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Wasserman Expires April 18, 2004 [Page 16]