A Practice for Revoking Posting Rights to IETF Mailing Lists
draft-mrose-ietf-posting-04

[Ballot comment]
Nits (these are in -04)

>    range of stakeholders. {+(For the purposes of this memo, the term "IETF
>    mailing list" refers to any mailing list functioning under IETF
>    auspices, such as the IETF general discussion list,, or a working
>    group or design team mailing list.)+}

s/,,/,/

>    to throttle active denial-of-service attacks againast the

s/againast/against/

[Ballot discuss]
>    Notably, in a small number of cases, a participant has engaged in a
>    "denial-of-service" attack to disrupt the consensus-driven process.

This sentence seems to say something about intent. Better to reword
this to say what the result is, so that motives aren't made an
issue. E.g.,:

    Notably, in a small number of cases, a participant has engaged in
    what amounts to a "denial-of-service" attack that disrupts the
    consensus-driven process.

>  undertake a new type of action, termed a PR-action.
   
"PR" stands for what? Oh. Posting Rights. Please expand on first usage.

>    Once taken, this action remains in force until explicitly nullified
>    and MUST remain in force for at least one year.

I'm fine with the normal period being a year. The point is to take
strong action.  But the above "MUST" also means that the IETF/IESG
can't make it shorter or reverse itself in less time. While I don't
expect this to happen often (ever?). I am not comfortable with the
process not allowing any wiggle room, for extenuating circumstances.

>    Working groups SHOULD ensure that their associated mailing list is
>    manageable. For example, some may try to circumvent the revocation of
>    their posting rights by changing email addresses.

What is the above intended to say? Is there some special action that
needs to be taken to deal with change of addresses?

[Ballot comment]
A small point - in Section 2, would it make sense to define 'any IETF mailing list' (5th paragraph, second unnumbered bullet)? A reader might interpret that very strictly (to mean just lists at ietf.org, say). Obviously it includes WG mailing lists. Does it include IETF-related lists (like e2e)? Mailing lists set up for BoFs that might not become WGs, or design teams? My guess is that this overlaps with the mailing lists covered by the IPR notice:

"any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices"

'auspices' is pretty vague - though it may be good vagueness.

[Ballot comment]
I agree with Ted's comment that the Q&A section should be removed.

I don't understand Russ' comments about removing the word "vote".
Since I am currently filling out a "ballot", it is pretty clear
to me that the IESG "votes".  Is there something wrong with that?

[Ballot discuss]
The 2nd paragraph of section 2 needs to be rewitten to avoid the word "vote."  Similarly, step 5, which appears later in section 2, also needs to be reworded to avoid the word "vote."

  Section 5 should say that this BCP implements a mechanism to squelch active denial of service attacks against the consensus-driven process used by the IETF.

[Ballot comment]
I personally think the FAQ style questions and answers should be dropped as it moves to RFC,
but will go with whatever others think on that point.

[Ballot comment]
I'm recusing myself on this one.
I asked Marshall to write this originally, and shepherded it through the discussions on POISED and the IETF mailing lists.
So I feel I've spoken enough in favour of it, and others should evaluate.