Re: [Last-Call] Question for the IESG

Ted Lemon <mellon@fugue.com> Tue, 11 October 2022 20:49 UTC

Return-Path: <mellon@fugue.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 53069C1522A3 for <last-call@ietfa.amsl.com>; Tue, 11 Oct 2022 13:49:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 (2048-bit key) header.d=fugue-com.20210112.gappssmtp.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 YJwRnL13A0U8 for <last-call@ietfa.amsl.com>; Tue, 11 Oct 2022 13:49:25 -0700 (PDT)
Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 1160DC14CE35 for <last-call@ietf.org>; Tue, 11 Oct 2022 13:49:24 -0700 (PDT)
Received: by mail-yb1-xb2b.google.com with SMTP id r3so3168643yba.5 for <last-call@ietf.org>; Tue, 11 Oct 2022 13:49:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RqAqM8weoJPsKoSVFy6dB55U2wDndhH8bYjP9i9ZxM4=; b=nSIF7hfmC0jKiRhkCoI/0O6tDQUhuRfro9yEdjF1MYvvHJlK6B1uIM6fn5iNNk/YXB a5O6BMkDpiw3DS+QOvB9/ap1l4CngiAocOEfqnVKblp3CZSTszbAEO9qgzxSIGtW0AIf G+A68eIaIM0q0rec8fuf98+nFUfNrOtZbVO4U8RIrF2g/lPBUHRFqM+CocgHNewB7NrH 7pv5WdCZy+YDOmvbm8GPaRToC29CqQ3IrBmE01a/ivBAxRleeWtOl/GewsbgcVv9UjV1 mqcEWT1Dkz8RrQXxyNf9hKpHO9O9+3SVy9NIGuhQWJ71Ob+dPV3Aqali/sKQJUm3MIHz GqAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=RqAqM8weoJPsKoSVFy6dB55U2wDndhH8bYjP9i9ZxM4=; b=ONZZ7+H5P9vS+w4Z28EU6J5j0K+JWLmG4XzDCLbe5BfCuEG/rdmyPdq4QcIzPDFgNy 6eVMAYRhgLiSxz8f/4pRbeQnnVR9rRyGQ4xglCBBfNRSjP7Si6TqoRjKLDACe2onzcUT 9JjGbOLEqPkiSdbO08ddBiIvGlS00yMDqaNi6a0JfA9yXYjbzr38s06Nwqp0dXFoUjDl xHjY3ynim9SVW68fH0Gwls3FgQ/ax0ORYLkvLCOMEDFTucTQTh8/QHJnaBHVdGSJYTwz czJgC3MAHCkerUJ+xo1vaIA5JffzgFgGgbD8KpyN1EJb1ZJoj/LZUfLkeH66aU7OAZGb jacg==
X-Gm-Message-State: ACrzQf1lN7PqhaSy7W5X5iijtEEvtwPPir9Q5puBrgABE49sLTjGeA/l ZhwKux1bdBvRbYrYfA+30i5FFMr/aCjvJ1ygVSRRdelv/vitOQ==
X-Google-Smtp-Source: AMsMyM5GoAeH3f3rhht+FR1qBFSRlTrmBbCcKkJFVPR8SwGgu+uETKzJ6SB8gWDS/p93nvHnUt5lORTzrsngrhK0zhc=
X-Received: by 2002:a25:7b06:0:b0:6a9:5f43:bd62 with SMTP id w6-20020a257b06000000b006a95f43bd62mr25728160ybc.357.1665521363847; Tue, 11 Oct 2022 13:49:23 -0700 (PDT)
MIME-Version: 1.0
References: <CFE25E25-D131-468E-9923-80350D6216F3@ietf.org> <33dcb391-6304-2a04-0041-ae8a0d9ee107@lounge.org> <118166719.778795.1665054336024@email.ionos.com> <CABcZeBOebDewrhpbntMHWLuF5iNd9WWUwKSTams-zbxEhtYe=w@mail.gmail.com> <1590543408.1336232.1665076691164@email.ionos.com> <E07D908383FCC3EF63B6E49F@PSB> <6.2.5.6.2.20221011054550.0d95bee0@elandnews.com> <F7D30295F215065F0FB845C4@PSB>
In-Reply-To: <F7D30295F215065F0FB845C4@PSB>
From: Ted Lemon <mellon@fugue.com>
Date: Tue, 11 Oct 2022 16:48:48 -0400
Message-ID: <CAPt1N1kG=jdP39zg1sn+D6UmcMRG1BWodx8dOFW0xc1Q1xbDUg@mail.gmail.com>
To: John C Klensin <john-ietf@jck.com>
Cc: S Moonesamy <sm+ietf@elandsys.com>, last-call@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004220f405eac86906"
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/R7wuUqP2o_TjBEeTpHoVuSIXMd4>
Subject: Re: [Last-Call] Question for the IESG
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: Tue, 11 Oct 2022 20:49:26 -0000

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. :)

