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

Lars Eggert <lars@eggert.org> Mon, 27 September 2021 06:56 UTC

Return-Path: <lars@eggert.org>
X-Original-To: gendispatch@ietfa.amsl.com
Delivered-To: gendispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49AB23A13D1 for <gendispatch@ietfa.amsl.com>; Sun, 26 Sep 2021 23:56:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stOY8v6kv3lo for <gendispatch@ietfa.amsl.com>; Sun, 26 Sep 2021 23:56:37 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA9283A13D0 for <gendispatch@ietf.org>; Sun, 26 Sep 2021 23:56:36 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:8959:e4c7:e08f:2df3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 2BD7B6003D5; Mon, 27 Sep 2021 09:56:22 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1632725783; bh=q/OyPGJ+LaFjbfFMkNRFMhW2k4u10YZ562svkl9ckQo=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=tI47BiTO3cCD45kuf4j1zS68e1JhbhyM+utkeafqxyzDT7RXKo7prYfjQlhPIyJu4 xZhDzWzxb4VKrtm2nssepe8JNWWscWsvtDO6cL5Lk4giW6D8gGDY326Sr/RzBxEqN2 ABxU2MOsT71LctzX7HAAxbZkaXPqOtzZCpTz/Cz4=
From: Lars Eggert <lars@eggert.org>
Message-Id: <BC2BE36D-1355-4A96-85EB-41728D207346@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_16E946F5-BD60-470B-8F4B-5D56BF51DB06"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Mon, 27 Sep 2021 09:56:20 +0300
In-Reply-To: <aa82c517-2117-e31a-8ce6-27336634e5db@network-heretics.com>
Cc: gendispatch@ietf.org
To: Keith Moore <moore@network-heretics.com>
References: <DM4PR11MB543899B05B3BD7AD92459B3FB5DB9@DM4PR11MB5438.namprd11.prod.outlook.com> <A1F6409C-97AA-42A9-AAFD-C1AED39559E9@yahoo.co.uk> <aa82c517-2117-e31a-8ce6-27336634e5db@network-heretics.com>
X-MailScanner-ID: 2BD7B6003D5.A3842
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/gendispatch/lp4oKPwYHE19YQBXytjQDLn9oR0>
Subject: Re: [Gendispatch] New Version Notification - draft-eggert-bcp45bis-04.txt
X-BeenThere: gendispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: General Area Dispatch <gendispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gendispatch>, <mailto:gendispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gendispatch/>
List-Post: <mailto:gendispatch@ietf.org>
List-Help: <mailto:gendispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gendispatch>, <mailto:gendispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Sep 2021 06:56:43 -0000

Hi,

On 2021-9-25, at 4:47, Keith Moore <moore@network-heretics.com> wrote:
> 1.  From experience with several "moderation" events over the past few years, I believe the power to appoint SAAs (and by inference, to direct the SAAs) has been misused by IETF Chairs in the past on multiple occasions, such as to suppress useful input that the Chair at the time did not like.

under BCP45, the IETF Chair can directly restrict posting privileges of individuals or on a thread, without involving the SAA team or relying on their ability to appoint SAAs. You will find that BCP45bis removes this ability, because practice for a number of yers has been to let the SAAs operate independently.

>  I therefore believe that the IETF Chair should no longer be appointing or directing the SAA of the IETF list.   I believe that the SAAs should act as independent, generally neutral moderators whose decisions can be overridden by IAB, and that the SAAs should instead be appointed by the nomcom or perhaps the IAB Chair.

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.

> Separating the SAA function from IESG entirely would leave IESG freer to concentrate on providing technical direction and evaluating technical work.

Under BCP45 and BCP45bis, the IESG is not involved in the appointment or operation of the SAAs. This is - and AFIK has been - always handled by the IETF Chair.

> 2. The use of the term "unprofessional" remains problematic,

The term "unprofessional" appears once in BCP45bis, in a bullet item that is directly taken from BCP45.

> But I think it would better to not use the term at all, and instead of trying to exclude "negative" contributions, define positive criteria for what makes a constructive contribution to the discussion.

BCP45 chose to do both, i.e., describe which topics are appropriate and give examples of which are considered inappropriate. BCP45 retains that structure.

Thanks,
Lars