Re: [ietf-nomcom] NomCom 2023 Process Details for Mid-Term Vacancies

Bernie Hoeneisen <bernie@ietf.hoeneisen.ch> Tue, 19 September 2023 09:13 UTC

Return-Path: <bernie@ietf.hoeneisen.ch>
X-Original-To: ietf-nomcom@ietfa.amsl.com
Delivered-To: ietf-nomcom@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661DDC15108F for <ietf-nomcom@ietfa.amsl.com>; Tue, 19 Sep 2023 02:13:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJqp_6dz0f5P for <ietf-nomcom@ietfa.amsl.com>; Tue, 19 Sep 2023 02:13:11 -0700 (PDT)
Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [IPv6:2a01:4f8:c0c:15fc::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12981C151535 for <ietf-nomcom@ietf.org>; Tue, 19 Sep 2023 02:13:09 -0700 (PDT)
Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <bernie@ietf.hoeneisen.ch>) id 1qiWn4-001LLT-2m for ietf-nomcom@ietf.org; Tue, 19 Sep 2023 11:13:06 +0200
Date: Tue, 19 Sep 2023 11:13:06 +0200
From: Bernie Hoeneisen <bernie@ietf.hoeneisen.ch>
X-X-Sender: bhoeneis@softronics.hoeneisen.ch
To: NomCom Discussion <ietf-nomcom@ietf.org>
In-Reply-To: <169510744912.45567.17200302232047307359@ietfa.amsl.com>
Message-ID: <alpine.DEB.2.22.394.2309191033390.270337@softronics.hoeneisen.ch>
References: <169510744912.45567.17200302232047307359@ietfa.amsl.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-1327949363-1695114419=:270337"
Content-ID: <alpine.DEB.2.22.394.2309191107190.270337@softronics.hoeneisen.ch>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch
X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-nomcom/ivNAXG2Ic3VWGkXV4E7V57FGtfU>
Subject: Re: [ietf-nomcom] NomCom 2023 Process Details for Mid-Term Vacancies
X-BeenThere: ietf-nomcom@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
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: Tue, 19 Sep 2023 09:13:15 -0000

Hi Martin

First of all, I am sorry to hear that Lars cannot continue. He has done a 
great job!

Regarding the gaps and open questions, I generally support your 
suggestions. Using the existing process (along with the most recent 
NomCom) makes a lot of sense and has the least likelyhood to get 
disruptive at some point. In particular I also support resetting the 
cycle of appointment in this case, if the IESG comes to the same 
conclusion.


Some suggestions for rfc8713bis:

- Regarding the terms question (1-year term, 2-years terms or anything 
sensible up to 3 years), it could make sense to delegate the decision 
(in certain and/or in undocumented cases) to the concerning body (e.g. for 
IETF chair or ADs, delegate to IESG), as they know their needs best.

- Also cover similar cases that may be arising in future, e.g. when an 
area has 3 ADs.


All the best,
  Bernie (voting member of the Nomcoms 2008/09 and 2019/20)


--

http://ucom.ch/
Modern Telephony Solutions and Tech Consulting for Internet Technology


On Tue, 19 Sep 2023, NomCom Chair 2023 wrote:

