IETF Discussion List Charter
draft-eggert-bcp45bis-08

Thank you for the work on this document.

Many thanks to Carsten Bormann for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/ZnkYEl-9mRWfKXtzHVUu7u92QB0/. Carsten asks for more clarity about text being normative or descriptive. I also share his concern with using references to web pages (and mailing list) which might change in the future, and require a further update of the document, but not sure anything can be done about that.

I'll report Carsten's review below for visibility (note that the last comment has been addressed by v-07).

Francesca

----

Reviewer: Carsten Bormann
Review result: Ready with Issues

* Review for draft-eggert-bcp45bis-06
* Reviewer: Carsten Bormann
* Review result: Ready with Issues

I am the requested ARTART reviewer for this document.

The document adjusts RFC3005 for the present.

It needs to be, and succeeds in being, succinct, with a few places
where a little more clarity would still be desirable.

## Minor

* Introduction, second paragraph

           The IETF Note Well [NOTE-WELL] applies to discussions on the IETF
           discussion list and all other IETF mailing lists, and requires
           conformance with the IETF Guidelines for Conduct [RFC7154] and the
           Anti-Harassment Policy [IETF-AHP], among others.

This is a statement of fact, so it is not clear whether this is a
normative statement.  If it were normative, there would be a need to
point out normative references to web pages are problematic.

* 3.  Moderation, third paragraph

This section introduces the SAA, but doesn't quite make clear whether
it is the normative statement about SAAs, or is more on the
descriptive side (and maybe even should have a reference to a
normative statement published elsewhere).

           Apart from appointing SAAs, the IETF Chair should stay away from the
           day-to-day operation and management of the SAA team.  This has been
           in practice for a while, and the SAA team has independently
           maintained definitions of abuse patterns [SAA-UPC] and operating
           procedures [SAA-SOP] for them.  The SAA team should reach out to the
           IETF Chair for any conflict resolution in a timely manner.

In this paragraph it suddenly becomes clear that SAAs operate as a
team.  This has significant implications for their operation that need
to be expanded upon a little.  E.g., do members of the SAA team vote?
Do they otherwise establish consensus among them before acting?

## Editorial

* Abstract

The abstract probably needs an editorial round:

It might give the impression that ietf@ is a technology list
and does not mention that there is a lot of process discussion and
discussion about the evolution of IETF and its related organizations
on this list.

Specifically, "latitude" is meant with respect to the set of topics,
but that is not explicitly said.

Last sentence of first paragraph of intro needs to be copied to
abstract:

           This document defines the charter for the IETF
           discussion list and explains its scope.

* Introduction

See comments on abstract.

* 3.  Moderation

           [...] SAAs [...] are
           empowered to restrict posting by a person, or of a thread, when [...]

Can't quite parse "posting of a thread".  Is "posting to a thread"
meant?  Is it then OK to open a new thread on the same topic?

* 4.  Security Considerations

           This document does not raise any security issues.

(Any device that can be abused for censorship clearly does.)

* 6.2.  Informative References

There are a number of "n.d." in the references.  The RFC editor will
probably want to delete them.  Are any of these intended to point out
that the reference is to a *live* document (as opposed to a static,
undated document) and therefore should be kept (or expressed otherwise)?

Two nits --

1. "Discussion of IETF administrative policies now take place"

Should be “Discussion… takes place” or “discussions… take place”.

2. I thought you had taken care of this already, but just in case you still need a suggestion:

OLD:
   restrict posting by a person, or of a thread

NEW:
   restrict posting by a person, or to a thread

Presumably we aren’t getting into the prior approval of new threads business, therefore we can’t restrict “posting… of a thread” which implies creation of a new thread. By the way, I am assuming “thread” is well enough understood to not need definition, but that’s open to discussion I guess.

Thank you to Stefan Santesson for the SECDIR review.

** Section 1

   The IETF Note Well [NOTE-WELL] applies to discussions on the IETF
   discussion list and all other IETF mailing lists, and requires
   conformance with the IETF Guidelines for Conduct [RFC7154] and the
   Anti-Harassment Policy [RFC7776], among others.

   This document obsoletes [RFC3005], documenting the use of other
   mailing lists for discussions that used to be in scope for the IETF
   discussion list, referring to applicable policies such as the
   Guidelines for Conduct [RFC7154] and the Anti-Harassment Policy
   [RFC7776], and clarifying moderation procedures.

