<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>How many times does this have to be re-iterated? It does not
matter whether the registrant is a legal or natural person. It
just matters if their data contains data of a natural person. So
even the data of a legal entity registrant can contain personal
information that must be protected. <br>
</p>
<p>And as you are so fond of the law, the law states that the basic
principle is privacy by design. That means, when in doubt, err on
the side of privacy. Protecting the data of legal entity when in
doubt is perfectly in line with legal requirements.</p>
<p>Can we end this debate now, please? We are wasting our cycles on
re-runs here!</p>
<p>Best,</p>
<p>Volker<br>
</p>
<div class="moz-cite-prefix">Am 02.09.2019 um 06:07 schrieb Alan
Greenberg:<br>
</div>
<blockquote type="cite"
cite="mid:YQBPR0101MB0754023B46B26462FEFCF82B93BE0@YQBPR0101MB0754.CANPRD01.PROD.OUTLOOK.COM">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
And I will make one last attempt as well. Although I am not sure I
agree that "it is unlikely if not impossible to ever provide a
legitimate rationale for disclosure", but I agree it would not be
common. So your analysis is spot on. *IF* the registrant is a
natural person and protected by GDPR.<br>
<br>
Although the issue is still on our Phase 2 list, in Phase 1 we
decided that contracted parties are not obligated to differentiate
between legal and natural persons. That set what they may or may
not put in the public RDS. And it relieved contracted parties from
having to recognize legal persons and treat them differently at
the time the RDS information is set.
<u>But it did not change the law!</u> <br>
<br>
If the registrar can tell (perhaps by looking at their customer
contact information) that the registrant is a legal person, and
that there is no personal information in the contact details, then
there is no balancing test that must be made.<br>
<br>
Alan<br>
<br>
<br>
<br>
<br>
At 31/08/2019 06:10 PM, Mueller, Milton L wrote:<br>
<blockquote type="cite" class="cite" cite="">Alan,<br>
I think we are still talking past each other. I will make one
last effort. <br>
<br>
The purpose of the use cases was to test our assumptions about
what would lead to a successful request for disclosure, what
kinds of legal bases would be used and what kind of safeguards
would have to be in place.
<br>
<br>
The ALAC use case we are debating was about disclosing the
identity of a registrant because a random Internet user is
curious about who the registrant is and thinks they need to know
this before buying something from the registrant. I think our
discussion of this case clearly demonstrated that this rationale
will never pass the balancing test and does not even meet the
threshold of 6.1.b. I say this because:
<br>
1. Curious users can easily, effectively and directly
protect themselves from this uncertainty by not buying or
interacting with unknown or untrusted sites/domains;<br>
2. Curious users can find the needed information about the
website from other potential sources besides Whois, including,
in many jurisdictions, laws that require such info to be
published;<br>
3. The fact that this curiosity occurs before any harm has
been done means that such a claim will always fail the balancing
test (what is the legitimate interest of the requestor?)
<br>
4. Curiosity about who is behind a domain in the absence
of any harm or demonstrable problem was the rationale behind the
openness of the old Whois, which is known to be illegal.
<br>
<br>
So Amr backed off from the notion of βrejecting this use
case,β but I think his initial statement was valid. Our
discussion of this proposed use case demonstrated that it is
unlikely if not impossible to ever provide a legitimate
rationale for disclosure. We appreciate your bringing it up as a
possible use case, which as you note is what you were asked to
do. Now that we have discussed it we are simply asking you and
Hadia to recognize that it is not going to provide a sufficient
rationale for disclosure of private info. <br>
<br>
--MM<br>
<br>
<b>From:</b> Gnso-epdp-team
<a class="moz-txt-link-rfc2396E" href="mailto:gnso-epdp-team-bounces@icann.org"><gnso-epdp-team-bounces@icann.org></a> <b>On Behalf Of </b>
Amr Elsadr<br>
<b>Sent:</b> Thursday, August 29, 2019 6:59 AM<br>
<b>To:</b> Alan Greenberg <a class="moz-txt-link-rfc2396E" href="mailto:alan.greenberg@mcgill.ca"><alan.greenberg@mcgill.ca></a><br>
<b>Cc:</b> <a class="moz-txt-link-abbreviated" 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<br>
<br>
Hi Alan,<br>
<br>
I take your point on rejection of a use case, and perhaps I
should have been more precise in what I was trying to say. I
chose my words poorly, but I hope you understand what Iβm
getting at. I did, after all, acknowledge that discussing this
use case has been helpful to our work.<br>
<br>
What I meant to say was that this use case should not result in
recommendations resulting in granting disclosure of gTLD
registration data to Internet users (not referring to TM holders
here) upon request, with the aim of them identifying persons
(natural or legal) conducting commerce online. The question of
wether an ICANN Consensus Policy grants the same level of
privacy protection to both the personal information of legal and
natural persons is a separate issue of course, with its own set
of arguments.<br>
<br>
Thanks.<br>
<br>
Amr<br>
<br>
<br>
<dl>
<dd>On Aug 29, 2019, at 1:51 AM, Alan Greenberg <<a
href="mailto:alan.greenberg@mcgill.ca"
moz-do-not-send="true">alan.greenberg@mcgill.ca</a> >
wrote:<br>
</dd>
<dd> <br>
</dd>
<dd>Amr, as few points.<br>
<br>
</dd>
<dd>1. This use case is NOT about content. It is true that the
user request *MAY* have been triggered by content of a web
site. But it could equally well have been triggered by an
e-mail received. Or just the semantics of the domain name. A
registrar *might* choose to use any web content as a basis
for responding positively or negatively to such a request
for access, but it could also use its own database of its
customer information to determine if the registrant is a
legal person. What the registrar does in resolving an access
request will not be dictated by any ICANN policy and is
purely up to its business practices.<br>
<br>
</dd>
<dd>2. I really do not understand the concept if us
"rejecting" a use case. We were asked to identify potential
use cases and we did. You captured the validity of the case
at the end of your message: "there is still nothing
preventing an Internet user from requesting information
about a website they might do business with from a
registrar". Any EPDP rejection notwithstanding, a user may
still request access to information about a registrant that
she believes may be a legal person. And a registrar/registry
may ultimately agree to grant that access - or not.
Therefore it *IS* a user case, albeit perhaps one you don't
like.
<br>
<br>
</dd>
<dd>Nothing in this use case presupposes that access will be
granted, nor does it presume that such a use will be handled
in anything but a manual mode with the registrar performing
the "balancing" as dictated by GDPR.<br>
<br>
</dd>
<dd>Alan<br>
<br>
</dd>
<dd>At 28/08/2019 03:30 PM, Amr Elsadr wrote:<br>
<br>
<dl>
<dd>Hi Brian,<br>
<br>
</dd>
<dd>I'm not sure that it makes a difference - wether
disclosure can or cannot be presupposed as an outcome.
If we, as a Team developing gTLD policy recommendations,
tackle an issue concerning web content, reach a
conclusion (any conclusion) on it, send a recommendation
to the GNSO Council, which is adopted and then sent to
the ICANN Board, which adopts it yet again, then what is
the outcome? To me, the answer to that question would be
that the EPDP Team, the GNSO Council and the ICANN Board
have all contributed to creating contractual obligations
on Contracted Parties that ICANN should have no business
creating.<br>
<br>
</dd>
<dd>To me, this is also a means of pulling topics
out-of-scope of ICANN's mission in to it, because
although this scope is defined by the Bylaws, there are
also Bylaws granting the GNSO responsibility for
developing gTLD policy. Would create a bit of a messy
constitutional sort of situation, I think.<br>
<br>
</dd>
<dd>Also, at some point in the future, the Consensus
Policy we are in the process of developing
recommendations for will be reviewed, and amendments may
be sought. Reviewing Consensus Policies could
potentially be initiated by either the GNSO or GDD (if
you're following the current Council conversation on
reviews of implemented Consensus Policies). So even if
we are not presupposing any outcome of disclosure in
this use case now, we open the door to further policy
development on this topic at some point in a future
iteration. On a topic that should have been flagged as
out-of-scope of ICANN's mission to begin with!!<br>
<br>
</dd>
<dd>Ideally, we would not submit any recommendations
concerning web content at all. If we did, it'd be nice
to know that there are checks and balances in place that
initiate some kind of course correction. For instance,
the GNSO Council or the ICANN Board would respond
saying, wait a minute, why are you sending us a policy
recommendation on a topic outside of ICANN's scope?!
Speaking for myself, unfortunately, I very much doubt
that would happen.<br>
<br>
</dd>
<dd>It's probably also noteworthy that even if we, as an
EPDP Team, reject this use case, and do not address the
topic in our recommendations, there is still nothing
preventing an Internet user from requesting information
about a website they might do business with from a
registrar, as you suggest. Our use of these use cases
should focus on helping respondents to disclosure
requests understand how best to deal with whatever
disclosure requests they receive. We can't cover every
single potential use case anyway, so the ones we do work
out should at least provide some guidance on how to deal
with unforeseen circumstances. With that in mind, I
believe there is value in addressing this use case, and
rejecting it, as opposed to not looking at it at all.<br>
<br>
</dd>
<dd>This is my personal perspective, and apologies if it
was slightly lengthier than it needed to be, but you
asked. ;-)<br>
<br>
</dd>
<dd>Thanks.<br>
<br>
</dd>
<dd>Amr<br>
<br>
<br>
</dd>
<dd>Γ’Γ’Γ’ Γ’Γ’Γ’Γ’ Original Message
Γ’Γ’Γ’Γ’Γ’Γ’Γ’ </dd>
</dl>
</dd>
</dl>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Gnso-epdp-team mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Gnso-epdp-team@icann.org">Gnso-epdp-team@icann.org</a>
<a class="moz-txt-link-freetext" 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 class="moz-txt-link-freetext" href="https://www.icann.org/privacy/policy">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a class="moz-txt-link-freetext" 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.</pre>
</blockquote>
<div class="moz-signature">-- <br>
Volker A. Greimann<br>
General Counsel and Policy Manager<br>
<strong style="border-bottom: 3px solid #5C46B5">KEY-SYSTEMS GMBH</strong><br>
<br>
T: +49 6894 9396901<br>
M: +49 6894 9396851<br>
F: +49 6894 9396851<br>
W: <a class="moz-txt-link-abbreviated" href="http://www.key-systems.net">www.key-systems.net</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: Alexander Siffrin<br>
<br>
Part of the CentralNic Group PLC (LON: CNIC) a company registered
in England and Wales with company number 8576358.</div>
</body>
</html>