<div dir="ltr"><div>I think you both make good points. Our starting point is the current status quo, which I expect will continue on into the far future: All registration data provided as a registrant must be viewed as potential personal information, in a Schroedingers Cat kind-of situation. Until you look at it, you do not know what it is, even though you can make certain assumptions with varying likelihoods. The 2B memo tells us nothing new in that regard. <br></div><div><br></div><div>What it does tell us is that the various methods of determination without looking have risk of various degrees attached. <br></div><div><br></div><div>Miltons proposed registrant-declaration is one of the lower risk ones methods. Stephanie is also right that in a highly competitive market with razor-thin margins, corners will be cut at some point of the channel, especially once you enter the realm of resellers. So Stephanie is absolutely correct in her point that the determination of whether contracted parties can rely on the accuracy of any declaration must be that of the contracted party itself. The declaration of legal status of the registrant ultimately does not help us make that determination. The declaration of content of the data goes a whole lot further in that regard. Controlling the process where the declaration is made helps even more (hence the requirement to allow post-registration declarations).</div><div><br></div><div>As for publication vs. disclosure, after having given this some thought, I still tend to come out on the side of disclosure, but with the following features:</div><div>- self-declared data sets would be set to automated disclosure.</div><div>- public RDAP could contain a marker/flag/label/something that shows that this data set is available for automated disclosure in SSAD</div><div>- Disclosure fees for such data sets in SSAD could be priced lower than non-automated data sets, say half-price</div><div>- Access levels for access to such data sets could be lower for users of SSAD. For example, if you just want to access automated-disclosure sets, accreditation could be voluntary, and a mere ID-check application process and a statement of legitimate interest for each request could be possible. <br></div><div><br></div><div>Advantages: <br></div><div>- Increased utility of SSAD<br></div><div>- SSAD User Fees would decrease (higher query volumes overall, lower fees for some queries)<br></div><div>- CP Risk would be limited</div><div>- CP handling times for requests would be reduced in case they implement that flag. <br></div><div><br></div><div>I still need to hear what the benefits of the differentiation of data sets and better availability of non-personal information really are, though. In my experience it is not like cyber criminals are setting up legal entities such as STEALATRADEMARK, Inc or VIOLATEACOPYRIGHT, Ltd. left and right to register their domain names. Those kinds of domains are usually registered with perfectly accurate personal data sets. If someone could really make the case of what the perceived benefit to all parties concerned is on this (something I have been asking for from days 1), I'd be happy to hear them. The common argument of security, stability and resilience of the DNS went out of the window the day the Temp Spec first came into effect after all, as neither of the three has been affected by the current vegetative state of the WHOIS (In the sense that it is not quite dead yet, but almost. Machines still keep it alive). <br></div><div><br></div><div>This also would solve the issue of thick vs thin RDAP:</div><div>If RDAP only returns the basic data set anyway and never any personal information, there is no longer any need to require registrars to provide RDAP services as there no longer is any concern in supplying said data to the registries for centralised publication. Thick RDAP would be saved.<br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><span lang="EN-US">-- <br>Volker A. Greimann<br>General Counsel and Policy Manager<br><b>KEY-SYSTEMS GMBH</b><br><br>T: +49 6894 9396901<br>M: +49 6894 9396851<br>F: +49 6894 9396851<br>W: </span><a href="http://www.key-systems.net/" style="color:rgb(17,85,204)" target="_blank"><span lang="EN-US">www.key-systems.net</span></a><span lang="EN-US"><br><br>Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835<br>CEO: Oliver Fries and Robert Birkner<br><br>Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.<br><br></span><span style="font-family:Roboto,sans-serif;font-size:14px;white-space:pre-wrap;background-color:rgb(248,249,250)">This email and any files transmitted are confidential and intended only for the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached.</span></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 17, 2021 at 12:19 AM Stephanie E Perrin via Gnso-epdp-team <<a href="mailto:gnso-epdp-team@icann.org">gnso-epdp-team@icann.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Bird and Bird is offering arguments for protection in the event
of complaint. While that protection is welcome and reassuring in
terms of risk, I am not certain that we have adequately explained
to 2Birds how registration actually takes place. It would have
been beneficial to walk them through a range of different ways to
register a domain name. As we have discussed in the calls, very
often non-savvy non-commercial users or small business/home
workers use resellers of various kinds to register their domains.
Additional risk creeps in here, WRT whether or not a positive
consent has been obtained from relevant employees. Further risk
creeps in when we look at automatic renewals, where the contact
data may not be updated. If updated, have the steps been taken to
get consent from new employees? To me this is key, non-savvy
users, and I count myself among them, are not likely to check what
an intermediary is doing with respect to the domain renewal or
updating.</p>
<p>Now, of course the argument is that they SHOULD be more diligent
and they SHOULD pay attention to the accuracy requirements, but
lets deal in facts here.....are they? As the data controller who
is pre-emptively disclosing personal data, allegedly with consent,
to unknown (to the contracted party) third parties, the
responsibility still rests with the controller. As I have
mentioned, a Facebook or a Google or a Microsoft can get away with
treading roughshod over their consent arrangements....not too many
folks are going to give up free or necessary services over
quibbles in a consent form, even if it is 75 pages long. However
the registrars (and to a lesser extent, the registries) are
operating in a highly competitive market. Once losing my trust,
perhaps over a trifling inattention to the accuracy of my data,
and I am transferring my domains to another company. Policing a
complex reseller market is also rather a difficult matter that we
have not discussed at length in our debates on this issue. I know
that the data commissioners as a group do not understand how the
accountability for the handling of personal information is
transferred in that market, and it would not be surprising if
2Birds did not either. Bottom line: accredited registrars are
shouldering the risk here, it is their risk, and they would know
best whether they can trust the accuracy of the designation of
legal personhood. This is why I think that this designation, in
my opinion, should always permit an override by the contracted
parties to treat the data as personal. I have suggested many many
times that commercial organizations should operate on an
accreditation basis and be linked to their official registration
numbers (business, corporation, municipal licence etc). Noone
ever responds to that idea....if it is totally ridiculous I would
certainly like to know why, I am offering it in good faith and I
think it would do something useful to stop fraudulent
registrations in their names. However, small business and
non-commercial organizations, even if incorporated or in
possession of a registration # of some kind have different needs
and circumstances, and they are frequently treated differently
under data protection law. <br>
</p>
<p>One final point that I have raised a few times.....we tend to
focus on enforcement fines and Court costs. Even if noone ever
complains to a DPA or takes a case to Court, where the advice of 2
Birds gives us some comfort that the risk is manageable, and the
results would exonerate the contracted parties.....what about
reputational damage in the meantime? Court costs? Who actually
wants to have customers complaining about the practices? Employee
morale, if it is employees who are objecting to the practices?</p>
<p>I support focusing on whether the data submitted is personal or
not, with a fulsome definition and description of same, and full
flexibility for contracted parties to err on the side of caution
and consider the possibility of some data being personal after
all. After all, much data is still being disclosed, and noone has
adduced strong evidence that the delay in requesting the data (as
opposed to getting it from the published data) will have huge
repercussions. What is actually at play here is who is doing the
extra work....the requesting party, or the data controller.</p>
<p>Stephanie Perrin<br>
</p>
<p> <br>
</p>
<div>On 2021-04-15 10:42 p.m., Mueller,
Milton L via Gnso-epdp-team wrote:<br>
</div>
<blockquote type="cite">
<div style="font-size:10pt;font-family:sans-serif;color:white;font-style:normal;font-weight:bold;padding:0.2em">
<strong><span style="color:rgb(199,80,0)">EXTERNAL EMAIL:</span></strong></div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">Further
legal support from TwoBirds<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p style="margin-left:19.5pt">
<span lang="EN-GB"><span>14.2<span style="font:7pt "Times New Roman"">
</span></span></span><span lang="EN-GB">If
personal data is erroneously included in published
Registration Data, it would in this scenario occur despite
substantial (VSC) steps taken by the Contracted Parties,
and would be primarily attributable to the
actions/omissions of the Registrant. This is likely to be
taken into account by data subjects, data protection
supervisory authorities, and courts.<u></u><u></u></span></p>
<p style="margin-left:19.5pt">
<span lang="EN-GB"><span>14.3<span style="font:7pt "Times New Roman"">
</span></span></span><span lang="EN-GB">The
data in question is likely to be low sensitivity. The
scenario being envisaged here (mistaken inclusion of
personal data in published Registration Data) seems to be
most likely to occur when a legal entity (e.g. a company
or non-profit organisation) is registering / maintaining
its own domains. In those scenarios, we assume the
personal data that could be disclosed would ordinarily
relate to an employee’s work details (e.g. a company email
address), not an individual’s private life. Although the
GDPR confers protection even in the workplace, the data in
question here may arguably be less capable of causing harm
to an individual than data relating to the data subject’s
private life.<a href="#m_2854865445665285661__ftn1" name="m_2854865445665285661__ftnref1" title=""><span><span><span style="font-size:11pt;font-family:"Georgia",serif" lang="EN-GB">[1]</span></span></span></a>
<u></u><u></u></span></p>
<p style="margin-left:19.5pt">
<span lang="EN-GB"><span>14.4<span style="font:7pt "Times New Roman"">
</span></span></span><span lang="EN-GB">In
more sensitive cases (e.g. disclosing that a person works
for a company in a sensitive or “embarrassing” sector), a
Registrant would be putting itself at serious risk of
complaints from its own employees. Registrants are
therefore already incentivised to avoid errors that could
have serious consequences for their own staff.</span><span lang="EN-GB">
</span><span lang="EN-GB"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<div>
<div style="border-color:rgb(225,225,225) currentcolor currentcolor;border-style:solid none none;border-width:1pt medium medium;padding:3pt 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11pt;font-family:"Calibri",sans-serif">
Mueller, Milton L
<br>
<b>Sent:</b> Thursday, April 15, 2021 10:34 PM<br>
<b>To:</b> <a href="mailto:gnso-epdp-team@icann.org" target="_blank">gnso-epdp-team@icann.org</a><br>
<b>Subject:</b> RE: [Gnso-epdp-team] On the proposed
guidance<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">Some
legal support for my argument below from Bird & Bird:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal" style="text-indent:0.5in"><a name="m_2854865445665285661__Ref68112068">There may even
be an argument, based on EU Court of Justice (“CJEU”)
caselaw, that this is a situation where Contracted Parties
should generally only be liable should they fail to
properly address a complaint about the data – i.e. only
once they are put on notice about the alleged illegality
and thereby have an opportunity to “verify” the merits of
the complaint.</a><a href="#m_2854865445665285661__ftn2" name="m_2854865445665285661__ftnref2" title=""><span><span>[1]</span></span></a><span> This bears some
parallels to other EU liability regimes for operators of
services online that process – unwittingly – content that
violates EU law.</span><a href="#m_2854865445665285661__ftn3" name="m_2854865445665285661__ftnref3" title=""><span><span>[2]</span></span></a><span> As discussed at
footnote 6 below, this is arguably recognised in (at least
some) decisions of GDPR supervisory authorities.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">In
other words, if personal data finds its way into a
published registration record that should not be there, an
objection can be lodged with the registrar and they can
verify the merits and remove the data. <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">Dr.
Milton L Mueller<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">Georgia
Institute of Technology<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">School
of Public Policy<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><a href="https://internetgovernance.org/" target="_blank"><span style="color:rgb(5,99,193)">Internet
Governance Project</span></a>
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<div>
<div style="border-color:rgb(225,225,225) currentcolor currentcolor;border-style:solid none none;border-width:1pt medium medium;padding:3pt 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11pt;font-family:"Calibri",sans-serif">
Mueller, Milton L
<br>
<b>Sent:</b> Thursday, April 15, 2021 9:14 PM<br>
<b>To:</b> <a href="mailto:gnso-epdp-team@icann.org" target="_blank">gnso-epdp-team@icann.org</a><br>
<b>Subject:</b> FW: [Gnso-epdp-team] On the proposed
guidance<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">>" Everyone who is named in a role in
a registration must have already been informed
<u></u><u></u></p>
<p class="MsoNormal">> and consented to all of the
conditions involved in the role. " This is the ideal. Sadly,
this ideal
<u></u><u></u></p>
<p class="MsoNormal">> is very often not the case.<span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">Whoa.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">Of
course, Volker, it is possible that a person making a
registration for a legal person won’t do it properly. But
it is absurd to expect a registrar to be legally
responsible for that. How can the registrar be liable for
privacy breaches made by the registrant? Indeed, I can’t
understand why gaining the consent of the administrative
assistant of the xyz department to have their name listed
in the whois is a matter for DNS/ICANN policy at all.
ICANN policy simply needs to inform registrants that under
certain conditions the data will be published.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">Let’s
take an extreme case – suppose a nasty IT manager in a
major corporation puts the name, email address and (what
the heck) a revenge porn photo of her ex-husband in her
company’s registration record. Are you telling me the
registrar would be considered responsible for that breach
of privacy? Not the nasty IT manager?
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">Show
me a legal case in which that kind of liability has been
assigned. I doubt you can, but I await the data from CP
lawyers who have been involved in these cases. I do know
of several cases in which agents for a corporation wrongly
listed themselves as the technical and administrative
contact, making it possible for them to hijack the name.
The registrar was NEVER held liable for that.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">Reminder:
We had to reform Whois/RDS policy because ICANN,
<b>as a matter of contractual obligation, required
registrars to publish sensitive PII of any and every
Registrant</b>. Once we have removed that obligation,
and once we have given registrants knowledge of the
conditions under which the data in the record should be
published, I don’t see why registrars need to worry about
some corporation listing the personal email address of
someone in their IT department.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">So
if this alleged risk is being cited to scare us away from
allowing registrants to self-designate as legal or
natural, it is a pretty weak case, imho.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">--MM
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11pt;font-family:"Calibri",sans-serif">
Gnso-epdp-team <<a href="mailto:gnso-epdp-team-bounces@icann.org" target="_blank">gnso-epdp-team-bounces@icann.org</a>>
<b>On Behalf Of </b>Volker Greimann via Gnso-epdp-team<br>
<b>Sent:</b> Thursday, April 15, 2021 10:10 AM<br>
<b>To:</b> Steve Crocker <<a href="mailto:steve@shinkuro.com" target="_blank">steve@shinkuro.com</a>><br>
<b>Cc:</b> <a href="mailto:gnso-epdp-team@icann.org" target="_blank">gnso-epdp-team@icann.org</a><br>
<b>Subject:</b> Re: [Gnso-epdp-team] On the proposed
guidance<u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">Employees are named by other
employees without their knowledge, or remain named long
after they leave. From the experience as a registrar
dealing with registrants every day, this ideal is an
assumption that does not survive contact with reality. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">-- <br>
Volker A. Greimann<br>
General Counsel and Policy Manager<br>
<b>KEY-SYSTEMS GMBH</b><br>
<br>
T: +49 6894 9396901<br>
M: +49 6894 9396851<br>
F: +49 6894 9396851<br>
W: <a href="http://www.key-systems.net/" target="_blank"><span style="color:rgb(17,85,204)">www.key-systems.net</span></a><br>
<br>
Key-Systems GmbH is a company registered at the
local court of Saarbruecken, Germany with the
registration no. HR B 18835<br>
CEO: Oliver Fries and Robert Birkner<br>
<br>
Part of the CentralNic Group PLC (LON: CNIC) a
company registered in England and Wales with
company number 8576358.<br>
<br>
<span style="font-size:10.5pt;font-family:Roboto;background:rgb(248,249,250) none repeat scroll 0% 0%">This
email and any files transmitted are
confidential and intended only for the
person(s) directly addressed. If you are not
the intended recipient, any use, copying,
transmission, distribution, or other forms of
dissemination is strictly prohibited. If you
have received this email in error, please
notify the sender immediately and permanently
delete this email with any files that may be
attached.</span><u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Thu, Apr 15, 2021 at 3:36 PM Steve
Crocker via Gnso-epdp-team <<a href="mailto:gnso-epdp-team@icann.org" target="_blank">gnso-epdp-team@icann.org</a>>
wrote:<u></u><u></u></p>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<div>
<p class="MsoNormal"><span style="font-size:18pt;font-family:"Garamond",serif">Laureen,<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:18pt;font-family:"Garamond",serif"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:18pt;font-family:"Garamond",serif">Thanks
for your note. With respect to the details under
legal person, we believe the issue of consent
should be moot. Everyone who is named in a role
in a registration must have already been informed
and consented to all of the conditions involved in
the role. This is a prerequisite for having a
working system and is not specific to meeting a
privacy regulation. The fact that this
requirement is not specified in the
existing contractual documentation is an error and
needs to be rectified.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:18pt;font-family:"Garamond",serif"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:18pt;font-family:"Garamond",serif">Steve<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:18pt;font-family:"Garamond",serif"><u></u> <u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Thu, Apr 15, 2021 at 6:28 AM
Kapin, Laureen via Gnso-epdp-team <<a href="mailto:gnso-epdp-team@icann.org" target="_blank">gnso-epdp-team@icann.org</a>>
wrote:<u></u><u></u></p>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<div>
<p class="MsoNormal"><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">I
think we share common ground on many key
issues and I would like to build on the many
helpful inputs received as to what would be
advisable. </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)"> </span><u></u><u></u></p>
<p class="MsoNormal"><b><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">Goal</span></b><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">:
publish non-personal, non-protected data to
the greatest extent permissible under the GDPR
and within low legal risks to data controllers
and processors. Note, the description below
does
<i>not </i>fully detail the advised
safeguards which B&B has documented and
which we’ve adopted in our prior input because
my impression is that we generally agree that
the safeguards are prudent. This description
merely seeks to identify the key steps that
must be taken to ensure that personal data is
identified and protected and non-personal data
is published. I also highlight the addition
of a potential additional safeguard –
Confirmation. I think this process
incorporates what we’ve discussed and inputs
received and could form a useful framework for
discussion. </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)"> </span><u></u><u></u></p>
<p class="MsoNormal"><b><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">Note:</span></b><u></u><u></u></p>
<p class="MsoNormal"><b><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)"> </span></b><u></u><u></u></p>
<p><span style="font-size:14pt;font-family:Wingdings;color:rgb(0,32,96)">n</span><span style="font-size:7pt;color:rgb(0,32,96)">
</span><b><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">New
Registrations:
</span></b><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">This
process applies to new registrations (Steve C.
has some useful thoughts on how to deal with
existing Registrations)
</span><u></u><u></u></p>
<p><span style="font-size:14pt;font-family:Wingdings;color:rgb(0,32,96)">n</span><span style="font-size:7pt;color:rgb(0,32,96)">
</span><b><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">Publish:
</span></b><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">When
I use the word “publish,” I mean made public
directly; not via the SSAD.
</span><u></u><u></u></p>
<p><span style="font-size:14pt;font-family:Wingdings;color:rgb(0,32,96)">n</span><span style="font-size:7pt;color:rgb(0,32,96)">
</span><b><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">Flexibility:
</span></b><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">Based
on input from our Registrar colleagues, we
should permit flexibility for how these steps
are implemented to account for the varied
business models in place.
</span><u></u><u></u></p>
<p><span style="font-size:14pt;font-family:Wingdings;color:rgb(0,32,96)">n</span><span style="font-size:7pt;color:rgb(0,32,96)">
</span><b><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">Timing:
</span></b><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">All
identifications need to take place at the time
of registration or shortly thereafter (w/in
the 13-day accuracy verification window) and
no registration data should be published until
the identification, consent, and confirmation
process concludes</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)"> </span><u></u><u></u></p>
<p class="MsoNormal"><b><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">Process:</span></b><u></u><u></u></p>
<p><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">1.</span><span style="font-size:7pt;color:rgb(0,32,96)">
</span><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">A
threshold identification of the registrant as
a natural or legal person;</span><u></u><u></u></p>
<p style="margin-left:1in"><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">a.</span><span style="font-size:7pt;color:rgb(0,32,96)">
</span><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">If
natural, registration info redacted</span><u></u><u></u></p>
<p style="margin-left:1in"><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)"> </span><u></u><u></u></p>
<p style="margin-left:1in"><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">b.</span><span style="font-size:7pt;color:rgb(0,32,96)">
</span><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">If
legal, further inquiries and advisories
(safeguards):</span><u></u><u></u></p>
<p style="margin-left:1.5in"><span style="font-size:7pt;color:rgb(0,32,96)">
</span><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">i.</span><span style="font-size:7pt;color:rgb(0,32,96)">
</span><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">if
the legal person identifies that it has a
protected status under the GDPR</span><u></u><u></u></p>
<p style="margin-left:2in"><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">1.</span><span style="font-size:7pt;color:rgb(0,32,96)">
</span><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">registration
info redacted</span><u></u><u></u></p>
<p style="margin-left:2in"><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)"> </span><u></u><u></u></p>
<p style="margin-left:1.5in"><span style="font-size:7pt;color:rgb(0,32,96)">
</span><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">ii.</span><span style="font-size:7pt;color:rgb(0,32,96)">
</span><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">If
the legal person registration contains
personal data, advise of consequences
(publication)</span><u></u><u></u></p>
<p style="margin-left:2in"><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">1.</span><span style="font-size:7pt;color:rgb(0,32,96)">
</span><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">Obtain
necessary consents</span><u></u><u></u></p>
<p style="margin-left:2in"><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">2.</span><span style="font-size:7pt;color:rgb(0,32,96)">
</span><i><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">Possible
additional safeguard</span></i><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">:
<i>Ask Registrant to Confirm any
identification that will result in
publication of contact data
</i>(akin to confirming a flight reservation
or stock trade)</span><u></u><u></u></p>
<p style="margin-left:2.5in"><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">a.</span><span style="font-size:7pt;color:rgb(0,32,96)">
</span><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">Publish
</span><u></u><u></u></p>
<p style="margin-left:2in"><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">3.</span><span style="font-size:7pt;color:rgb(0,32,96)">
</span><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">If
no consent</span><u></u><u></u></p>
<p style="margin-left:2.5in"><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">a.</span><span style="font-size:7pt;color:rgb(0,32,96)">
</span><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">Redact</span><u></u><u></u></p>
<p style="margin-left:2in"><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)"> </span><u></u><u></u></p>
<p><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">2.</span><span style="font-size:7pt;color:rgb(0,32,96)">
</span><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">Provide
quick and easy opportunity to correct any
mistakes</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)">I
hope this is useful.
</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:14pt;font-family:"Helvetica",sans-serif;color:rgb(88,0,176)">Kind
regards,</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:14pt;font-family:"Helvetica",sans-serif;color:rgb(88,0,176)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:14pt;font-family:"Helvetica",sans-serif;color:rgb(88,0,176)">Laureen
Kapin</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:14pt;font-family:"Helvetica",sans-serif;color:rgb(88,0,176)">Counsel
for International Consumer Protection</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:14pt;font-family:"Helvetica",sans-serif;color:rgb(88,0,176)">Federal
Trade Commission</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:14pt;font-family:"Helvetica",sans-serif;color:rgb(88,0,176)">(202)
326-3237
</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:14pt;font-family:"Arial",sans-serif;color:rgb(0,32,96)"> </span><u></u><u></u></p>
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11pt;font-family:"Calibri",sans-serif">
Gnso-epdp-team <<a href="mailto:gnso-epdp-team-bounces@icann.org" target="_blank">gnso-epdp-team-bounces@icann.org</a>>
<b>On Behalf Of </b>Volker Greimann via
Gnso-epdp-team<br>
<b>Sent:</b> Thursday, April 15, 2021 8:35 AM<br>
<b>To:</b> Hadia Abdelsalam Mokhtar EL miniawi
<<a href="mailto:Hadia@tra.gov.eg" target="_blank">Hadia@tra.gov.eg</a>><br>
<b>Cc:</b> <a href="mailto:gnso-epdp-team@icann.org" target="_blank">gnso-epdp-team@icann.org</a><br>
<b>Subject:</b> Re: [Gnso-epdp-team] On the
proposed guidance</span><u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">I
think we need to be cognisant of the current
status quo and use that as the basis for our
thoughts on the matter:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">1)
There is no differentiation between legal or
natural contacts.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">2)
The redaction of all contacts is permitted
and has become the de-facto standard.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">3)
We allow consent-based disclosure.
<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">4)
NIS 2 may at some point in the future
require publication of non-personal
information.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">This
leads to two very simple follow-on
questions:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">a)
How do we identify such non-personal
information? What is really necessary for
this end?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">b)
What would publication entail?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">For
a) we and Twobirds identified voluntary
self-declaration of the data submitted. As
all data is redacted by default, the
differentiation of the data subject category
is irrelevant as it ultimately only boils
down to the declaration of the data subject
thatthe data contains no personal
information.
<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">For
b), the term "publish" is undefined. For all
we know, it could mean publication in a
physical print edition (it doesn't mean that
though). But publication within SSAD can
very well be sufficient for that definition.
There is no reason whatsoever to assume
differently.
<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">-- <br>
Volker A. Greimann<br>
General Counsel and Policy Manager<br>
<b>KEY-SYSTEMS GMBH</b><br>
<br>
T: +49 6894 9396901<br>
M: +49 6894 9396851<br>
F: +49 6894 9396851<br>
W: <a href="http://www.key-systems.net/" target="_blank"><span style="color:rgb(17,85,204)">www.key-systems.net</span></a><br>
<br>
Key-Systems GmbH is a company
registered at the local court of
Saarbruecken, Germany with the
registration no. HR B 18835<br>
CEO: Oliver Fries and Robert
Birkner<br>
<br>
Part of the CentralNic Group PLC
(LON: CNIC) a company registered
in England and Wales with company
number 8576358.<br>
<br>
<span style="font-size:10.5pt;font-family:Roboto;background:rgb(248,249,250) none repeat scroll 0% 0%">This
email and any files transmitted
are confidential and intended
only for the person(s) directly
addressed. If you are not the
intended recipient, any use,
copying, transmission,
distribution, or other forms of
dissemination is strictly
prohibited. If you have received
this email in error, please
notify the sender immediately
and permanently delete this
email with any files that may be
attached.</span><u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<div id="gmail-m_2854865445665285661gmail-m_-3565268638294194630gmail-m_7094575180366425829DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2">
<p class="MsoNormal"> <u></u><u></u></p>
<table style="border-style:solid none none;border-width:1pt medium medium;border-color:currentcolor" cellspacing="3" cellpadding="0" border="1">
<tbody>
<tr>
<td style="width:41.25pt;border:medium none;padding:9.75pt 0.75pt 0.75pt" width="57">
<p class="MsoNormal"><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail" target="_blank"><span style="text-decoration:none"><img style="width: 0.4791in; height: 0.3055in;" id="gmail-m_2854865445665285661gmail-m_-3565268638294194630gmail-m_7094575180366425829_x005f_x0000_i1025" src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif" width="46" height="29" border="0"></span></a><u></u><u></u></p>
</td>
<td style="width:352.5pt;border:medium none;padding:9pt 0.75pt 0.75pt" width="397">
<p class="MsoNormal" style="line-height:13.5pt"><span style="font-size:10pt;font-family:"Arial",sans-serif;color:rgb(65,66,78)">Virus-free.
<a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail" target="_blank">
<span style="color:rgb(68,83,234)">www.avast.com</span></a>
</span><u></u><u></u></p>
</td>
</tr>
</tbody>
</table>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">On
Thu, Apr 15, 2021 at 1:52 PM Hadia
Abdelsalam Mokhtar EL miniawi via
Gnso-epdp-team <<a href="mailto:gnso-epdp-team@icann.org" target="_blank">gnso-epdp-team@icann.org</a>>
wrote:<u></u><u></u></p>
</div>
<blockquote style="border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt;border-color:currentcolor currentcolor currentcolor rgb(204,204,204)">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">Dear
Milton,</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">Thank
you for your constructive thoughts. I
believe we have a lot to build on. In
relation to principle one, I think we
all agree that some legal data
subjects would want to publish their
data in the RDDS, but without your
first principle they can only do this
through consent. The legal memo
received lately from Bird & Bird
explains that if CPs publish the data
of legal persons based on consent they
are at a higher risk than if they
publish the data of legal persons
based on self-designation. In the
latter case CPs might only be liable
if they fail to address a complaint.
So the question always was: what is
the benefit of labeling the data as
belonging to a natural or legal
person? Of course we all know that
GDPR protects the data of natural
persons and not legal persons, but the
important answer now is that the
distinction significantly reduces the
liability of CPs. In addition, the
distinction is helpful in performing
the balancing test in case the data is
not published and I am sure if we look
into individual use cases we can find
much more benefits. Moreover, it could
prove to be useful regarding possible
upcoming regulations. I would also add
that the level of protection assigned
to the data elements suggested by
Steve provides additional safe guards
and flexibility in the implementation.
</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">Finally,
I join you in being optimistic about
our ability to finish this.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">Kind
regards</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">Hadia
</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
<div>
<div style="border-style:solid none none;border-width:1pt medium medium;padding:3pt 0in 0in;border-color:currentcolor">
<p class="MsoNormal"><b><span style="font-size:10pt;font-family:"Tahoma",sans-serif">From:</span></b><span style="font-size:10pt;font-family:"Tahoma",sans-serif">
Gnso-epdp-team [mailto:<a href="mailto:gnso-epdp-team-bounces@icann.org" target="_blank">gnso-epdp-team-bounces@icann.org</a>]
<b>On Behalf Of </b>Mueller,
Milton L via Gnso-epdp-team<br>
<b>Sent:</b> Wednesday, April 14,
2021 10:12 PM<br>
<b>To:</b> <a href="mailto:gnso-epdp-team@icann.org" target="_blank">gnso-epdp-team@icann.org</a><br>
<b>Subject:</b> Re:
[Gnso-epdp-team] On the proposed
guidance</span><u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">Colleagues:</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">I
have only gotten time to review
the latest Guidance document and
the surrounding debate today.
Apologies, but there is a lot
going on in my day job. </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">I
am disappointed to see that we
seem to be going backwards. I see
divergence rather than convergence
on the way we are approaching the
problem.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">I
see no point in adding more noise
to the current document via the
Comments function. What I would
like to try to do is articulate
some broad principles about how to
deal with the legal/natural
distinction. If we can agree on
those principles, it will be
relatively easy to complete the
document. If we cannot/do not
agree on those principles,
additional wordsmithing and
debates over terms will not get us
anywhere. </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">So
here are the broad principles that
I would offer up for debate:
</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">1.</span><span style="font-size:7pt;color:rgb(31,73,125)">
</span><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">The
legal/natural distinction is
relevant and we need to find a way
make it in RDDS without
compromising privacy rights.
</span><u></u><u></u></p>
<p><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">2.</span><span style="font-size:7pt;color:rgb(31,73,125)">
</span><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">Registrants
should be able to self-designate
as legal or natural, with no
burden of authentication placed on
registrars or registries</span><u></u><u></u></p>
<p><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">3.</span><span style="font-size:7pt;color:rgb(31,73,125)">
</span><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">To
protect small home offices or NGOs
who are technically Legal persons
but whose registration data may
include Personal data, we need an
additional check in the process.</span><u></u><u></u></p>
<p><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">4.</span><span style="font-size:7pt;color:rgb(31,73,125)">
</span><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">As
long as they conform with the
above 3 principles,
registrars/ries (CPs) should be
given maximum flexibility to
choose the way to differentiate.
</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">Principle
1 discussion:</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">If
we cannot agree on this (or agree
to abandon this principle), _<i>nothing
else will fall into place</i>_.
Ever. So let’s settle that. Steve
and Volker I suspect will disagree
with this principle. Steve has
argued that the L/N distinction is
“not a central concern” and all
that matters is whether the
registrant’s data is to be made
available to anyone. If he is
right, we can discard the guidance
altogether, because we already
have a recommendation to allow the
RNH to consent to the publication
of their data. Volker has also
suggested that it is personal data
we need to differentiate, not L/N
. I disagree with Steve and Volker
on this and so do most of the rest
of the group. L/N distinction is a
central concern to certain
stakeholder groups in the EPDP,
because a) GDPR and other data
protection laws do not protect it
and this process is all about
bringing RDS into compliance with
privacy law; b) Legal person data
could be published and it would
provide easier access to their
registration data. As a NCSG
member I can find no basis for
objecting to the publication of
WalMart’s, Kroger’s or the local
hardware store’s registration
data. Any concerns about PII are
addressed by principles 2 and 3.
Steve is approaching this as an
engineer, but this is a policy
process, and we will not obtain
agreement on a solution unless
certain stakeholders are
satisfied. If they think it is a
central concern, it’s a central
concern, that’s how
policy/politics work.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">Principle
2 discussion</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">This
is the key principle that keeps
NCSG and CPH satisfied.
Registrants are in control of how
they are designated. Yes, this
means that some people will lie.
That is just something we will
have to accept. One cannot erase
that possibility without creating
a system that is too burdensome
and costly as to outweigh any
benefits.
</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">Principle
3 discussion</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">This
is something everyone seems to
agree on already. But it is good
to make it explicit, then we can
work out how specific our guidance
can get, so as to conform to …</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">Principle
4</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">Avoid
being overly prescriptive, but
ensure that the other 3 principles
are honored. So yes, Volker, we
give you maximum flexibility to
implement in accordance with
different business models, but you
can NOT make a designation for a
RNH, because it violates principle
2.
</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">I
truly believe that if we can come
to agreement on these 4 principles
and use them as the basis for
drafting guidance, we can actually
finish this.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
Gnso-epdp-team mailing list<br>
<a href="mailto:Gnso-epdp-team@icann.org" target="_blank">Gnso-epdp-team@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-epdp-team" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-epdp-team</a><br>
_______________________________________________<br>
By submitting your personal data, you
consent to the processing of your personal
data for purposes of subscribing to this
mailing list accordance with the ICANN
Privacy Policy (<a href="https://www.icann.org/privacy/policy" target="_blank">https://www.icann.org/privacy/policy</a>)
and the website Terms of Service (<a href="https://www.icann.org/privacy/tos" target="_blank">https://www.icann.org/privacy/tos</a>).
You can visit the Mailman link above to
change your membership status or
configuration, including unsubscribing,
setting digest-style delivery or disabling
delivery altogether (e.g., for a vacation),
and so on.<u></u><u></u></p>
</blockquote>
</div>
<div id="gmail-m_2854865445665285661gmail-m_-3565268638294194630gmail-m_7094575180366425829DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2">
<p class="MsoNormal"> <u></u><u></u></p>
<table style="border-style:solid none none;border-width:1pt medium medium;border-color:currentcolor" cellspacing="3" cellpadding="0" border="1">
<tbody>
<tr>
<td style="width:41.25pt;border:medium none;padding:9.75pt 0.75pt 0.75pt" width="57">
<p class="MsoNormal"><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail" target="_blank"><span style="text-decoration:none"><img style="width: 0.4791in; height: 0.3055in;" id="gmail-m_2854865445665285661gmail-m_-3565268638294194630gmail-m_7094575180366425829_x005f_x0000_i1026" src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif" width="46" height="29" border="0"></span></a><u></u><u></u></p>
</td>
<td style="width:352.5pt;border:medium none;padding:9pt 0.75pt 0.75pt" width="397">
<p class="MsoNormal" style="line-height:13.5pt"><span style="font-size:10pt;font-family:"Arial",sans-serif;color:rgb(65,66,78)">Virus-free.
<a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail" target="_blank">
<span style="color:rgb(68,83,234)">www.avast.com</span></a>
</span><u></u><u></u></p>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
Gnso-epdp-team mailing list<br>
<a href="mailto:Gnso-epdp-team@icann.org" target="_blank">Gnso-epdp-team@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-epdp-team" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-epdp-team</a><br>
_______________________________________________<br>
By submitting your personal data, you consent to the
processing of your personal data for purposes of
subscribing to this mailing list accordance with the
ICANN Privacy Policy (<a href="https://www.icann.org/privacy/policy" target="_blank">https://www.icann.org/privacy/policy</a>)
and the website Terms of Service (<a href="https://www.icann.org/privacy/tos" target="_blank">https://www.icann.org/privacy/tos</a>).
You can visit the Mailman link above to change your
membership status or configuration, including
unsubscribing, setting digest-style delivery or
disabling delivery altogether (e.g., for a
vacation), and so on.<u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal">_______________________________________________<br>
Gnso-epdp-team mailing list<br>
<a href="mailto:Gnso-epdp-team@icann.org" target="_blank">Gnso-epdp-team@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-epdp-team" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-epdp-team</a><br>
_______________________________________________<br>
By submitting your personal data, you consent to the
processing of your personal data for purposes of
subscribing to this mailing list accordance with the
ICANN Privacy Policy (<a href="https://www.icann.org/privacy/policy" target="_blank">https://www.icann.org/privacy/policy</a>)
and the website Terms of Service (<a href="https://www.icann.org/privacy/tos" target="_blank">https://www.icann.org/privacy/tos</a>).
You can visit the Mailman link above to change your
membership status or configuration, including
unsubscribing, setting digest-style delivery or
disabling delivery altogether (e.g., for a vacation),
and so on.<u></u><u></u></p>
</blockquote>
</div>
<div>
<p class="MsoNormal"><br clear="all">
<u></u><u></u></p>
<div class="MsoNormal">
<hr width="33%" size="1" align="left">
</div>
</div>
</div>
<div><br clear="all">
<hr width="33%" size="1" align="left">
<div id="gmail-m_2854865445665285661ftn1">
<p><a href="#m_2854865445665285661__ftnref1" name="m_2854865445665285661__ftn1" title=""><span><span><span style="font-size:8pt;font-family:"Georgia",serif">[1]</span></span></span></a>
As explained above, we have understood this question to be
asking about scenarios where Registrants are legal
persons, as per the EDPB quote at paragraph 1. In respect
of individual (natural person) Registrants, the issues
will be largely similar: if a natural person incorrectly
states that their data is not personal data, then (i) the
verification measures should prevent the data from being
published, since they will give the data subject an
opportunity to correct their mistake; (ii) the mitigating
factors and legal arguments described at paragraphs 11.7
and 11.8 and paragraphs 14.1 - 14.6 here, should confer
reasonable legal protection for Contracted Parties.<span lang="EN-GB"><u></u><u></u></span></p>
</div>
<div id="gmail-m_2854865445665285661ftn2">
<p><a href="#m_2854865445665285661__ftnref2" name="m_2854865445665285661__ftn2" title=""><span><span lang="EN-GB">[1]</span></span></a><span lang="EN-GB"> In its judgement in Case C</span><span style="font-family:"Times New Roman",serif" lang="EN-GB">‑</span><span lang="EN-GB">136/17
<i>GC and Others</i>, the CJEU explained that GDPR
obligations relating to an erasure (“Right to Be
Forgotten”) request apply “<i>to the operator of a
search engine in the context of his responsibilities,
powers and capabilities as the controller of the
processing carried out in connection with the activity
of the search engine, on the occasion of a
verification performed by that operator, under the
supervision of the competent national authorities,
following a request by the data subject”</i>. As the
Advocate General explained in that case, “<i>such an
operator can act only within the framework of its
responsibilities, powers and capabilities. In other
words, such an operator may be incapable of ensuring
the full effect of the provisions of [EU data
protection law], precisely because of its limited
responsibilities, powers and capabilities. . . An ex
ante control of internet pages which are referenced as
the result of a search does not fall within the
responsibilities or the capabilities of a search
engine</i>.” It could not know, from the moment it
indexed a webpage, that the content of that page was
(for example) out of date (as in the original
<i>Google Spain / Costeja</i> ruling), or (in the <i>GC
and Others</i> case<i>) </i>
“special category” or “criminal offence” data for which
it required consent.<u></u><u></u></span></p>
</div>
<div id="gmail-m_2854865445665285661ftn3">
<p><a href="#m_2854865445665285661__ftnref3" name="m_2854865445665285661__ftn3" title=""><span><span lang="EN-GB">[2]</span></span></a><span lang="EN-GB"> See, for example,
<a href="https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=celex%3A32000L0031" target="_blank">
Article 14</a> of the e-Commerce Directive 2000/31/EC
and its transposition into the national laws of EU/EEA
Member States and the UK.
<u></u><u></u></span></p>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Gnso-epdp-team mailing list
<a href="mailto:Gnso-epdp-team@icann.org" target="_blank">Gnso-epdp-team@icann.org</a>
<a href="https://mm.icann.org/mailman/listinfo/gnso-epdp-team" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-epdp-team</a>
_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (<a href="https://www.icann.org/privacy/policy" target="_blank">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a href="https://www.icann.org/privacy/tos" target="_blank">https://www.icann.org/privacy/tos</a>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.</pre>
</blockquote>
</div>
_______________________________________________<br>
Gnso-epdp-team mailing list<br>
<a href="mailto:Gnso-epdp-team@icann.org" target="_blank">Gnso-epdp-team@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-epdp-team" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-epdp-team</a><br>
_______________________________________________<br>
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (<a href="https://www.icann.org/privacy/policy" rel="noreferrer" target="_blank">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a href="https://www.icann.org/privacy/tos" rel="noreferrer" target="_blank">https://www.icann.org/privacy/tos</a>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.</blockquote></div>