[db-wg] Locking unmaintained PERSON and ROLE objects in the RIPE Database
- Previous message (by thread): [db-wg] Locking unmaintained PERSON and ROLE objects in the RIPE Database
- Next message (by thread): [db-wg] Locking unmaintained PERSON and ROLE objects in the RIPE Database
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Piotr Strzyzewski
Piotr.Strzyzewski at polsl.pl
Wed Apr 13 23:50:47 CEST 2016
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. 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. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski at polsl.pl
- Previous message (by thread): [db-wg] Locking unmaintained PERSON and ROLE objects in the RIPE Database
- Next message (by thread): [db-wg] Locking unmaintained PERSON and ROLE objects in the RIPE Database
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]