Re: [ietf-nomcom] NomCom 2023 Extension of Nomination Period to 2023-10-12

Michael StJohns <msj@nthpermutation.com> Thu, 28 September 2023 17:33 UTC

Return-Path: <msj@nthpermutation.com>
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 84837C137395 for <ietf-nomcom@ietfa.amsl.com>; Thu, 28 Sep 2023 10:33:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.995
X-Spam-Level:
X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.091, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20230601.gappssmtp.com
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 bLTWMQ8DPbt9 for <ietf-nomcom@ietfa.amsl.com>; Thu, 28 Sep 2023 10:33:46 -0700 (PDT)
Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB33FC151091 for <ietf-nomcom@ietf.org>; Thu, 28 Sep 2023 10:33:46 -0700 (PDT)
Received: by mail-qk1-x72e.google.com with SMTP id af79cd13be357-7741bffd123so809422785a.0 for <ietf-nomcom@ietf.org>; Thu, 28 Sep 2023 10:33:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20230601.gappssmtp.com; s=20230601; t=1695922425; x=1696527225; darn=ietf.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=mzEUDpgqv2IB+gG2zoswvqiNyhfapb5j/56Oo12ZDZw=; b=fGP3qkCGKGpCZ+EN5OLVDW7o+AvKMHatgCfe5TAKSiFNMgpDZEYnr/d/OMpHfR8xAM qN6YfjB4ZGEtpJIQOXaBO/dmAbyyb6jStrI+prBr67uiJL1WGwFtYJfNQRxQ6m7ECppc JZbAm+lNzrFGPO18u1j895JPrVPAHjAysOTjKogSpWt4+fkD2jLpFqr1akQlbSH4vHwO yL9MWPkHVDPkdV5hU7fL6MwopNR52CsZ/tv8Pu6UafkKN9IJyFE1ffyhdsnhPqvDfsI6 lSfi/3nZAKeA7nOyyh0hvGjPE1Ofd/n69s3tF4P63JYGC7X8gJNFJbnXQ6gIoCvUd0th v7Mg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695922425; x=1696527225; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mzEUDpgqv2IB+gG2zoswvqiNyhfapb5j/56Oo12ZDZw=; b=ugGjYZotDOl7yi2iSlNkmWD5m4L2y9PCYz3cSe7VjmZiAT4OWaUcsSHfqKIoniRqWi cWojZXReE/yA+Zls5oB0Xo/GjK1eFaxN8uxuiDZB0Iq6Hn0Ro2iGIfsN4bDdPikiV40j GTAWAvko85g8qqfUChhIDAgI3FOTF8vHgdaPHGa6MLOA2mUt402GxQbWAw4ADwyFqAnw PisJKo77N4J9/oQK9JluN/kdZ01Kyv+hNyewZ9tgR0i+dYTS6VEefas4+fEQKrrwhYRC YVjqPq6SzmW2PKIhzn9/YBXec+P9D0kcklTgPf797cPRHDN7QUIJr5F9ha7L6+q/jUWI ujjw==
X-Gm-Message-State: AOJu0Ywk2/DxklEVoh3EZq2sCuV9/icx2ulZQyLuFbMa/2r+fjyVWVJc ya9F2xgkkBQ62EcV+Ywac3inptqXmXhpn/+huhA=
X-Google-Smtp-Source: AGHT+IGmzEsl3poUZr+ulp1UkIG1X+kUorj5ZQB14dN9Yy/eUo1l9vHNO+ZVWIw/9J/sFKzABTrRlw==
X-Received: by 2002:a37:ad16:0:b0:774:fb6:124f with SMTP id f22-20020a37ad16000000b007740fb6124fmr1924759qkm.29.1695922424616; Thu, 28 Sep 2023 10:33:44 -0700 (PDT)
Received: from [192.168.1.23] (pool-108-31-156-76.washdc.fios.verizon.net. [108.31.156.76]) by smtp.gmail.com with ESMTPSA id k1-20020a05620a142100b007758b25ac3bsm76600qkj.82.2023.09.28.10.33.44 for <ietf-nomcom@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 28 Sep 2023 10:33:44 -0700 (PDT)
Message-ID: <ffb9a9bb-5a8d-8d24-1549-6d00b8115aec@nthpermutation.com>
Date: Thu, 28 Sep 2023 13:33:43 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1
Content-Language: en-US
To: ietf-nomcom@ietf.org
References: <169586436096.57370.9087034672258353524@ietfa.amsl.com> <b50bb5d9-7f2b-5260-f04f-44561794d68c@comcast.net> <325534a5-8a69-4b8e-bf69-d1a656db2c19@betaapp.fastmail.com>
From: Michael StJohns <msj@nthpermutation.com>
In-Reply-To: <325534a5-8a69-4b8e-bf69-d1a656db2c19@betaapp.fastmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-nomcom/bPPCEDqob0sBGTb1u4IcFFVXRFM>
Subject: Re: [ietf-nomcom] NomCom 2023 Extension of Nomination Period to 2023-10-12
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: Thu, 28 Sep 2023 17:33:50 -0000

