Wijnen, Bert (Bert) <bwijnen(_at_)lucent(_dot_)com> wrote:
I certainly hope that we do not have to have the equivalent of an
"IETF Last Call" everytime that a WG chair or AD finds that an individual
is disrupting normal WG process.
RFC 3683 (BCP 83) is concise enough to quote the applicable part in
its entirety:
]
] A PR-action identifies one or more individuals, citing messages
] posted by those individuals to an IETF mailing list, that appear to
] be abusive of the consensus-driven process. If approved by the IESG,
] then:
]
] o those identified on the PR-action have their posting rights to
] that IETF mailing list removed; and,
]
] o maintainers of any IETF mailing list may, at their discretion,
] also remove posting rights to that IETF mailing list.
]
] Once taken, this action remains in force until explicitly nullified
] and SHOULD remain in force for at least one year.
]
] One year after the PR-action is approved, a new PR-action MAY be
] introduced which restores the posting rights for that individual.
] The IESG SHOULD consider the frequency of nullifying requests when
] evaluating a new PR-action. If the posting rights are restored the
] individual is responsible for contacting the owners of the mailing
] lists to have them restored.
]
] Regardless of whether the PR-action revokes or restores posting
] rights, the IESG follows the same algorithm as with its other
] actions:
]
] 1. it is introduced by an IESG Area Director (AD), who, prior to
] doing so, may choose to inform the interested parties;
]
] 2. it is published as an IESG last call on the IETF general
] discussion list;
]
] 3. it is discussed by the community;
]
] 4. it is discussed by the IESG; and, finally,
]
] 5. using the usual consensus-based process, it is decided upon by
] the IESG.
]
] Of course, as with all IESG actions, the appeals process outlined in
] [4] may be invoked to contest a PR-action approved by the IESG.
]
] 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; accordingly it
] should be possible to restrict the new email address.
A "PR-action" under BC 83 is intended to be permanent. I certainly
hope we _do_ have an IETF Last Call every time a WGC feels the "need"
to _permanently_ revoke posting rights.
RFC2418 allows a WG chair and the ADs to also take measures if someone
is disrupting WG progress (sect 3.2).
]
] As with face-to-face sessions occasionally one or more individuals
] may engage in behavior on a mailing list which disrupts the WG's
] progress. In these cases the Chair should attempt to discourage the
] behavior by communication directly with the offending individual
] rather than on the open mailing list. If the behavior persists then
] the Chair must involve the Area Director in the issue. As a last
] resort and after explicit warnings, the Area Director, with the
] approval of the IESG, may request that the mailing list maintainer
] block the ability of the offending individual to post to the mailing
] list.
This looks similar, but it does not require the one-year minimum,
nor does it require a LastCall.
Furthermore, this _has_been_done_ for Dean Anderson on dnsops.
From the IESG minutes of 13 May 2004:
]
] 7.2 Approval to block participant on a WG list (Bert Wijnen)
]
] This management issue was discussed. The IESG agrees that Bert
] Wijnen may block posting rights for Dean Anderson on the dnsops
] mailing list if he refuses to stay on topic as per the list rules.
which raises the question, "Why are we even discussing this?"
--
John Leslie <john(_at_)jlc(_dot_)net>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf