<html><head></head><body>Hi,<div class=""><br class=""/></div><div class="">Following up on the action item from Thursday 30 August on a proposed rewrite of section 4.4.2 of the Temp Spec, which in its current form goes as follows:</div><div class=""><br class=""/></div><div class=""><span style="color: rgb(51, 51, 51); background-color: rgb(255, 255, 255);" class=""><i class="">4.4.2<span class="Apple-tab-span" style="white-space:pre"> </span>Providing access to accurate, reliable, and uniform Registration Data based <span class="Apple-tab-span" style="white-space:pre"> </span>on legitimate interests not outweighed by the fundamental rights of relevant <span class="Apple-tab-span" style="white-space:pre"> </span>data subjects, consistent with GDPR</i></span></div><div class=""><br class=""/></div><div class=""><b class=""><u class="">My proposed course of action on section 4.4.2 is to delete it altogether</u></b>. My rationale is as follows:</div><div class=""><br class=""/></div><div class="">1. Reading through Kurt’s email titled "Project Plan Adjustments and Policy Organization”, sent on 4 September, I found myself in agreement that sections 4.4.2, 4.4.8, 4.4.9 and 4.4.10 are better placed under a different heading than <i class="">“</i><i class="">Lawfulness and Purposes of Processing gTLD Registration Data”</i>. These 4 sections are not really purposes, and would likely be better placed under a different heading altogether, so I proceeded with that in mind.</div><div class=""><br class=""/></div><div class="">2. Feedback submitted by different groups in response to the survey on this section indicated a view that it was too vague, to broad, and not sufficiently specific to serve as a purpose for lawful processing of gTLD Registration Data. Subsequent discussions supported this, both of which I presume contributed to the rationale of moving 4.4.2 out from under the Section 4 header.</div><div class=""><br class=""/></div><div class="">3. If 4.4.2 does not actually serve to clarify a lawful purpose for processing gTLD Registration Data, it made sense to me to attempt to identify what purpose it does serve:</div><div class=""><ul class="MailOutline"><li class="">4.4.2 is a statement that creates an obligation to provide access to gTLD Registration Data</li><li class="">4.4.2 describes conditions that need to be fulfilled before access to gTLD Registration Data may be provided; that they be <i class="">“</i><span style="background-color: rgb(255, 255, 255);" class=""><i style="color: rgb(51, 51, 51);" class="">based on legitimate interests not outweighed by the fundamental rights of relevant data subjects, consistent with GDPR</i><font color="#333333" class=""><i class="">”</i></font></span></li><li class="">4.4.2 describes obligatory characteristics of the gTLD Registration Data to which access shall be provided; that the data will be <i class="">“accurate, reliable, and uniform”</i> </li></ul><div class=""><i class=""><br class=""/></i></div></div><div class="">4.4.2, to me, appears to serve as a guiding principle under which access may be provided to certain third-parties, which will need to be deliberated upon. 4.4.8, 4.4.9 and 4.4.10 may indeed serve the same purpose. However, these principles describe already existing requirements. The need to process (including disclose to third-parties) gTLD Registration Data based on legitimate interests not overridden by the fundamental rights and freedoms on the data subject, and in compliance with GDPR already exists in the section 4 heading. My understanding is that Thomas and Kurt will be proposing modifications/improvements to this header as well.</div><div class=""><br class=""/></div><div class="">Furthermore, it seems to me that the characteristics of gTLD Registration Data being being accurate, reliable and uniform are already existing requirements that are better detailed in the 2013 RAA’s WHOIS Accuracy Program Specification, and the Consensus Policy of “thick” WHOIS under consistent labelling and display.</div><div class=""><br class=""/></div><div class="">My conclusion is that not only is 4.4.2 unhelpful and vaguely drafted, but is also very redundant. If there are reasons why other EPDP Team members believe it should be retained, and what modifications might make this provision more useful, I’m happy to discuss.</div><div class=""><br class=""/></div><div class="">Thanks.</div><div class=""><br class=""/></div><div class="">Amr</div><div class=""><br class=""/></div><div class=""><i class=""><br class=""/></i></div></body></html>