> All,
>
> Apologies for not including the procedural details in my previous email [1].  This email contains more details on the proposed process.
>
>
> # Process for filling mid-term vacancies replacement given advance notice
>
> RFC 8713, Section 3.5 describes a process that the NomCom is expected to follow in the event that a seat on the IAB, IESG, Trust, or LLC board is vacated. This procedure assumes that notice about a vacancy occurs at the same time as the vacancy.
>
> In the event that a sitting member gives advance notice of a vacancy, this procedure is not sufficiently clear. There are questions about which NomCom is responsible for filling the vacancy, as well as timing concerns.
>
> This describes a process for filling vacancies in the event that advance notice is available.
>
> ## Timing and RFC 8713
>
> When a vacancy occurs, there are four distinct events of interest:
>
> 1. When the incumbent announces their intention to stand down.
> 2. When the incumbent intends to vacate their position.
> 3. When the confirming body approves the selection made by the NomCom.
> 4. When the person replacing the incumbent is seated.
>
> RFC 8713 only contemplates a scenario when announcement and vacation are concurrent.  In that case, the vacancy needs to be filled promptly, so a six week period is allowed to find, confirm, and seat a replacement.  In this expedited  process, the replacement is seated at the same moment as confirmation occurs.
>
> In a situation where the announcement comes ahead of the incumbent vacating a position, several questions arise:
>
> * Which NomCom is responsible for filling the vacancy?
> * When can NomCom commence its proceedings (call for nomination, feedback, interviews, etc…)?
> * How long is the NomCom given to fill the vacancy?
> * When is a replacement seated?
>
> These questions are not adequately answered in RFC 8713.
>
> ## Decisions
>
> Given a situation where advance notice is available, we need to make several decisions to answer the above questions.
>
> ### Decision 1: Which NomCom
>
> The date of the vacancy determines which NomCom is responsible for filling the vacancy.
>
> According to RFC 8713, there is a period during which two different committees are active. For example, the 2022-2023 NomCom was seated on 2022-08-22 for a period of 15 months, until 2023-11-22, overlapping with the 2023-2024 NomCom that was seated on 2023-07-26. Section 4.2 of RFC 8713 (also Section 3.5) is clear that if a position is vacated during the period of overlap, it is filled by the NomCom from the previous year. 
>
> This only potentially changes the responsible NomCom for vacancies that are announced prior to the end of the overlap period, where the vacancy occurs later than that date. The proposal retains the requirement to activate the previous NomCom if the vacancy occurs within this overlap period.
>
> Using the date of vacancy has the advantage that coordination between the committees from different years is minimised.  For instance, if a vacancy occurs in March, having the NomCom run its process concurrently with the regular process of selection of replacements, which makes coordination simpler.  A hypothetically-vacated IESG seat would be filled alongside the other IESG positions that are filled.
>
> ### Decision 2: When
>
> The NomCom can start work to find a replacement from the date that the vacancy is announced, not when the vacancy occurs.
>
> This gives more time to find a replacement. This assumes that the intent behind having a six week period to fill a mid-term vacancy (as described in Section 3.5) is to minimise the length of time where the position is not occupied. A longer time to fill the position also benefits interested candidates, allowing them more time to arrange their candidacy.
>
> ### Decision 3: Duration
>
> The time available to the NomCom is six weeks, or the time from receiving notice to the time that the position is vacated, whichever is longer.
>
> This ensures that a position does not remain vacant for more than six weeks. Note that, based on a strict reading of Section 3.5, the six week time limit only applies if a NomCom is reconvened. Taking that interpretation means that a sudden vacancy that occurs in December (when a NomCom might be active) would not be filled with any real urgency.
>
> ### Decision 4: Seating
>
> A replacement is seated when both their selection is confirmed and when the position is vacated. Critically, a selection can be confirmed before a vacancy occurs.
>
> The text in Section 3.5 says that a replacement is seated immediately after confirmation. This assumes that there is a vacant position that needs to be filled urgently.  However, in a situation with advance notice, there is no need to tightly couple these events. Allowing confirmation to occur ahead of the vacancy ensures that it is possible to avoid having a vacant position and creates a transition period that aids a smooth handover.
>
> ## Handling Process Variations
>
> We need to discuss the above principles with the community. Because there is an immediate need to act, the NomCom will likely need to act while the consultation is ongoing. We can work through any objections that are raised, by adjusting the process and also by correcting any documentation.
>
> Ultimately, it seems unavoidable that a revision (or update) to RFC 8713 that includes a rewritten Section 3.5 is necessary.  That is a longer process that can use the motivation above, and build on the experience gained from executing the revised process.
>
> The IESG can oversee both the immediate community discussion around what is done now and the longer effort to improve RFC 8713. This is based on RFC 8713 being an IETF stream document.
>
> Martin Thomson
> nomcom-chair-2023@ietf.org
>
> [1] https://mailarchive.ietf.org/arch/msg/ietf-announce/mU-FKwga3EDaDapXNgR_FX4Wiqs/
>
> _______________________________________________
> ietf-nomcom mailing list
> ietf-nomcom@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-nomcom