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

John C Klensin <> Mon, 03 October 2022 14:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 60934C1524B0; Mon, 3 Oct 2022 07:55:49 -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 runDSsNnflVS; Mon, 3 Oct 2022 07:55:44 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 77200C1522AD; Mon, 3 Oct 2022 07:55:40 -0700 (PDT)
Received: from localhost ([::1] helo=JcK-HP5) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1ofMr4-000Hz3-IT; Mon, 03 Oct 2022 10:55:38 -0400
Date: Mon, 03 Oct 2022 10:55:38 -0400
From: John C Klensin <>
To: John Scudder <>, Keith Moore <>
Message-ID: <6D73DC0B476B71667CA9FA89@JcK-HP5>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
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 14:55:49 -0000

John, Keith,

I have to agree with John but, after rereading Keith's
suggestion, I'm not sure I see the distinction he is making.  A
decision to put any spec out for Last Call is ultimately a
decision by the IESG, or at least the relevant AD, that the spec
is, in fact, ready.  There is not, or is not supposed to be, a
rule that says "the WG made a publication request so the Last
Call is automatic" and we've seen many cases in which ADs hold
things up until assorted issues are sorted out.  I suppose the
IESG could avoid the usual boilerplate and post a Last Call
notice that says "we suspect this spec is a piece of <bad word>
but want to get the community's comment", but I have not seen
that very often and suspect it would cause a whole different
type of controversy, starting with the IESG's choice of

So, if a document went to Last Call and someone responded by
pointing out a series of problems and suggested that it was not,
in fact, ready for Last Call and that the WG and/or AD fell down
on the job and was wasting the community's time, wouldn't that
also be subject to retaliation?  Might not that retaliation
concentrate on the tone and vocabulary of the criticism rather
than the issues themselves?  

Much the same concerns would apply to IESG decisions to form a
new WG, issues a "statement", or to appeal anything at all.

I would hope for, and expect, no retaliation, much less
retaliation whose stated reason involved vocabulary or behavior,
but, if we should be concerned about it in this PR-action case,
it is not clear to me why we should not be concerned about it in
any case in which someone in the community disagrees about
document quality or readiness for the Last Call to have been
initiated.  Ultimately, we need to assume that ADs are mature
adults who understand that they are not infallible in either
technical matters or judgment about the likely consensus of the
community and, consequently, that IETF participants may disagree
with them.  Should that assumption ever turn out to be false,
that is why we have opportunities to ask questions and challenge
actions at plenaries, the Nomcom process, and, at least in
theory, the recall one.

And, while I understand how we got here and think the IESG (and
Dan) have done us a favor by opening up some broader, and
probably overdue, discussions, I don't see what it has to do
with the particular action in question.


--On Monday, 03 October, 2022 14:04 +0000 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? 
> Thanks,
> —John
> P.S.: For avoidance of doubt: as far as I'm concerned,
> anyone is free to object to this last call, without reprisal.
> While I haven't consulted with my colleagues before sending
> this, I have no reason to believe any of them would feel
> differently. (Needless to say, this doesn't represent carte
> blanche to object in terms that would be considered
> unacceptable in any other IETF mailing list context, there
> isn't some special aura of "anything goes" that attaches
> to this thread. It pains me that I feel the need to say this.)