Re: [Eligibility-discuss] ISE vs IETF Stream RFCs for Path 3

John C Klensin <john-ietf@jck.com> Tue, 30 August 2022 23:33 UTC

Return-Path: <john-ietf@jck.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 39983C2B71E2 for <eligibility-discuss@ietfa.amsl.com>; Tue, 30 Aug 2022 16:33:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 XxfjBwZcIj24 for <eligibility-discuss@ietfa.amsl.com>; Tue, 30 Aug 2022 16:33:08 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.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 E44E8C180A8A for <eligibility-discuss@ietf.org>; Tue, 30 Aug 2022 16:28:50 -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 1oTAf1-0001Lk-Cq; Tue, 30 Aug 2022 19:28:47 -0400
Date: Tue, 30 Aug 2022 19:28:40 -0400
From: John C Klensin <john-ietf@jck.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
cc: adrian@olddog.co.uk, eligibility-discuss@ietf.org
Message-ID: <BE796865FF37D3520741AA50@PSB>
In-Reply-To: <13714.1661896843@localhost>
References: <CALaySJ+uvZME0bWQnB9tSvABxkjgsTG8xpfLT1g62bBL3QeG6w@mail.gmail.com> <2b7ada30-7919-fef4-6d8a-6bd85e1c5625@lear.ch> <edb6684b-a1cb-6e95-eac9-1f7e9fc9f0ad@gmail.com> <CABcZeBOJk-5ksk+mixU8Qm1gp1BDEd=0fgQ+hd9TcgACqa82ew@mail.gmail.com> <5012c5dc-e8c0-202c-0a28-6cf2f982b77d@lear.ch> <CABcZeBMe1wckz0edXyETTp2qAMKZ9QbZBGEoM8cMHahbUAk+1w@mail.gmail.com> <d25f4549-5976-6c1e-6356-e48ca8251f19@lear.ch> <31835.1661872935@localhost> <08d901d8bc90$eec4b150$cc4e13f0$@olddog.co.uk> <2347.1661883651@localhost> <21D8E12CCAC8F679B068A7EB@PSB> <13714.1661896843@localhost>
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/eligibility-discuss/LsczDxMQWns48ZDdbcE2UguH8jg>
Subject: Re: [Eligibility-discuss] ISE vs IETF Stream RFCs for Path 3
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: Tue, 30 Aug 2022 23:33:10 -0000


--On Tuesday, August 30, 2022 18:00 -0400 Michael Richardson
<mcr+ietf@sandelman.ca> wrote:

> 
> <NOHATS>
> 
> John C Klensin <john-ietf@jck.com> wrote:
>     > mentioned and that should be considered.  The first
> involves people who     > supplied significant (perhaps most)
> of the text of the document but     > strongly disagreed with
> the way WG or IETF consensus took things and     > hence did
> not want to be listed as authors and blamed for the text.
> > The case is rare, but not non-existent.
> 
> Do you think such people are/should be nomcom qualified?

Generally not, but a complex question, so see below.

>     > The other involves people who supplied most of the ideas
> behind a     > specification but, for one reason or another,
> did not do significant     > writing.  Sometimes they have
> been listed as authors anyway, but that     > has the
> potential to cause problems at AUTH48, so they often end up as
>     > Contributors or in Acknowledgements.  This category may
> overlap with     > the "dead" one; the four categories I see
> are not disjoint.
> 
> Yes, this is often a problem.
> Sometimes they just drift away from things, retire, or get
> promoted and just can't find the time.
> 
>     > It may be worth mentioning that people in both of those
> categories have     > sometimes ended up very hostile to the
> IETF as an institution.     > While
>     > it is unlikely they would volunteer for the Nomcom, at
> least unless     > they felt vengeful as well as hostile, one
> would not be doing any     > service to the Nomcom process by
> inviting them in with an effective     > invitation to be
> disruptive.
> 
> So they might volunteer if they are vengeful, but I think in
> the other categories they would not.

