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

Keith Moore <> Mon, 27 September 2021 19:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D6783A163D for <>; Mon, 27 Sep 2021 12:32:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j_gEa9vJUbzn for <>; Mon, 27 Sep 2021 12:32:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3E5D83A163F for <>; Mon, 27 Sep 2021 12:32:12 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 4DB5B3201061 for <>; Mon, 27 Sep 2021 15:32:11 -0400 (EDT)
Received: from mailfrontend1 ([]) by compute1.internal (MEProxy); Mon, 27 Sep 2021 15:32:11 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=QNzlHaRr9uxCMTR+d+AaTEr74FFD8XNjxI0bZkdsC 7A=; b=VSETkZ34ztM61wBw8sUPrzzIfN0T80CbX3Wb3dNTbLcOJWKoJfXN1GOGj KF3tnE/bkPOZteGeYQVDbiYfqRdTPxT+J9GNtUT1XsfW2C0g/DY3WvwKLDXzeAh5 tGyVk4QQgldHrlpRLUGib0E6SOjKT8OM3Iq+Pq/C+LklpgDXkWrUbR1tEyRpWYL5 QHs+/LyZCWpRu0+bKa4ax5apX/fpuM80OnRLNtl1rNIS+m8lKtgA9KbqO3Bk6dEx n5Pl9J/V+K3QG2JNJNsdSMTCbqpbEJ3NI3FdxMAsR0nXxBLjIKKQMKg9lIBh2nGd 5N1w+Q6f2EdkoHXUrGdIQcZEUQ00A==
X-ME-Sender: <xms:OhxSYXWhAIOu9saWW10KaW86jxTKyxjdYFSXAMzgUCEgti7MngizMg> <xme:OhxSYfn4Je63ra0wXG2YkMK2Zqfc_J9z4tvfTZWSZz1ojQQQlF9TwfxjM1eVEAkQc xNaWpwrLOkq5A>
X-ME-Received: <xmr:OhxSYTYQx-4DdAqUWyheI4Yp_tlXUyy2M_YR-qk_UN53yJ48jggeU88nD5wBHpJnfEtf3vJlJrfNrXnJcZ5VqS18R6aUAre01fiHIzYvQA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudejkedgudefiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesth ekredttdefheenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvght fihorhhkqdhhvghrvghtihgtshdrtghomheqnecuggftrfgrthhtvghrnhepheduhfelud egueetveevhfeujeejfefffeettedtvdelfefgkeeikeehjeffvdffnecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhoohhrvgesnhgvthifoh hrkhdqhhgvrhgvthhitghsrdgtohhm
X-ME-Proxy: <xmx:OhxSYSXX_Y2IYcwaHJkwyrxlASf0_Nr1Gopdik35-8Sv7Jdy6X1E2g> <xmx:OhxSYRmdvywKNjwG0j1fOKA5zObgis8nk3mPN1oAQbf_dSkdM_bSog> <xmx:OhxSYff1rDZaUzeRlYuJ1uImI1fe24_FL75muQy212be5zUPEVS9Dw> <xmx:OhxSYdzlldSVOdjAtja3LgX9i0cxKREnOQBB_XFfRAwVrekysyJiiA>
Received: by (Postfix) with ESMTPA for <>; Mon, 27 Sep 2021 15:32:10 -0400 (EDT)
References: <> <> <> <>
From: Keith Moore <>
Message-ID: <>
Date: Mon, 27 Sep 2021 15:32:09 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
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: Mon, 27 Sep 2021 19:32:22 -0000

On 9/27/21 2:56 AM, Lars Eggert wrote:
> Hi,
> On 2021-9-25, at 4:47, Keith Moore <> 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 think I see your point, but I'm not entirely sure that the current 
draft is an improvement even in that aspect.   If the IETF Chair 
directly restricts someone's posting privileges, at least the Chair is 
visibly taking responsibility for that action.   If the Chair instead 
directs the SAAs to restrict someone else's posting privileges, it can 
hide the Chair's action.

I'm not aware of any case in the past in which this has actually 
occurred, but the lack of a requirement for transparency is somewhat 
troubling regardless of the mechanism.

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

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.   I can guess, for 
example, that you'd rather not have IETF rathole on a discussion of 
exactly what "professional" means.   I could understand such a 
reluctance, but to me it seems clear that the ambiguity has caused 
problems in the past, and allowed people's input to be suppressed for 
dubious reasons.

The problem I have with making it a separate work item is that doing 
that can be an effective way of making sure that such a discussion never 

At any rate I don't think the current proposal qualifies as a "best 
current practice".

IETF was a very different organization when RFC3005 was written. My 
recollection is that dealing with input from disagreeing, sometimes 
strident, and/or eccentric individuals, though it was sometimes annoying 
to some, was accepted at that time as a necessary condition of the 
openness required for consensus building in IETF.    As such, RFC3005 
seems to have been written with the expectation of general comity among 
most IETF participants, as well as a common sense of purpose which sadly 
no longer seems to exist.

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.