<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Essentially:</p>
<p>Just because it is not part of the SSAD, it does not mean ICANN
cannot do it. They may not be able to use SSAD for it, but there
are other ways.</p>
<p>For Example: Escrow does not rely on SSAD. That data deposit
occours outside of SSAD/RDAP/Whois. If public whois never existed,
escrow would still have been possible. <br>
</p>
<p>Volker<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">Am 05.03.2020 um 15:27 schrieb Alan
Woods:<br>
</div>
<blockquote type="cite"
cite="mid:CAPQ5EHCVL4cErysXMcB06B-KU15Y9hP72n0GMykmMcq0CsXzDQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>HI all, </div>
<div><br>
</div>
I truly cannot believe we are still having the same
conversations
<div><br>
</div>
<div>Let me 1st deal with Alan's statement re "SOME 3rd party
requests are in fact in support of ICANN's mission" </div>
<div><br>
</div>
<div>Agreed, Alan. "Support" - not "contracted to", not "obliged
to" or not anything that denotes that they are in any way an
actual legal and direct part of the data processing which we
have been discussing for years now. These 3rd parties maintain
their own, completely separate , possibly quite aligned,
purposes to us. They may share a goal, an Ideal or a mission,
but they are legal strangers to this CLOSED data processing
ecosystem. By continuously invoking their aligned but legally
separate 'purposes' - that is conflation. </div>
<div><br>
</div>
<div><br>
</div>
<div>For the wider questions, I think we need to be crystal
clear here. I think we need to call out 3 very important
things are causing a lot of misunderstandings both in the past
week and indeed beyond: <br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><b><u><i>1) IS SSR a purpose?:</i></u></b></div>
<div><br>
</div>
<div>The URS is a purpose. The UDRP is a purpose. Contacting a
registrant to deal with issues with the Domain, is a purpose:
but let's be clear SSR is far bigger than a mere purpose. To
be especially clear, nothing the EPDP will do or say, can
change that, as it is enshrined at ICANN's core. </div>
<div><br>
</div>
<div>ICANN (Community, org, GNSO process) may decide to process
data in a manner that they believe is reasonable for the
protection of SSR. They don't need the EPDP's permission to do
so. </div>
<div><br>
</div>
<div>To draw a clumsy analogy, (bear with me) Think of SSR as a
very large building. That building has rooms that make up the
individual efforts (such as the URS, UDRP, Spec 11 (3)b etc.)
These rooms are the purposes which must be described on our
policy. - a visitor to the 'SSR building' may look at the
building but they will have no idea of what's in there or
where they are supposed to go. They consult the building
directory/map ( which is the privacy policy) and they can see
which rooms are in that building and more importantly what
each room contains.</div>
<div><br>
</div>
<div>Weird analogy aside, as an example. the processing of data
for URS or UDRP - this is a tangible thing that has stated
rules, processes, procedures - all of which try to outline
the use of any personal data in that process. The URS and the
UDRP are without a doubt a part of the SSR efforts of the
community, but were I but an auspicious bystander - If I was
merely told that my data will be used for the purposes of SSR
... and not told specifically about the URS / UDRP, I would
be utterly clueless as how my data may be used. That is the
very problem we apparently are stuck on here - SSR grounds a
purpose - but it is not a purpose in it's own right. </div>
<div><br>
</div>
<div><br>
</div>
<div><i>NOTE: just seeing Hadia's email now - her suggestion to
further define a purpose with further purposes - is EXACTLY
the point here, and why Purpose 2 is considered far too
broad to be effective. </i></div>
<div><i><br>
</i></div>
<div><br>
</div>
<div>2) <b> If SSR is not stated as a 'purpose'</b>, <b>then
ICANN can't process data for SSR</b>. </div>
<div><br>
</div>
<div><b><u>This is absolutely not true.</u></b></div>
<div><br>
</div>
<div>Policies can continue to be created that add to the efforts
to protect the SSR. NOTHING stops ICANN and the community from
creating any new purposes with SSR at its core. To use the
building analogy again (sorry) - The Building is the Bylaws
-It's already built - we can create as many rooms in that
building as we can imagine, as long as they are up the
Building's standards and where there will be people staying in
those rooms, that they meet the GDPR building regulations
(including giving all existing tenants notice of the new
rooms). </div>
<div><br>
</div>
<div>We should also note that where policy necessitates a change
to the manner in which the CPs or ICANN handle personal data,
then obviously as our privacy policies are not governed by
consensus policy, but any competent data controller, would
merely ensure a process of registrant notification and
necessary updates to our individual privacy policies. Again
this is not a block to us implementing additional data
processing, just that we need to ensure that we fulfil our
legal obligations to inform the data subjects appropriately
about the change, impact etc..<br>
</div>
<div><br>
</div>
<div>ICANN holds a very unique and very strong position to
sponsor and enforce such policy creation, not because the EPDP
somehow granted a 'purpose to create purposes for SSR' - but
because it is the actual mission and reason for being of ICANN
as is helpfully enshrined in its bylaws and mission.. </div>
<div><br>
</div>
<div><b>Finally and this is as HUGE one</b></div>
<div><br>
</div>
<div>3) <b><u>Nothing in the conversation relating to Purpose
II, affects or is intended to affect, or in ANY WAY
prevent the SSAD from occurring.</u></b> </div>
<div><br>
</div>
<div>That is completely separate. SSAD is the operationalization
of a process for disclosure of data to third parties. That
remains completely possible <b><u>regardless of Purpose II or
NOT </u></b>- we do not need to create a purpose to
disclose data to 3rd parties - that's the way the law is
written. Phase II is defining this process for disclosure,
making a process that currently EXISTS (in reality and as
permitted by law) so that it is in a more streamlined and
predictable manner. Any suggestion otherwise is simply not
true. <br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Sorry about the length as per usual, but I think we need to
move past certain assumptions, so that we can focus on our
actual task at hand. </div>
<div><br>
</div>
<div>Thank you! </div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>
<div>
<div dir="ltr" data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<table
style="padding:0px;margin:10px
0px;border:none">
<tbody>
<tr>
<td
style="vertical-align:middle;padding:0px
7px 0px 0px"><a
href="http://donuts.domains"
rel="nofollow"
target="_blank"
moz-do-not-send="true"><img
alt="Donuts Inc."
src="https://storage.googleapis.com/signaturesatori/customer-C02zzlf7k/images/-54f9d8ac97e7f575bf497d10ac1f1aafafddf8afceab5f269d49034f01b3217b.png"
moz-do-not-send="true" width="75" height="75"></a></td>
<td
style="vertical-align:middle;padding:0px
7px 0px
0px;text-align:left">
<div
style="font-family:tahoma,sans-serif;font-size:14px;line-height:17px;font-weight:bold;color:black"><span
style="font-size:12px"><span
style="font-family:arial,helvetica,sans-serif"><span
style="color:rgb(51,51,51)">Alan Woods</span></span></span></div>
<div><span
style="font-size:12px"><span
style="font-family:arial,helvetica,sans-serif"><span
style="color:rgb(51,51,51)">Senior
Compliance
& Policy
Manager, Donuts
Inc.</span></span></span>
<hr>
<div><font
face="arial,
helvetica,
sans-serif"
color="#333333"><span
style="font-size:11px">Suite 1-31, </span></font></div>
<div><font
face="arial,
helvetica,
sans-serif"
color="#333333"><span
style="font-size:11px">Block D, Iveagh Court</span></font></div>
<div><font
face="arial,
helvetica,
sans-serif"
color="#333333"><span
style="font-size:11px">Harcourt Road</span></font></div>
</div>
<div><font
face="arial,
helvetica,
sans-serif"
color="#333333"><span
style="font-size:11px"> Dublin 2, County Dublin</span></font><br
style="color:rgb(214,214,214);font-family:"open
sans";font-size:12px;background-color:rgb(34,34,34)">
<font face="arial,
helvetica,
sans-serif"
color="#333333"><span
style="font-size:11px"> Ireland</span></font><br>
<span
style="font-size:11px"><span
style="font-family:arial,helvetica,sans-serif"></span></span><br>
<span
style="line-height:36px"><a
href="https://www.facebook.com/donutstlds" rel="nofollow"
target="_blank"
moz-do-not-send="true"><img
src="http://storage.googleapis.com/signaturesatori/icons/facebook.png"
moz-do-not-send="true"></a> <a href="https://twitter.com/DonutsInc"
rel="nofollow"
target="_blank"
moz-do-not-send="true"><img
src="http://storage.googleapis.com/signaturesatori/icons/twitter.png"
moz-do-not-send="true"></a> </span><span style="font-size:14px"><a
href="https://www.linkedin.com/company/donuts-inc"
rel="nofollow"
target="_blank"
moz-do-not-send="true"><img
src="http://storage.googleapis.com/signaturesatori/icons/linkedin.png"
moz-do-not-send="true"></a></span></div>
</td>
</tr>
</tbody>
</table>
<br>
</div>
<div><span
style="font-size:12pt;font-family:Cambria,serif">Please
NOTE: This electronic
message, including any
attachments, may
include privileged, confidential and/or
inside information owned by
Donuts Inc. . </span><span
style="font-size:12pt;font-family:Cambria,serif">Any
distribution or use of this
communication by anyone
other than the intended
recipient(s) is strictly
prohibited and may be
unlawful. If you are not
the intended recipient,
please notify the sender by
replying to this message and
then delete it from your
system. Thank yo</span></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Mar 5, 2020 at 10:41
AM Volker Greimann <<a
href="mailto:vgreimann@key-systems.net" target="_blank"
moz-do-not-send="true">vgreimann@key-systems.net</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>I fully agree with your first sentence. For this reason,
specificity of the actual purposes is required instead of
the blanket statement proposed up to now. <br>
</p>
<p>Ultimately, any ICANN purpose must be specifically
defined by the questions of what is collected for what
specific purpose for and with whom it may be shared. <br>
</p>
<p>Say we take escrow as a purpose, which is likely
univerally agreed as a valid ICANN purpose:</p>
<p>ICANN will collect registration data to: protect the
ownership of a data subject in his registered domain names
in case of a registry or registrar failure or
de-accreditation. For this purpose, the data may be shared
with escrow service providers x,y,z (and potentially
others) as well as other contracted parties who may be
assigned to take over the management of the affected
domain name registrations. <br>
</p>
<p>The language is not perfect, but I hope this illustrates
the level of specificity I am seeking here. If ICANN has
purposes (and I think we agree that it does), we need to
specify these purposes by saying what, how and why.</p>
<p>Best,</p>
<p>Volker</p>
<p><br>
</p>
<p><br>
</p>
<div>Am 05.03.2020 um 11:21 schrieb Hadia Abdelsalam Mokhtar
EL miniawi:<br>
</div>
<blockquote type="cite">
<div>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">We
need not forget that data subjects need to know with
whom their data might be shared and for what
purposes. To this end purpose 2 is important as it
establishes one core purpose for processing the data
related to ICANN's mission and stated in its bylaws.
Also in the EC letter to Joran in May 2019 under
purposes of processing and access model, the EC say
"For this reason we would recommend revising the
formulation of purpose two by excluding the second
part of the purpose "through enabling responses to
lawful data disclosure requests" and maintaining a
broader purpose " Contribute to the maintenance of
the security, stability and resiliency of the Domain
Name System in accordance with ICANN's mission" </span></p>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">This
was the recommendation of the EC to us in May 2019,
the question now is why don't we want to follow this
recommendation? Maintaining the SSR of the internet
is ICANN's core mission and is indeed a purpose for
which data might be processed why don't we want to
be clear about this.</span></p>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Hadia</span></p>
<div>
<div
style="border-right:none;border-bottom:none;border-left:none;border-top:1pt
solid rgb(181,196,223);padding:3pt 0in 0in">
<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 [<a
href="mailto:gnso-epdp-team-bounces@icann.org"
target="_blank" moz-do-not-send="true">mailto:gnso-epdp-team-bounces@icann.org</a>]
<b>On Behalf Of </b>Alan Greenberg<br>
<b>Sent:</b> Thursday, March 05, 2020 2:18 AM<br>
<b>To:</b> Margie Milam; <a
href="http://brian.kingATmarkmonitor.com"
target="_blank" moz-do-not-send="true">brian.kingATmarkmonitor.com</a>;
<a href="mailto:gnso-epdp-team@icann.org"
target="_blank" moz-do-not-send="true">gnso-epdp-team@icann.org</a><br>
<b>Subject:</b> Re: [Gnso-epdp-team] Purpose 2</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<p class="MsoNormal">I have to agree with Margie. These
are all important things and we cannot be left at some
later date being told that we cannot do this because
it was never mentioned to registrants.<br>
<br>
I could live with a much more general statement, but
we have been told by the CPH that they need something
less vague to put in their policies to registrants.<br>
<br>
Although I do not believe there is any merit in
pursuing it, I will restate that SOME 3rd party
requests are in fact in support of ICANN's mission
(those that directly protect the SSR of the DNS) and I
believe that the statement that we were conflating
3rd-party purposes with our own was partially in
error.<br>
<br>
Alan<br>
<br>
At 04/03/2020 05:50 PM, Margie Milam wrote:<br>
<br>
<br>
</p>
<p class="MsoNormal">We support Brian’s proposed
Purpose 2 below, and note that without it – theere are
many gaps, including: </p>
<ul type="disc">
<li class="MsoNormal"> Operationalizing and
implementing new policies and contract provisions
(RDAP, transfers, TM Clearinghouse, etc.) </li>
<li class="MsoNormal"> Conducting research using the
contacts </li>
<li class="MsoNormal"> Coordinating cyber-attack
responses such as Conficker & other cyber
attacks </li>
<li class="MsoNormal"> Publishing Accuracy Reporting
System (ARS) reports </li>
<li class="MsoNormal"> Conducting testing of new
registrar/registries to ensure that the WHOIS
systems work in the manner required by the contract
</li>
<li class="MsoNormal"> Implementing & testing
escrow deposits with 3<sup>rd</sup> party escrow
providers </li>
</ul>
<p class="MsoNormal"> <br>
All the best,<br>
<br>
Margie, Mark & Steve<br>
On behalf of the BC<br>
<br>
<b> <br>
Margie Milam<br>
</b>IP Enforcement & DNS Policy Lead | Facebook
Legal<br>
NOTICE: This email (including any attachments) may
contain information that is private, confidential, or
protected by attorney-client or other privilege.
Unless you are the intended recipient, you may not
use, copy, or retransmit the email or its contents.<br>
<br>
<br>
<br>
<b>From: </b>Gnso-epdp-team <a
href="mailto:gnso-epdp-team-bounces@icann.org"
target="_blank" moz-do-not-send="true"><gnso-epdp-team-bounces@icann.org></a>
on behalf of "King, Brian via Gnso-epdp-team" <a
href="mailto:gnso-epdp-team@icann.org"
target="_blank" moz-do-not-send="true"><gnso-epdp-team@icann.org></a><br>
<b>Reply-To: </b>"<a
href="http://brian.kingATmarkmonitor.com"
target="_blank" moz-do-not-send="true">brian.kingATmarkmonitor.com</a>"
<a href="mailto:brian.king@markmonitor.com"
target="_blank" moz-do-not-send="true"><brian.king@markmonitor.com></a><br>
<b>Date: </b>Wednesday, March 4, 2020 at 10:12 AM<br>
<b>To: </b><a href="mailto:gnso-epdp-team@icann.org"
target="_blank" moz-do-not-send="true">"gnso-epdp-team@icann.org"</a>
<a href="mailto:gnso-epdp-team@icann.org"
target="_blank" moz-do-not-send="true"><gnso-epdp-team@icann.org></a><br>
<b>Subject: </b>[Gnso-epdp-team] Purpose 2<br>
<br>
Hi all, <br>
<br>
Following last week’s conversation about some EPDP
members’ desire to have a bit more specificity in
Purpose 2 (the irony of which is not lost on the IPC
), I propose the below: <br>
<br>
Contributing to the maintenance of the security,
stability, and resiliency of the Domain Name System in
accordance with ICANN’s mission, specifically
“maintenance of and access to accurate and
up-to-date information concerning registered names and
name servers.†(ICANN Bylaws, Annex G-1; ICANN
Bylaws, Annex G-2)<br>
<br>
<b>Brian J. King </b><br>
Director of Internet Policy and Industry Affairs<br>
<br>
T +1 443 761 3726<a
href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.markmonitor.com&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=_4XWSt8rUHZPiRG6CoP4Fnk_CCk4p550lffeMi3E1z8&m=Q65Or6H39_7X6LJk1SN78sszy_Hne8qlISmI8kN7Wh8&s=72C7v9XA12IEQxdYxgz5IDlXPMnrRUz4uW6aDcYmwcU&e="
target="_blank" moz-do-not-send="true"> <br>
markmonitor.com</a><u><br>
</u> <br>
<b>MarkMonitor<br>
</b>Protecting companies and consumers in a digital
world<br>
<br>
_______________________________________________<br>
Gnso-epdp-team mailing list<br>
<a href="mailto:Gnso-epdp-team@icann.org"
target="_blank" moz-do-not-send="true">Gnso-epdp-team@icann.org</a><br>
<a
href="https://mm.icann.org/mailman/listinfo/gnso-epdp-team"
target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">
https://www.icann.org/privacy/policy</a>) and the
website Terms of Service (<a
href="https://www.icann.org/privacy/tos"
target="_blank" moz-do-not-send="true">
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.</p>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Gnso-epdp-team mailing list
<a href="mailto:Gnso-epdp-team@icann.org" target="_blank" moz-do-not-send="true">Gnso-epdp-team@icann.org</a>
<a href="https://mm.icann.org/mailman/listinfo/gnso-epdp-team" target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a href="https://www.icann.org/privacy/tos" target="_blank" moz-do-not-send="true">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>
Volker A. Greimann<br>
General Counsel and Policy Manager<br>
<strong style="border-bottom:3px solid rgb(92,70,181)">KEY-SYSTEMS
GMBH</strong><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"
moz-do-not-send="true">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>
</div>
_______________________________________________<br>
Gnso-epdp-team mailing list<br>
<a href="mailto:Gnso-epdp-team@icann.org" target="_blank"
moz-do-not-send="true">Gnso-epdp-team@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-epdp-team"
rel="noreferrer" target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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>
</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>