Hi Shane You raised several points here, but I think they fall into two different issues. I will address one of them in this email. Then address the other ones in another email. First, the long standing question about referencing anyone's PERSON or ROLE object. I raised this question with the RIPE Data Protection Task Force and they considered the issue at great length some time ago. The Task Force concluded that it is actually better to NOT require authentication. As things stand now anyone can reference *your* PERSON object in their data. But you can do an inverse query (-i pn NIC-Hdl) and find any object in the RIPE Database where your PERSON object has been referenced. If you see a reference that you did not make, in data that you do not maintain, then you can question it with the maintainer of that data. If you get no success or response from them you can use the legal process (also set up by that Task Force) to deal with requests to remove (references to) personal data in the RIPE Database by a data subject. If the community asks for references to PERSON/ROLE objects to require mandatory authorisation, then no one can add a reference to YOUR object in their data. At first this looks like the ideal situation. However, the RIPE Data Protection Task Force looked at this from a different angle. There is no restriction on anyone creating a PERSON object containing any data. So anyone can create a new PERSON object with a copy of the data contained in your PERSON object. The guy who creates this copy also maintains it. So he can provide any mandatory authorisation for referencing this data copy. In the first case you can find any unauthorised references. In the second case you may never know someone has copied your personal data. So the Task Force considered it is safer to leave it as it is. Maybe a more important question to address is WHO made the changes? From the logs we can see which MNTNER and which password/PGP authorised a reference to your PERSON object or that created a copy of it. But a MNTNER is a box holding anonymous credentials of unknown people. What is missing is accountability. regards Denis On 1/12/11:49 3:06 PM, Shane Kerr wrote:
Denis,
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