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
- [Eligibility-discuss] New ELEGY working group -- … Barry Leiba
- Re: [Eligibility-discuss] New ELEGY working group… Stephen Farrell
- Re: [Eligibility-discuss] New ELEGY working group… John C Klensin
- [Eligibility-discuss] Discussion: do eligibility … Barry Leiba
- [Eligibility-discuss] probabilities of N voting m… Michael Richardson
- Re: [Eligibility-discuss] Discussion: do eligibil… Stephen Farrell
- Re: [Eligibility-discuss] Discussion: do eligibil… Brian E Carpenter
- Re: [Eligibility-discuss] Discussion: do eligibil… Stephen Farrell
- Re: [Eligibility-discuss] Discussion: do eligibil… Michael Richardson
- Re: [Eligibility-discuss] New ELEGY working group… Salz, Rich
- Re: [Eligibility-discuss] New ELEGY working group… Eliot Lear
- [Eligibility-discuss] Considering I-D contributor… Lars Eggert
- Re: [Eligibility-discuss] Considering I-D contrib… Eliot Lear
- Re: [Eligibility-discuss] Considering I-D contrib… Eric Rescorla
- Re: [Eligibility-discuss] Considering I-D contrib… Michael Richardson
- Re: [Eligibility-discuss] New ELEGY working group… Luc André Burdet
- Re: [Eligibility-discuss] New ELEGY working group… Salz, Rich
- Re: [Eligibility-discuss] New ELEGY working group… Eliot Lear
- Re: [Eligibility-discuss] New ELEGY working group… Brian E Carpenter
- Re: [Eligibility-discuss] Considering I-D contrib… Brian E Carpenter
- Re: [Eligibility-discuss] New ELEGY working group… Eric Rescorla
- Re: [Eligibility-discuss] New ELEGY working group… Eliot Lear
- Re: [Eligibility-discuss] New ELEGY working group… Eric Rescorla
- Re: [Eligibility-discuss] New ELEGY working group… Eliot Lear
- Re: [Eligibility-discuss] New ELEGY working group… Eric Rescorla
- Re: [Eligibility-discuss] New ELEGY working group… Eliot Lear
- Re: [Eligibility-discuss] New ELEGY working group… Eric Rescorla
- Re: [Eligibility-discuss] New ELEGY working group… Joel Halpern
- Re: [Eligibility-discuss] New ELEGY working group… Stephen Farrell
- Re: [Eligibility-discuss] New ELEGY working group… Salz, Rich
- Re: [Eligibility-discuss] New ELEGY working group… Joel Halpern
- Re: [Eligibility-discuss] New ELEGY working group… Salz, Rich
- [Eligibility-discuss] ISE vs IETF Stream RFCs for… Michael Richardson
- Re: [Eligibility-discuss] New ELEGY working group… Michael StJohns
- Re: [Eligibility-discuss] New ELEGY working group… Eliot Lear
- Re: [Eligibility-discuss] ISE vs IETF Stream RFCs… Adrian Farrel
- Re: [Eligibility-discuss] ISE vs IETF Stream RFCs… Michael Richardson
- Re: [Eligibility-discuss] ISE vs IETF Stream RFCs… Adrian Farrel
- Re: [Eligibility-discuss] ISE vs IETF Stream RFCs… John C Klensin
- Re: [Eligibility-discuss] ISE vs IETF Stream RFCs… Michael Richardson
- Re: [Eligibility-discuss] ISE vs IETF Stream RFCs… Michael Richardson
- Re: [Eligibility-discuss] ISE vs IETF Stream RFCs… John C Klensin
- [Eligibility-discuss] RFC criterion [was ISE vs I… Brian E Carpenter
- Re: [Eligibility-discuss] RFC criterion [was ISE … Stephen Farrell
- Re: [Eligibility-discuss] RFC criterion [was ISE … Michael Richardson
- Re: [Eligibility-discuss] RFC criterion [was ISE … John C Klensin
- Re: [Eligibility-discuss] RFC criterion [was ISE … Michael Richardson
- Re: [Eligibility-discuss] RFC criterion [was ISE … John C Klensin
- Re: [Eligibility-discuss] New ELEGY working group… Barry Leiba
- Re: [Eligibility-discuss] ISE vs IETF Stream RFCs… Donald Eastlake
- Re: [Eligibility-discuss] ISE vs IETF Stream RFCs… Michael Richardson