Network Working Group T. Hardie Internet-Draft Qualcomm, Inc. February 2003 Working Groups and their Stuckees draft-hardie-wg-stuckees-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. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes one of the informal roles present in IETF working groups and explores how incorporating it more fully into the IETF's process might affect working group operations. 1. Introduction. The IETF currently defines working groups by the mailing list noted in the charter. We can identify participants on the mailing list; those who express opinions, submit documents, or provide critiques. The process as defined is remarkably open and it has the tremendous benefit that anyone can make a comment and be heard. That openness, though, also makes it difficult to make anyone other than the working group chairs and current authors accountable for the working group making progress. Making a comment on a document does not, in essence, imply that you are taking responsibility for the work of the working group. That ambiguity, in turn, makes it very difficult to predict how much attention a work item will receive or to estimate when a work item will be completed. 2. Stuckees. Stuckees are individuals who have volunteered or otherwise been identified as responsible for some aspect of a working group's activities. Document authors and working group chairs are stuckees, as are working group participants who agree to write example code, review the work of other working groups, or take on other tasks for the working group. Stuckees have no special rights in the working group process, they are simply individuals interested enough in the group's completing its work items to commit to specific tasks. 3. Working group stuckees. Currently, stuckees have volunteered for very specific tasks, and it is usually easy to identify which stuckee is the draft author, which the working group chair, and which a security or area advisor. It is much less easy to identify the "working group stuckees", that is, those who have committed to contributing to the engineering effort implicit in the work items and the review effort explicit in producing documents which adequately specify the engineering decisions which the group has made. This document suggests that the IETF in its current form needs a new class of stuckees, the "working group stuckee". 4. Straw proposal. 1) All working groups are open to participation by anyone. Anyone may join a working group mailing list at any time, and anyone may provide technical commentary on the output of a working group at any time. 2) A subset of those participating in the working group commit to becoming the stuckees for that working group. 3) When becoming a stuckee for the working group, an individual agrees to read the documents produced for the working group: mailing list, minutes of meetings, chartered drafts. 4) For each charter document, working group stuckees agree to provide public feedback within the time frames set out by the chair (i.e. if a two week working group last call is issued, within two weeks). This is not a vote; it is a public review of the document's incorporated engineering decisions, specificity of language, or record of working group discussion. 5) Working group stuckees who consistently do not provide feedback within the timeframes set out, may be dropped as stuckees by the application of a consistent policy set by the working group chair(s). This does not in any way bar future technical contributions by the former stuckee; it simply means that they are no longer identified as someone who has committed to the work of the working group. 6) An individual may at any time resign as a working group stuckee. An individual who has resigned as a stuckee may become a stuckee again at any time; a stuckee who has been dropped by chair action may become a stuckee again on the approval of the chair. 7) When chartering new work, Area Directors may ask for a list of those who have indicated willingness to become working group stuckees. 8) In reviewing working groups, Area Directors may ask for a current list of working group stuckees in order to assess the energy and expertise available for the existing or new work. 9) Anyone may raise a technical issue with the work produced by a working group. Working group stuckees have no special rights in this regard. They have, instead, taken on a responsibility to consider and answer technical problems raised. 10) In assessing consensus, working group chairs would consider first if there are technical objections raised by anyone, then if they had received sufficient positive input from the working group stuckees to proceed. 5) Why would anyone agree to be a working group stuckee? So, becoming a working group stuckee requires committing to a lot of work without getting any special privileges. It is possible, of course, to recognize the contribution of stuckees in documents and on working group web pages. It might also be easier to justify time spent on a working group to some employers if the commitments were more explicit. The primary reason for taking on the role, though, would have to be a desire to see the work complete. To make that desire translate into a willingness to publicly record one's engineering opinion about specific proposals, it would have to be clear that a lack of committed stuckees meant that the work would not complete. 6. Security Considerations. The risk to moving to a system like this is that it shifts the basis of decision making within the IETF. The author presumes that this is a positive shift, since it increases the likelihood that there will be public statements about the suitability of a protocol or document. These public statements, in turn, should help working group chairs and area directors determine both the technical merits of proposals and the adequacy of the review. It could, however, devolve into a regime in which de facto voting by those with narrow interests could ride roughshod over good design. Note well that this bad not because it is voting, but because the narrow interests may overwhelm good engineering from the view of the Internet as a whole. Since the point of the IETF is arguably to provide a forum for engineering problems which benefit from a view of the Internet as a whole, any change which risks losing that benefit must be examined very carefully indeed. 7. IANA Considerations. There are no IANA considerations defined in this memo. 8. Acknowledgements The author would like to thank Fred Baker, Bert Wijnen, Spencer Dawkins and Marshall Rose for input into early thoughts on this matter. The author is, however, solely responsible for any bone-headedness expressed in this document. Normative References None. Non-normative References None. Authors' Addresses Ted Hardie Qualcomm, Inc. 675 Campbell Technology Parkway Suite 200 Campbell, CA U.S.A. EMail: hardie@qualcomm.com Full Copyright Statement Copyright (C) The Internet Society (2002). 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 assigns. 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.