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

John C Klensin <> Thu, 27 October 2022 20:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1F167C1524B4; Thu, 27 Oct 2022 13:47:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pcdGmRfnF31l; Thu, 27 Oct 2022 13:47:34 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 800B0C1524A3; Thu, 27 Oct 2022 13:47:32 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1oo9mj-000K0A-DJ; Thu, 27 Oct 2022 16:47:29 -0400
Date: Thu, 27 Oct 2022 16:47:22 -0400
From: John C Klensin <>
To: Pete Resnick <>
cc: Ted Lemon <>, Brian E Carpenter <>,, IETF Chair <>
Message-ID: <40901823039A72E927E6387C@PSB>
In-Reply-To: <>
References: <> <> <> <> <E35A397E4DCDAD5D0BA33D9A@PSB> <>
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-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Subject: Re: [Last-Call] Change of position: 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: Thu, 27 Oct 2022 20:47:35 -0000

--On Thursday, October 27, 2022 10:39 -0500 Pete Resnick
<> wrote:

> On 27 Oct 2022, at 8:58, John C Klensin wrote:
>> ... if he
>> is forced off mailing lists until he demonstrates that he has
>> stopped the problem behavior, he has no opportunity to make
>> that demonstration, amounting to a lifetime ban.  Moreover,
>> at least from my point of view, it hurts the community by
>> depriving us of the widest possible diversity of perspectives
>> on our actual technical work.
> Revocation of posting rights does not require that we never
> see posts from this person. Yes, it does permit (but not
> require) any chair or list moderator to simply bit-bucket
> posts. However, it would also permit a chair to check the
> "moderation" bit for the mailing list and require chair
> approval of posts before the message went to the list, and in
> particular it would allow them to do so without giving a
> formal public warning or limiting them to 30 days or requiring
> consultation with their AD. Without the posting rights
> revocation, a chair simply cannot do that. In this particular
> case, given that we have someone who does contribute valuably
> to technical discussions, I would hope that chairs would not
> simply blindly block posts, but rather do the moderation until
> such time that there is a demonstration that postings can be
> made without reverting to earlier behavior. Yes, that does
> mean more work for chairs. Yes, that does mean that if the
> behavior returns, chairs will have to read rude messages and
> then explain why those messages were not allowed on the list.
> Yes, this does require chairs to be fair and judicious. But at
> least it allows for these things to happen without the
> constant return to the "warning, ask AD, suspend for 30" cycle.


Completely agreed for all mailing lists other than those called
out in the PR-action Last Call notice.    If what you are saying
is "let's force him off the enumerated set of mailing lists and
then see what happens with other lists to which he might
contribute", I can see some sense in that... Except that at
least one of those lists --the one-- is something
we at least used to tell people was important for full
participation in the IETF.

And, again, unlike my understanding of Brian's note, I am not
suggesting the IESG decide the PR-action is unjustified.  That
could, if inappropriate postings continue, lead to what you warn
against above.  Instead, I am suggesting that they pragmatically
postpone making a decision for some extended period to see how
things develop.  If one or more chairs/moderators encounter
problems, they consult ADs, the IESG puts the PR-action on the
agenda for their next meeting (or even conducts a quick email
vote since the situation would, at that point, presumably be
clear), and move forward.  Their approving the PR-action at that
time would presumably preempt any additional waiting or
consultation periods, accomplishing what I infer is your goal
from the above.  

Borrowing a bit from Ted's more recent note, my concern is not
being nice to Dan, it is finding the right balance going
forward, emphasizing protecting the community from disruptive
behavior but also preserving the full range of useful
contributions and perspectives and doing so without punishing
prior inappropriate behavior if, indeed, it has stopped.