Re: [Gendispatch] New Version Notification - draft-eggert-bcp45bis-04.txt

Lars Eggert <> Tue, 28 September 2021 06:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6CFEF3A208D for <>; Mon, 27 Sep 2021 23:54:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GAFxpcl5Ftg9 for <>; Mon, 27 Sep 2021 23:54:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EDEAB3A206B for <>; Mon, 27 Sep 2021 23:54:16 -0700 (PDT)
Received: from (unknown [IPv6:2a00:ac00:4000:400:25d9:bb26:1bfe:2ffc]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id D8D686003D5; Tue, 28 Sep 2021 09:54:08 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=dkim; t=1632812048; bh=lQ+O9kJxG93hpBa1XtzavZmeCd8+YbOCKBQzN4l9dls=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=u9V0dFeuCD+DecxNZF5cEBg+47XlWOtqFk/5kHdnTAAtHOgpNNN1UZ2/0ITSoXqeS 78KqX+6QdLty+dxkq3NdXnYVESw4wTqZMW2vkUNyI1rEcT5nWh2ZhxzEuaxWcyW821 nEuX6/zwgROkfYD/6Hks+vTbJJR7JdnBmyP5KbjA=
From: Lars Eggert <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_1A4DF75E-9B21-429F-83E9-988CBA0E2B93"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Tue, 28 Sep 2021 09:54:08 +0300
In-Reply-To: <>
To: Keith Moore <>
References: <> <> <> <> <>
X-MailScanner-ID: D8D686003D5.A1712
X-MailScanner: Found to be clean
Archived-At: <>
Subject: Re: [Gendispatch] New Version Notification - draft-eggert-bcp45bis-04.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: General Area Dispatch <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Sep 2021 06:54:31 -0000


On 2021-9-27, at 22:32, Keith Moore <> wrote:
>> As has been suggested on this thread, if there is a desire for a more fundamentally respecification of how list moderation on the discussion list operates, this would be better handled as a separate work item.
> I haven't seen a reason given for making it a separate work item, so I can only guess as to why you make that assertion.

let me try and explain.

The only reason I even started a BCP45bis (thinking it would be a quick, non-controversial update...) was that a previous IESG promised to the community this would be done in case the "last-call experiment" was declared a success, to "to formally move the location for last-call discussions". [1]

Besides minor corrections and wording suggestions from various IETF participants, the only other changes of note are:

* to remove the wording about IETF Exec Dir's ability to impose posting restrictions (which RFC8717 already made effective)

* to do the same for the IETF Chair (per current practice)

* to add some material from the SAA team on their self-organization principles

* to clarify that the normal appeals process applies to SAA decisions

None of these changes - in my opinion - go beyond what BCP45 already defined, and I'd therefore characterize them as minor updates.

However, more fundamental changes to this process, suggested by you and others, such as appointing SAAs through the NomCom, making the SAA team the IAB's responsibility, closing the discussion list entirely, etc. would go beyond the scope of BCP45 and the minor update that BCP45bis is intending to be. I would therefore prefer to see them made independently from this minor revision.

I also think someone other than the IETF Chair should be the editor for such a larger revision of the process.

> These days, it seems that suppression of inconvenient input is now much more in fashion, and is even justified as enforcing "professionalism".    So I think BCP45 needs to be updated to fit the current times.

I still disagree with your characterization that any "suppression of inconvenient input" is happening or has happened, and will point out again that BCP45 was already concerned with maintaining a level of professionalism on the discussion list; this is not terminology I added or even changed in BCP45bis.