Re: [Last-Call] OT: change BCP 83 [Re: Last Call: BCP 83 PR-Action Against Dan Harkins]

Adam Roach <adam@nostrum.com> Sun, 02 October 2022 09:12 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D76FC14F73A; Sun, 2 Oct 2022 02:12:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level:
X-Spam-Status: No, score=-2.086 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001, 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 (1024-bit key) header.d=nostrum.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 5eemqE50P-uw; Sun, 2 Oct 2022 02:12:16 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 8A6F4C14F725; Sun, 2 Oct 2022 02:12:16 -0700 (PDT)
Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.17.1/8.17.1) with ESMTPSA id 2929CCUb075778 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 2 Oct 2022 04:12:14 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1664701934; bh=Jp6BynVSdwWfMS9OUaq6K6m8cuLy62ZtH3XkkYQ+dko=; h=Subject:To:References:From:Date:In-Reply-To; b=H2SlDuWuyirL3IW5ACAdS4u7VMq+07Oagk+3LmPqdYtB+5TBFu2pF5La9TPQMiKne OQTAXcXpxYkg5uuodbXAVYXRq8o3GRMFE57dWFvaJ9N6XnoVc06/r86sGt0lbuS0Tc ISV9sLtqCr0GiG60fNWze+y1u9J045D9onfKMp90=
X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48]
To: Eliot Lear <lear@lear.ch>, last-call@ietf.org, IETF Chair <chair@ietf.org>
References: <CFE25E25-D131-468E-9923-80350D6216F3@ietf.org> <3e0356f6-8288-2ab4-ef77-52bda4ad54cf@nostrum.com> <76f3ef5e-13d0-7b0d-2b94-8f3085e06344@lear.ch>
From: Adam Roach <adam@nostrum.com>
Message-ID: <69cff9aa-9540-b369-06d6-5cee531852f0@nostrum.com>
Date: Sun, 02 Oct 2022 04:12:07 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <76f3ef5e-13d0-7b0d-2b94-8f3085e06344@lear.ch>
Content-Type: multipart/alternative; boundary="------------B4B2F2A2EF6B08806CDBAA78"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/M49pUUCOzAnt1VTai_EPHhckpYU>
Subject: Re: [Last-Call] OT: change BCP 83 [Re: Last Call: BCP 83 PR-Action Against Dan Harkins]
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 02 Oct 2022 09:12:21 -0000

On 10/2/2022 2:08 AM, Eliot Lear wrote:

> What I discovered is that we have occasionally had these outbursts 
> pretty much all along, 

Oh, definitely. I could name a few additional episodes from my own 
recollection, but those aren't really what I'm referencing in my 
previous message. What I'm seeing -- and this is admittedly subjective 
because I have neither the time nor energy to quantify it -- is an 
increase in /frequency/ of such events, and an increase in the number of 
specific individuals who choose to participate in such a fashion as a 
matter of course, rather than simply when passions run high. To be 
clear, it's not good in either case; but it's the /routine/ toxicity 
that makes working here such a uniquely unpleasant experience nowadays.

> I mostly *do* like that we are not so tolerant, but I don't like how 
> we resolve these sorts of PR actions.  The openness we like engenders 
> humiliation of the individual involved.  This began with 
> sergeants-at-arms and seemingly has gotten (in my opinion) worse. In 
> any other standards organization, the matter would be handled a lot 
> more quietly.


For what it's worth, the SAA team has a formal policy of handling 
matters of "uncivil commentary and disruptive behavior" off-list unless 
and until the poster persists in their behavior. See 
<https://github.com/ietf/Moderators/tree/main/email-templates>. 
Subsequent actions are publicly announced, because they carry at least 
nominal consequences for the people being disruptive, and because the 
community has historically demanded a radical amount of transparency 
when anything like that happens.


> I would much rather that we redid BCP 83 to reflect this, that the 
> matter fall to the IETF chair to resolve, and that that person should 
> have some freedom of action, so long as it proposed and reported to 
> the IESG.  This can result in better outcomes and can be effected more 
> quickly.  While there is a risk of abuse of power, that risk is 
> mitigated by having a handful of people with different perspectives 
> review the proposed action.
>
> That lack of openness is actually a benefit.  When matters are dealt 
> with quietly and decisively, they can happen faster.  For instance, 
> when I was chairing a calendaring working group, there was one 
> participant who had a tendency to be disruptive.  In consultation with 
> the AD, we agreed that I would moderate his participation for some 
> period of time, and reject posts I felt were offensive, a copy of 
> which would go to the AD when such a decision was made.  He was made 
> aware of his right to appeal.  Not a single message needed to be 
> moderated, and he contributed as a productive member of the group.
>
> Also, IMHO there are benefits to the community in not having these 
> debates out in the open.  We're here to develop technical standards 
> and guidance, not to debate people's behavior.  Also, these actions 
> can happen with more alacrity.
>
> So I would prefer to reopen BCP 83 along the above lines.  I'd propose 
> a mailing list if others are interested.

As your anecdote demonstrates, these kinds tools are already entirely 
within the purview of WG chairs (and their analogs for other mailing 
lists). The introduction to BCP 83 explicitly calls out that actions of 
this sort have historically been undertaken, and does nothing to remove 
permission for them to continue to be applied to this day. What you did 
for your calendaring group worked, and there's nothing procedural 
stopping it from being repeated everywhere and often. Perhaps the reason 
it doesn't happen more frequently is a matter of training of chairs, or 
tooling for our mailing lists. Perhaps we've created a culture where 
chairs are hesitant to act decisively when people become disruptive (and 
having been, on several occasions, privately forwarded the vile off-list 
abuse that chairs get when they try, this carries a fair degree of 
plausibility). Maybe they don't think it's in their power to do so. In 
any case, I don't believe the issue here is formal permission to act; 
what's at issue is the infrequency of doing so. If we get to the root 
cause of that shortcoming and take meaningful steps to change it -- 
whatever "it" is -- maybe things start getting better. That might take 
the form of an amendment to BCP 83; but your experience shows that doing 
so isn't actually necessary, and I have fairly strong doubts that it 
would be sufficient.

/a