More to the point, the guideline in RFC 3683 is:
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.
Henk is applying the second bullet of the guideline and is, per the
RFC, within his rights in doing so.
With respect to rai-ads@tools and similar lists, I can see it two
ways. I should imagine that Dean could send mail directly to Cull at
his Cisco email address, where only Cisco's and Cullen's filters are
relevant, so there is not an argument that "Dean really needs access
to rai-ads@". But unless Cullen sees an issue with posting to that
list, it also doesn't solve a problem that anyone has (unless Henk has
a problem as administrator). I see the second bullet as addressing the
case where someone is a pain on some list such as the IDN list and
migrates the problem to another list; if he has been banned from one,
the administrator of the second has everything he needs to make that
change. But that doesn't really apply in this case.
So I would ask what problem blocking access to lists at tools.ietf.org
is solving, and if there is none, would argue in favor of a "principle
of least mechanism"; there is no value in making someone go away from
a place that he is not.
My two yen.
On Apr 17, 2009, at 8:32 AM, Samuel Weiler wrote:
On Fri, 17 Apr 2009, Cullen Jennings wrote:
I really don't understand why Dean should be blocked from rai-ads@xxxxxxxxxxxxxx
.
Dean is the subject of a PR Action; Henrik needs no other reason to
apply the blocking and, if there is a reason or triggering event
(which seems likely), he needn't disclose it to Dean or to this list.
In the general case, I also see no harm in the blocking: those
aliases are for convenience, and it's easy to expand them using
public sources. Blocking their use doesn't meaingfully hamper IETF
participation.
-- Sam
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf