[anti-abuse-wg] Proposal for technical details for abuse contact information in the RIPE Database

Hi,

> a restriction or ACL for the abuse address is simple not
> what a lot of people intended.

We do not want to have a restriction on the abuse address it self. But
we are able to control and split personal data from public data with
these ACLs. And that is exactly what should happen.

> You forgot about bigger ISPs that likes to report abuse
> automatically in standarized formats (and what most abuse departments
> really LIKE to receive).
> An unrestricted abuse contact really helps here a lot.

That is exactly what we want. That the abuse-mailbox attribute is
unrestricted, but not the email address attribute. And that can be
managed by ACLs.

> Sure, personal data should be protected, and thats why we
> really like the idea of seperating them from personal
> objects.

And that again is exactly what ACLs are for, to separate personal data
from public data. I do not see any sense in splitting this up in
different objects, since this makes things much more complicated for
maintainers and especially for smaller maintainers.

> But to be honest: no restriction helps that your email
> address ends up in a spammers list, they have more
> power you can dream of (I even heared that they pay
> people to enter captcha codes).

Paying people to entering captcha codes is not that new at all. ;-) The
point is that we would not change anything. The abuse-mailbox attribute
can be queried without restrictions already. So the whole proposal is
about adding an abuse-c which makes imho sense and the implementation
will take care of clearing thing up a little bit.

Thanks,

Tobias

-- 
abusix






> 
> 
> Kind regards, Frank
> 
>>
>> On Wed, 2011-11-30 at 16:25 +0100, Denis Walker wrote:
>>> The RIPE NCC Database Group has now published an article on RIPE Labs
>>> with a detailed explanation of how we propose to implement abuse
>>> handling with an "abuse-c:" attribute referencing a ROLE object.
>>>
>>> https://labs.ripe.net/ripe-database/abuse-handling-in-the-ripe-database
>>
>> Thanks for putting this together.
>>
>> Basically, I think that the basic split between ABUSE and STANDARD ROLE
>> objects does not make a lot of sense, and will likely lead to user
>> confusion and frustration. Some of the ideas you've presented do make
>> sense, but make sense for any contact data rather than restricting them
>> via arbitrary business rules.
>>
>> One thing that I think would be a positive step forward for the RIPE
>> Database is *not* to restrict references to ABUSE ROLE, but rather to
>> restrict *all* references to person or role objects. I believe the
>> database currently still allows me to reference any person/role object
>> if I want to. This is a bug, not a feature, and I think adding
>> "mnt-ref:" to person/role objects would be a better way forward than
>> adding yet another special case. (This was introduced as a special case
>> to the irt type, but then generalised in the organisation object.)
>>
>> I also suggest that normal access controls should apply to roles when
>> used for abuse. Abuse desks don't like spam either.
>>
>> -- 
>> Shane
>>
>>
>>
>>
> 
> 


-------------- 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/20111201/2bf0f913/attachment.sig>