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

[Lars Eggert <[e-mail]>]

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