I assume you mean my other two categories.  If the only category
you are concerned about allowing to volunteer are those who were
pushed off authorship of a "too many authors" document, then
there are two questions (i) why were they pushed off?  and (ii)
should they be allowed to volunteer if they don't meet any of
the other criteria?  The first question is often complicated but
rarely random -- examples on request but my favorite one is a
2004 document that was retroactively classified into the
Independent Stream.  See below for the second.

>     > So, let's see.  We have an undocumented section/feature
> (see below) to     > which names can be added entirely at the
> discretion of the author with     > little or no visibility to
> anyone who doesn't read the XML.
> 
> No, it's not the case that they are not visible.
> They are rendered into the HTML and TXT.  They show up in
> rfcdiff.

Then they are real Contributors as the RFC Editor function has
understood that term for years and, other than the observation
that we don't have a clue from one RFC to the next what the
term/category means, them being put in the XML has nothing to do
with the Nomcom eligibility question.   Either that or I am
really, really, confused.

> This assumes that WG chairs, ADs and reviewers are all
> automatons.

I don't want to go there although I note that several aspects of
the Nomcom selection are designed precisely to prevent WG Chairs
and ADs from selecting the Nomcom or influencing its composition.

>     > AFAICT, a large company wanting to pad
>     > Nomcom eligibility could have authors who worked for it
> add a thousand     > names that way, arguing (if asked) that
> they had conversations with     > them about the document at
> work and they had ideas that contributed to     > the text.
> That would be even cheaper and less trouble than attending
> > remotely and asking for fee waivers.  Maybe there would be a
> way to     > reduce the possibility of abuse, but see below.

> And you think that the rest of the IETF would just go along
> with this?

If those thousand names are visible in the RFC output plaintext,
HTML, and PDF versions, it is a non-issue and I apologize for
bring it up.  I thought you were suggesting something else.

> It seems to me that path 1's inclusion of very lax remote
> attendance definition renders the other paths useless.

Quite possible although I doubt it for several reasons.  You
will note my prediction that no one will be selected on the
basis of being listed as a Contributor who was not qualified in
some other way.  However, if you believe that, why are we having
a discussion about using, or fine-tuning the use of, the
Contributor list?
 
>> (2) Track, for the 2023-2024 Nomcom, how many people
>> qualified under that criterion who would not otherwise be
>> qualified.  I am guessing that number will be close to zero,
>> but my soothsayer badge was revoked long ago.

> I'm more interested in the opposite.
> How many were qualified by path 1 remote that would otherwise
> have been qualified as RFC authors.

Ah, but then, again, the question of why it is useful to try to
fine-tune the Contributor category (categories) is relevant.
So, let me tell you about a scenario I think _is_ relevant.

Some of our working groups have gotten very specialized to the
point that a major contributor (idea contributor, document
author, etc.) to one many not have significant involvement in
other things going on in the IETF.  While I think that type of
specialization is increasing, I believe we've had a few WG's
like that for as long as I can remember.  What has changed is
that, pre-pandemic and going back to at least the early 1990s,
those people often had incentives to attend meetings: multiple
meetings of the relevant WG(s) during the IETF week, side
meetings, informal gatherings, etc.  Now, with pressures
preventing a WG from meeting more than once during the week and
shifting company policies, the incentives for showing up in
person (and the opportunity to do so) might be greatly reduced.
If the relevant WG(s) decide to hold interims rather than
sessions that week (possibly even on the theory that
technical-level interactions with the rest of the IETF might not
be useful to the WG's work), those contributors don't attend
meetings.

Now, one can have a separate discussion about whether having
those people who are actively contributing to part of the IETF's
work but not participating in meetings and "mainstream" IETF
activities is useful.  I think the answer is "yes" because they
are affected by how the leadership behaves and may have useful
perspectives and inputs.  YMMD.  However, even if the answer is
"possibly yes", then we should make them Nomcom-eligible.  Is
RFC authorship a good surrogate for "involved in the IETF,
contributing, and representing a perspective we should not
exclude from the Nomcom"?  IMO, not very.  But, especially in
combination with the other paths, better than anything else that
has been suggested.

best,
   john