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]