<div>+1 Volker<br></div><div><br></div><div class="protonmail_signature_block"><div class="protonmail_signature_block-user"><div>-- Ayden <br></div></div><div class="protonmail_signature_block-proton protonmail_signature_block-empty"><br></div></div><div><br></div><div>‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐<br></div><div> On Monday, 26 August 2019 17:55, Volker Greimann <vgreimann@key-systems.net> wrote:<br></div><div> <br></div><blockquote class="protonmail_quote" type="cite"><p>Thanks Hadia, but everything that needed to be said with regard
to this use case has been said already and instead of r-iterating
every argument I merely point towards what has been discussed
before. This use case is not fit for RDS access.<br></p><p>Best,<br></p><p>Volker<br></p><p><br></p><div class="moz-cite-prefix">Am 26.08.2019 um 17:37 schrieb Hadia
Abdelsalam Mokhtar EL miniawi:<br></div><blockquote type="cite"><div><p><span style="color:rgb(31, 73, 125)"><span style="font-family:"Calibri", "sans-serif""><span style="font-size:11pt"> </span></span></span><br></p><p><span style="color:rgb(31, 73, 125)"><span style="font-family:"Calibri", "sans-serif""><span style="font-size:11pt">Hello
All,</span></span></span><br></p><p><span style="color:rgb(31, 73, 125)"><span style="font-family:"Calibri", "sans-serif""><span style="font-size:11pt"> </span></span></span><br></p><p><span style="color:rgb(31, 73, 125)"><span style="font-family:"Calibri", "sans-serif""><span style="font-size:11pt">The
ALAC online buyers online case is a real life scenario for
why there needs to be a distinction between natural and
legal persons. I shall not get into this debate. However, I
note that consumers identity and even location is now
available to buyers through many online applications, GDPR
protects personal information of natural persons and not
legal persons. It is only fair to Internet end users to
allow them to have the contact information of the online
businesses. This is particularly important in case Internet
end users are dealing with small businesses online. You can
find online businesses contact details now through some
existing applications. What and who are we trying to protect
by not allowing this use case. Commercial websites should be
encouraged to indicate who they are and publish their
information. The architecture of the web inherently does not
require real identity, but having a complete anonymous
system is always an invitation to problems, making people
feel less accountable and diminishing the trust in the
network. A survey conducted by Bright Local showed that 60%
of customers prefer to call small businesses on the phone.
The survey also showed that consumers now look beyond
websites, RDS is only one tool of many however, prohibiting
it to exist works against the norm. I also note that getting
clarity in relation to the contracted parties liability in
this regard is very important and if implemented information
should only be provided if the case is absolutely clear.</span></span></span><br></p><p><span style="color:rgb(31, 73, 125)"><span style="font-family:"Calibri", "sans-serif""><span style="font-size:11pt"> </span></span></span><br></p><p><span style="color:rgb(31, 73, 125)"><span style="font-family:"Calibri", "sans-serif""><span style="font-size:11pt">I
attach the updated user case, which is also available
through the google doc</span></span></span><br></p><p><span style="color:rgb(31, 73, 125)"><span style="font-family:"Calibri", "sans-serif""><span style="font-size:11pt"> </span></span></span><br></p><p><span style="color:rgb(31, 73, 125)"><span style="font-family:"Calibri", "sans-serif""><span style="font-size:11pt">Best</span></span></span><br></p><p><span style="color:rgb(31, 73, 125)"><span style="font-family:"Calibri", "sans-serif""><span style="font-size:11pt">Hadia
el-Miniawi </span></span></span><br></p><p><span style="color:rgb(31, 73, 125)"><span style="font-family:"Calibri", "sans-serif""><span style="font-size:11pt"> </span></span></span><br></p><div><div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0in 0in 0in"><p><b><span style="font-family:"Tahoma", "sans-serif""><span style="font-size:10pt">From:</span></span></b><span style="font-family:"Tahoma", "sans-serif""><span style="font-size:10pt"> Gnso-epdp-team [<a href="mailto:gnso-epdp-team-bounces@icann.org">mailto:gnso-epdp-team-bounces@icann.org</a>] <b>On Behalf Of </b>Mueller, Milton L<br> <b>Sent:</b> Monday, August 19, 2019 5:27 PM<br> <b>To:</b> Tara Whalen; <a href="mailto:gnso-epdp-team@icann.org">gnso-epdp-team@icann.org</a><br> <b>Subject:</b> Re: [Gnso-epdp-team] Notes and action
items from EPDP Team Phase 2 Meeting #11 - 1 August 2019
- ALAC Online buyers Use Case</span></span></p></div></div><p> <br></p><p><span style="color:rgb(31, 73, 125)"><span style="font-family:"Calibri", "sans-serif""><span style="font-size:11pt">Tara:</span></span></span><br></p><p><span style="color:rgb(31, 73, 125)"><span style="font-family:"Calibri", "sans-serif""><span style="font-size:11pt">Responses
inline below:</span></span></span><br></p><p><span style="color:rgb(31, 73, 125)"><span style="font-family:"Calibri", "sans-serif""><span style="font-size:11pt"> </span></span></span><br></p><div><div><ol style="margin-top:0in" type="1" start="1"><li style="mso-list:l1 level1 lfo1"><span style="color:black"><span style="font-family:"Arial", "sans-serif"">The
ICANN Board resolved in May to have the ePDP
“determine and resolve the Legal vs. Natural issue in
Phase 2." <a href="https://www.icann.org/resources/board-material/resolutions-2019-05-15-en#1.b" target="_blank">https://www.icann.org/resources/board-material/resolutions-2019-05-15-en#1.b</a>
Because the issue is not decided.</span></span><br></li></ol><p style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"><span style="font-family:"Calibri", "sans-serif""><span style="font-size:11pt"> </span></span></span><span style="color:rgb(31, 73, 125)"><span style="font-family:"Calibri", "sans-serif""><span style="font-size:11pt">Not
quite correct. The Board noted that EPDP’s own
Recommendation said that we would resolve the issue in
Phase 2. The board did not tell us to do so. The
resolution also notes the “</span></span></span><span style="background-color:white"><span style="color:rgb(31, 78, 121)"><span style="font-family:"Calibri", "sans-serif""><span style="font-size:11pt">Potential
liability of a registered name holder's incorrect
self-identification of a natural or legal person, which
ultimately results in public display of personal data.”
This concern was one of several that motivated our
reluctance to attempt differentiation.</span></span></span></span><span style="color:rgb(31, 78, 121)"><span style="font-family:"Calibri", "sans-serif""><span style="font-size:10pt"></span></span></span><br></p><ol style="margin-top:0in" type="1" start="2"><li style="mso-list:l2 level1 lfo2"><span style="color:black"><span style="font-family:"Arial", "sans-serif"">The
EWG recommended a differentiation solution -- that
registrants be required to identify as a Registrant
Type, with Legal Person and Natural Person among the
options. It also required that a mandatory Business
PBC be published for “Registrants that self-identify
as Legal Persons engaged in commercial activity"
(pages 42-44 of final report). <span> </span></span></span><br></li></ol><p style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:rgb(31, 73, 125)"><span style="font-family:"Calibri", "sans-serif""><span style="font-size:11pt">This
option _<i>was</i>_ discussed and discarded in Phase 1.
It was noted that to the vast majority of ordinary
people the distinction between legal and natural has no
meaning, and that there would be liability consequences
if there were incorrect identification (see above). And
besides, the recommendation of the EWG was made prior to
GDPR and has no bearing on EPDP.</span></span></span><span style="font-family:"Calibri", "sans-serif""><span style="font-size:11pt"></span></span><br></p><ol style="margin-top:0in" type="1" start="3"><li style="mso-list:l3 level1 lfo3"><span style="color:black"><span style="font-family:"Arial", "sans-serif"">ICANN’s
Procedure for Handling WHOIS Conflicts with Privacy
Law was reviewed by the GNSO and revised in mid-2017.
A goal of the Procedure was “to resolve the problem in
a manner that preserves the ability of the
registrar/registry to comply with its [current]
contractual WHOIS obligations to the greatest extent
possible”. So -- to publish as much data as possible
as allowed by law.</span></span><br></li></ol><p style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"><span style="font-family:"Arial", "sans-serif""> </span></span><span style="color:rgb(31, 73, 125)"><span style="font-family:"Calibri", "sans-serif""><span style="font-size:11pt">Now
you are way off base. Contractual Whois obligations in
2017 were not compliant with GDPR. The Conflicts with
Privacy Law procedure is completely irrelevant to our
proceedings.</span></span></span><span style="font-family:"Calibri", "sans-serif""><span style="font-size:11pt"></span></span><br></p><ol style="margin-top:0in" type="1" start="4"><li style="mso-list:l0 level1 lfo4"><span style="color:black"><span style="font-family:"Arial", "sans-serif"">Under
that Procedure, about the only precedent was the .TEL
case, which addressed concerns raised by UK privacy
law. In that case, the WHOIS service was made to
differentiate between natural and legal persons. Some
public WHOIS data was limited for natural persons who
had elected to withhold their personal information
from disclosure by the WHOIS service, records for
Legal Persons had to return full and complete WHOIS
data (including applicable personal data), and Legal
Persons were not permitted to opt out of disclosing
such information. The GDPR is definitely a different
law and may yield a different policy. But the .TEL
case did show that it’s possible to tell the
difference between a natural person’s data and a legal
person’s data, and to control where that data appears.</span></span><br></li></ol><p style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:black"><span style="font-family:"Calibri", "sans-serif""><span style="font-size:11pt"> </span></span></span><span style="color:rgb(31, 73, 125)"><span style="font-family:"Calibri", "sans-serif""><span style="font-size:11pt">Same
comment as above. </span></span></span><span style="font-family:"Calibri", "sans-serif""><span style="font-size:11pt"></span></span><br></p></div></div></div><div><br></div><pre wrap>_______________________________________________
Gnso-epdp-team mailing list
<a href="mailto:Gnso-epdp-team@icann.org">Gnso-epdp-team@icann.org</a>
<a href="https://mm.icann.org/mailman/listinfo/gnso-epdp-team">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">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a href="https://www.icann.org/privacy/tos">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.<br></pre></blockquote><div><div>-- <br></div><div> Volker A. Greimann<br></div><div> General Counsel and Policy Manager<br></div><div> <b>KEY-SYSTEMS GMBH</b><br></div><div> <br></div><div> T: +49 6894 9396901<br></div><div> M: +49 6894 9396851<br></div><div> F: +49 6894 9396851<br></div><div> W: <a href="http://www.key-systems.net">www.key-systems.net</a><br></div><div> <br></div><div> Key-Systems GmbH is a company registered at the local court of
Saarbruecken, Germany with the registration no. HR B 18835<br></div><div> CEO: Alexander Siffrin<br></div><div> <br></div><div> Part of the CentralNic Group PLC (LON: CNIC) a company registered
in England and Wales with company number 8576358.<br></div></div></blockquote><div><br></div>