Internet-Draft nchairsel February 2022
Sullivan Expires 18 August 2022 [Page]
Workgroup:
Network
Internet-Draft:
draft-sullivan-nomcom-chair-select-00
Published:
Intended Status:
Informational
Expires:
Author:
A. Sullivan
Internet Society

A Selection Process for Nomcom Chairs

Abstract

The Internet Engineering Task Force Nominating Committee has a Chair. The Chair is selected by the President of the Internet Society. This memo outlines a procedure for Chair selection.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

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."

This Internet-Draft will expire on 18 August 2022.

Table of Contents

1. Introduction

Various positions in the Internet Architecture Board, Internet Engineering Steering Group, IETF Trust, and IETF Administration LLC are selected by the IETF Nominating Committee (NomCom). The procedures in [RFC8713] lay out the way the NomCom operates; section 4.3 says that the NomCom must have a Chair, and section 4.5 says that the Chair is selected by the President of the Internet Society (Internet Society President). There is no guidance for how the Internet Society President should perform the task. There is guidance that the selection must be complete in time for the second IETF meeting in any year.

In order to ensure that the Internet Society President considers all the factors relevant for the community in making the appointment, to ensure that there are candidates willing and able to serve in any given year, and to decrease the potential for familiarity bias in the selection, the present memo outlines a procedure by which the Internet Society President might seek both candidates and feedback about such a candidate. The sitting Internet Society President intends to use this method for selection of the Chair for the 2022-23 NomCom.

1.1. Terminology

In this memo, the key words described in BCP 14, [RFC2119] are not used as there defined; if those words occur, it is with their ordinary English meaning. This memo defines no protocol.

Terms with unusual title-case capitalization (such as "Internet Society President", and "NomCom Chair") are used here consistently with their use in [RFC8713].

2. Procedure

2.1. Consult with Past Chair

The Internet Society President shall consult with the Past Chair (see [RFC8713] section 4.10) for advice on issues that are likely to be of particular concern to the incoming NomCom.

2.2. Prepare and post a Call for Candidates

The Internet Society President prepares a call for candidates to be Chair. The call must include at least a reference to the qualifications mandated by [RFC8713] and any additional qualifications that seem important given the consultation mentioned in Section 2.1. The Internet Society President is strongly advised to require prior experience in a NomCom: experience indicates that there can be challenges for Chairs who have never participated in a NomCom in any capacity. That likely should not extend to requiring that a Chair nominee must have been a voting member of a previous NomCom. (For instance, prior liason experience counts.)

The Call for Candidates is to be posted at least to the IETF general mailing list and the announcement list. Self-nomination will be encouraged. The Call should be open for no more than four (4) weeks, and nominees are not expected to provide anything more than a name and the indication of a willingness to serve. At this stage it is explicitly not expected that a nominee expresses availability of time or employer support to serve in the position, though affirmations of those conditions would be of course welcome.

Nominees also must explicitly consent to a public request for confidential feedback about the potential that they are under consideration as NomCom Chair (see Section 2.4). Nominations are to be sent to an email address under the sole control of the Internet Society President. Note that this represents a change to the existing process, because at present there is no expectation that any candidate under consideration might be mooted publicly. See more below in Section 3.

The Internet Society President is expected to spend a certain amount of time trying to convince especially-qualified and (including widely-nominated) people to consider taking on this task.

2.3. First consideration

The Internet Society President must examine the nominations received and ensure that they meet the necessary qualifications outlined in the Call for Candidates. The Internet Society President ought to consult at least with the Past Chair on those nominations that meet the necessary qualifications, and may consult with anyone else in respect of any or all of the nominees.

2.4. Long (public) list

The Internet Society President will construct a long list of candidates who qualify after first consideration. The Internet Society President will post that long list to the IETF general mailing list and the announcement list, and will request any feedback about the candidates be sent to the same address as was used to collect nominations. This feedback is to be treated as confidential in the way that nomcom feedback would be considered confidential, though during the initial implementation there is no expectation of tool integration with the datatracker or anything of that sort (so this is exactly as confidential as any email exchange). According to the Internet Society President's discretion and availability, feedback may be collected in person, via telephone calls, or any other way the Internet Society President thinks is useful. The period for collection of feedback should not be overly long, but it should not complete before the ending of the first IETF meeting of the year. Note that this represents a change to the existing process; see more below in Section 3.

2.5. Short (private) list

The Internet Society President will take the feedback received, and construct an ordered short list of candidates. The Internet Society President is advised to discuss at least the first few entries in that list with the Past Chair and anyone else who seems likely to provide helpful input, according to the Internet Society President's thinking and discretion. This consultation will result in a final, ordered short list.

Note that the short list is not subject to comment or public discussion the way the long list is; that any candidate is on a short list should itself be treated as a private matter (though obviously, those providing input may be able to make some guesses).

2.6. Negotiation/Interview

The Internet Society President will approach, in order, each candidate on the short list and inquire as to continued willingness. It is expected that this will entail a degree of persuasion. Assuming the candidate remains willing, the Internet Society President will discuss the candidate's views about the position, how the NomCom might function or face particular problems, and so on. Assuming those discussions remain positive, the Internet Society President will ask the candidate to confirm availability of time and where necessary employer support or other financial support. If it is confirmed, the Internet Society President shall select that candidate as NomCom Chair. If not, the Internet Society President shall move to the next candidate in the list.

2.7. List Exhaustion

There is no procedure defined in this memo for recovery from the case where no candidate on the short list is willing and able to be appointed Chair. This is a gap in the existing processes that ought to be filled, but it is not filled yet. It is important to note that, without a selected NomCom Chair, the procedures in [RFC8713] appear not to work, but that document seems to have no provision for a NomCom without a Chair.

3. Process Change Considerations

The model outlined in this memo represents a significant departure from past practice. It is not clear whether that departure is a good thing, so it is worth considering what the consequences might be. There are advantages and disadvantages. Some are listed below, though this is probably not an exhaustive list.

The proposed process has a better chance of capturing a wider range of possible candidates for NomCom Chair than the process historically used. It is not possible for the Internet Society's President to know everyone participating in the IETF; indeed, depending on the President's background, the selection could be made with little personal knowledge at all. So, a mechanism to solicit suggestions seems like a way to improve both the size and diversity of the pool of potential NomCom Chair candidates.

Historically, feedback about potential candidates necessarily had to come from informal information-gathering, because the list of people who might be up for consideration to be NomCom Chair was largely unknown (though it may have been a more or less widely-held secret). A consequence of that mode of operation is a reinforcement of the idea that selection of future leaders might be managed by an "insider's club". That the NomCom Chair does not have a vote might be irrelevant to that perception. So, the effort to provide a mechanism for anyone to send feedback about a candidate might be regarded as more open than prior ways of making this selection. On the other hand, the public request for feedback subjects this process to "campaigns" for some candidate or other.

Previously, candidates who might be considered to be NomCom Chair did not have to expose their names (or initially, even know they were in consdideration), and there was little risk that someone would post on a public mailing list an attack on that candidate as somehow unworthy of the position. In addition, in the past a candidacy was largely unknown (possibly even to the candidate!) until some private action or public announcement. The process proposed in this memo makes the long list public at least among IETF participants. That might make some otherwise excellent candidates reluctant to stand due to the potential negative perceptions from possible non-selection. Worse, it is possible that some participant on IETF lists could mount a personal campaign against a nominee. It is worth observing that such a campaign would be largely out of keeping with IETF norms around other nominees for positions; it is nevertheless a difference.

This process has a feedback component that is larger than the informal methods historically used. A larger number of messages may increase the absolute risk (though ideally not the proportional risk) that some message will be disclosed inappropriately. In effect, then, this process might increase the risk that some feedback will become public when it should not have been.

The NomCom Chair has historically been somewhat difficult to fill; compared some other positions within the IETF, it appears to be less desirable. It is possible that this process will alter that situation, though it is hard to know how.

4. Comments/Discussion

Comments on this memo are welcome at the author's email address. There is no mailing list for discussion of this proposed process.

5. Security Considerations

This document defines no protocol, so there are no protocol considerations of any kind. The procedure depends on people sending observations via email, which could be intercepted.

6. IANA Considerations

This memo involves no actions by IANA.

7. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8713]
Kucherawy, M., Ed., Hinden, R., Ed., and J. Livingood, Ed., "IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees", BCP 10, RFC 8713, DOI 10.17487/RFC8713, , <https://www.rfc-editor.org/info/rfc8713>.

Author's Address

Andrew Sullivan
Internet Society