On 9/27/2023 10:23 PM, Martin Thomson wrote:
> Hi Mike,
>
> On Thu, Sep 28, 2023, at 11:56, Michael StJohns wrote:
>
>> *_Generally, moving someone from one AD position to another is handled
>> by the Nomcom, not  by the IESG._*
> Can you point me to where this is documented?  I have consulted RFC 8713 and the word "area" appears only in two places and one of those places is an "Oral Tradition" appendix.  My best interpretation of that is the alternative fungible one you included in your postscript.  Fungible ADs are free to move around, which fits my mental model better: they already do that to some degree for those working groups that are in one area, but are overseen by an AD from a different area.

But word "position" appears throughout.  We do not select someone as a 
member of the IESG, but as the Area Director for "foo".  We do not 
select the IETF chair as a member of the IESG with additional 
responsibilities as Chair.  This model is distinct from the other three 
groups (LLC, Trust, IAB) where the positions ARE fungible, and where one 
"Member of the IAB" position is the same as another position (with the 
specific exception of the attached term).

> The Chairs of the IESG, IAB, IETF Trust, and IETF LLC Board each 
> informs the NomCom of their respective positions to be reviewed. (3.7.1)

In each of these messages, the IESG does not say "we have 6 terms coming 
to an end" it details which positions have expiring terms, and the 
nomcom takes into consideration guidance for each of those positions, 
each guidance tending to contain requirements specific to the position 
rather than your fungible AD model.

In any event, getting back to your first question - let me turn it 
around on you and ask where it's documented that the IESG may as a body 
appoint someone to a new position without going through the Nomcom?

Will you agree to start with the stipulation that the IESG may not 
appoint a non-member to an open or new position without going through 
the Nomcom?

Next, let's deal with the difference between acting and permanent.  I 
would have no problem with a current AD being designated to shepherd a 
new area pending the appointment of a permanent director via the Nomcom 
process.  But that doesn't appear to be what this is.

Next, reorg by reassignment and renaming.  Moving responsibilities for a 
WG from one area to another or a WG from one AD to another is definitely 
an IESG purview.  Renaming an existing area - also an IESG purview.  
Neither of these is what's proposed here.

Next, reorg by splitting.  Taking a single area and splitting it into 
two and assigning an AD to each of the new groups.  Possibly an IESG 
purview, but since the skills for each of the new areas differed from 
the old area, I'd want to run them through the Nomcom sooner than later.

Next - reorg by shrinking.  Taking a single area and reducing the number 
of ADs. Definitely an IESG purview.  Most recent was the ART reduction.  
There's also specific language in 8713 that contemplates this case.

Last reorg by combination.  E.g. RAI/Applications -> ART. Same ADs, same 
WGs, no real change in responsibilities - probably IESG purview, but 
makes the Nomcom have to have sub-requirements for different term slots 
for ART.

In this specific case, as I calculate it, if Francesca took over WIT, 
she'd be dealing with 50% old ART groups, and 50% something else.  Of 
the 16 groups, she'd be the new AD for 12 of them (including 1/2 of the 
old ART groups).   That seems to go a bit past a simple move and/or 
rename, and doesn't necessarily show any benefit doing it the way 
proposed as opposed to advertising the position.  WIT is a new area with 
a new set of responsibilities and related skills.  Francesca will do a 
fine job - but why wouldn't you look for the possibility of a "superior 
candidate"?

> The principal functions of the NomCom are to review each open IESG, 
> IAB, IETF Trust, and IETF LLC Director position and to select either 
> its incumbent or a superior candidate. (3.2)

The Nomcom could agree with the IESG that this is the way to go and go 
forward from there.  They could decide to leave her in ART (if she was 
willing) and pick up a different candidate for WIT with possibly a 
better match of skills.   There's no urgency here given these changes 
are scheduled for March and all of the current folk will stay in place 
until then.


>
> I will admit that that interpretation requires extrapolating from a very small signal, so I'm relying on the consultation that the IESG ran as far as legitimacy goes.

I don't necessarily agree this is a "small signal".  8713 is clear that 
the Nomcom  fills "open positions".  So the question is whether or not 
the IESG can create a  new AD slot that's filled at creation, and I 
don't see how that would work.   We (community) intentionally give the 
IESG a lot of power, but we (community) reserve the right to participate 
in the selection of the leadership.  For the IESG, it's not just 
membership, it's a specific role we select for.


>
> I'm not old enough to remember the details previous IESG shuffles, so I'll rely on others regarding what happened in those cases, if precedent is your preferred method of judging criterion.

The first time we did this was when we moved Harald from one area to 
another because he had mad skills in both and we could backfill him - 
but that went through the Nomcom.  That preceded most of the iterations 
of 8713 and its ancestors though.  AFAICT the more recent reorgs were 
simple and small changes to a given ADs responsibility.  RAI seems to be 
the last time a new area was created out of whole cloth - it's possible 
that Jon Peterson was moved over by fiat from Transport, but I *think* 
he went through the Nomcom and may have gotten a 3 year term out of it.

I'd first try and read 8713 as black letter rules and see if it 
explicitly permits an approach.  If it doesn't, then we can look at 
various interpretations and pragmatic approaches.

In this case, I believe WIT should go to the Nomcom, not be an 
appointment by the IESG. (*sigh* More topics for an 8713 re-write).

Mike


>
> Cheers,
> Martin
>
> _______________________________________________
> ietf-nomcom mailing list
> ietf-nomcom@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-nomcom