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

Barry Leiba <barryleiba@computer.org> Wed, 20 October 2021 13:13 UTC

Return-Path: <barryleiba@gmail.com>
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 77EA43A0865; Wed, 20 Oct 2021 06:13:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level:
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 oi2cNJY_SQQh; Wed, 20 Oct 2021 06:13:53 -0700 (PDT)
Received: from mail-vk1-f175.google.com (mail-vk1-f175.google.com [209.85.221.175]) (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 36D393A0857; Wed, 20 Oct 2021 06:13:53 -0700 (PDT)
Received: by mail-vk1-f175.google.com with SMTP id o42so12031235vkf.9; Wed, 20 Oct 2021 06:13:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=IRAJc7BwF2bvKYcDifaFbrMNxBcizC8ZuwNQCD50quA=; b=D1aO6x5+EFgJXlw/HTUOLK8KPEnFLUSFag0ACTPeeQxXdooUZrMI75Kyf/hpybuXLw UgSYT5xyGy+Nh0399Ol8c+jcn06+sbuFnJyFW7c1j0MKXbwqJg0Jav2BS7RfxKBWAt98 ZRJcyGaX5TQNhqKw5G62RM8EAuHFm1MggsSzhfSAwHMiKHNClSyq+e6en5yPnG3jathc 6AfwDOssM7K21OGCZWKBKFomWLi5IGTXpX/YsV8Mk4/UNeuGlAJPdLFFYx4Ulf9Llmkr VPXvtfCIYroPBFLxqRqBDdR2WeUnCaJ8uLVHS2+fTxu1Frclc6xrMXLFxV80VKMKHuY+ XrSA==
X-Gm-Message-State: AOAM530Hc86MxY53t7osjcf/RwdV6hEsM8j4D6idj2g/y8udh6nvHt22 xYJzeX9mGOc05y3yIQaU+IrqE0afZlYfog+TrOxVkKr6g9wpxA==
X-Google-Smtp-Source: ABdhPJxkU3+WA1vmGf+vxuiO3kNmBMBo/VeBuqHRlLdRxluBvNUnHy+ri7CYWAhBEVZ9s8mcY95JM7iyLUYkF7ZHuSY=
X-Received: by 2002:a1f:324d:: with SMTP id y74mr38719549vky.20.1634735630811; Wed, 20 Oct 2021 06:13:50 -0700 (PDT)
MIME-Version: 1.0
References: <163465875866.13316.15860075014903480611@ietfa.amsl.com> <EA85619D-83D6-409B-AAE7-C13850B18BA0@yahoo.co.uk>
In-Reply-To: <EA85619D-83D6-409B-AAE7-C13850B18BA0@yahoo.co.uk>
From: Barry Leiba <barryleiba@computer.org>
Date: Wed, 20 Oct 2021 09:13:39 -0400
Message-ID: <CALaySJKeHDr7EJy4hf5GyS9W0PwpQ0C05TGtS4Gc_ihEFeQtsA@mail.gmail.com>
To: last-call@ietf.org
Cc: The IESG <iesg@ietf.org>, GENDISPATCH List <gendispatch@ietf.org>, draft-eggert-bcp45bis@ietf.org, IETF Discussion <ietf@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/gendispatch/BiUwPjPYGc4KJaIRSTP2EsVQ6Cs>
Subject: Re: [Gendispatch] Last Call: <draft-eggert-bcp45bis-06.txt> (IETF Discussion List Charter) to Best Current Practice
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: Wed, 20 Oct 2021 13:13:58 -0000

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

I have looked at it closely, and I do NOT share the concerns raised
here.  I think the draft is a reasonable update to BCP 45, that it
clarifies the charter for the IETF list and the SAA team's role, and
that anything more than this would need a fresh effort by the
community to make a more significant update -- which I don't think is
needed.

I think there is no contradiction between the use of Wikipedia to
explain the general role of Sergeants at Arms and the role the SAAs
have with respect to the IETF list.  Wikipedia discusses some
mechanisms for appointment and use of SAAs, but those are not the only
mechanisms.  It's not wrong, and neither is it exhaustive.

The only way we have, at this point, to make community appointments is
through the NomCom, and I think it would be a bad approach to add SAA
positions to the NomCom's slate.

The draft makes it clear that the purpose of the SAA team is to allow
the IETF Chair to appoint people to handle this role, and then to step
back and *not* be a king, to *not* have a day-to-day role in
monitoring and managing the IETF list.  That is as it should be.

I find nothing at all wrong with the IETF Chair being the editor of
this draft: Lars has fairly edited it based on input, and its contents
reflect not Lars's thoughts, but rough consensus of the community so
far.  That not everyone is happy with everything it says shows that we
have *rough consensus*, not unanimity... it does not say that the IETF
Chair has done anything inappropriate here.

This is ready to be published and to update BCP 45.

Barry

On Wed, Oct 20, 2021 at 5:26 AM Lloyd W
<lloyd.wood=40yahoo.co.uk@dmarc.ietf.org> 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. 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?
>
> 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 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.
>
> (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.
>
> I encourage IETF mailing list contributors to look closely at this draft.
>
> Lloyd Wood
> lloyd.wood@yahoo.co.uk
>
> On 20 Oct 2021, at 02:53, The IESG <iesg-secretary@ietf.org> wrote:
>
> 
> The IESG has received a request from an individual submitter to consider the
> following document: - 'IETF Discussion List Charter'
>  <draft-eggert-bcp45bis-06.txt> as Best Current Practice
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> last-call@ietf.org mailing lists by 2021-11-23. Exceptionally, comments may
> be sent to iesg@ietf.org instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
>
> Abstract
>
>
>   The Internet Engineering Task Force (IETF) discussion mailing list
>   furthers the development and specification of Internet technology
>   through the general discussion of topics for which no dedicated
>   mailing lists exists.  As this is the most general IETF mailing list,
>   considerable latitude is allowed, but there are posts and topics that
>   are unsuitable for this mailing list.
>
>   This document obsoletes RFC3005.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-eggert-bcp45bis/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>
> --
> Gendispatch mailing list
> Gendispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/gendispatch
>
> --
> Gendispatch mailing list
> Gendispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/gendispatch