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

Keith Moore <> Mon, 03 October 2022 17:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2BEFEC1524CF for <>; Mon, 3 Oct 2022 10:48:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u4H6o2uIVmw1 for <>; Mon, 3 Oct 2022 10:48:27 -0700 (PDT)
Received: from ( []) (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 (Postfix) with ESMTPS id 31976C14CF1F for <>; Mon, 3 Oct 2022 10:48:27 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 23DF2320090A; Mon, 3 Oct 2022 13:48:26 -0400 (EDT)
Received: from mailfrontend1 ([]) by compute2.internal (MEProxy); Mon, 03 Oct 2022 13:48:26 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1664819305; x= 1664905705; bh=yjgxQiL09DV9ASwikgpf+7V+PVqVkiRWWxicQms1zMg=; b=k q3Z4Lah/EVZW7GOJK89vlaHf4HsU5GFYiZR6K1qwHM4eTPYUbPHOftydvON9mRV/ 0vwUNwC+ewKoTttAo4a2yfO3uJcpN4ZsZiNLxH68kpXfKUP5zdi+4iOXrx5rRiXX B5g8snRF7fSkcu4QADax8ybFPthVKdzrlxlq9XdhoOkJaejUCxsbsCkxMln/HWBX kH2b8C1+KVCvt5OfFpQ9gi8emROU9Al8A1Dg6JY4p97XAfyjb4UBcdzYm1MhuGH9 kn+aeV9etHBMBcAflrQlcs5t/qTGWlNf45+a9w1H7DliE64vtF4eq+TBEol0o3gl srtnwWt5fcEIDxzPT4KLw==
X-ME-Sender: <xms:aSA7Y1Vo34-SwcJlJPkOyYlOnhaYfbEh4X2J6JcguWxWoTqHp2CmHg> <xme:aSA7Y1nmLSajHSExHmpK_WXLUHbXHK17n7Lhhyj3lpDN5vtIFwmGjky_oooprLE0B EJAogETHETnww>
X-ME-Received: <xmr:aSA7YxZi6_0zMdRnHETzccrVdU5naTd5Hh6cD3SyxgoSDNaj0WiVm6onm0j33PI756oF7bEsPkZBXiSIgNEzg-Y_z2jWlNNQyFevoS7E-0wbH53UmzxXPw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeehledgudduiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfuffvvehfhfgjtgfgse htkeertddtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgv thifohhrkhdqhhgvrhgvthhitghsrdgtohhmqeenucggtffrrghtthgvrhhnpeeuvdehhe etfeduueejtdeludeigfevgffgudevveekuddvheevveegkeffvdejvdenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmohhorhgvsehnvghtfi horhhkqdhhvghrvghtihgtshdrtghomh
X-ME-Proxy: <xmx:aSA7Y4Xzg1xBKk3aBk7NKGWlrpIkq4vOgB8XC7-c2pquqXiGuMV54A> <xmx:aSA7Y_nx1wFalL9jQr8hYWNFE9kYccnTwDlm8paG1XpUORLqUSIZ8A> <xmx:aSA7Y1dZykwftlZxc-_3qATIfE2XyrnDNdwgGPuSwH7YMIp97tKlzQ> <xmx:aSA7Y1QrnW-du-32elZQ94FWV3ydphU1aIxrLc_01wwzPhpxg5tj1A>
Feedback-ID: i5d8c41f0:Fastmail
Received: by (Postfix) with ESMTPA; Mon, 3 Oct 2022 13:48:25 -0400 (EDT)
Message-ID: <>
Date: Mon, 03 Oct 2022 13:48:24 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
Content-Language: en-US
To: John Scudder <>
Cc: "" <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Keith Moore <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Last-Call] Last Call: BCP 83 PR-Action Against Dan Harkins
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 03 Oct 2022 17:48:32 -0000

On 10/3/22 10:04, John Scudder wrote:

> Hi Keith,
>> On Oct 2, 2022, at 9:24 PM, Keith Moore <> wrote:
>> In a normal Last Call, anyone is free to object without significant
>> reprisal.    In this case, anyone can see that by objecting they'd be
>> courting disfavor from those in power.   That's not a consensus call at
>> all.
> I’m curious as to what you think the right approach would have been, then. Let’s review. BCP 83 says:
>     A PR-action identifies one or more individuals, citing messages
>     posted by those individuals to an IETF mailing list, that appear to
>     be abusive of the consensus-driven process.
> So, the initiation of the PR-Action requires that the IESG form some opinion as to the whether the cited messages “appear to be abusive of the consensus-driven process”.
> “In the IESG’s opinion”, IMO, communicates two things. First, that the IESG has done its duty according to BCP 83 to weigh the facts presented and come to some opinion about them (“appear to be abusive”). Second, that the IESG acknowledges that this is an opinion only and doesn’t assert it as incontrovertible fact. Read the consensus call message again without those four words. Would it be better that way? Or might you object that the statement would then be implicitly presented as if a fact, rather than an opinion?
> Beyond that, would you see it as other than disingenuous for the IESG to have posted a PR Action that took pains to avoid directly expressing any opinion? Given the requirements of BCP 83, how would that even be done? Would the consensus call use language like “the IESG has heard that people are saying”? Doesn’t the simple posting of the PR Action consensus call represent a de facto expression of opinion, regardless of the niceties of the language used?

Given that IESG has decided to try to remove some of Dan's posting 
rights, clearly BCP 83 is the right procedure for doing so.  Whether 
trying to remove Dan's posting rights is actually helpful to IETF's 
mission is a different question.

Having recently been prompted by this discussion to reread BCP 83, I 
actually don't think it's a very wise way of dealing with things today.  
The idea that we should make decisions by consensus, and the procedures 
we use to determine consensus, have long been well-baked into IETF 
culture, and BCP 83 just tries to apply that same practice to the 
question of whether to revoke someone's posting rights.    But the IETF 
community was very different when MTR wrote that document, and it was 
much more accepting of diverse input then than it is now.   I don't 
think the community would have supported marginalizing someone like Dan 
then, and from my memory it was tolerant of far more difficult voices 
than his.  The demand for intolerance (which is exactly how I see it) 
has grown considerably since then not only in IETF but in society in 
general.  I observe it but I struggle to understand why this is the case.

If I were trying to replace BCP 83 today, I'd place a much greater 
emphasis on trying to address such perceived problems by facilitating 
better communication, by listening more and accusing less, by more 
constructively engaging with the person believed to be the problem.    
There should be people tasked with trying to constructively mediate 
between IESG and such individuals, rather than serving as IESG's cops 
like the ombudsteam and SAAs/moderators have become.   It's almost as if 
there's a witch hunt mentality in IETF these days.   I think that's a 
huge part of the toxicity problem, and I don't think that problem can be 
solved by a process document.