[db-wg] Locking unmaintained PERSON and ROLE objects in the RIPE Database

HI Piotr

On 13/04/2016 23:50, Piotr Strzyzewski wrote:
> On Wed, Apr 13, 2016 at 11:42:45PM +0200, denis wrote:
>
> Denis
>
>>>> So how do they claim to be the owner? They change the details in the PERSON
>>>> object, including the PERSON name, and maybe add their own MNTNER to it.
>>>> But the key element here is the name. In the past you could not change the
>>>> PERSON object name. This is a change that was implemented a couple of years
>>>> ago and has led to this current issue. ONLY by changing the name of the
>>>> PERSON object can you claim to be the 'owner' of this address space. If you
>>>> can't change the name and you can't produce any ID to show you are the
>>>> named person, then you have no claim over the address space. Hijacking in
>>>> this way is not possible. So if you had rolled back that change to allow
>>>> changes to the PERSON object name you would have fixed this problem.
>>>
>>> Leaving aside rest of your email, this is plain wishful thinking.
>>>
>>> It is not a problem to find and pay/bribe someone with the same name to
>>> be a mere front man. Or change a name at some jurisdictions. Or marry
>>> someone and then change the name.
>>> This has been "invented" years ago.
>>
>> Maybe I am missing something here. But considering what you have just
>> said....what have you fixed by locking almost a million objects?
>
> I did not say anything about solving any problem.

I thought solving problems was the goal...

>
> Just to remind what you have said:
>
> "So if you had rolled back that change to allow changes to the PERSON
> object name you would have fixed this problem."
>
>> Consider 3 address blocks:
>> 1/ admin-c and tech-c are properly maintained
>> 2/ admin-c and tech-c were unmaintained
>> 3/ admin-c and tech-c are now locked
>>
>> If you consider that a hijacker can 'get' id to show they are the
>> referenced person, what difference does it make which of these three cases
>> the address space is?
>>
>> The locked is now the same as properly maintained to a hijacker. So instead
>> of simply changing the name they have to 'get' id.
>>
>> So you have solved nothing, but created a massive, long term problem. In
>> fact you have created a new data protection problem. Almost a million
>> personal data sets cannot be changed by the data subject. The RIPE NCC will
>> not recognise anyone as the 'person' referenced in one of these objects. If
>> they are not in a position to remove the reference what will you do? More
>> generally you have a million personal data sets that you cannot claim to be
>> accurate personal data. But as long as they remain referenced there is
>> nothing the RIPE NCC can do about it.
>>
>> So I will say again, the action you have taken is not the answer to this
>> problem.
>
> Taking your arguments stated above, I once again (this time more clear)
> say that rolling back the change to allow changes to the PERSON object
> name would _not_ have fixed the problem.

Maybe not, but it would have been a harmless change. Your action has 
created massive, long term, legal problems and a lot of inconvenience to 
members.

cheers
denis

>
> Piotr
>