Re: [Eligibility-discuss] Discussion of draft-ietf-elegy-rfc8989bis and IETF 115

Donald Eastlake <d3e3e3@gmail.com> Sun, 06 November 2022 23:51 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: eligibility-discuss@ietfa.amsl.com
Delivered-To: eligibility-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D79C14CF02 for <eligibility-discuss@ietfa.amsl.com>; Sun, 6 Nov 2022 15:51:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.856
X-Spam-Level:
X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=gmail.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 TowmjPJPfzvQ for <eligibility-discuss@ietfa.amsl.com>; Sun, 6 Nov 2022 15:51:24 -0800 (PST)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 DA372C14F5E1 for <eligibility-discuss@ietf.org>; Sun, 6 Nov 2022 15:51:23 -0800 (PST)
Received: by mail-ed1-x52b.google.com with SMTP id x2so15124305edd.2 for <eligibility-discuss@ietf.org>; Sun, 06 Nov 2022 15:51:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=P9gX/ueJ/NtEAPtEKveM1Tq/ljcaus9BqG5gfiTmAlw=; b=Gh8bL5QqdfhRBfmlFz1TDJaVwge8HLQ9cawlBvDec4XARGERb6cN1ae5yr7xFOiStJ f3+VT0Nkndgu9kLQDtLdpfDUmocv5BZ8FSh5FQfd1aJ+MnrYD9x7fX7d1xF3QbTLWz9U nQ1f5qpXRL0tJD5mPrd/ABAZI9VGWfMp3Qudpby3lujxHAFYbulOYfGKNj3NHAEp2l5A /NmEJAi9VjmmoyVHPsh51hEJcWE2WTwFlma5MFDPpVjzAEzDm31szBcdNDJyxIGZCIrt JKKdaKdPCXGdmgy24l3GxoKuUHXjPdPm9HXH8rWiM8KB6gOeti9Q9rY3g8NLOc8jX0Ll wv4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=P9gX/ueJ/NtEAPtEKveM1Tq/ljcaus9BqG5gfiTmAlw=; b=4fm/WIMMsC9Oq60Tl9sR63n5NYd/Elz1mEmGqHjLA++n5RyrzEFSN9bLaudIN2xyku mmAmzTEgHV1asW69rK3cpluY5dIhjFO+2FiKDx77T/h0d6Oxl3uUOOvBBL92lTH4KPbx 6vXM3+8OyZeL+rQZ+iPcTZtL/vdx2us06wa7w+J6bfhWjLWAG0lSZMuslyLMv4dXS6jy Amq6qB/QstOeH1r/RxRmS3LLsUEhZx2TPLx/BjE8LXbx4BkDiEiZm8B8FxPzxYVy7mHQ qCAtpUfZEjOTaeTE461jkiUAG3PJ6dB2fG2EuQJVKCRQeZ7Xeewiqbggq8odSJ2BDZN2 OXZA==
X-Gm-Message-State: ACrzQf1GnOgmjrG2A24iHpn/aJlOddZlJxnIO8a/gJc7b8vcKU40STA7 pZkx7dVLYkyZro/hyAAMewlVT3SpITRzOQQhXiy3UOyeIGs=
X-Google-Smtp-Source: AMsMyM4/XzYIiqYyCcb49qdaIwJXaTNdA1pTh2uW2DO2IwshBxx/DnXo/mPOk0brTJ0G1rUx6uQbHXvwdnCK/8XVgV0=
X-Received: by 2002:a05:6402:94e:b0:463:525e:8738 with SMTP id h14-20020a056402094e00b00463525e8738mr39761458edz.154.1667778681993; Sun, 06 Nov 2022 15:51:21 -0800 (PST)
MIME-Version: 1.0
References: <CALaySJK5n=YqPZa+aOa8i+ttymXn2yWYzekkB4gDG4QbNohdwg@mail.gmail.com> <CAF4+nEFTMMNE9pVMm5XMyb-P7ST-MKdNDeRuD3ZaWR=qia6dsQ@mail.gmail.com> <fd4b3c3c-651c-87f1-a702-27f6e80728ce@gmail.com>
In-Reply-To: <fd4b3c3c-651c-87f1-a702-27f6e80728ce@gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Sun, 06 Nov 2022 18:51:10 -0500
Message-ID: <CAF4+nEGR2W=2Qdhh40GSnSsSguSOwrL3o8OWcV6C3BNmxoAtkA@mail.gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: eligibility-discuss@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/eligibility-discuss/jrMTiR20A8Y4sqDusHh0r_hI4PY>
Subject: Re: [Eligibility-discuss] Discussion of draft-ietf-elegy-rfc8989bis and IETF 115
X-BeenThere: eligibility-discuss@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF eligibility procedures <eligibility-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eligibility-discuss>, <mailto:eligibility-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eligibility-discuss/>
List-Post: <mailto:eligibility-discuss@ietf.org>
List-Help: <mailto:eligibility-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eligibility-discuss>, <mailto:eligibility-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Nov 2022 23:51:25 -0000

