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

["STARK, BARBARA H" <[e-mail]>]

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

+1
I find the definition of SAA at "https://www.wordnik.com/words/sergeant%20at%20arms"
to be more consistent with IETF usage but don't object to the Wikipedia page being used
to help people understand the origins of the term. Understanding the origins of the term is
a reasonable use of an informative reference. I do not agree with suggestions that "if IETF
wants to use this term and point to the Wikipedia page to help people understand the
term's origins, then IETF must define the role exactly as described on the Wikipedia page".
I also would not agree with a suggestion that "because IETF's definition of the SAA role
does not precisely match the Wikipedia description of the term's origins, IETF must use
a different name for the role".
Neither suggestion makes sense to me.
I also think the proposed updates are fine and don't think it's a problem for Lars to have
written them.
Barbara

> Barry
> 
> On Wed, Oct 20, 2021 at 5:26 AM Lloyd W
> <lloyd.wood=[e-mail]> 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
> > [e-mail]
> >
> > On 20 Oct 2021, at 02:53, The IESG <[e-mail]> 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
> > [e-mail] mailing lists by 2021-11-23. Exceptionally, comments may
> > be sent to [e-mail] 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-eggert-
> bcp45bis/__;!!BhdT!0qhHLkRLBCzfz2_B0zYKcT-
> 87lxnEs7p5XEnW4bhmTHp_R8vdc6fchEhGrNTRw$
> >
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >
> >
> >
> >
> >
> > --
> > Gendispatch mailing list
> > [e-mail]
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/gendispatc
> h__;!!BhdT!0qhHLkRLBCzfz2_B0zYKcT-
> 87lxnEs7p5XEnW4bhmTHp_R8vdc6fchGfidxfJA$
> >
> > --
> > Gendispatch mailing list
> > [e-mail]
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/gendispatc
> h__;!!BhdT!0qhHLkRLBCzfz2_B0zYKcT-
> 87lxnEs7p5XEnW4bhmTHp_R8vdc6fchGfidxfJA$