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

John C Klensin <john-ietf@jck.com> Thu, 28 September 2023 19:28 UTC

Return-Path: <john-ietf@jck.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 67430C16B5B1; Thu, 28 Sep 2023 12:28:25 -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_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 CyTSS4kT8-3P; Thu, 28 Sep 2023 12:28:21 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B90CBC16B5B2; Thu, 28 Sep 2023 12:28:20 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1qlwgM-0006c3-Qy; Thu, 28 Sep 2023 15:28:18 -0400
Date: Thu, 28 Sep 2023 15:28:13 -0400
From: John C Klensin <john-ietf@jck.com>
To: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, Michael StJohns <msj@nthpermutation.com>, ietf-nomcom@ietf.org
Message-ID: <8B3524ED5D57C7C43CBF0A5E@PSB>
In-Reply-To: <0024EBA9-5174-4030-B69A-FFA52C602C2E@akamai.com>
References: <169586436096.57370.9087034672258353524@ietfa.amsl.com> <b50bb5d9-7f2b-5260-f04f-44561794d68c@comcast.net> <325534a5-8a69-4b8e-bf69-d1a656db2c19@betaapp.fastmail.com> <ffb9a9bb-5a8d-8d24-1549-6d00b8115aec@nthpermutation.com> <F77FEBE2-A323-4B3B-9AD1-F5D5E7A189B2@akamai.com> <deb58221-f245-0404-f3d0-132f16a6c512@nthpermutation.com> <0024EBA9-5174-4030-B69A-FFA52C602C2E@akamai.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-nomcom/9DOIf2SfPE_ZZH2jf8NrvKjUd6E>
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 19:28:25 -0000


--On Thursday, September 28, 2023 18:09 +0000 "Salz, Rich"
<rsalz=40akamai.com@dmarc.ietf.org> wrote:

>> By virtue of their position in the process, the Nomcom and
>> the 
> confirming bodies have an ability to say something about the
> job  descriptions.
> 
> I have never heard that from anyone before this. I wonder if
> others believe this, or if you are in the rough.

Rich,

While I probably would not have phrased things that way Mike
did, I think it has been clear since the beginning of the Nomcom
model that job descriptions provided by the IESG or other bodies
are advisory to the Nomcom, not rigid requirements.  The Nomcom
interprets those PDs according to its own knowledge and
perceptions and fills positions as it understands them.  It does
not make precise matches to particular job descriptions and, if
it (including the liaisons) do not see a job description as
adequate for a particular position, it is not obligated to go
back to the body that provided the description and negotiate
(although, at its discretion, it might ask for a clarification
or the relevant liaison might try to provide one).  The
confirming bodies, too, evaluate selected candidates on the
basis of the match to those positions, not to the provided job
descriptions.  

In addition to the two examples Mike gave and to be very
pragmatic, consider the alternative.  If the descriptions
provided by, e.g., the IESG are really intended to represent the
community understanding of those position (rather than an IESG
ex cathedra one), then many other precedents suggest that the
IESG would need to announce the descriptions to the community
and conduct an IETF Last Call.  Failure to do that (or to push a
description forward without it) would create grounds for appeal,
putting oversight of those job descriptions in the hands of the
IAB (which may have an interest in the matter) and potentially
on grounds of fairness, with the ISOC BoT.  That would,
incidentally, be one of the best mechanisms yet imagined for
making it hard for a Nomcom to meet its calendar/schedule.
Instead, we trust the Nomcom, supposedly as representative
sample of the community, to make decisions as to how much to
weigh the provided job descriptions against their perceptions of
the job (including input they receive in looking at candidates).

As an example somewhat different from Mike's two, when the
Nomcom issues a call for comments on candidates for a particular
position, a member of the community gets to write "hey, based on
experience with that area, the following skills (or knowledge)
are vitally important despite not being emphasized (or maybe
even mentioned) in the job description...".  They might even add
"and that is why the Area is having problems and needs someone
to clean house".  They then explain why and how that might
affect choices of candidates.  Are you suggesting the Nomcom is
obligated to ignore that input because it (the input) questions
the job description?   Or, if the Nomcom pays attention to that
input in its choices, isn't it effectively overriding the job
description?  Could the confirming body question a candidate
selected on that basis?  Sure it could, but presumably the
Nomcom would then explain its reasoning, with which the
confirming body could agree or not.  Vocabulary aside, isn't
that mechanism equivalent to what Mike is suggesting whether
Nomcom conducts a formal review of the job description and
explicitly decides to do something else or not?

I did not see the notes from Adrian or Joel until this note was
nearly finished but I think the three of us --again from
slightly different perspectives -- are largely in agreement.

  best,
   john