Re: [Gendispatch] Last Call: <draft-eggert-bcp45bis-06.txt> (IETF Discussion List Charter) to Best Current Practice

Lars Eggert <> Wed, 20 October 2021 12:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 976F03A0654; Wed, 20 Oct 2021 05:36:56 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dy4jfnVD_i3n; Wed, 20 Oct 2021 05:36:49 -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 B5EED3A05E2; Wed, 20 Oct 2021 05:36:48 -0700 (PDT)
Received: from (unknown [IPv6:2a00:ac00:4000:400:9937:ce73:118c:3221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 6C381600C9C; Wed, 20 Oct 2021 15:36:36 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=dkim; t=1634733396; bh=trhUm9vLVobZEFov1aFwNNPc/NARN6vCIdcEHCz5Qz0=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=oT8mR4NQjxX6/l1o7vNDpQI6cqE4YlYGgg3kT68zxsWq31IvBI1OgE8spmNtSmKZr ghy1MvcCi7w/KPgafy1sh2RtbKuUaA+1YMxfxEhssUjYt8833ESDKy0iUjMEbO2rO4 rhunHR5jfrWLWEbWYXTjWvjgyZHEPK2FsFuqkdIs=
From: Lars Eggert <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_131D3CEE-DDCA-4E17-BE94-77D8BDFDC733"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Subject: Re: [Gendispatch] Last Call: <draft-eggert-bcp45bis-06.txt> (IETF Discussion List Charter) to Best Current Practice
Date: Wed, 20 Oct 2021 15:36:33 +0300
In-Reply-To: <>
Cc:, The IESG <>, GENDISPATCH List <>,, IETF Discussion <>
To: Lloyd W <>
References: <> <>
X-MailScanner-ID: 6C381600C9C.A3E1C
X-MailScanner: Found to be clean
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Oct 2021 12:36:57 -0000

Hi Lloyd,

thank you for your feedback.

On 2021-10-20, at 12:25, Lloyd W <> wrote:
>    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 and are
>    empowered to restrict posting by a person, or of a thread, when the
>    content is inappropriate and represents a pattern of abuse
> there's an inherent contradiction in that little quoted snippet, which remains unexplained in the text of this draft despite being raised previously on gendispatch.
> In many bodies, the body itself appoints the SAAs, and that Wikipedia page says as much, at least until someone edits it to say otherwise.
> Here, in a draft being written by the IETF Chair, the very next sentence says that the SAAs are not appointed by the deliberative body itself - which is to say, the mailing list contributors - but by the Chair.

First, I added the link to that Wikipedia page (which was not in the original BCP45), because I received feedback from IETF participants outside of the US/UK geos that the term "sergeant at arms" was unfamiliar. I'd be happy to point to a better definition.

Second, I think we're reading the Wikipedia text differently. I read "appointed by a deliberative body" pretty broadly, including appointments by an elected committee or chair of the body in question.

> Who, by the way, is the person writing this draft describing the Chair's powers. Yes, the Chair is the person doing the necessary work of writing this update draft, but, just maybe, hear me out, since it describes powers of the Chair, the Chair really shouldn't have been tasked with doing it in the first place?

BCP45bis does not grant the IETF chair any additional powers. In fact, it removes some.

I repeatedly asked if the community felt that someone else should hold the pen for this, and most feedback I received seemed to indicate that it was OK for me to do this, given the minor nature of the changes. I'll leave it up to my sponsoring AD to decide if this is a change we should (now) do anyhow.

> This cascading cognitive dissonance remains a bad look, and the draft should at least attempt to explain these points somehow -  historical practice, under further review, we didn't realise how much the SAAs were at the behest of the chairs, the SAAs actually have very little independence, this is just how it is, the SAAs are not appointed by the list, but by the chair who is writing this draft which tightens and tidies and documents previous practice, we can't trust the list to even stay on topic and keep to an undefined level of 'professionalism', so have it appoint its own SAAs? Ha, you must be joking, IETF LLC has a reputation to protect.

I'm sorry this minor update is giving you cascading cognitive dissonance.

You raised two points in this email: (1) that in your opinion the Wikipedia page for SAA is not fully aligned with our SAA selection, and (2) that the IETF chair is authoring this minor update. I hope I gave additional context on both points above.

> I don't know what the explanation will be, but there needs to be one. Just saying 'well, the wikipedia page is not a dictionary and is not normative' would not be enough - and if referencing wikipedia you'd need to give a date/revision, anyway, just as we do for drafts, because wikipedia is eternally drafted.

The Wikipedia page is an informative reference already. I don't think it's common practice to call out in the text that a reference is informative, but I can of course do so if that ends up being the consensus. I will add a retrieval date to the reference, or alternatively cite an snapshot of the page.

> (we reject kings etc. and the chair unfortunately looks here very much like a king issuing executive fiat. but we also reject voting, so we'd have to... hum between candidates?)
> The draft can't skip around this, but imo does have to explicitly address and explain these points in its text, and thus shed some light on the underlying philosophy of list governance which must underpin and support the reasoning given.  Somehow.
> How the draft chooses to do this will imo say a lot about the IETF.

Again, I hope I gave you additional context above. I remain unconvinced that the document itself needs text to capture some of this context, however.

> I encourage IETF mailing list contributors to look closely at this draft.