Hi Brian,

On Wed, Oct 5, 2022 at 9:06 PM Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:
> Donald,
> On 06-Oct-22 07:17, Donald Eastlake wrote:
> ... (eliding many of Donald's comments)
>
> > Why would the eligibility criterion be loosely based on RFC 8989 rather
> > than loosely based on the first principles?
>
> It's factual that the proposal is loosely based on 8989. Shouldn't the
> criteria be *firmly* based on the first principles?

The draft talks about first principles but then says what it proposes
is loosely based on RFC 8989. I was just copying from the draft when I
used the words "loosely based".

To be specific, the abstract in -00 says "This document updates
RFC8713 by building a new set of eligibility criteria from first
principles" and there is a whole section on nomcom principles, but
then it says the the document's "objective is to eventually replace
Section 4.14 of RFC8713 with criteria loosely based on those in
RFC8989."

I think its goal should be neither (1) generating new agreed upon
principles from which nomcom eligibility can be deduced, nor is it (2)
just copying RFC8989. It's more like it is finding some point in the
nomcom eligibility space between RFC 8713 and RFC 8989 that has
consensus.

> ...
>
> >    -- Path 1: The person has registered for and attended 3 out of the last
> >    -- 5 IETF meetings, either in-person or online.  In-person attendance is
> >    -- as determined by the record keeping of the Secretariat.  Online
> >    -- attendance is based on being a registered person who logged in for at
> >    -- least one session of an IETF meeting.
> >
> > Someone who logs in for only one session for a meeting seems like the
> > sort of ultra-narrow participant that we DO NOT want on the nomcom.
> > Furthermore, a reference to the "last 5 IETF meetings" is affected by
> > the number of meetings per year.  Better to say something like "3 IETF
> > meetings during the last 2 years".
>
> Even that isn't resilient enough, IMHO. What if the IETF decides to
> reduce the frequency of plenary meetings in favour of more interim
> WG meetings? As we adapt to sustainability in one way or another,
> I think it's wise to be as resilient to change as possible. I think
> that gives the current wording an edge.

OK.

> > Remote attendance is OK and was
> > obviously necessary in the era of COVID but this "one session"
> > criterion is absurdly lax.
>
> Yes, we used this in RFC8989 because it was straightforward to automate.
> I agree it's weak, but I think we need to hear from the tools people
> whether it's easy to automate the sort of change you suggest.

I don't see what the problem would be since the data is now automated.
Should I be the one to pester tools people about this?

> > With automated blue sheets and hybrid meetings, even though in-person
> > attendance is more securely determined than on-line, I'm not sure how
> > much sense it makes to distinguish them. How about something more like
> > "The person has attended at least 3 IETF meetings over the previous 2
> > years. Attendance is defined as their attendance being recorded
> > (either on-line or in-person) for at least two sessions on each of at
> > least 3 days of the meeting."
>
> Since we started offering day passes to in-person attendees, has
> a day pass sufficed under RFC 8713? I assume it has, since there is
> no wording in the RFC to exclude it. So I wonder whether we are being
> unfair if we add a multi-day requirement here.

You seem to like to use "fairness" which, I would maintain, is a very
poorly defined concept. Among other questions, fair from whose point
of view? It is clearly unfair to a qualifying individual IETF
participant who just happens to work for a sponsor that sends a lot of
people that they are denied the same probability of being chosen from
the nomcom as a participant from a sponsor that sends few people. But
it is unfair to the IETF to allow participants with the same sponsor
to constitute 3 or 4 of the voting members of the nomcom because of
the threat of their possible collusion and the bad appearance this
presents.

The nomcom eligibility criterion should not be considered solely in
the light of whether somewhere, somehow, some individual is not being
treated as nicely as you would like. If you try to include individual
case that should be eligible due to some contingency, you end up with
rules of escalating complexity (if you try to really narrow in on that
contingency) or such laxness that they are easily abused (if you just
add simple criteria which include the meritorious contingency but a
lot besides).

Assuming agreement on why there are eligibility requirements, say that
you want people with reasonable familiarity with IETF processes in
practice, be willing to put in the work, and have some knowledge of
IETF leaders, there is clearly a spectrum. Someone attending for a
whole week would be more desirable under such a criteria goal than
someone who had just a day membership. So I see ignoring day
membership/attendance at IETF meetings a reasonable.

> > (Although the criterion has been totally revised due to the era of
> > COVID, you might be interested in what the attendance requirements of
> > another standards organization were, in particular IEEE 802.11 WG
> > which has 6 weeklong meetings a year. Before COVID, as I recall, to
> > count as having attended for the week you have to be present for 75%
> > of the time slots (some slots were plenary while other time slots were
> > broken out by Task Group). And to count as having attended during a
> > time slot, you had to be in attendance for 90% of that time slot.
> > After attending for a couple of these weeks within a one-year interval
> > (it's actually a bit more complex than that), you qualified as a voter
> > and decisions were made by in-person voting.)
> >
> >    -- Path 2: The person has been a Working Group Chair or Secretary within
> >    -- the 3 years prior to the day the call for NomCom volunteers is sent
> >    -- to the community.
> >
> > I understand that very few people qualified under this path that
> > didn't qualify under Path 1.  Especially if that's true, then I see no
> > reason for the path
>
> I disagree. The point isn't that most WG Chairs (and Secretaries) attend
> in-person meetings anyway; it's that we should not be exclusionary if
> there are WGs that prefer not to work that way. I certainly expect that
> there will be more, not fewer, non-meeting WGs in future.

The very existence of ANY nomcom eligibility criteria is explicitly
exclusionary by excluding those who do not qualify. The basis of the
criteria is that, of the 8 billion or  so people in the world, some
characteristics make it likely that someone would be a more desirable
nomcom member and some would be less desirable and we want to
establish a cut line in the spectrum of desirability. Opinions will
obviously differ on where such a line should be, including differences
based on factors such as how many above the line are "enough" and how
important the abusability of a criteria are and what the public
appearance of the criteria is.

> > -- there is plenty of representation of the WG
> > Chair viewpoint among others qualifying under Path 1. Each path adds
> > complexity and increases the attack surface. It also doesn't look that
> > good where the ADs/IESG select WG Chairs and the WG Chairs, even if
> > they haven't qualified in any other way, are eligible to be involved
> > in the selection of the ADs/IESG.
> >
> > I didn't realize that WG Secretaries were included. This seems pretty
> > flakey to me. Some WG Secretaries do a fair amount of work, and some do
> > very little. They can just be appointed/removed by the Chairs. I have
> > a lot more confidence in the ADs/IESG than I do in, say, the worst of
> > the WG Chairs. Can a WG Chair appoint a new Secretary of their WG each
> > day for a month? I see no reason why not. And as far as I know,
> > neither the WG nor the AD is directly informed when a Secretary is
> > appointed.
> >
> > Why should someone new to the IETF just appointed a Chair (presumably
> > paired with an experienced co-Chair) or Secretary and perhaps having
> > only served for a few weeks or even days be nomcom eligible if they
> > don't qualify in any other way?
> >
> > I would just drop this path. (If it were to be kept, I would change it
> > to require time in office. So "... Chair [or Secretary] for at least a
> > year within the 2 years prior ...".)
>
> Yes, adding a minimum time in office is reasonable, iff it can be automated.

I would never have even thought of including WG Secretaries. Some do a
significant amount of work but some do nothing. If you're going to
include them, why not WG Technical Advisors (who usually do almost
nothing), why not Document Shepherds, why not every member of every
Directorate, why not anyone who has written a document review more
than a screenful long, why not .....? Where does this stop? You can
pretty much always find someone somewhere who might be worthy but
slips through the cracks of any finite set of criteria that have any
teeth.

I would not include anyone just because of the positions I list in the
paragraph above. However, WG Chairs are different and I can see
including them. But there are the following factors:
1.  It needs to have a time requirement, like someone has to be a
Chair for a year or the like, and we have had a post saying that is
hard because it is hard to tell, from the data available, when someone
leaves that position.
2. It adds very few people.
3. It doesn't look that good that the IESG can bless people to be in
the pool from which those who determine who is on the IESG are
selected.

Given these factors, it doesn't seem worth the added complexity of
having another "path" just for WG Chairs even though they are trusted
and it would otherwise be reasonable. However, I seem to be in the
rough here so I won't fight about WG Chairs. But I draw the line at WG
Secretaries or other WG functionaries.

> >    -- Path 3: The person has been a listed author or editor (on the front
> >    -- page) of at least two IETF Stream RFCs within the last 5 years prior
> >    -- to the day the call for NomCom volunteers is sent to the community.
> >    -- An Internet-Draft that has been approved by the IESG and is in the
> >    -- RFC Editor queue counts the same as a published RFC, with the
> >    -- relevant date being the date the draft was added to the RFC Editor
> >    -- queue.  For avoidance of doubt, the 5-year timer extends back to the
> >    -- date 5 years before the date when the call for NomCom volunteers is
> >    -- sent to the community.
> >
> > I certainly think people who contribute to RFCs should get
> > recognition.  However, I think the nomcom eligibility pool should be
> > chosen primarily with the aim of getting the best nomcom, not
> > primarily as a reward for people who have contributed. You do
> > learn/see some things in putting a document through but mostly if you
> > are the primary author.
>
> It is not a reward.

So you say but many will believe it is.

> Like the previous point, it's intentionally
> broadening the pool to include people who for whatever reason don't
> attend meetings (for budgetary, travel-aversion, time zone or any
> other reason). Not doing this is exclusionary.

As above, saying it "is exclusionary" says nothing about whether it is
good or bad. It is extremely exclusionary that only ADs can
participate in ballots to make standardization decisions in the IETF
but I think that is OK.

> > And 5 years is too long.  I think 2 or 3 years would be long
> > enough. Consider that documents can get stuck in misref for
> > years.
>
> That's exactly the reason for the 5 year rule. If our publication
> process wasn't sometimes so slow, a shorter period would be fine.
> However, I don't see 5 years as a very long time scale in the
> history of a 36 year-old organization. Most candidates that NomCom
> considers have been involved for several years.
>
> > Here, for example, is a document that has been stuck in misref
> > for almost 5 years:
> > https://datatracker.ietf.org/doc/search?name=trill-ecn&activedrafts=on <https://datatracker.ietf.org/doc/search?name=trill-ecn&activedrafts=on>
> > This sort of thing could stretch eligibility out for quite a while but
> > only in a few isolated cases.
> >
> > Say someone is the world's leading expert of the WYX protocol. They
> > review a lot of drafts and provide excellent comments and even suggest
> > some text but someone else is always the primary author of drafts they
> > contribute to. And they are happy with that because they care about the
> > technicalities of the protocol and don't want to futz around with
> > documents. They only subscribe to the WYX email list and never attend
> > a meeting of anything but the WYX WG.  They get listed on the first
> > page of a number of RFCs. Why is it a good idea for them to be nomcom
> > eligible? And the current zeitgeist is the if you are eligible,
> > people are going to push, Push, PUSH for you to volunteer because they
>
> They are? I've never been aware of that; in fact it seems to me that
> we have been rather unassertive about encouraging volunteers.

I do not agree that all the messages that go out on different mailing
list and the checkbox on registration collectively are unassertive.

Perhaps I don't pay as much attention as I should to various nomcom
volunteer recruiting messages. Points that I recall are claims that we
"need" more volunteers and that a larger nomcom volunteer pool is more
"representative". I would reply that we do not need more volunteers.
In my opinion, the system works just fine with the historically huge
200+ person pools we are getting, and would work fine with a pool size
half as large. And I would say that the more the rules are relaxed to
produce a larger pool, the more representative it will be of those
less involved in the IETF and the less representative it will be of
those most involved in the IETF.

> > seem to think a bigger and bigger and bigger volunteer pool is always
> > better even if the result is more people not that enthusiastic about
> > putting in the work required and more people declining if they are
> > randomly selected, etc.
>
> Correct, but the point here is to have a diverse and non-exclusionary
> pool.

So, you think it is fine that an increasing number of people are
declining when initially selected? I view that as a bad sign and it
requires an increased number of iterations of selection.

> > So, I don't want to just be critical without providing an
> > alternative. I guess if I was drafting a new criterion to replace
> > these multiple paths, it would be something along the following line:
> >
> >     The person has attended at least 3 IETF meetings over the previous
> >     2 years. Attendance is defined as recording your attendance (either
> >     on-line or in-person) at at least two sessions on each of at least
> >     3 days of the meeting. Being a front-page author of an IETF Stream
> >     RFC (or approved draft in the RFC Editor's queue) in the previous
> >     three years may be substituted for up to two of these attendance
> >     instances.
> >
> > No doubt the above wording needs some tuning even if people like it.
>
> That would still exclude people who never attend meetings. I think
> that is a mistake.

For 28 years or so, the physical attendance criteria for nomcom
eligibility has served the IETF well. It had to change due to the
pandemic but I'm not sure if people realize how big a change allowing
virtual attendance is. Despite some technical advances, physically
attending an IETF meeting is a markedly different experience than
remotely attending it.

I think excluding people who never attend an IETF meeting would be fine.

> Certainly we've discussed blending the criteria in this way before,
> but I'd like to see a very precise algorithm and simulated runs
> on the last few years' data before knowing if it's feasible.

Having such simulated runs sure seems like a good thing. Maybe, until
we have that, we should minimize changes from RFC 8713.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com

> Regards,
>       Brian