Re: [Last-Call] Question for the IESG

John C Klensin <> Wed, 12 October 2022 01:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E3BD1C152567 for <>; Tue, 11 Oct 2022 18:38:50 -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 Wpi11djBT1fM for <>; Tue, 11 Oct 2022 18:38:48 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 90F7EC14CF00 for <>; Tue, 11 Oct 2022 18:38:48 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1oiQho-000MZh-N1; Tue, 11 Oct 2022 21:38:44 -0400
Date: Tue, 11 Oct 2022 21:38:38 -0400
From: John C Klensin <>
To: Ted Lemon <>
cc: S Moonesamy <>,
Message-ID: <DEB2FBF76D55A53463021262@PSB>
In-Reply-To: <>
References: <> <> <> <> <> <E07D908383FCC3EF63B6E49F@PSB> <> <F7D30295F215065F0FB845C4@PSB> <>
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-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Subject: Re: [Last-Call] Question for the IESG
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: Wed, 12 Oct 2022 01:38:51 -0000

--On Tuesday, October 11, 2022 16:48 -0400 Ted Lemon
<> wrote:

> Generally speaking we do a document update after a last call
> to address all comments, either by correcting the problem
> identified in the comment, or by pointing out why the problem
> is not applicable. Nobody is asking you to "support" the last
> call. The point of the last call is not for you to support
> it—it's for you to raise substantive objections, which I
> believe you have done. So I don't think you need to do
> anything more here—the only sense in which it matters
> whether you express support for this action or not is that it
> might make the IESG feel like they haven't gone beyond the
> pale. The IETF rather famously does not vote. So what we
> should hope for is that the IESG follows the consensus process
> properly, and that the input you have given them results in a
> post-last-call clarification.
> But you know all this. :)

Indeed I do.  But, mapped into the above way of looking at
things (which I consider entirely reasonable), the Last Call
request from the IETF asked for feedback on the proposed action
(not quite, as you suggest above, a document to be updated).
In particular, quoting without much context from the IETF
Chair's Last Call announcement, 

	'...plans to make a decision in the next few weeks, and
	solicits final comments on this action'


	'Comments should be limited to the criteria described in
	BCP 83, notably on whether the individual in question
	has engaged in postings that are "unprofessional
	commentary, regardless of the general subject" in a
	manner disruptive enough to warrant this action.'

Now, I (and I believe others) have suggested that we support the
action (an instance of a "final comment") but that we have deep
misgivings about some of the reasons and reasoning in the Last
Call announcement, particularly as they relate to BCP 83 and its
intent (another part of that "final comment").  I have tried to
avoid getting drawn into the discussion of whether it is
appropriate to apply today's standards for professional conduct
--including both very narrow and very broad interpretations of
what those standards are-- to an almost 19-year-old document
that used the term "unprofessional commentary" (presumably as
the term was understood then), partially because others have
explored those issues extensively.  

However, again because there is no document of the variety you
refer to above, I think it is entirely reasonable to ask the
IESG how they intend to handle the commentary.   One possible
answer is that they will simply count up comments that can
reasonably be interpreted as "do it" and ones can can, equally
reasonably, be interpreted as "don't do it", and then, if the
rough consensus favors the former, put out some sort of action
notice that basically reprises the Last Call announcement,
disregarding all comments that did not conform to a narrow
interpretation of the "should be limited" request above (or
queuing those comments for a later discussion of BCP 83 itself).
IMO, that answer would be entirely plausible, especially if my
guess that at least some IESG members would prefer to be
spending (or consider it more important to spend) their time in
other ways is correct.  

Or they could decide their responsibility includes doing a
careful, post-Last-Call, rewrite of the statement of
justification, treating it more like a document as you suggest
above, and possibly even getting a quick community review of the
revised version (a variation of the debates a few months ago
about how much it is appropriate to do in AUTH48 versus going
back to WGs and/or LC probably applies to that process).  

If they intend the first, then my position is that the path by
which we have gotten here is sufficiently flawed that Dan should
asked once again to cut back on the behavior the community finds
obnoxious and disruptive, warned that the next invocation of BCP
83 (if needed) will almost certainly be more definitive, but
otherwise let off the hook this time.  If the second, I'm happy
about that more nuanced approach.  So, IMO, the question is
reasonable and should be answered precisely because this is not
normal document processing.

Speaking only for myself, I'd care far less about this (and
would have tuned the discussion out) if we were processing BCP
83 PR-actions more frequently, perhaps a couple of times a year.
Fortunately, the vast majority of participants in the IETF are
either sufficiently well-behaved or respond well enough to
counseling and advice that many ADs have served out their terms
without having to deal with one.   The bad news is that means
that each one sets precedents, including precedents about how
the language of RFC 3683 is interpreted, that will likely be
looked to for guidance the next time around.  And that, at least
IMO, means that we need to be very clear, not just about what
actions we are taking but about why we are taking them.