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

Lars Eggert <> Thu, 30 September 2021 08:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7612E3A08D8 for <>; Thu, 30 Sep 2021 01:53:04 -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 vCDvKDU-8u6V for <>; Thu, 30 Sep 2021 01:53:00 -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 9EACA3A08D7 for <>; Thu, 30 Sep 2021 01:52:59 -0700 (PDT)
Received: from (unknown [IPv6:2a00:ac00:4000:400:218a:e90a:3666:76e7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id E81E0600070; Thu, 30 Sep 2021 11:52:44 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=dkim; t=1632991965; bh=QFYC5ge/vOA9m8D85HSFICLOoQkPRvBhkmZc020bY0w=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=T1ttr2/Zz2EsbGJR785VBaIash0wEfnNSJGG4WLbIgWQqr7oByg5WJU32X1Q1tq85 4jXjgsM7I/DnNR9lu8p67Nq7qLvJCjmiXINLm2Prw3PvBSXcxT3OFO1WlJm9K5Vs+c uH3Q4oq7ixYR7vcF54p+hPbT+3HK7KuVngSJZ0V0=
From: Lars Eggert <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_52A6F118-B2C4-47F5-A052-76F814E5ADAA"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Thu, 30 Sep 2021 11:52:40 +0300
In-Reply-To: <>
To: Brian E Carpenter <>
References: <> <> <> <> <> <> <> <>
X-MailScanner-ID: E81E0600070.A20C6
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: Thu, 30 Sep 2021 08:53:05 -0000


On 2021-9-30, at 0:52, Brian E Carpenter <> wrote:
> 1) The current BCP45 states "It also hosts discussions of IETF direction, policy, meetings, and procedures." That has been deleted in the draft, which leaves a gap.

Most of those topics moved to admin-discuss and the meeting attendees lists. Others are in scope for gendispatch (although I am unsure whether a possibly ephemeral WG should be explicitly named in the BCP).

> I think that the list of appropriate postings should include something like:
> * Discussions of IETF direction, policy, and the standards process in general.
> (and perhaps mention that drafts in this area go to GENDISPATCH.)

I think this may be a little too broad. How about:

* Discussions of IETF direction, policy, and the standards process
  in general, when a more suitable list (such as admin-discuss,
  architecture-discuss, a meeting attendees list, or a
  process-oriented WG list) cannot be identified.

> 2) I suggest an extra sentence just after this:
>> These topics used to be in scope for the IETF discussion list, but have since moved to dedicated lists:
>> * Last Call discussions of proposed protocol actions now take place on the IETF Last Calls mailing list [LAST-CALLS].
>> * Discussion of IETF administrative policies now take place on the discussion list for IETF LLC administrative issues [ADMIN-DISCUSS].
> Add:
> However, if the discussion is broader than the specific protocol concerned, or than administration as such, it may revert to the IETF discussion list, preferably with an appropriate change of the Subject header.
> [For example, if the Last Call discussion identifies a completely separate technical requirement, or if the admin discussion identifies a problem with the standards process.]

I agree that should be possible. Do you think that with the proposed change above, this would still need to be explicitly called out again?