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>
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf