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

[Rob Sayre <[e-mail]>]

Also in favor of publishing, but do agree that SAA is a rather pompous term
for “moderator”. That wording doesn’t need to change now, though.

thanks,
Rob

On Fri, Sep 24, 2021 at 7:19 PM Eric Rescorla <[e-mail]> wrote:

> I am in favor of publishing this document. Those who would prefer some
> more global change to the SAA process should instead propose those changes
> in the form of a draft.
>
> -Ekr
>
>
> On Sat, Sep 18, 2021 at 12:25 AM Lars Eggert <[e-mail]> wrote:
>
>> Hi,
>>
>> On 2021-9-17, at 13:31, Lloyd W <lloyd.wood=[e-mail]>
>> 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.
>>
>> I added this quote from Wikipedia, because SAA is a pretty US/UK-centric
>> term, and I received feedback that it is confusing to participants from
>> other regions when they first encounter it.
>>
>> I'd be happy to point to a different explanatory definition. I'd also be
>> happy to remove it again.
>>
>> > An SAA
>> > should be appointed by the deliberative body itself, which is to say,
>> the list
>> > itself, by the list members.
>>
>> Maybe it should, but BCP45 didn't set it up this way and this draft is
>> not intending to change that.
>>
>> > Furthermore, this draft is written by the current IETF Chair. So, this
>> can
>> > be seen as shoring up and reaffirming the Chair's power.
>>
>> If you compare this document to BCP45, you will find that it actually
>> significantly reduces the power of the IETF Chair. First, BCP45 allows for
>> the Chair to directly impose posting restrictions. This hasn't been the
>> practice for quite a number of years, and this document hence removes that
>> option, placing it entirely at the disposition of the SAAs. Second, it
>> clarifies that the appeals process applies here, which BCP45 left somewhat
>> unclear.
>>
>> > 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.
>>
>> If you would like to propose changes to the BCP45 SAA process, please do
>> so. Objecting to this document isn't going to result in such changes,
>> because BCP45 would remain unchanged.
>>
>> Thanks,
>> Lars
>>
>>
>> >
>> > Lloyd Wood
>> > [e-mail]
>> >
>> >> On 15 Sep 2021, at 18:48, Rob Wilton (rwilton) <rwilton=
>> [e-mail]> wrote:
>> >>
>> >> 
>> >> I’ve not seen any further comments on this thread since Saturday.
>> >>
>> >> My interpretation is that Lars and Barry are supportive of this change.
>> >>
>> >> Brian, my interpretation is that Lar’s proposed text is acceptable to
>> you.  Please clarify if this is not the case.
>> >>
>> >> I would like to wait until Friday to see if there are any further
>> comments on Lar’s proposed text.  If there are no strong objections then on
>> Friday I’ll ask Lars to post a -05 with the change and I’ll kick off IETF
>> LC.
>> >>
>> >> Regards,
>> >> Rob
>> >>
>> >>
>> >> From: Brian Carpenter <[e-mail]>
>> >> Sent: 11 September 2021 08:38
>> >> To: Lars Eggert <[e-mail]>
>> >> Cc: Barry Leiba <[e-mail]>; GENDISPATCH List <
>> [e-mail]>; [e-mail]
>> >> Subject: Re: [Gendispatch] New Version Notification -
>> draft-eggert-bcp45bis-04.txt
>> >>
>> >> Hi Lars,
>> >> Since 2026 doesn't mention conflict of interest, that's probably the
>> procedure. Not entirely satisfactory, but we could live with it.
>> >>
>> >> Regards,
>> >>     Brian Carpenter
>> >>     (via tiny screen & keyboard)
>> >>
>> >> On Sat, 11 Sep 2021, 17:37 Lars Eggert, <[e-mail]> wrote:
>> >> Hi Brian,
>> >>
>> >> Is that an option in your reading of 2026? They way I understand it is
>> that if the AD is conflicted, the entire IESG is the next step?
>> >>
>> >> Thanks,
>> >> Lars
>> >>
>> >> --
>> >> Sent from a mobile device; please excuse typos.
>> >>
>> >> > On Sep 10, 2021, at 23:20, Brian E Carpenter <
>> [e-mail]> wrote:
>> >> >
>> >> > On 10-Sep-21 23:01, Barry Leiba wrote:
>> >> >> That works for me, Lars, and thanks.
>> >> >>
>> >> >> I see Brian's point about Gen AD instead of IETF Chair, but I don't
>> >> >> agree with it here, because the SAAs are explicitly appointed by the
>> >> >> IETF Chair, not related to the Gen Area.
>> >> >
>> >> > You're correct. There's still the corner case where the IETF Chair is
>> >> > conflicted - for example, if the message(s) objected to by the SAAs
>> >> > made allegations about the IETF Chair themself. Probably another AD
>> >> > should be the first recourse in that case.
>> >> >
>> >> >   Brian
>> >> >
>> >> >>
>> >> >> Barry
>> >> >>
>> >> >>> On Fri, Sep 10, 2021 at 3:11 AM Lars Eggert <[e-mail]>
>> wrote:
>> >> >>>
>> >> >>> Hi,
>> >> >>>
>> >> >>> I have a proposed change to use the normal RFC2026 appeals process
>> in https://github.com/larseggert/bcp45bis/pull/7/files. This is the
>> current change:
>> >> >>>
>> >> >>> --- a/draft-eggert-bcp45bis.md
>> >> >>> +++ b/draft-eggert-bcp45bis.md
>> >> >>> @@ -192,8 +192,8 @@ manner.
>> >> >>>
>> >> >>> Because an SAA serves at the discretion of the IETF Chair - even
>> if the IETF
>> >> >>> Chair is not otherwise involved in the operation of the SAA team -
>> any SAA
>> >> >>> -decision could be appealed to the IAB. The IAB shall then review
>> the situation
>> >> >>> -and attempt to resolve it in a manner of its own choosing.
>> >> >>> +decision can be appealed to the IETF Chair, per {{!RFC2026}}.
>> Decisions by the
>> >> >>> +IETF Chair can be appealed to the IESG as whole, again per
>> {{!RFC2026}}.
>> >> >>>
>> >> >>> # Security Considerations
>> >> >>>
>> >> >>> Please let me know if this expresses what is desired?
>> >> >>>
>> >> >>> Thanks,
>> >> >>> Lars
>> >> >>>
>> >> >
>> >> > --
>> >> > Gendispatch mailing list
>> >> > [e-mail]
>> >> > https://www.ietf.org/mailman/listinfo/gendispatch
>> >>
>> >> --
>> >> Gendispatch mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/gendispatch
>> > --
>> > Gendispatch mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/gendispatch
>
>
>>
>> --
>> Gendispatch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/gendispatch
>>
> --
> Gendispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gendispatch
>