Internet DRAFT - draft-klensin-chair-empowerment
draft-klensin-chair-empowerment
Network Working Group J. Klensin
Internet-Draft May 22, 2006
Expires: November 23, 2006
Enabling the IESG Chair to Resolve Personality or Other Problems
draft-klensin-chair-empowerment-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 November 23, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
From time to time, there have been complaints about internal
conflicts within the IESG that have retarded projects. Some IETF
Chairs have expressed frustration about not being able to resolve the
problems and several members of the community have expressed
frustration that the Chairs cannot do so. The recall process has not
been effective in either dealing with or deterring these problems.
This document proposes, as a process experiment, an alternate model
whose intent is to give the Chair some leverage on solving any such
problems that may arise in the future.
Klensin Expires November 23, 2006 [Page 1]
Internet-Draft Chair Empowerment May 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protection Against Abuse . . . . . . . . . . . . . . . . . . . 3
4. Experimental Evaluation . . . . . . . . . . . . . . . . . . . . 4
5. Some Questions and Answers . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
9.1. Normative References . . . . . . . . . . . . . . . . . . . 5
9.2. Informative References . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . . . 7
Klensin Expires November 23, 2006 [Page 2]
Internet-Draft Chair Empowerment May 2006
1. Introduction
From time to time, there have been complaints about internal
conflicts within the IESG that have retarded projects. Some IETF
Chairs have expressed frustration about not being able to resolve the
problems and several members of the community have expressed
frustration that the Chairs cannot do so. The recall process has not
been effective in either dealing with or deterring these problems.
This document proposes, as a process experiment, an alternate model
whose intent is to give the Chair some leverage on solving any such
problems that may arise in the future.
The difficulty with any mechanism that gives a Chair authority to
discipline or remove a member of the body is how one prevents abuse.
The model used here does not give the Chair that authority but rather
permits the Chair to identify a difficulty so severe that an
independent body, the Nomcom, must deal with it, either by removing
and replacing the member involved or by removing and replacing the
Chair.
2. Mechanism
The IETF Chair may, at any time, present the Nomcom Chair with a
complaint against an IESG member. This sets the following process in
motion.
1. The Nomcom reviews the complaint and, just as it does when making
normal selections, solicits and evaluates input from the
community. The evaluation is not only of the complaint but of
the general behavior of the subject IESG member and of the IETF
Chair.
2. When this evaluation is complete, the Nomcom announces a vacancy
in either the subject IESG member's position or in the position
of IETF Chair and then proceeds to fill that vacancy according to
normal rules then in effect.
3. Protection Against Abuse
The reader should note that the procedure outlined above is a "him
(or her) or me" procedure, not a "Chair gets to fire people" one. It
gives the Chair authority and responsibility to diagnose and resolve
personality conflicts and behavior that is preventing the IESG from
getting work done. The complaint to the Nomcom effectively creates a
vacancy: by initiating it, the IETF Chair puts his or her own
position on the line. Presumably an IETF Chair who abuses the
Klensin Expires November 23, 2006 [Page 3]
Internet-Draft Chair Empowerment May 2006
mechanism will be removed instead of the subject AD. The conflict
will be resolved in any event.
Note that this procedure has no impact on the recall procedure: it
remains available to the community as specified in other documents.
4. Experimental Evaluation
As with the conventional recall procedure, if a mechanism of this
type is ever used, there is already a problem within the IETF that
fairly drastic mechanisms must be used to resolve it. Like the
recall procedure, this mechanism serves its purpose best when it acts
to deter bad behavior, rather than being used as a last-resort
remedy. On the other hand, the recall mechanism is so drastic and
time-consuming that it has not been used even when personality and
stylistic conflicts have developed that have essentially paralyzed
the IESG, with the individuals involved having no real incentives to
figure out how to work together. The availability of this procedure
is expected to give individuals strong incentives to work around
problems and work effectively together.
The consequence of this model is that there will probably be no way
to evaluate the procedure other than subjectively. Certainly one
would not expect it to be used twice in a fairly short period of
time. If it is used, the community will be able to evaluate the
consequences of using it. If it is not used, the community may be
able to evaluate whether its existence staved off ongoing bad
behavior or whether its existence as a standby mechanism caused harm.
5. Some Questions and Answers
Preliminary discussions leading up to this specification identified a
number of questions that were asked repeatedly. This section
identifies those questions and responses, in question and answer
form.
Q: Why can only the Chair initiate this procedure? Wouldn't it be
better to let any IESG member initiate it?
A: Part of the intent is to give the Chair a tool to manage an out-
of-control IESG and the responsibility (presumably enforced only
by the Nomcom or the recall procedure) to do so. If different
IESG members were able to use it on each other, there is too much
risk of abuse or repeated invocations,
Klensin Expires November 23, 2006 [Page 4]
Internet-Draft Chair Empowerment May 2006
Q: Why isn't this mechanism available to the IAB Chair, or other
group leaders, as well?
A: It seemed less necessary and hence better to limit the scope of
the experiment. The model is easily extended to other groups and
positions if the community decides it is desirable to do so.
Q: Couldn't an IETF Chair use this procedure to systematically
eliminate IESG members with whom he or she did not get along?"
A: Only if the Nomcom permitted it. Logic and an understanding of
human nature suggests that a Nomcom would respond to an IETF Chair
who apparently was taking an "everyone here is a problem other
than me" position by replacing that person, immediately
eliminating the problem and sending a message to the selected
successor,
6. Security Considerations
This document specifies an IETF procedure. It has no specific
security implications.
7. IANA Considerations
This document requires no actions by the IANA.
8. Acknowledgments
[[anchor8: ... To be supplied ...]]
9. References
9.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
9.2. Informative References
Klensin Expires November 23, 2006 [Page 5]
Internet-Draft Chair Empowerment May 2006
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 November 23, 2006 [Page 6]
Internet-Draft Chair Empowerment May 2006
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 (2006). 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 November 23, 2006 [Page 7]
