[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 ]
denis
ripedenis at yahoo.co.uk
Thu Apr 14 00:00:45 CEST 2016
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 >
- 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 ]