Why are two references to RFC7154 and RFC7776 needed in back-to-back paragraphs?

** Section 2. Per “… they should be continued at that other venue as soon as this is pointed out”, pointed out by who?  A moderator? Community member?

** Section 3.  
  The moderators are intended to	
  establish a self-moderation function on the community, by the	
  community.

I don’t follow the intent of this text.

** Section 3.  Editorial.  Less colloquial.  s/should stay away from/should refrain from/

** Section 3.
  This has been in practice for a while, and the moderator team has	
  independently maintained definitions of abuse patterns [MOD-UPC] and	
  operating procedures [MOD-SOP] for them.

I’m not sure if “this has been in practice for a while” will age well.  Also, who is the “them”?  Likewise, do we want to assert that the moderator teams operate transparently with a set of operating procedures?  Perhaps:

NEW
The moderator team will independently define, publish, and execute their roles according to a set of documented operating procedures.  See abuse patterns [MOD-UPC] and operating procedures [MOD-SOP].

I have only a small editorial comment. Obviously it is non-blocking...

"Moderators (previously known as the "sergeant-at-arms") for the IETF discussion list are appointed by the IETF Chair and are empowered to restrict posting by a person, or of a thread, ..."
The "restrict posting by a person, or of a thread, ..." reads a little strangely, but I don't have a good suggestion to fix it. My think at my issue is that if you are not in a situation where you are not restricting a person, then it collapses to "restrict posting of a thread, ..." and I don't thing that one restricts posting *of* a thread, rather one restricts posting *to* a  thread, or *continuing* a thread, or something.
Perhaps "restrict posting by a person, or continuing a thread, ..." or "restrict posting by a person, or to a thread, ..." or something. Again, this is just an editorial nit.

Thanks for working on this update. 

I have two comments/observations-

  * I think it would good if the bullet 2 and bullet 3 of the "Appropriate postings to the IETF discussion list include" list to be rewritten with the tone of bullet 4. With the current write up it feels like bullet 2 and bullet 3 says "something is allowed but there are other preferred venues". I think it would good if it says "think about other venues first then post here". This will be more consistent with a allowed "appropriate posting" tone. 

  * Can we define "a self-moderation function" better? People might have different perspective of "a self-moderation function" in the IETF context.

Thank you Lars for refreshing BCP45. I second the shepherd's text: "the document is short and well written". Thank you as well for replacing "sergeant-at-arm" by "moderator", this is more civil ;-)

Minor comments (as usual they can be ignored):

- should the actual email "ietf@ietf.org" be mentioned ?

- section 2, 1st §, "as soon as this is pointed out" should "by whom" be clarified ?

- section 2, in "Announcements of conferences" should IRTF be mentioned ?

Regards

-éric

Section 2

   When no dedicated mailing list exists, it may be preferable to
   request the creation of one [NON-WG-LISTS] and announce the
   availability of the new list on the IETF discussion list and on other
   related lists, such as area lists.

It seems that the other side of the comparison (rather than having the
discussion of that topic on the IETF discussion list) is implicit here.
There may be some benefit from making it explicit, perhaps as:

% When no dedicated mailing list exists for a topic, it may be preferable to
% request the creation of one [NON-WG-LISTS] and announce the
% availability of the new list on the IETF discussion list and on other
% related lists, such as area lists, rather than discussing that topic on
% the IETF discussion list.

   *  Last Call discussions of proposed document actions now take place
      on the IETF Last Calls mailing list [LAST-CALLS].

I assume this has already been extensively discussed and that I have nothing
further to add, but just in case: "document action" is a term of art used in
IESG telechat agendas, referring to documents that are not on the standards
track ("protocol actions", the term that RFC 3005 used, is the term used on
IESG telechat agendas for the standards-track documents).  I believe that we
also use this list for last calls on WG charters, which may or may not
qualify as "document"s; I didn't check if there was previous discussion of
changing this to just "proposed actions".

Section 3

               Because the IESG and IAB are in the appeals chain for
   moderator decisions (see below), the IETF Chair therefore should not
   appoint a moderator who is serving in such a role.  If a moderator is
   selected for the IESG or IAB, they will step down from the moderator
   team.

I note that this gives no guidance on whether the stepping down should occur
"immediately" or not until a replacement has been designated.  Perhaps that
lack of guidance is intentional, but I note that the gap has been quite long
in practice (i.e., more than a year).