I want to stress that I'm not making any of the following arguments:
* Dean should be permitted to post to tools.ietf.org addresses--I don't care
* We should not ban people who have PR actions against them from tools.ietf.org
- after consideration, I think banning specific people who have PR actions
against them from posting to tools.ietf.org is fine
* The person running tools.ietf.org should not do something about abuse -
absent any specific policy I think they should exercise good judgment
"Brian" == Brian E Carpenter
<brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com> writes:
Brian> On 2009-04-21 02:44, Dave CROCKER wrote:
>>
Andrew Sullivan wrote:
On Fri, Apr 17, 2009 at 04:18:06PM -0400, Sam Hartman wrote:
My question is whether treating tools.ietf.org aliases as IETF
>> lists
>>>> is reasonable policy.
>>>
>>> In my opinion, it is.
>>
>>
>> +1
Brian> But the question is not whether they are IETF lists. It's
Brian> whether they are official in the sense that IETF
Brian> office-holders (such as WG chairs, ADs and IAB members) are
Brian> obliged to read what is sent to them, in order to exercise
Brian> their duties under our process BCPs.
I think that's one of two questions. I believe that most of the
review directorates assumes that sending mail to *-chairs or
draft-*(_at_)tools(_dot_)ietf(_dot_)org is an entirely appropriate way to send
review
comments. I'd be really incredibly put out if a wg ignored my review
comments because I sent to a tools.ietf.org address rather than the
draft authors. Similarly, I'd be incredibly annoyed if I sent a bof
proposal to int-ads(_at_)tools(_dot_)ietf(_dot_)org and it was bitbucketed
because of
my choice of address.
I have high confidence that
1) Chairs, ADs and draft authors should not treat legitimate mail to
tools.ietf.org differently than mail to the individual email address.
2) Restricting someone's access to tools.ietf.org significantly
impacts their ability to participate in certain ietf processes,
including cross-area reviews, etc. It does not make it impossible;
it requires them to do more work than someone who is not restricted.
3) It is possible to abuse the tools.ietf.org mailing lists. Doing so should
be dealt with.
4) It is possible to abuse an individual's mail address. Doing so should be
dealt with.
5) There are situations where it would be reasonable for an AD, chair,
or author to block mail they were receiving at their individual
address to deal with spam, abuse, etc.
So, in some sense I do think that the tools aliases have some official
status in that they significantly facilitate review within our
processes. I think it would be a big problem if they were unreliable,
if we granted access to them unfairly, etc. I also think it would be
a big problem if they were abused in a manner where people started
discarding legitimate traffic.
I think that our spam-/list policies are a bad fit for the tools
lists. The spam/list policies are designed to provide spam control
and abuse handling for relatively large discussion groups. Having the
archive remain useful is important to our lists, but not to the tools
lists. Similarly, the availability of a public archive allows someone
to see if their postings are making it through.
In contrast each tools alias reaches a fairly small number of people.
Certain network effects--for example the tendency of a flamewar to
break out because of the actions of a small number of recipients are
less likely. For example, I don't think it would make sense to
suspend someone from posting for a few days until they cool down from
the tools aliases although this has often been done with WG lists.
I think that the boundaries for taking action are likely different for
the tools aliases than for lists. In many cases individual mail
filters will be better tools to apply than anything global.
In conclusion, I do agree that abuse management for tools.ietf.org is
necessary. I simply don't believe that assuming all our list/spam
policies apply makes sense. I think that considering those policies
and especially the principles behind them (good luck figuring out what
those are) would be a good idea. I also don't think we need to spend
a bunch of time defining policies; until the tools maintainers do
something we disagree with, I see no need to spend a lot of time on
it.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf