Subject: [Last-Call] IETF last call review of draft-eggert-bcp45bis-06.txt

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 22 Nov 2021 20:03:56 +0000

Hi,

Thank you all for the comments so far that have been received on BCP45.

I've noted 3 significant comments in the feedback received, and have some concrete proposed changes:

(1) To rename the SAA role to Moderator, whilst keeping the role the same.

To give a specific proposal:

OLD:

   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.  They are
   encouraged to take into account the overall nature of the postings by
   an individual and whether particular postings are an aberration or
   typical.

NEW:

   Moderators (previously known as the sergeant-at-arms, or SAA),
   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.  They are
   encouraged to take into account the overall nature of the postings by
   an individual and whether particular postings are an aberration or
   typical.

// Other references in this draft to SAA would be replaced with "moderators" or "list moderators" as appropriate.  The existing SAA github repository should be renamed to reflect a name change, keeping a forwarding reference for the old SAA github, if possible.  Similarly, a new email alias, perhaps "ietf-list-moderators" would be recreated to replace [email-masked].  [email-masked] would be changed to being an alias for ietf-list-moderators.

Two other RFCs (RFC 4677 and RFC 4633) reference the SAA, but I do not see that they need to be updated if this document keeps a reference to the historic name.

(2) To change unprofessional to uncivil:

OLD:

   Inappropriate postings include:

   *  Advertising and other unsolicited bulk e-mail

   *  Discussion of subjects unrelated to IETF policy, meetings,
      activities, or technical topics

   *  Unprofessional commentary, regardless of the general subject

   *  Announcements of conferences, events, or activities that are not
      sponsored or endorsed by the Internet Society or the IETF.

NEW:

   Inappropriate postings include:

   *  Advertising and other unsolicited bulk e-mail

   *  Discussion of subjects unrelated to IETF policy, meetings,
      activities, or technical topics

   *  Uncivil commentary, regardless of the general subject

   *  Announcements of conferences, events, or activities that are not
      sponsored or endorsed by the Internet Society or the IETF.

// Personally, I didn't really have a problem with unprofessional, but clearly some members of the community feel strongly that that the use of this word sends the wrong message or picks up additional unintended emphasis.  Uncivil seems like a reasonable alternative, and bike shedding on the choice of word here is probably not helpful.

(3) To make the text more explicit that BCP45bis defines the charter that is
used for list moderation.

OLD

   The SAAs are intended to establish a self-moderation function on the
   community, by the community.  The IETF Chair therefore should not
   appoint an SAA who is serving in a NomCom-appointed IETF leadership
   position.  If an SAA is selected for such a position, they will step
   down as SAA.

NEW

  Moderation of the list, including the handling of any appeals, is to be
  guided by the IETF discussion list charter specified in section 2, and the
  related guidance from section 1 that applies to all mailing lists.  The IETF
  list moderators are intended to establish a self-moderation function on
  the community, by the community.  The IETF Chair therefore should not
  appoint a list moderator who is serving in a NomCom-appointed IETF
  leadership position.  If a list moderator is selected for such a position,
  they will step down as a moderator.

Does anyone have any strong opinions on any of these proposed changes?  In particular, is anyone opposed to these changes.

Regards,
Rob

// Shepherding AD

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 22 Nov 2021 20:05:16 +0000

Hi Adrian,

Thanks for the review and feedback.  I think that most of your comments can be dealt with by Lars, but that your first comment is perhaps aimed at me, and please see my separate email that I just sent regarding the SAA term and unprofessional.

Hence inline ...

> -----Original Message-----
> From: last-call <[email-masked]> On Behalf Of Adrian Farrel
> Sent: 30 October 2021 14:04
> To: [email-masked]
> Subject: [Last-Call] IETF last call review of draft-eggert-bcp45bis-06.txt
> 
> Hi,
> 
> I did a quick review of this draft since it is in IETF last call.
> 
> ---
> 
> The shepherd write-up claims reasonable consensus from the interested
> community, but this seems to be based on the discussions on the
> GenDispatch mailing list. Was the consensus of the "interested
> community" actually looked for before this IETF last call?

My reading of the shepherd template was that this is judging the consensus of the community that was discussing the document, i.e., my assumption is that the individuals who are interested in such discussions frequent the GenDispatch mailing list and have had ample time to comment on what is meant to be a small process update document.

Note, my interpretation of this document is that it is trying to update BCP 45 to accurately describe how the ietf@ mailing list currently operates rather than specifying any new behaviour or requirements on participants.

Does that answer your question?

Regards,
Rob

// Shepherding AD

> 
> ---
> 
> I see you have included the pre-November 10, 2008 copyright boilerplate.
> Did you attempt to contact the author of RFC 3005 to ensure that this
> was no longer an issue?
> 
> ---
> 
> Please remove the "Note to Readers" at the top of the document. It no
> longer applies.
> 
> ---
> 
> 2.
> 
>    within the area of any working group, area or other established list.
> 
> This would read better as
> 
>    within the scope of any working group, area, or other established
>    list.
> 
> ---
> 
> 2.
> 
>    When discussions are started on the IETF discussion list for which
>    such venues do exist, they should be continued there as soon as this
>    is pointed out.
> 
> The use of "there" is mildly ambiguous. Try...
> 
>    When discussions are started on the IETF discussion list for which
>    such a venue does exist, they should be continued at that other venue
>    as soon as this is pointed out.
> 
> ---
> 
> 2.
> 
> s/and only announce/and announce/
> 
> ---
> 
> 2.
> 
> I, too, am uneasy about the use of the term "unprofessional commentary".
> 
> I think that you should simply point back at the references you have in
> the second paragraph of Section 1. That gives you wider scope than
> "commentary", and it saves you from the debate about "unprofessional"
> since "professional" is only mentioned one (in passing) in RFC 7154.
> 
> ---
> 
> 3.
> 
> Please remove all mention of "Sergeant at Arms". We are not a quasi
> military organisation, we have no Internet Police, and the list
> moderators do not carry weapons.
> 
> Please rewrite this whole section in terms of "list moderators". This
> looks like a relatively straightforward piece of editing, but since it
> is to the core of the document, I think the draft should be presented
> for further review after the changes.
> 
> (I appreciate that this document is described in the shepherd write-up
> as intended to set out how the list is *currently* managed and to not
> make substantial changes. That may have been the original intention, but
> it is clear from the changes applied since RFC 3005 that the scope has
> gone beyond this. It is, therefore, appropriate to also fix this use of
> inappropriate terminology.)
> 
> ---
> 
> Appendix A
> 
>    The acknowledgements section should be an unnumbered appendix.
> 
> ---
> 
> Appendix B
> 
>    Such an appendix is usually removed prior to publication. Please add
>    a note telling the RPC to do that.
> 
>    However, the changes from 3005 to the final version of this document
>    should be summarised in a section of this document (appendix or main
>    section).
> 
> ---
> 
> You reference [IETF-AHP] as authored by the IETF. I think that should be
> "IESG" as the policy was not a consensus document (for all that we agree
> with it). Your alternative would be to refer to RFC 7776.
> 
> 
> Thanks for the work,
> Adrian
> 
> --
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call