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

Keith Moore <> Sat, 25 September 2021 01:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ABA753A0AB9 for <>; Fri, 24 Sep 2021 18:47:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 UFgxit7-Gehe for <>; Fri, 24 Sep 2021 18:47:06 -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 CD7A93A0AB4 for <>; Fri, 24 Sep 2021 18:47:06 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 5EEF75C00FE for <>; Fri, 24 Sep 2021 21:47:05 -0400 (EDT)
Received: from mailfrontend1 ([]) by compute6.internal (MEProxy); Fri, 24 Sep 2021 21:47:05 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=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=w/z9j2 gxnURdB3AzbSuVISwT3totrpQAzgt7206qemU=; b=XSFLCSq76EiK6Bef2idoGM jzfdriZP1c3btlCMt742MigVBT69Gaeu8OIuJe38X/jNYP+A8EQs2JiiBZ4oGFCm FbWTJ2p0zuik5/7jhHulw7P870sEe+N3EQEgLPJZuD60AowWaCceMIID7ai6euvS 5JohBG9vUEvgRuzCC7c006Gte7nFwekmbs83TAo7vFc7ZiG7/aefEn1k0QQW8EGZ 99ZG88AXZqHZK+m1cG1epZmsr9SmI53DdbfbIr9/COCOiFufmP3qSMNK6NFi45FC 89Plc9ch9txtSCsPLeu4n6YBHqR0UhiYP9JzMrcpKQ6Ehpn0GBGT52B81WpA1BWg ==
X-ME-Sender: <xms:mX9OYdx1NFhYhRECoqgqlJ4144g6Xff34irDqmsZk-J9yGjHJIgBwQ> <xme:mX9OYdTy_2ZoyKU0NgfPlXpOXnBRD1NTRmWH0quG0GWH4AvFXATrImn_9N8yNK38Y KFF1TXxHyzd5w>
X-ME-Received: <xmr:mX9OYXU09XnmvyX-LUPAJJe9RXZUfdxyJq5AYOvJDiExv_bUt_9P4grEtdbuKRJJI_gM-8XEkefaw8t04qjS_ASQagEj5h5UJw8Tif3X5Q>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudejvddghedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgesrgdtre ertdefjeenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvghtfiho rhhkqdhhvghrvghtihgtshdrtghomheqnecuggftrfgrthhtvghrnhepveefteduieegtd elvddvtddufeejjeffvdefteejieeulefgtdfggedtffektedunecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhoohhrvgesnhgvthifohhrkh dqhhgvrhgvthhitghsrdgtohhm
X-ME-Proxy: <xmx:mX9OYfjfR1GV-_f0WmF2cvTwtYEN9mfK3uEDY14xNyVtKY50ojm-0g> <xmx:mX9OYfDwtvM8g_xwZcwXZpW16PnB0i1sB1JXNgmhxDb0J9QL7kh-WA> <xmx:mX9OYYLSgt92HDhWj2k0zvTxMBs72j2A9orHr3PNEtHqP0gWier7Hw> <xmx:mX9OYSNAEy1UKNyruaeISxXdnW2FqtWlB1WZDIeJ9pW3GhxKyx4T1w>
Received: by (Postfix) with ESMTPA for <>; Fri, 24 Sep 2021 21:47:05 -0400 (EDT)
References: <> <>
From: Keith Moore <>
Message-ID: <>
Date: Fri, 24 Sep 2021 21:47:04 -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: multipart/alternative; boundary="------------D5BDEF254312D6EFB00312AF"
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: Sat, 25 Sep 2021 01:47:12 -0000

On 9/17/21 6:31 AM, Lloyd W wrote:

> As a latecomer to this thread, and as someone with rather more recent
> experience of the SAAs than most... section 4 says:
>     A sergeant-at-arms (SAA) is an officer appointed by a deliberative
>     body to keep order during its meetings [SAA-WIKIPEDIA].  SAAs for the
>     IETF discussion list are appointed by the IETF Chair
> The contradiction here is obvious. An SAA is appointed by a 
> deliberative body,
> during its meetings, and the IETF Chair is not a deliberative body. An SAA
> should be appointed by the deliberative body itself, which is to say, 
> the list
> itself, by the list members.
> Furthermore, this draft is written by the current IETF Chair. So, this can
> be seen as shoring up and reaffirming the Chair's power.
> I strongly object to this. Documenting or redocumenting an existing 
> process
> doesn't make that process right, and this violates the basic concept 
> of the
> SAA as described.
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.  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.

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

2. The use of the term "unprofessional" remains problematic, both 
because the term is poorly defined, and because there are a number of 
associations with the word "professional" in employment settings that 
should not apply to the IETF.   For example, "professional" often means 
that you should not disagree with the technical opinions of your 
"superiors", whereas in IETF we should behave as peers on technical 
matters in order to preserve consensus-based decision making that at 
least to some extent helps to minimize decisions being made by major 
industry players without regard to other input.

In practice, being "professional" often means "don't rock the boat", say 
by not contributing ideas that differ from what the corporate or 
community leaders seem to favor

Professional can also mean not calling out abusive practices or 
practices that harm employees or the public.

Professional" can also mean "be conventional" even when the notion of 
"conventional" is arbitrary and specific to or excludes a particular 
culture, region, gender and/or gender role, sexual preference, etc.   It 
can impose expectations on appearance and behavior in ways that do not 
affect the quality of work or job performance, such as by disallowing 
certain hairstyles, styles of dress, etc.

"Professional" can even mean "follow industry conventions" even when 
such conventions lack justification, or are harmful to the industry or 
to ordinary people.

In general what "professional" means is to conform to an unwritten set 
of arbitrary prejudices that "everybody is supposed to know" even though 
(or perhaps because) they're only vaguely defined and rarely, if ever, 
stated.   And for that reason, accusations of being "unprofessional" can 
be and sometimes are used to marginalize or punish anyone who is 
different in any way.

These concerns could be addressed by either (a) not using any derivative 
of the word "professional" as criteria for what's appropriate for the 
IETF list; or (b) specifically defining "professional" in an IETF context.

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.

For the above reasons I strongly recommend against publication of the 
current draft as an RFC.