Re: Challenge: was Re: Updated Nomcom 2020-2021: Result of random selection process

Toerless Eckert <tte@cs.fau.de> Sun, 12 July 2020 14:19 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375243A09AF for <ietf@ietfa.amsl.com>; Sun, 12 Jul 2020 07:19:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level:
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8LL0E2hB79H for <ietf@ietfa.amsl.com>; Sun, 12 Jul 2020 07:19:07 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D3853A09A1 for <ietf@ietf.org>; Sun, 12 Jul 2020 07:19:06 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id E5281548047; Sun, 12 Jul 2020 16:19:00 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id D7F96440043; Sun, 12 Jul 2020 16:19:00 +0200 (CEST)
Date: Sun, 12 Jul 2020 16:19:00 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Rob Sayre <sayrer@gmail.com>
Cc: Yoav Nir <ynir.ietf@gmail.com>, The IETF List <ietf@ietf.org>
Subject: Re: Challenge: was Re: Updated Nomcom 2020-2021: Result of random selection process
Message-ID: <20200712141900.GN49328@faui48f.informatik.uni-erlangen.de>
References: <159422819660.27889.6475902734358747001@ietfa.amsl.com> <b4f5a3cf-5fab-8188-926a-a4100f776610@comcast.net> <892C3021-1B44-463C-B2C4-5070396EFD50@gmail.com> <c3de3ced-2995-dba2-6bf6-89d0659138be@comcast.net> <EA1BCB3A-5473-4C14-92FF-B38713132D2C@gmail.com> <800a4f9b-504c-7725-11d8-a855d074e91e@comcast.net> <80BE06AD-146F-4DE1-A160-2A7B1E7CB59D@gmail.com> <CAChr6SwaMYcV6ysWMHMOcaGbn3TPbSAe6e_sZ0B3ABup+incug@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAChr6SwaMYcV6ysWMHMOcaGbn3TPbSAe6e_sZ0B3ABup+incug@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/9YUVgUFZCORUfkEOc86gY2pZTng>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Jul 2020 14:19:09 -0000

It seems to me as if better RFC text, it could IMHO pick either of the
following two options to amend the text we have now:

A) removal of Tal - because of re-evaluation of hash-list.
B) removal of Luigi - because of new disclosure about his affiliation.

To me, B) looks more logical because it maintains a bit more of the
"individual contributor" pretense the IETF claims to have (and directly violates
with the max2 rule). Aka: It only eliminates a person for which there is a
new disclosure, not a different person.

Any disucssion between Luigi and NomCom chair to me just looks like an
attempt to decide which one of these two cases would be best match the
intent of the process given how the RFCs are not prescriptive enough.

Both options i think match Eliots corollary of removal based on association.

The more important corollary from Eliot not well written down either is the
non-addition based on association, e.g.: If Luigi would have been Huawei initially
and would have left Huawei instead, then that would not raise Tal from the max2
eliminations of the initial run.

Cheers
    Toerless

P.S.: If there was a new RFC done, you should ask for the rights to use the
names Luigi and Tal, otherwise use Alice and Bob ;-))

On Sun, Jul 12, 2020 at 01:28:16AM -0700, Rob Sayre wrote:
> On Sat, Jul 11, 2020 at 11:00 AM Yoav Nir <ynir.ietf@gmail.com> wrote:
> 
> > Clearly, Luigi requested to be removed because both he and the NomCom
> > chair agreed with an interpretation like mine. If the powers that be (which
> > AFAIK is the NomCom chair) decide that this is a wrong interpretation, he
> > should at least be allowed to withdraw his resignation which was made in
> > error.
> >
> 
> I don't agree with your reading of the RFC. But, even if I did, it seems
> unwise to do this kind of negotiation. Your reading grants the chair a lot
> of discretion, but does not make a case for this particular decision.
> For example, one relevant piece of information might be who the next few
> candidates would have been.
> 
> It would be a shame to call any of these into question:
> 
> - selection of NomCom members
> - the actions of their nominees
> - the IETF itself
> 
> If those seem questionable, there is no benefit to publishing an RFC over
> an Internet Draft.
> 
> thanks,
> Rob

-- 
---
tte@cs.fau.de