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