[db-wg] PERSON objects in the RIPE Database

On 20/09/2018 15:04, denis walker via db-wg wrote:
> Colleagues,
>
> I will start with a blunt question, then give some arguments for my
> concern. In May the RIPE NCC told me there are more than 2 million
> PERSON objects in the RIPE Database. That is almost 25% of the objects
> in the database. Who are these people and why do we hold so much
> personal data?
>
> At RIPE 76 the RIPE NCC legal team gave a presentation on GDPR and the
> RIPE Database. The basis of that presentation seemed to be that
> Article 3 of the RIPE Database Terms and Conditions defined one of the
> purposes of the database as:
> Facilitating coordination between network operators (network problem
> resolution, outage notification etc.)
>
> It was argued that this justifies the inclusion of personal data in
> the RIPE Database so that these people can be contacted in the event
> of network operational issues, even by people who have no business
> relationship with these contacts. But this Article makes no mention of
> 'personal' contact information.
>
> It was also mentioned that some personal data is included for policy
> reasons. The IPv4 Address Allocation and Assignment Policy makes a
> couple of references to contact data. In 4.0 Registration Requirements
> it says:
> All assignments and allocations must be registered in the RIPE
> Database....Registration data (range, contact information, status
> etc.) must be correct at all times
>
> This clearly associates contact information with the necessary
> registration. But this does not specify that it has to be 'personal'
> contact information. In 6.2 Network Infrastructure and End User
> Networks it says:
> When an End User has a network using public address space this must be
> registered separately with the contact details of the End User. Where
> the End User is an individual rather than an organisation, the contact
> information of the service provider may be substituted for the End Users.
>
> This clearly has the intent of avoiding the need to enter 'personal'
> data as contact information. In the IPv6 Address Allocation and
> Assignment Policy it is even more vague saying in 3.3 Registration:
> Internet address space must be registered in a registry database
> accessible to appropriate members of the Internet community. This is
> necessary to ensure the uniqueness of each Internet address and to
> provide reference information for Internet troubleshooting at all
> levels, ranging from all RIRs and IRs to End Users.
> The goal of registration should be applied within the context of
> reasonable privacy considerations and applicable laws.
>
> 'Reference' information and concerns about privacy again clearly
> indicate that the intent is to avoid using 'personal' data for the
> contacts.
>
> This does raise a number of questions:
> -Should I believe that we really do have more than 2 million
> individual people in this region who can seriously address technical
> or administrative questions on Internet resources or network
> operational issues?
> -Why is it considered necessary for contacts to be identifiable people
> rather than roles?
> -Abuse-c was intentionally designed to reference a ROLE object, which
> no longer needs to have any referenced PERSON objects, to avoid the
> need to enter personal data, why can't technical matters be addressed
> in the same way?
>
> The purpose in the Terms and Conditions may define a reason for
> holding contact information, but it doesn't justify this level of
> personal data being held in the database. Perhaps it's time to review
> what is meant by 'contact information'. What is really needed to
> satisfy this purpose? For example, why do we need an address for a
> technical contact who may need to be contacted in the event of an
> operational issue? No one is going to go to that address or post a letter.
>
> As always your thoughts and opinions are welcome...
>
> cheers
> denis
> co-chair DB WG
>
I think HOHO-RIPE would tend to disagree.

-Hank

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20180920/686bc8e9/attachment.html>