[db-wg] PERSON objects in the RIPE Database

Hi Nick
I agree the situation we are in is historic. Let me just address your third question "can we come up with a migration plan from one to the other which can be implemented before the heat death of the universe? (highly unlikely)."
The RIPE NCC legal presentation at RIPE 76 made it clear that the responsibility for this personal data is shared between the RIPE NCC and the (mostly) members who put the data into the database. Now collectively I don't believe we can justify holding 2million personal data sets in this database and hide behind the Terms and Conditions's defined purpose as the justification. Now everyone can bury their heads in the sand and pretend this problem doesn't exist and the law on personal data in public databases never changed. But, should you need one, that is not a very good legal defense.

So really the only question that must be answered is "Can we justify holding this amount of personal data on the basis of contacts for administrative and technical issues relating to internet resources and network operations?" If the answer is 'no' then change MUST happen, long before the universe dies.
cheersdenisco-chair DB-WG



      From: Nick Hilliard via db-wg <db-wg at ripe.net>
 To: denis walker <ripedenis at yahoo.co.uk> 
Cc: DB-WG <db-wg at ripe.net>
 Sent: Tuesday, 25 September 2018, 23:46
 Subject: Re: [db-wg] PERSON objects in the RIPE Database
   
denis walker via db-wg wrote on 20/09/2018 13:04:
> This does raise a number of questions:

the requirement for admin-c and tech-c derive from what was thought to 
be useful information to have at hand at the time when network 
registrations were starting out at the InterNIC, way back in the late 
1980s. These token made their way into ripe81 as machine-parseable 
fields, then into ripe181.

This dates from the time when we all had fingerd enabled, for example, 
and when SMTP ETRN and VRFY usually returned something useful, and when 
gopher was hot stuff and when 2mbit/s links were so outrageously fast 
that it was normal to boast about the speed in the DNS PTR records for 
your router interface IP addresses.  Thankfully we've moved on from at 
least some of these things, but they all shared one characteristic: "it 
seemed like a good idea at the time".

Really we have three questions: is what we have both legal and fit for 
purpose? (hard to tell), could we bang heads together to come up with a 
new schema which would be comfortably legally compliant and technically 
fit for purpose? (probably yes), and can we come up with a migration 
plan from one to the other which can be implemented before the heat 
death of the universe? (highly unlikely).

Nick



   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20180925/6b7a6457/attachment.html>