idnits 2.17.00 (12 Aug 2021) /tmp/idnits38975/draft-hardie-wg-stuckees-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 266 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Hardie 2 Internet-Draft Qualcomm, Inc. 3 February 2003 5 Working Groups and their Stuckees 6 draft-hardie-wg-stuckees-00.txt 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Copyright Notice 31 Copyright (C) The Internet Society (2003). All Rights Reserved. 33 Abstract 35 This document describes one of the informal roles present 36 in IETF working groups and explores how incorporating 37 it more fully into the IETF's process might affect 38 working group operations. 40 1. Introduction. 42 The IETF currently defines working groups by the mailing list 43 noted in the charter. We can identify participants on the mailing 44 list; those who express opinions, submit documents, or provide 45 critiques. The process as defined is remarkably open and it has 46 the tremendous benefit that anyone can make a comment and be 47 heard. That openness, though, also makes it difficult to make 48 anyone other than the working group chairs and current authors 49 accountable for the working group making progress. Making a 50 comment on a document does not, in essence, imply that you are 51 taking responsibility for the work of the working group. That 52 ambiguity, in turn, makes it very difficult to predict how much 53 attention a work item will receive or to estimate when a work item 54 will be completed. 56 2. Stuckees. 58 Stuckees are individuals who have volunteered or otherwise been 59 identified as responsible for some aspect of a working group's 60 activities. Document authors and working group chairs are 61 stuckees, as are working group participants who agree to 62 write example code, review the work of other working groups, 63 or take on other tasks for the working group. Stuckees 64 have no special rights in the working group process, they 65 are simply individuals interested enough in the group's 66 completing its work items to commit to specific tasks. 68 3. Working group stuckees. 70 Currently, stuckees have volunteered for very specific tasks, and 71 it is usually easy to identify which stuckee is the draft author, 72 which the working group chair, and which a security or area 73 advisor. It is much less easy to identify the "working group 74 stuckees", that is, those who have committed to contributing 75 to the engineering effort implicit in the work items and the 76 review effort explicit in producing documents which adequately 77 specify the engineering decisions which the group has made. 79 This document suggests that the IETF in its current form needs 80 a new class of stuckees, the "working group stuckee". 82 4. Straw proposal. 84 1) All working groups are open to participation by anyone. 85 Anyone may join a working group mailing list at any 86 time, and anyone may provide technical commentary on 87 the output of a working group at any time. 89 2) A subset of those participating in the working group 90 commit to becoming the stuckees for that working group. 92 3) When becoming a stuckee for the working group, an individual 93 agrees to read the documents produced for the working group: 94 mailing list, minutes of meetings, chartered drafts. 96 4) For each charter document, working group stuckees agree to 97 provide public feedback within the time frames set out by the 98 chair (i.e. if a two week working group last call is issued, 99 within two weeks). This is not a vote; it is a public review 100 of the document's incorporated engineering decisions, 101 specificity of language, or record of working group discussion. 103 5) Working group stuckees who consistently do not provide 104 feedback within the timeframes set out, may be dropped as 105 stuckees by the application of a consistent policy set by the 106 working group chair(s). This does not in any way bar future 107 technical contributions by the former stuckee; it simply means 108 that they are no longer identified as someone who has committed 109 to the work of the working group. 111 6) An individual may at any time resign as a working group 112 stuckee. An individual who has resigned as a stuckee may 113 become a stuckee again at any time; a stuckee who has been 114 dropped by chair action may become a stuckee again on the 115 approval of the chair. 117 7) When chartering new work, Area Directors may ask for a list 118 of those who have indicated willingness to become working 119 group stuckees. 121 8) In reviewing working groups, Area Directors may ask for a 122 current list of working group stuckees in order to assess the 123 energy and expertise available for the existing or new work. 125 9) Anyone may raise a technical issue with the work produced by 126 a working group. Working group stuckees have no special 127 rights in this regard. They have, instead, taken on a 128 responsibility to consider and answer technical problems 129 raised. 131 10) In assessing consensus, working group chairs would consider 132 first if there are technical objections raised by anyone, 133 then if they had received sufficient positive input from the 134 working group stuckees to proceed. 136 5) Why would anyone agree to be a working group stuckee? 138 So, becoming a working group stuckee requires committing to a lot 139 of work without getting any special privileges. It is possible, 140 of course, to recognize the contribution of stuckees in documents 141 and on working group web pages. It might also be easier to 142 justify time spent on a working group to some employers if the 143 commitments were more explicit. 145 The primary reason for taking on the role, though, would have to 146 be a desire to see the work complete. To make that desire 147 translate into a willingness to publicly record one's engineering 148 opinion about specific proposals, it would have to be clear that a 149 lack of committed stuckees meant that the work would not complete. 151 6. Security Considerations. 153 The risk to moving to a system like this is that it shifts the 154 basis of decision making within the IETF. The author presumes 155 that this is a positive shift, since it increases the likelihood 156 that there will be public statements about the suitability of a 157 protocol or document. These public statements, in turn, should 158 help working group chairs and area directors determine both 159 the technical merits of proposals and the adequacy of the review. 161 It could, however, devolve into a regime in which de facto voting 162 by those with narrow interests could ride roughshod over good 163 design. Note well that this bad not because it is voting, 164 but because the narrow interests may overwhelm good engineering 165 from the view of the Internet as a whole. Since the point 166 of the IETF is arguably to provide a forum for engineering 167 problems which benefit from a view of the Internet as a whole, 168 any change which risks losing that benefit must be examined 169 very carefully indeed. 171 7. IANA Considerations. 173 There are no IANA considerations defined in this memo. 175 8. Acknowledgements 177 The author would like to thank Fred Baker, Bert Wijnen, Spencer 178 Dawkins and Marshall Rose for input into early thoughts on this 179 matter. The author is, however, solely responsible for any 180 bone-headedness expressed in this document. 182 Normative References 184 None. 186 Non-normative References 188 None. 190 Authors' Addresses 192 Ted Hardie 193 Qualcomm, Inc. 194 675 Campbell Technology Parkway 195 Suite 200 196 Campbell, CA 197 U.S.A. 199 EMail: hardie@qualcomm.com 201 Full Copyright Statement 203 Copyright (C) The Internet Society (2002). All Rights Reserved. 205 This document and translations of it may be copied and furnished to 206 others, and derivative works that comment on or otherwise explain it 207 or assist in its implementation may be prepared, copied, published 208 and distributed, in whole or in part, without restriction of any 209 kind, provided that the above copyright notice and this paragraph are 210 included on all such copies and derivative works. However, this 211 document itself may not be modified in any way, such as by removing 212 the copyright notice or references to the Internet Society or other 213 Internet organizations, except as needed for the purpose of 214 developing Internet standards in which case the procedures for 215 copyrights defined in the Internet Standards process must be 216 followed, or as required to translate it into languages other than 217 English. 219 The limited permissions granted above are perpetual and will not be 220 revoked by the Internet Society or its successors or assigns. 222 This document and the information contained herein is provided on an 223 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 224 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 225 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 226 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 227 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 229 Acknowledgement 231 Funding for the RFC Editor function is currently provided by the 232 Internet Society.