[anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database)

Hi,

> Lets say order the relevant technical processes should be included in
> this proposal (Some might call this a plan).

I will ask RIPE NCC to join this discussion since I can not talk about
implementation in behalf of RIPE NCC.

In my opinion it does not make any sense to include implementation
details into an policy. Two reasons for that. Nobody cares about the
implementation details in 10 years when things are in place. This would
pollute the policy. And second, what happens if another proposal coming
up in 5 years changes the whole design of database?

Policy is policy and implemetation details are implementation details.

I agree that RIPE NCC should publish their ideas, but not put it into
the proposal text.

And an example at the end. If we agree that we have to be in London on
10th of December. We agreed on that. If RIPE NCC tells us to walk and
swim, we can say "No way!" and ask them if we could fly, but we do not
disagree about being in London.

I do not want to mix up the fact of going to London (introducing the
abuse-c) with the fact on how to go to London (how to implement things).


>>>> Another point: if the general idea of the policy is acceptable,
>>>> wouldn't it be nice to have 2 abuse mailboxes: one for humans,
>>>> one for bots?
>>> 
>>> +1;
>> 
>> Having two contacts might complicates things, it might be
>> complicated for the end user to decide wich one to contact.

No. End users should not take the way of whois. They should use the
abuse finder tool. This tool will give them exactly what they need.

>> Maybe it would be easier to make one contact wich has to be marked 
>> as "person", "role" or "robot". Both, end user or automatic
>> reporting tools, could then decide themself, if the type of the
>> contact fits their intention. It might also be nice to have a
>> "preferred reporting method" field included, what could be "email,
>> phone, url, ARF, X-ARF" or similar.

This will make things much more complicated. I agree and we had a
discussion about this in the Task Force as well, that a url may be an
option as well. On the other hand, parsing email in a standard format is
not that difficult and in the abuse community offering a form to report
abuse is most likely seen as a "Fuck off!" to the reporter.

The idea behind abuse-mailbox and e-mail attribute is the following: The
email attribute can be personal information, so you do not want to
publish it unrestricted. The information in the abuse-mailbox attribute
will be not personal information and can be queried unrestrictedly.

If you have no need for a differentiation between those, take the same
address for both. That would be absolutely fine.

> What if the people or robots reporting to such an address, don't care
> about robot vs. human mailboxes and/or relevant reporting formats (or
> are reporting bogus due to bugs)? I would suggest, that every
> team/member/robot behind such an address should figure that for
> themselves.

There is a second reason for differentiation. Spam filters on abuse
addresses do not make a lot of sense. But spam filters on a team
addresses read by humans do make a lot of sense.

What if a bot does not care. He will take care, because if he sends the
reports to the personal address they will get lost, because the spam
filter will take care of them.

I'm against every team/member/robot should figure that out themselves.
That is exactly the situation at the moment with loads of opportunities.

Receiving all kinds of robot reports on one mailbox (abuse-mailbox) is
already best practice today. So this is nothing new.


A last reason why I would not split up things to far. I want to avoid
adding to much opportunities at once. I think there is not reason not to
add Jabber/IRC/XMP-PRC/whatever as a new attribute as soon as it shows
up and is widely used. At the moment mail is the most common way of
exchanging reports about abusive behavior. So that is why I would
suggest to stay with email and see if something really new comes up.

Thanks,

Tobias

-- 
abusix




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 307 bytes
Desc: OpenPGP digital signature
URL: </ripe/mail/archives/anti-abuse-wg/attachments/20111129/e8071c32/attachment.sig>