[ietf-nomcom] NomCom 2023 Mid-Term Vacancy Eligibility Clarifications and Questions

NomCom Chair 2023 <nomcom-chair-2023@ietf.org> Wed, 20 September 2023 01:20 UTC

Return-Path: <nomcom-chair-2023@ietf.org>
X-Original-To: ietf-nomcom@ietf.org
Delivered-To: ietf-nomcom@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E7776C151090; Tue, 19 Sep 2023 18:20:12 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: NomCom Chair 2023 <nomcom-chair-2023@ietf.org>
To: IETF Announcement List <ietf-announce@ietf.org>
Cc: ietf-nomcom@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 11.11.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: ietf-nomcom@ietf.org
Message-ID: <169517281292.65045.5821119946773619226@ietfa.amsl.com>
Date: Tue, 19 Sep 2023 18:20:12 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-nomcom/DIRKNOKhhkZRyP7ml53erXNbHeE>
Subject: [ietf-nomcom] NomCom 2023 Mid-Term Vacancy Eligibility Clarifications and Questions
X-BeenThere: ietf-nomcom@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Discussions of possible revisions to the NomCom process <ietf-nomcom.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-nomcom>, <mailto:ietf-nomcom-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-nomcom/>
List-Post: <mailto:ietf-nomcom@ietf.org>
List-Help: <mailto:ietf-nomcom-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-nomcom>, <mailto:ietf-nomcom-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Sep 2023 01:20:13 -0000

All,

A question has been raised privately about who might be considered an eligible nominee for the IETF chair position.  Unfortunately, RFC 8713 does not deal with this question well when it comes to a mid-term vacancy. I will offer my own interpretation on each, which is based strictly on a reading of RFC 8713.

My reading is that the current situation does not make a process variation absolutely necessary.  However, if the community would like to propose that the NomCom follow a revised process – perhaps because that will result in more good nominees – the committee exists to serve the best interests of the community. The NomCom will follow the advice of the community.

I cannot say at this point whether these questions are academic or not, but I believe that they are worth clarifying either way.

1. As both the 2022 NomCom and the 2023 NomCom are still active, which members – if any – are eligible to be considered for a position that is vacated unexpectedly?

The relevant text is in Section 5.11 of RFC 8713:

> NomCom members are not eligible to be considered for filling any open position by the NomCom on which they serve. They become ineligible as soon as the term of the NomCom on which they serve officially begins. They remain ineligible for the duration of that NomCom's term.
>
> Although each NomCom's term overlaps with the following NomCom's term, NomCom members are eligible for nomination by the following committee if not otherwise disqualified.

This seems clear to me.  Only members of the NomCom responsible for filling a position are ineligible.

2. Are liaisons considered to be members by this definition?

Given the imprecise language in the rest of the document, it is not possible to be completely confident. For instance, Section 4.7, which deals with liaisons specifically, does not use the word “member” at all.

My conclusion that a liaison is a member therefore depends on inference. There are many places in RFC 8713 where the word “member” is used to refer to the NomCom as a whole (3.6, 4.3, 4.17, 5.1, 5.7, 5.8, 5.9, …). I also note that the RFC is typically careful in using “voting member” or similar to distinguish those who are drawn from the community at random.

3. Are advisors considered to be members?

My interpretation is that advisors are not members.

Note that the chair of the previous NomCom is strictly defined as an advisor. Consequently, they are not ineligible by a strict interpretation of the RFC.  However, I would suggest that it would be a very bad idea to consider a previous NomCom chair as being eligible for any position.

4. Can a member resign from the NomCom and therefore become eligible?

Section 5.11 seems pretty clear on this point.  A member becomes ineligible instantaneously at the point that the NomCom members are announced, which is the point at which the NomCom term starts. That ineligibility applies to any position that their NomCom is responsible for, whether or not they continue to serve in that NomCom.

5. Is this fair?

No.  Consider Section 4.13, which says:

> The list of open positions is published with the solicitation to facilitate community members choosing between volunteering for an open position and volunteering for the NomCom.

Clearly, the intent is to ensure that people who might consider a leadership position are given the best opportunity to make themselves eligible. That is not possible for a mid-term vacancy.

6. Can/should we revise these rules?

I have no opinion on this question, but will abide by the consensus of the community.

If anyone wishes to propose a revision to the process for this cycle, I will ask the IESG to judge consensus regarding any proposal. The NomCom will then follow any agreed process.

If you intend to propose a process amendment, please do so as soon as possible, to minimise any delays.

7. What considerations might apply to rule changes?

Controlling access to confidential information about the NomCom, their deliberations, and nominees is probably the most difficult component of this process. Members have full access to this information, which might influence their ability to effectively campaign for an open position. Advisors – especially the chair from the preceding year – might also be in a position to access this information.

The way that the datatracker system is built, each NomCom has a single key pair, which controls access to most of the confidential information that is stored.  The public key can be changed, causing new information to be stored against the new key.  If keys change in this way, then people accessing confidential information need to juggle multiple keys.

The NomCom could likely manage if there was strong support for varying the process.

Martin Thomson
nomcom-chair-2023@ietf.org