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

John C Klensin <john-ietf@jck.com> Tue, 30 August 2022 20:59 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 0FD87C1522BB for <eligibility-discuss@ietfa.amsl.com>; Tue, 30 Aug 2022 13:59: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_DNSWL_BLOCKED=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 jM_NUmoTGSVu for <eligibility-discuss@ietfa.amsl.com>; Tue, 30 Aug 2022 13:59:20 -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 6F29AC14CE3B for <eligibility-discuss@ietf.org>; Tue, 30 Aug 2022 13:59:19 -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 1oT8KK-00013m-9q; Tue, 30 Aug 2022 16:59:16 -0400
Date: Tue, 30 Aug 2022 16:59:09 -0400
From: John C Klensin <john-ietf@jck.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, adrian@olddog.co.uk, eligibility-discuss@ietf.org
Message-ID: <21D8E12CCAC8F679B068A7EB@PSB>
In-Reply-To: <2347.1661883651@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>
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/ZdmvGXdI9cGGkXflqF5MQz-b404>
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 20:59:25 -0000


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


> Adrian Farrel <adrian@olddog.co.uk> wrote:
>> And on another point. The front page debate is painful.
>> It is often the case that one or two people have to step
>> back from the front page, allowing themselves to be
>> listed as Contributors. They usually do this with good
>> grace notwithstanding the "loss" of association with the
>> document. Now we are giving them another reason to push back.

There are actually two other cases/categories, in addition to
the "too many authors" one that you cite and the "dead prior
authors" that Eliot 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.  As with the other types, sometimes
we handled that in a Contributor section (with narrative) and
sometimes embedded in the acknowledgements (sometimes with a
convenient statement that they cannot be held responsible).  

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.

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.

> There are two kinds of Contributors now, btw.

> There are those listed in the Acknowledgments or Contributions
> section in english.  And there are those listed in the XML.
> The XML hasn't been used much to date, (and might even be
> absent from the v2, I don't know,didn't check), but it is now
> quite easy to move an author from authors: yaml section in
> kramdown to contributors section.
> 
> <NOHATS>
> I've been pushing for sometime to make the XML-Contributors
> section better used, specifically because of the ability to
> mechanically pull them out, and potentially list them in a
> path-3-like process.

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.  If it is really just undifferentiated contact
information, an author might list someone violently opposed to
the spec just to keep the contact information handy (that is
another addition to Adrian's comment about unintended
consequences).   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 another point: *all* the names on the front page of
>> an IETF RFC are at the discretion of the WG chairs.

Or by agreement of other authors, etc.  The ability of a WG
chair to intervene does not imply that they will, or always have.

>> While this is largely a theoretical point, it does
>> happen that chairs appoint a single editor to go on the
>> front page, moving everyone else to be Contributors.

Once upon a time, that was close to the norm rather than the
exception and WG Chairs had nothing to do with it.  Someone
named Postel believed very strongly, and for multiple reasons,
that the number of authors should be minimized and limited to
either an editor or those who could be held accountable for its
content.  That was a goal, not a firm policy even though the
"maximum five" was a corollary, but ...  And it was long before
the Contributors section was introduced.

> Yes.  And that's exactly where I want the XML-Contributors to
> be used, and where I'd like Path 3 to consider that.  I don't
> mind if the threshold is higher.
 
>> We have a severe case of unintended consequences here.
>> The cause is trying to assign a qualitative measure of
>> IETF participation without understanding that this might
>> motivate other behaviours.
>...

And _that_ is what concerns me, as does introduction of
XML-contributors without, AFAICT, clear documentation about
content or description in any of 7991, draft-iab-rfc7991bis, or
draft-irse-draft-irse-xml2rfcv3-implemented and then attributing
meaning to it that goes far beyond the document itself.


Recommendation, only partially motivated by the schedule: 

(1) Stick to listed authors of IETF stream RFCs for now
(although, like Adrian, I'm not convinced even that is needed)

(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.

(3) Task the RSWG with coming out with some clear (obviously not
retroactive) definition of "Contributor", who should go into
that category, etc.  Also ask they come up with boilerplate to
use with the categories we have identified and, if they allow
exceptions for edge cases, what to say about them.   Because the
RSWG theoretically owns the xml2rfc, let them decide as to
whether markup for Contributors should include the category.  If
they cannot, or will not, reach a conclusion, then I think the
discussion about including Contributors for Nomcom eligibility
should die a well-deserved (and ideally quiet) death.

(4) Iff the RSWG comes up with a decent definition and there is
evidence that making some or all contributors eligible would be
helpful and/or significantly more fair, convene a new effort and
consider making them Nomcom eligible for the third Nomcom after
the RSWG's definitions and rules are in place (so that no one
become eligible due to lack of definition).  Of course, other
streams could be taken up at the same time if people really
wanted to do that.  

I just don't see how anything can be done now without opening
cans of worms that will take far too long to close.

best,
   john