On Tue, Oct 11, 2022 at 12:52 PM John C Klensin <john-ietf@jck.com> wrote:

>
>
> --On Tuesday, October 11, 2022 07:54 -0700 S Moonesamy
> <sm+ietf@elandsys.com> wrote:
>
> > Hi John,
> > At 03:02 PM 06-10-2022, John C Klensin wrote:
> >> I am asking because, while I think parts of it have been very
> >> helpful and should be considered going forward, I am probably
> >> at least as sick of the scale and tone of some of the
> >> discussion as I infer at least some IESG members are. I also
> >> agree with those who have suggested that parts of the
> >> discussion itself have been at least as unpleasant, divisive,
> >> and disruptive than anything Dan (or anyone else, at least
> >> anyone not in the leadership) could manage on their own.
> >> I'm trying to lay the foundation for a way forward that is
> >> more closely focused on the rather specific criteria that I
> >> understand (and have understood since 2003-2004) BCP 83 to be
> >> about.  Or, to put it differently to allow asking if a
> >> PR-action against [removed] is the right decision whether or
> >> not the IESG wrote the optimal description of why action
> >> should be taken and why.
> >...
> > I have read the various comments on the thread.  The topics
> > are, to put it mildly, quite controversial.
> >
> > I looked up the definition of the word "censorship".  The
> > American Library Association defines the "censorship" as "the
> > suppression of ideas and information that some individuals,
> > groups, or government officials find objectionable or
> > dangerous".  It is the first time, if I am not mistaken, that
> > a draft was removed from the I-D public repository.  The
> > removal is not compliant with BCP 83.
> >
> > BCP 83 is not listed in the "Note Well".  That does not negate
> > the fact that it is part of the IETF statute book.  The
> > criteria set in 2004 in that BCP is open to interpretation.
> > There is a barrier to prevent misuse; the BCP requires an Area
> > Director to make a judgement call.  The BCP includes an avenue
> > to anyone who wants to contest the "PR-action", i.e. the
> > appeals process.
> >
> > BCP 83 lists the following case: a participant has engaged in
> > what amounts to a "denial-of-service" attack to disrupt the
> > consensus-driven process.  That is different from some of the
> > points raised in the sub-threads (on this mailing list).
>
> Your analysis above, some of the text in BCP 83, and memories of
> the discussion when RFC 3683 was adopted and published, are why
> I have been trying to focus on disruptive effects and level and
> duration of disruption rather than language used, hurt feelings,
> or perceived incorrect or antisocial attitudes of the
> participant/offender.  That does not make any of those other
> types of issues less significant or harmful, it just suggests
> that BCP 83, as it now stands, may be a mismatch to the problems
> as described in the IESG statement and other comments and hence
> not the appropriate instrument.  It may also be that some of the
> point you consider different (fwiw, I probably agree) are
> symptoms of that mismatch.
>
> > I am a bit curious about whether you will receive a reply to
> > the question.
>
> Assuming you mean a reply from the IESG (as distinct from
> comments by others), as am I.
>
> I hope I am wrong.  However, as we move into the last week of
> the Last Call window, I am beginning to assume that I will not
> receive one before that window closes.  That would leave those
> of us who support a PR-action but not some or all of the
> justification in the IESG announcement for applying BCP 83 in
> the difficult position of having to decide whether formally
> withdrawing our support move would be effective enough to be
> appropriate.  Especially if we do not do so, it would also leave
> the IESG in the awkward position of having to interpret rather
> ambiguous input and leave them even more open to an accusation
> that has, I believe, been made several times already, i.e., that
> they have already made up their minds and that this action will
> go through either independent of the Last Call comments or
> unless there is very large scale and completely unambiguous
> opposition to it.
>
> >From my perspective, that is not a happy situation for the IESG,
> the community, or even for Dan (not that the purpose of this
> effort is to make him happy at this point).
>
> best,
>    john
>
> --
> last-call mailing list
> last-call@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call
>