| TOC |
|
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 9, 2009.
This document describes issues with the current IETF Nominating Committee process that have arisen in practice.
1.
Introduction
2.
Background of this document
3.
Issues that Affect NomCom Participation
3.1.
Shortening the NomCom Epoch
3.2.
Random Selection of NomCom Membership
3.3.
Gaming NomCom Participation
3.4.
Affiliation and Related Issues
4.
Issues Affecting NomCom Operation
4.1.
Model for Candidate Evaluation
4.2.
One NomCom for All Positions
5.
Candidate Issues
5.1.
Candidates Who Are Not Selected
5.2.
Running Against an Incumbent
5.3.
Soliciting Feedback on Non-Incumbent Candidates
5.4.
Interaction between Affiliation and Willingness to be Considered
6.
Confirming Body Issues
6.1.
Role of the Confirming Body
6.2.
Confirming Body Liaisons
6.3.
What a Confirming Body Actually Confirms
6.4.
2007-2008 Dispute Resolution Process Experience
6.4.1.
Selecting an Arbiter
6.4.2.
Scope of Dispute Resolution Process
6.4.3.
Constitutional Crisis
7.
Security Considerations
8.
IANA Considerations
9.
Contributing Authors
10.
References
10.1.
Normative References
10.2.
Informative References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
The Internet Engineering Steering Group (IESG), the Internet Architecture Board (IAB), and at-large IETF representatives to the IETF Administrative Oversight Committee (IAOC) are selected by a "Nominating and Recall Committee" (universally abbreviated as "NomCom"). [RFC3777] (Galvin, J., “IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees,” June 2004.) defines how the NomCom is selected, and the processes it follows as it selects candidates for these positions.
This document describes issues with the current NomCom process that have arisen in practice. It does not propose ways to resolve those issues - that will potentially be the role of one or more follow-on documents and/or IETF work items.
| TOC |
[RFC3777] (Galvin, J., “IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees,” June 2004.) is the latest in a series of revisions to the NomCom process, which dates back to [RFC2027] (Galvin, J., “IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees,” October 1996.) in 1996. [RFC3777] (Galvin, J., “IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees,” June 2004.) has been updated once since 2004, but this update ([RFC5078] (Dawkins, S., “IAB and IESG Selection, Confirmation, and Recall Process: Revision of the Nominating and Recall Committees Timeline,” October 2007.) did not change normative text (it replaced a sample timeline, allowing more time for required tasks and identifying a small number of tasks that are performed every year but were not included in the sample timeline).
Although NomCom deliberations are held to a high level of confidentiality, three recent NomCom chairs {Danny McPherson {2004-2005}, Ralph Droms {2005-2006}, and Andrew Lange {2006-2007}) have reported a variety of issues at IETF Plenaries. They reported several issues (that arise across NomCom cycles), including experience that NomComs seem to consistently "run out of time" at the end of the process, a small number of candidates for at least some positions, confusion with confirming bodies, and a tension between confidentiality and an open request for feedback on candidates.
This document is a compilation of discussions among a number of recent NomCom chairs (named in Section 9 (Contributing Authors)) who acted as a design team, at the IETF Chair's request. In addition, we used Lakshminath Dondeti's IETF 71 Plenary NomCom report, and subsequent on-list and off-list discussions, as input, but Lakshminath was not included in the design team because he was currently serving as NomCom chair.
This document is closer to being a union of views than a consensus of views. Given that each NomCom operates behind a wall of confidentiality, with the past NomCom chair as the only "common" participant, it's difficult even for a group of former NomCom chairs to agree on "what the problems common to all NomComs are".
| TOC |
| TOC |
We struggled with several aspects of the length of the NomCom cycle. Using the schedule suggested in ([RFC5078] (Dawkins, S., “IAB and IESG Selection, Confirmation, and Recall Process: Revision of the Nominating and Recall Committees Timeline,” October 2007.), the 2008-2009 NomCom will be budgeting for a 43-week NomCom cycle. There are several concerns that go along with a very long NomCom cycle:
| TOC |
NomCom membership is selected randomly from a set of qualified volunteers. This means that NomCom members are probably not personally familiar with all of the candidates, and may not be familiar with the required skillset for specific positions. This has implications for the amount of time needed for NomCom to collect inputs from the community.
We also discussed concerns about the level of awareness of IETF culture for a randomly-selected NomCom - since an IETF attendee can become NomCom-eligible in one year.
| TOC |
We have a sense that there are a small number of large sponsors for IETF participants who provide a disproportionate number of NomCom volunteers.
The issue isn't that a single sponsor can "pack" a NomCom - current [RFC3777] (Galvin, J., “IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees,” June 2004.) rules limit that effect - but that large sponsors can be almost assured of at least one participant being selected for NomCom, year after year. We note that for several years, 50-60 percent of NomCom participants have come from four large sponsors. We aren't saying this is a problem, only that it's a trend worth noticing.
| TOC |
As described in [RFC3777], the term "primary affiliation" is used in the following ways:
Despite the importance of "primary affiliation" in determining eligibility for the nominating committee and the validity of a signature on a recall petition, the term is never defined within RFC 3777.
While a potential nominating committee member or signatory with a single employer may not have difficulty in determining their "primary affiliation", the "primary affiliation" of an individual with multiple consulting clients or part-time employers may be less clear. Such ambiguities can make it difficult to determine whether the RFC 3777 requirements for nominating committee balance are being followed, and may even affect the ability of the nomcom to accurately assess the "primary affiliation" of the candidates for the positions that the nomcom is attempting to fill.
For its definition of "affiliation", IEEE has come up with the following:
"An individual is deemed 'affiliated' with any individual or entity that has been, or will be, financially or materially supporting that individual's participation in a particular IEEE standards activity. This includes, but is not limited to, his or her employer and any individual or entity that has or will have, either directly or indirectly, requested, paid for, or otherwise sponsored his or her participation."
It should not noted that the above definition focuses on support for a particular activity, and therefore it is possible for a participant to have different "affiliations" while developing a standards submission, participating in an chair position, or serving on one or more committees.
There are plenty of corner cases here - "do a UCLA professor and UC-Irvine grad student have the same affiliation?" - so what's needed is guidance, judgement, and flexibility.
| TOC |
| TOC |
We discussed two models - a Personal Experience (PE) model, and a Consultive (C) model.
Under the PE model, a NomCom member would use personal experience to determine positions on candidates where the NomCom member has enough background to support those positions, and would rely on candidate feedback only for the positions where the NomCom member cannot support a position based on personal experience.
Under the C model, a NomCom member would base candidate positions almost exclusively on candidate feedback for all positions under consideration.
We recognized that there's a tension in both directions - "personal experience" can become "personal bias", while "consultive" can become a popularity contest.
One former chair pointed out that the NomCom moved pretty quickly from a model where a random sample of the community selects leadership based on personal experience to a model where the random sample of the IETF is expected to survey a large and increasing percentage of the total community in order to select leadership. If we expect NomCom to act as a PE group, the process would be less intrusive to the rest of the community and would require less time for NomCom deliberations.
We also noted that since NomCom voting members are unlikely to have personal experience with all candidates in all areas, there's a tendency for NomCom voting members to rely on other NomCom members when considering an unfamiliar candidates in an unfamiliar area.
| TOC |
We discussed whether having a single group of randomly-selected IETF attendees working to fill all positions under consideration was the right model. For example, one former NomCom chair noted that the IAB's responsibilities have changed dramatically since the NomCom structure was put in place, and a considerable amount of IAB time has been spent on administrative restructuring, hearing appeals, and representing the IETF in liaisons with other SDOs. Is the NomCom the best way way to choose people with the required skillset to carry out these tasks?
| TOC |
We had some discussions about a relatively shallow candidate pool for some positions. We noted that it's not unusual for recent NomComs to reopen specific positions for late nominations (an indicator that the first round didn't generate enough candidates who were both qualified and willing to serve) - this happened in both 2005-2006 and in 2006-2007.
| TOC |
We noted that candidates must obtain confirmation of support from employers for a multi-year commitment, including commitments to fund travel for IETF meetings and workshops. There are IETF participants who are willing to obtain these commitments every year, but other participants are not willing to be considered every year when they must obtain high-level approval to be considered, and then must notify the same high approval levels that they weren't selected - especially if business plans were adjusted to accommodate the candidate serving and must now be adjusted again to accommodate the candidate not serving.
Even if a candidate is willing to be considered every year, the current NomCom cycle length requires serious candidates to "put their lives on hold" for up to six months between first being approached/volunteering and ultimately being selected. Being in limbo for this period of time may be a negative factor with respect to possible job actions, especially new employment and promotions.
Potential candidates may be unwilling to be considered for leadership positions, or may simply be unwilling to be considered during a specific NomCom cycle (given a choice between standing for a position against an incumbent finishing a first term and an incumbent finishing a third or fourth term, a candidate may "lay out" for a year to be considered against the long-time incumbent).
| TOC |
For a variety of reasons, mostly good reasons, a NomCom may be influenced by a candidate being an incumbent.
Rules we've heard discussed by various NomComs include:
Given the confidentiality requirements of [RFC3777] (Galvin, J., “IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees,” June 2004.), potential candidates do not know what the informal rules a NomCom may choose to follow. [RFC3777] (Galvin, J., “IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees,” June 2004.) encourages candidates to be considered, anyway, but candidates may choose to "be conservative in when you are considered", and may decline to be considered even if the NomCom would like to replace an incumbent.
Recent experience seems to show that a higher number of candidates emerge when incombents publicly state they are unavailable to return for another term than when incumbents publicly state that they are available to return for another term, although this is only an impression.
Note that this effect exists today, before any proposed changes to NomCom confidentiality rules are considered. We expect that the effect would be more pronounced if candidate lists are made public (more about this in Section 5.3 (Soliciting Feedback on Non-Incumbent Candidates)).
When potential candidates refuse to be considered, this complicates life for a NomCom evaluating an incumbent who is willing to serve again, but really needs to be replaced.
We see no way for a NomCom to signal that a slot is "REALLY open" under the current rules of engagement.
We note that spending effort on NomCom questionnaires when a NomCom is ready to reappoint an incumbent wastes valuable IETF participant time, and this is doubly wasteful when a NomCom requests input on a "ringer" who was not under consideration, and was only added to the list to obscure which candidates WERE under consideration.
| TOC |
NomCom announces the slots being considered in each NomCom cycle, so incumbents being considered are known publicly, but other candidates are not made public. This complicates the decision to provide input to NomCom, because community members may provide information about a "candidate" who isn't being considered, or who isn't willing to serve - or, equally likely, they may simply choose not to provide input about non-incumbent candidates without being solicited to do so.
There isn't any formal guidance to NomComs about how to solicit input, so each NomCom tends to use a modified version of what the previous NomCom used to solicit input. Current NomCom practice is to request feedback on lists of candidates from a large "private" population - existing working group chairs, RFC authors in an area, current document authors in an area, and the entire IESG and/or IAB likely to see candidate lists which, although the lists contain "ringers", necessarily expose the names of all candidates for a position to a large and relevant portion of the IETF community.
Even with solicitation of feedback on large "private" distributions, non-incumbents are at a disadvantage because the NomCom announcement names the incumbents, but does not name the non-incumbents - who may be tempted to do something that starts to look like campaigning, to make sure that people who honestly believe they would be the best candidate do provide input.
| TOC |
We noted that there are unwritten rules about affiliation that affect a candidate's willingness to be considered. For example, apparent NomCom practice is that two area directors in the same area should not have the same affiliation. If an area director is from company X, possible candidates from company X may be less willing to be considered for the second area director slot, assuming they will be summarily rejected because of this affiliation.
Potential candidates for IAB slots may have similar concerns, and may not be willing to be considered, if there are already two IAB members with the same affiliation serving.
| TOC |
| TOC |
In an e-mail on 2008/03/17, the IETF Chair asked the design team "to propose a definition for the role of the confirming body. The discussion in plenary indicates that this is a place where RFC 3777 is lacking. In part, this discussion has already taken place on the IETF mail list, with members of the design team taking radically different views. Please review the archives of the nomcom WG when they are available."
We gave that our best shot.
We recognized a tension between a confirming body that is expected to "rubber-stamp" a candidate slate, and a confirming body that expects to "re-run the NomCom process" - ("show us the information the NomCom used to select this candidate slate, and we'll see if you picked the right candidates"). Conversations at IETF 71 frequently used these terms. We don't think either extreme is desirable. In subsequent discussions we noted that there is a middle ground - a confirming body would use information forwarded by the NomCom as part of its "sanity check" diligence.
We haven't agreed on a proposed definition of the role of the confirming body (yet). This is where the editor thinks we are, as of 00 I-D submission cutoff for IETF 72 (and the editor apologizes in advance if he has been unable to capture the group's consensus on what we didn't have consensus about)...
| TOC |
Two sets of concerns were expressed about liaisons:
Since [RFC3777] (Galvin, J., “IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees,” June 2004.) places no restrictions on the "primary affiliation" of liaisons, it is possible for more than two NomCom members to share the same primary affiliation. One example is the 2006-2007 NomCom, where two voting members, the past NomCom chair, the ISOC Liaison and the IESG liaison all shared a single primary affiliation.
In addition to affiliation imbalances, there is the issue of diversity in liaison participation. While IESG and IAB liaisons cannot serve in successive years (since IESG and IAB terms are two years and a candidate whose position is being considered is not eligible to serve as a liaison), no such restriction exists for other liaisons and it has become common for other liaisons to return in successive years.
While liaisons are non-voting, concerns were raised about the influence that liaisons may have on NomCom voting members. Some confirming bodies have explicitly instructed liaisons not to provide any information unless the NomCom asks for the information directly, and some NomCom chairs have set similar rules for liaisons. However, there is a tension between being told "say nothing unless you are asked directly", and participating in conference calls unable to say anything when incorrect or incomplete factual statements are made.
We discussed how best to limit liaison participation in NomCom. Currently, an important role of the liaisons is to monitor the nomcom process and raise potential concerns about process violations. However, currently [RFC3777] (Galvin, J., “IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees,” June 2004.) does not provide guidance on what a liaison should do in the situation where a process violation occurs, and it is not clear that this responsibility primarily resides with the liaisons or with the past nomcom chair. If the primarily responsibility for process monitoring is assumed to reside with the past nomcom chair, then the role of the liaisons may be reduced or eliminated, or the role may be restricted to those activities required to supplement the past nomcom chair's responsibilities.
| TOC |
The 2006-2007 NomCom encountered a situation where they moved one Area Director to IETF Chair and reopened nominations for the vacated position - at this point, they had a complete slate, except for the vacant slot, but IAB wasn't sure they could confirm a slate with one vacancy or not.
Two considerations apply here.
While it would simplify the confirmation process if confirming bodies were willing to confirm partial slates or complete slates with problematic candidates and "fill in" the remaining slots later, the design team members were aware of several cases where the confirming bodies identified concerns about two candidates serving together. In some cases, both candidates were asked if this was really a concern ("can you let bygones be bygones?"). In other cases, the NomCom provided a slate with a different candidate, to address the confirming body's concern.
| TOC |
The 2007-2008 NomCom exercised a new code path - for the first time, a NomCom chair invoked the RFC 3777 dispute resolution process. This means that a third-party arbiter is selected to investigate and resolve the issue under dispute.
| TOC |
The arbiter is selected by the ISOC President - but the ISOC President has no way to know whether a proposed arbiter is also a current "willing candidate" being considered by the same NomCom committee.
| TOC |
[RFC3777] (Galvin, J., “IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees,” June 2004.) names four cases where the dispute resolution process should be invoked. None of the cases cover disputes between the NomCom and a confirming body.
| TOC |
It is possible for either the Nomcom or a CB to wedge the process in a way where it cannot proceed. The Nomcom can refuse to select a candidate. A CB can refuse to either confirm or reject a proposed candidate. It's unlikely that it would make sense to provide an arbiter the powers to override either of these decisions.
Ultimately, we're dependent on the good will of both the Nomcom and CB in the completion of the nominations process, and such good will should be encouraged. The maxim is that "good fences make good neighbors" - in this case, a better delineation of expectations between the Nomcom and the CB is probably the best defense against a future "Constitutional Crisis".
| TOC |
This specification describes issues with the current IETF Nominating Committee process ([RFC3777] (Galvin, J., “IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees,” June 2004.)). No security considerations apply beyond those discussions regarding confidentiality of NomCom deliberations.
| TOC |
No IANA actions are requested in this specification.
| TOC |
| TOC |
| TOC |
| [RFC3777] | Galvin, J., “IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees,” BCP 10, RFC 3777, June 2004 (TXT). |
| TOC |
| [RFC2027] | Galvin, J., “IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees,” BCP 10, RFC 2027, October 1996 (TXT, HTML, XML). |
| [RFC5078] | Dawkins, S., “IAB and IESG Selection, Confirmation, and Recall Process: Revision of the Nominating and Recall Committees Timeline,” RFC 5078, October 2007 (TXT). |
| TOC |
| Spencer Dawkins (editor) | |
| Huawei Technologies (USA) | |
| Phone: | +1 214 755 3870 |
| Email: | spencer@wonderhamster.org |
| Danny McPherson | |
| Arbor Networks, Inc. | |
| Email: | danny@arbor.net |
| TOC |
Copyright © The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
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.