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 <[email protected]>
To: denis walker <[email protected]>
Cc: DB-WG <[email protected]>
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
