<div dir="auto"><div>Hi Nick</div><div dir="auto"><br></div><div dir="auto"><pre style="white-space:pre-wrap">I'll give you the short answers first, then the detailed reply. So people who don't like to read long emails can skip the detail.</pre><pre style="white-space:pre-wrap"><br></pre><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Sun, 19 Jun 2022, 16:06 Nick Hilliard, <<a href="mailto:nick@foobar.org">nick@foobar.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">denis walker via db-wg wrote on 16/06/2022 16:05:<br>
> I have listened to your comments in recent discussions and had some <br>
> preliminary talks with the RIPE NCC about what could be implemented. So <br>
> now we have a second version of my proposal on personal data.<br>
<br>
There are some fairly serious structural issues with the justification <br>
in this proposal, for example:<br>
<br>
- that there's something new with GDPR that wasn't there before<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">These issues have always been there. GDPR focused our minds on them in recent years. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- that the RIPE database is not GDPR compliant<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">It isn't. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- repeated claims that "In almost all cases, personal data is not needed".<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">It isn't. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- etc<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Please expand if you want me to reply. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
GDPR, and previously the 1995 Data Protection Directive, has been <br>
addressed continuously by the RIPE NCC over the years.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">No it hasn't. The first time it was considered was by the task force in 2006. They concluded in 2009. Nothing much was then discussed until GDPR came into effect in 2018.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> There are some <br>
blog posts on the RIPE NCC web site which provide an overview of the <br>
current lawful basis for holding and publishing the information:<br>
<br>
> <a href="https://www.ripe.net/about-us/legal/corporate-governance/gdpr-and-the-ripe-ncc" rel="noreferrer noreferrer" target="_blank">https://www.ripe.net/about-us/legal/corporate-governance/gdpr-and-the-ripe-ncc</a><br>
<br>
</blockquote></div></div><div dir="auto"><br></div><div dir="auto">These blogs were written over 4 years ago and have quite a number of open issues outstanding. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So in the absence of firm reasoning to the contrary, this policy needs <br>
to step back quite far from claiming or hinting at GDPR non-compliance.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Read the detail below for the firm reasoning...</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
There are numerous other cases where the current justification presents <br>
opinions without providing an adequate factual basis.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Please highlight these opinions and I'll offer the factual basis. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Incidentally, I'm not arguing that there shouldn't be changes to the <br>
scope and style of information contained in the ripe database, but as it <br>
stands, the scope of this policy proposal isn't justified by the <br>
rationale provided.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Again, please elaborate and I'll expand on the rationale. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Nick</blockquote></div></div><div dir="auto"><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Now the detailed answers. Let me firstly disclose my interest here. I was a RIPE NCC staff member of the Data Protection Task Force (DPTF) from start to finish. Unlike with the recent Database TF, I wasn't just an advisor. Jochem and I were full and active members of the TF. At the start of the DPTF work, the RIPE NCC had no legal team. We worked with the NCC's external lawyers, who had limited knowledge of the RIPE Database. I drafted the early versions of the RIPE Database Terms & Conditions, Acceptable Use Policy, NRTM and Bulk Access Agreements and much of the Database content of the DPTF report. Towards the end of this work the NCC had a legal council and I worked with Jochem and Athina on final drafts of these documents before community and EB approval.</div><div dir="auto"><br></div><div dir="auto">So I have a good knowledge of what is in these documents, the context in which they were created and the mistakes (that still exist) in them.</div><div dir="auto"><br></div><div dir="auto">You referenced a series of RIPE Labs articles on GDPR. These articles referenced the DPTF Report. These contain some interesting points, and some errors, partly as a result of the errors in the DPTF report. Bear in mind also that these labs articles were all written over 4 years ago and the DPTF report over 10 years ago. Knowledge and understanding of the issues has increased in this time.</div><div dir="auto"><br></div><div dir="auto">1st labs article</div><div dir="auto">----------------</div><div dir="auto"><br></div><div dir="auto">"In 2005, the RIPE Database Working Group identified a need to comply with data protection legislation by updating the processes and services relating to the RIPE Database. At RIPE 52 in April 2006, the community established the RIPE Data Protection Task Force (DPTF). The DPTF was mandated by the RIPE Database Working Group to recommend steps that the RIPE NCC should take to comply with the legislation."</div><div dir="auto"><br></div><div dir="auto">This was the first time the RIPE NCC and community considered privacy and personal data issues. It was a good starting point, but we were a bit naive and the external lawyers had little knowledge of the database. That is why some errors were made and these errors have been duplicated ever since.</div><div dir="auto"><br></div><div dir="auto">"According to the Dutch Personal Data Protection Act (prior to the GDPR), personal data may be collected for specific, explicitly defined and legitimate purposes. Once collected, this data must:</div><div dir="auto"><br></div><div dir="auto">-Be adequate, relevant and not excessive in relation to the purposes for which it is collected and further processed</div><div dir="auto">-Be accurate and, if necessary, kept up-to-date"</div><div dir="auto"><br></div><div dir="auto">The big mistake we made was to consider 'registration information' and 'personal data' as single entities. So when looking at the purposes of the database and asking the question "do the purposes allow for the processing of personal data" as a single entity, the answer was yes. But when you break down that personal data, single entity into components the answer is yes and no. The primary purpose of the database is as a public registry of 'who' holds or uses blocks of address space. The key is in the alternative name, 'whois database'. So yes the purposes do justify publishing names. Even for natural persons, there is justification for publishing the names. As a contact database to resolve network issues the purposes also justify processing phone numbers and/or email addresses. BUT none of these need to be personal. In fact in the second labs article it even stresses the business nature of this information. Now when it comes to (postal) address, this is where it is crucial to break down this personal data into components. By definition the postal address of resource holders is "a full postal address for the business contact related to the organisation holding the resource". By this definition this contact can be anyone located anywhere in the world. It has no 'relevance in relation to the purposes'. It also cannot be verified as accurate or up-to-date. Therefore it cannot be justified to be processed according to the purposes, where it is a personal address, under either the Dutch Personal Data Protection Act or the GDPR.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">2nd labs article</div><div dir="auto">----------------</div><div dir="auto"><br></div><div dir="auto">"The contact details of a resource holder and their appointed contact persons consist of names, (business) email addresses, (business) phone and fax numbers, and (business) postal addresses."</div><div dir="auto"><br></div><div dir="auto">Although broken down here into components and the business nature of the data is stressed, the individual components were not compared with the purposes.</div><div dir="auto"><br></div><div dir="auto">"The purpose must be specified, explicit, and legitimate. Personal data may only be collected and processed to fulfil this purpose and must not be further processed in a way that is incompatible with this purpose."</div><div dir="auto"><br></div><div dir="auto">Again when personal postal address is compared to the purpose, it cannot be justified.</div><div dir="auto"><br></div><div dir="auto">"The purpose described in the third bullet point of Article 3 of the Terms & Conditions "Facilitating coordination between network operators (network problem resolution, outage notification etc.)" is the one that justifies the publication of personal data in the RIPE Database.</div><div dir="auto"><br></div><div dir="auto">For this reason, the RIPE Database includes the contact details of resource holders and persons that are responsible for the administration and the technical maintenance of a particular network."</div><div dir="auto"><br></div><div dir="auto">These statements are not correct. This need to coordinate between operators does not require any personal data. Contact details of persons is not needed. Contact details can all be business related information.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">3rd labs article</div><div dir="auto">----------------</div><div dir="auto"><br></div><div dir="auto">[I am going to disagree with most of this...I have added my comments inside [...] ]</div><div dir="auto"><br></div><div dir="auto">Legal grounds for lawful personal data processing</div><div dir="auto"><br></div><div dir="auto">In order for the processing of personal data to be lawful, it must be done on a legitimate basis, as defined in Article 6.1 of the GDPR:</div><div dir="auto"><br></div><div dir="auto">Processing shall be lawful only if and to the extent that at least one of the following applies:</div><div dir="auto">[So which of these apply to the personal data in the RIPE Database?]</div><div dir="auto"><br></div><div dir="auto">(a) the data subject has given consent to the processing of his or her personal data for one or more specific purposes;</div><div dir="auto">[Consent is difficult to verify in a database with such a widely distributed data entry. Better not to enter data that is not needed for the purposes, even if consent is given.]</div><div dir="auto"><br></div><div dir="auto">(b) processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract;</div><div dir="auto">[This covers some components of personal data, such as name of resource holder or end user.]</div><div dir="auto"><br></div><div dir="auto">(c) processing is necessary for compliance with a legal obligation to which the controller is subject;</div><div dir="auto">[Does not apply.]</div><div dir="auto"><br></div><div dir="auto">(d) processing is necessary in order to protect the vital interests of the data subject or of another natural person;</div><div dir="auto">[Does not apply.]</div><div dir="auto"><br></div><div dir="auto">(e) processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller;</div><div dir="auto">[This covers some components of personal data, such as name of resource holder or end user.]</div><div dir="auto"><br></div><div dir="auto">(f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child.</div><div dir="auto">[This one is interesting as the exception recognises that, if publishing the home address of resource holders or end users is against the interests of the data subject, that overrides the database purposes.]</div><div dir="auto"><br></div><div dir="auto">Personal data of a resource holder</div><div dir="auto"><br></div><div dir="auto">As our previous article mentioned, the RIPE NCC has a mandate from the RIPE community to register and distribute Internet number resources and maintain an Internet number resource registry. While the RIPE community defined the purposes of the RIPE Database, the RIPE NCC is responsible for operating it.</div><div dir="auto">[The RIPE community is not a legal authority. It cannot mandate the RIPE NCC to force natural persons to publish their full home postal address in the database, especially as this address is not relevant to the defined purposes.]</div><div dir="auto"><br></div><div dir="auto">The RIPE Database contains registration information about Internet number resources and, in particular, information about the natural or legal persons that hold these resources. The contact details consist of (legal) name, (business) email address, (business) phone and fax numbers, and (business) legal and postal address(es).</div><div dir="auto">[This mixes registration information with contact details. They are not the same. Legal address is not held in the RIPE Database. The definition of the postal address makes it not relevant to the defined purposes.]</div><div dir="auto"><br></div><div dir="auto">Contact details of the parties responsible for specific Internet number resources are essential for the smooth and uninterrupted operation of Internet and connectivity. The RIPE Database facilitates communication between the people responsible for networks to address technical issues, allowing for quick coordination between operators that do not have a direct relationship.</div><div dir="auto">[This paragraph mixes 3 terms, parties, people and operators. Bottom line is, personal data is not needed for contacts.]</div><div dir="auto"><br></div><div dir="auto">For the purpose described above, it is clear that the processing of personal data referring to a resource holder is necessary for the performance of the registry function, which is carried out in the legitimate interest of the RIPE community and the smooth operation of the Internet globally (and is therefore in accordance with Article 6.1.f of the GDPR).</div><div dir="auto">[The postal address of resource holders, as defined, is not relavant to the purposes and therefore not in accordance with the GDPR. It also comes under the exception stated in Article 6.1.f above]</div><div dir="auto"><br></div><div dir="auto">Personal data of a resource holder's contact person</div><div dir="auto"><br></div><div dir="auto">When resource holders are legal persons, they must provide contact details for the individuals responsible for the networks the Internet number resources correspond to, and/or responsible for maintaining information in the RIPE Database. This is also the case for resource holders that are individuals but do not want to have this role themselves.</div><div dir="auto">[Not correct. These contacts do not need to be identifiable persons for the purposes of the database.]</div><div dir="auto"><br></div><div dir="auto">The contact details usually refer to the technical and administrative employees of a resource holder and consist of names along with a (business) email address, phone, fax number and postal address.</div><div dir="auto">[Only business details are needed and no address is needed for a contact.]</div><div dir="auto"><br></div><div dir="auto">The purpose for which personal data is requested and made publicly available in the RIPE Database is always the same: ‘Facilitating coordination between network operators (network problem resolution, outage notification etc.).</div><div dir="auto">[Absolutely not correct. This purpose does not require any personal data.]</div><div dir="auto"><br></div><div dir="auto">In order for consent to serve as the legal ground of a processing activity, the resource holder must be able to demonstrate that the individual has consented to the processing of their personal data...</div><div dir="auto">[Consent is a murky area in a database with such a widely distributed data entry responsibility. It is possible to have multiple levels of sub-allocations. Each level introduces another layer of data entry, further removed from the RIPE NCC and resource holders. The data quality and responsibilities may be diminished with each level. Where personal data is not necessary for the purposes, it is better to avoid it rather than allow sporadic consensual data.]</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">DPTF Report</div><div dir="auto">-----------</div><div dir="auto"><br></div><div dir="auto">The Dutch Data Protection Act includes the definition:</div><div dir="auto">"Personal data is any information relating to an identified or identifiable natural person."</div><div dir="auto">So the term 'Personal Data' is an umbrella term for all pieces of personal information. It makes sense to use this umbrella term in some situations. But when considering if the database purposes cover the processing of 'personal data', this must be broken down into it's component pieces of information and each piece needs to be assessed against the purposes.</div><div dir="auto"><br></div><div dir="auto">"The data subject has the right to request that the responsible party correct or delete their personal data."</div><div dir="auto">In order for the data subject to be able to exercise this right, they must be given details of what personal data is processed and where to find it. It is not sufficient to sign a contract that mentions that personal details will be published in 'the RIPE Database' or 'some database'.</div><div dir="auto"><br></div><div dir="auto">cheers</div><div dir="auto">denis</div><div dir="auto">Proposal author</div></div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>