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.