> > Wijnen, Bert (Bert) <bwijnen@xxxxxxxxxx> 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@xxxxxxx> > John- Could you please specify the RFC that details the procedure for when an AD requests that the IESG remove someone's posting privileges from the IETF list (the RFC other 3683 of course). If there isn't one then I'd have to ask that you refrain from making wildly unsupported claims as they are disruptive to the process. Thanks, Nick _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf