Re: New-comers (was Re: the old fellowship program)

John C Klensin <john-ietf@jck.com> Sat, 17 April 2021 17:28 UTC

Return-Path: <john-ietf@jck.com>
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 F09663A2A7F; Sat, 17 Apr 2021 10:28:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 gDAmTeMCfl39; Sat, 17 Apr 2021 10:28:11 -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 F24323A2A7D; Sat, 17 Apr 2021 10:28:10 -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 1lXojo-000E6K-NF; Sat, 17 Apr 2021 13:28:08 -0400
Date: Sat, 17 Apr 2021 13:28:03 -0400
From: John C Klensin <john-ietf@jck.com>
To: Michael Thomas <mike@mtcc.com>, ietf@ietf.org
cc: iesg@ietf.org
Subject: Re: New-comers (was Re: the old fellowship program)
Message-ID: <71A3F4ECF01DBB59C3038E1D@PSB>
In-Reply-To: <f85245a0-f2c0-cc2f-88f9-465aaab9659a@mtcc.com>
References: <CAHw9_iKcacK-gsmL9P_yBuyeGYnB44j1=TxF=VnG3Uu65JKJcQ@mail.gmail.com> <10C5497B-FCC3-45BE-B6A7-EE3A1C1D6883@akamai.com> <f02a58f3-ff79-3f3f-fc31-7aa17f7d14aa@mtcc.com> <698cf4f7-de67-8efb-a944-b29da42dca31@network-heretics.com> <dc7ff33f-a007-7afe-7d1b-92a242b7c799@mtcc.com> <aaebce66-6318-dc16-b8b0-5a7d7e3361a3@network-heretics.com> <6f709190-7f44-906b-a36b-90a8a4d73153@mtcc.com> <1b9fd5ac-5ef6-0114-4a2e-96e7a53aa665@network-heretics.com> <cec30d23-6d88-9de9-c606-b6cc2bbeb922@mtcc.com> <3fa5b354-c11c-9051-8416-46859f10cce6@network-heretics.com> <20210416031704.gu46kq46fmp6a3yh@crankycanuck.ca> <6AABB43E-FB70-4FDE-AA59-3D2AE25F4B64@me.com> <433863C0CD9449636063CDE3@PSB> <f85245a0-f2c0-cc2f-88f9-465aaab9659a@mtcc.com>
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/ietf/vwXiBWHTHfwWYfzxJ5l206RA17Q>
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: Sat, 17 Apr 2021 17:28:16 -0000

(IESG copied because of the last paragraph)

--On Saturday, April 17, 2021 08:07 -0700 Michael Thomas
<mike@mtcc.com> wrote:

> 
> On 4/16/21 8:03 PM, John C Klensin wrote:
>> But Randy's other point is, IMO, important too.  Suppose we
>> could adopt a rule that forbade snarling at people until after
>> they had participated in the IETF for a few years and
>> magically changed the culture so that everyone observed it,
>> at the same time declaring open season on people with longer
>> participation records or at least a couple of RFCs behind
>> them.  Whether because of what Randy describes as having a
>> shred of empathy or because of the sense that they are likely
>> to be treated obnoxiously and aggressively about the time
>> they were ready to make significant contributions, people
>> would still go away after watching others be mistreated,
>> abused, or dismissed.
> 
> I don't know how you enforce such a thing because who knows
> whether somebody is new to IETF or just new to a particular
> working group? Frankly there ought not be such a distinction,
> as it is intimately related to the "security researcher"
> problem discussed previously.

Mike,

Sorry... I obviously wasn't clear.  I was trying to pose a
hypothetical and extreme scenario precisely to point out that it
would not work, not advocating it.  That was why I said "suppose
we could" and "magically".   In the real world, not only could
such a thing not be enforced, but we would need, IMO, to be
collectively insane to try it.

> The problem is that too often
> working groups become fiefdoms and accrue self-coronated
> manner lords while the chairs sit idly by, or worse enable
> them. It is extremely off putting for chairs to shut down
> questions as off topic or members jumping down your throat for
> questions that cannot reasonably be answered any other way.

Indeed, that is at least a key part of the problem -- and a
problem that I believe Andrew, myself, Randy, and probably Brian
were trying to address from our different perspectives.  It is
the part of this problem that I think has gotten worse in the
last decade or so.  It is one that the anti-harassment
procedures and guidelines for conduct developed during that
period either do not address or have proven inadequate to
prevent or remedy.  I suggest that guidelines for improved
terminology will not help either.  People can jump down the
throats of others (or snarl at them) for departing from
homogeneous opinion or the preference of leadership in a WG (or
even in other contexts) without violating any specific rules
(even though it is fairly clear from RFC 7154 that it is bad
behavior) with impunity.

> Who needs that kind of grief? Especially when you're not
> getting paid to take it.

Exactly.

I don't see any way to stop that behavior -- and stop it from
driving people away from those WGs at least and probably the
IETF more generally -- unless:

(1) The IESG, perhaps borrowing ideas for other SDOs, will not
tolerate (i.e., charter or allow to continue) WGs whose
participation represents only a narrow range of interests.

(2) The IESG and community will not tolerate WGs (or other
groups) in which shutting down dissent or questions that differ
from the opinions of WG leadership (including de facto
leadership by those you describe as manor lords) is a regular
practice.

(3) The community has effective ways to push back on individuals
who exhibit that sort of shutting down or snarling behavior
regularly, whether it is confined to one WG or not. 

Of course a WG should not need to tolerate someone who raises
the same questions or proposals repeatedly after they have been
fairly considered and rejected, but that is disruptive behavior
and we have many years of mostly-successful experience in
dealing with it. 

Independent of the impact on feelings and participation, the
behavior you describe damages the credibility of the IETF and
its work if a cabal, especially one with shared commercial
interests, can take over (or initiate) a WG, push documents into
and through IETF Last Call, and then successfully claim IETF
consensus and standards status for the results.

And none of the above would likely be meaningful or effective
unless there is also a mechanism for reporting problems and
having them considered that does not put the reporter at risk
for further abuse.  In that regard, the recent IESG statement
about Last Calls may be a step backward. If someone feels a need
to make a Last Call comment identifying ways in which claimed
consensus (in a WG, on a mailing list, etc.) is invalid because
those who disagreed were silenced or driven away, it should be
possible to make that comment to the IESG with the same degree
of anonymity associated with the Ombudsteam process.  More
generally, someone should be able to make such a report to an AD
or the whole IESG at any time and have it taken seriously
without disclosing the identity of the reporter.  At least for
Last Calls, that seems to be precluded by the new process
description.

    john