One document matched: draft-klensin-nomcom-term-00.txt

Network Working Group                                         J. Klensin
Internet-Draft                                              July 9, 2005
Expires: January 10, 2006


  Terms of Appointments for Nomcom-selected IETF Leadership Positions
                   draft-klensin-nomcom-term-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 January 10, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   A consensus is emerging in the IETF that very long tenure in
   leadership roles is not in the best interests of the community.
   While, in theory, that advice could simply be given to the Nomcom,
   there is reason to believe that a different model for consideration
   of renewal or replacement for members of the leadership would be more
   efficient for the Nomcom and would impose less hardship on incumbents
   and the community.  This document outlines that alternate method.





Klensin                 Expires January 10, 2006                [Page 1]

Internet-Draft         Nomcom and Terms of Office              July 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   Mailing List . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  The Review and Clean Nomination Model  . . . . . . . . . . . .  3
     2.1   Phase 1: Review of Incumbents  . . . . . . . . . . . . . .  4
     2.2   Phase 2: Nomination and Selection of New Candidates  . . .  5
     2.3   Revised schedule . . . . . . . . . . . . . . . . . . . . .  5
   3.  Open Questions . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Internationalization Considerations  . . . . . . . . . . . . .  5
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  6
   6.  Security considerations  . . . . . . . . . . . . . . . . . . .  6
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  6
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     8.1   Normative References . . . . . . . . . . . . . . . . . . .  6
     8.2   Informative References . . . . . . . . . . . . . . . . . .  6
       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  6
       Intellectual Property and Copyright Statements . . . . . . . .  7

































Klensin                 Expires January 10, 2006                [Page 2]

Internet-Draft         Nomcom and Terms of Office              July 2005


1.  Introduction

   A consensus is emerging in the IETF that very long tenure in
   leadership roles is not in the best interests of the community.
   While, in theory, that advice could simply be given to the Nomcom,
   there is reason to believe that a different model for consideration
   of renewal or replacement for members of the leadership would be more
   efficient for the Nomcom and would impose less hardship on incumbents
   and the community.  This document outlines that alternate method.

1.1  Mailing List

   This proposal should be discussed on the main ietf list at ietf.org.

2.  The Review and Clean Nomination Model

   The current nomination process pits incumbents, incumbent
   performance, and questions of stability in the IESG against potential
   other candidates.  This is undesirable for a number of reasons.  It
   creates the notion of incumbents being "fired" rather than honorably
   retired to the citizenry after a brief period of contributing to the
   community by assuming a leadership role.  And, while there is
   significant value in treating stability as a goal, it can also create
   distortions about the degree of support various ideas have in the
   community.

   This specification changes the current model by reintroducing some
   principles that the author believes are widely held in the community
   and optimizing the selection process to support those principles.
   The principles include:
   o  Service in the IETF's leadership bodies is a short-term
      contribution to the community, not a career.  Indeed, assuming
      those positions may be considered a responsibility to the
      community.
   o  It takes long enough to learn the job of being an effective AD
      that, in general, having someone retire after a single two-year
      term is uneconomic for the community.
   o  Just as retirement of an AD after one term should be considered a
      major step because of the inefficiencies of the learning period,
      the six-month or more period in which an incumbent is uncertain
      about whether work should be planned that spans the "first meeting
      of the next year" introduces inefficiencies that should be
      minimized to the degree possible.
   o  A demonstrated shortage of people willing to do work in the IETF
      should be taken as an indication that there is insufficient real
      community interest in the work to reach a meaningful consensus
      about high-quality results.  While that position appears to be
      reasonably well-understood with regard to the number of active



Klensin                 Expires January 10, 2006                [Page 3]

Internet-Draft         Nomcom and Terms of Office              July 2005


      IETF participants interested in putting a working group together,
      and in finding leadership for working groups, the same principle
      probably should be applied to ADs and areas: if there are only one
      or two people willing and qualified to do the AD job, that may be
      an indication that the IETF should review the appropriateness of
      that area's existence or definition.
   To deal effectively with these problems, the Nomcom consideration and
   evaluation process is broken into two phases.

