Internet DRAFT - draft-hardie-wg-stuckees

draft-hardie-wg-stuckees



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.