2.1  Phase 1: Review of Incumbents

   Incumbent performance should be evaluated, not compared to potential
   other candidates or replacements.  The incumbent will always have
   more experience.  An AD who has done his or her job well, will have
   accumulated strong proponents and probably strong detractors.  Other
   candidates are always risks, and direct comparison is inevitably
   difficult.

   In Phase 1, the Nomcom will evaluate the performance of incumbents,
   collecting information from the community as needed to do that.  The
   nomcom is instructed that an incumbent should be returned once (i.e.,
   permitted/encouraged to serve two terms) unless there is strong
   evidence of problems (e.g., incompetence, inability to work with WGs,
   non-feasance, or malfeasance).  Conversely, the nomcom should assume
   that it is better to return an incumbent who has served two terms to
   the community and active WG work unless some special circumstances,
   including but not limited to an outstanding job, apply.  The level of
   special circumstances required for a fourth, or subsequent, term
   should be required to be much higher than that for a third: the
   intent is to make more than three terms a rare and nearly impossible
   event without formally prohibiting that through a term limit: it is
   important that the Nomcom retain flexibility and the opportunity to
   judge special circumstances.

   [[ Note in draft: In informal discussions before the initial version
   of this draft was completed and posted, there was considerable
   discussion about whether it was better to offer the Nomcom the
   guidance above, discouraging terms beyond the second, or whether to
   flatly prohibit more than two terms.  One group believed that giving
   the Nomcom a little extra flexibility was a good idea; the other
   believed that any additional flexibility would likely lead to very
   long terms since there would always be a reason to make an exception.
   The community will need to discuss, and decide upon, this issue. ]]

   Discussions between the nomcom and a candidate as to whether that
   candidate is willing to serve again should be covered by the nomcom's
   normal privacy rules except as mutually agreed.  If the nomcom
   chooses to not return a candidate who is willing to serve, the



Klensin                 Expires January 10, 2006                [Page 4]

Internet-Draft         Nomcom and Terms of Office              July 2005


   expectation is that this will be indistinguishable to the community
   from the candidate voluntarily stepping down.  Under normal
   circumstances, the nomcom is expected to conduct informational
   evaluations of even those candidates who have chosen to step down
   (the evaluations may inform later choices), but such candidates may
   negotiate with the nomcom as appropriate, perhaps supplying in-depth
   analysis of the relevant Area and its status and issues as an
   alternative.

   At the end of this phase, the nomcom submits the list of returning
   candidates to the IAB as usual.  The IAB makes its decision and the
   choices are announced to the community.  The list of (remaining) open
   slots is then announced to the community and nominations and
   recommendations sought.  Any incumbent who is not returned in this
   phase is not eligible for the relevant position in the second phase.

2.2  Phase 2: Nomination and Selection of New Candidates

   This procedure works exactly as described in [RFC3777], with the
   understanding that no incumbent will ever be a candidate for the same
   position under this process.  As a side-effect, the process makes it
   more difficult than it has traditionally been to shift people around
   within the IESG: it is considered an explicit corollary to the
   principles above that an incumbent AD is one area should normally
   have WG-level exposure in a new area before being considered as a
   candidate for AD in that area.

2.3  Revised schedule

   [[to be supplied]]

3.  Open Questions

   [[Note in draft: To be emptied and removed before Last Call]]

   This specification has been written to apply to the IESG only, since
   the IESG's operational role and observed rates of AD burnout make it
   most obviously important there.  However, consideration should be
   given as to whether a similar or identical model should be applied to
   the IAB and/or other appointments made by the Nomcom.

4.  Internationalization Considerations

   This specification is about IETF Procedures.  It has no impact on
   internationalization issues.






Klensin                 Expires January 10, 2006                [Page 5]

Internet-Draft         Nomcom and Terms of Office              July 2005


5.  IANA Considerations

   This specification is about IETF Procedures.  It has no impact on
   IANA issues and does not contemplate any IANA actions.

6.  Security considerations

   This specification is about IETF Procedures for leadership selection.
   It has no impact on Internet security issues.

7.  Acknowledgements

   [[ to be supplied ]]

8.  References

8.1  Normative References

   [RFC3777]  Galvin, J., "IAB and IESG Selection, Confirmation, and
              Recall Process: Operation of the Nominating and Recall
              Committees", BCP 10, RFC 3777, June 2004.

8.2  Informative References


Author's Address

   John C Klensin
   1770 Massachusetts Ave, #322
   Cambridge, MA  02140
   USA

   Phone: +1 617 491 5735
   Email: john-ietf@jck.com

















Klensin                 Expires January 10, 2006                [Page 6]

Internet-Draft         Nomcom and Terms of Office              July 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Klensin                 Expires January 10, 2006                [Page 7]