<div dir="ltr">I think we need to be careful and not to mix two terms: automatic and automated.<div>We agreed at the beginning of the process that there won't be an automatic access or disclosure. Each request will be examined on its own merits - in automated or manual
fashion. When it comes to manual processing - we will attempt to standardize it as much as possible.</div><div>JK</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 21, 2019 at 4:30 PM Volker Greimann <<a href="mailto:vgreimann@key-systems.net">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 bgcolor="#FFFFFF">
<p>Hi Hadia,</p>
<p>the problem with automatic disclosure is that even if it were
legally possible in certain circumstances, it carries with it a
certain liability risk. Naturally therefore, it should be the
decision of the party (-ies) carrying this liability whether they
accept this liability risk or not. From everything Göran has told
us, ICANn will not be the party accepting this liability, so that
leaves the contracted parties. <br>
</p>
<p>I for one would be open to granting some form of automated access
to certified law enforcement agencies of my own jurisdiction (and
others that may be legally applicable) for example as they have
the power to legally compel me to provide that data, but others
may not accept that liability of short-cutting due process. <br>
</p>
<p>6(1)a - is a tricky number, since it also (amongst other
requirements) requires us to provide evidence of that consent, and
everytime we act through third parties, we cannot be sure that the
consent we gathered is actually that of the data subject. <br>
</p>
<p>As far as processing for fraud protection, IT security, etc go
under the GDPR, I would advise revisiting this section as you may
be surprised as to whose protection and security this is intended
for (that of the processor and controller, but not that of
unrelated third parties). It is a legitimate purpose for internal
processing by the processor but not for disclosure by a third
party who wants to use it for that purpose. So again, it is not as
easy as you think it is. <br>
</p>
<p>You are correct that for <span style="color:rgb(79,129,189)">the
balancing test you need to prove that the interests of the data
subject does not override the interests of the requestor, but
for that, you need to look at the specific circumstances. I
think it would be very difficult to automate such a review to
find out the interests of the data subject, let alone figuring
out whether they do not outweigh the interests of the requestor.
Maybe Google and Facebook have that kind of AI tech, but we
don't. Again, certain types of LEA requests may be on a
different scale that make this easier.<br>
</span></p>
<p><span style="color:rgb(79,129,189)">I have been a big fan of doing the
LEA part first and then looking at what parts of that would be
adaptable to other requestors from the start. With that, we
would likely already have another part that would be ready for
development now.</span></p>
<p><span style="color:rgb(79,129,189)">Best,</span></p>
<p><span style="color:rgb(79,129,189)">Volker<br>
</span></p>
<div>Am 21.10.2019 um 15:35 schrieb Hadia
Abdelsalam Mokhtar EL miniawi:<br>
</div>
<blockquote type="cite">
<div>
<p class="MsoNormal"><span style="color:rgb(79,129,189)">Hi ,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(79,129,189)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(79,129,189)">At least we can
agree that using the accreditation system only for
identification is a waste of money, resources and defies any
kind of logical thinking. Also Amr, I don't know why you
see automatic disclosure as impossible (provided of course
that it abides by the law) Whether automatic disclosure
will be possible or not will depend on the lawful basis used
for disclosure and on the specific context and circumstances
(under some lawful basis and not all). So for example if you
are disclosing data under 6(1)(a) -consent for specific
purposes- I would argue that automating this is both
desirable and possible. But also if we look at the
disclosure of the data under 6(1)(f) (legitimate interest)
In order to decide whether to disclose the data or not you
will need to perform a legitimate interest assessment which
would consist of three parts<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(79,129,189)">Purpose test<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(79,129,189)">Necessity test<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(79,129,189)">Balancing test<u></u><u></u></span></p>
<p class="MsoNormal" style="text-align:justify"><span style="color:rgb(79,129,189)">For the purpose test, legitimate
interest may include a wide range of purposes, however GDPR
specifically mentions fraud prevention, IT security and
criminal acts as legitimate interests so if you have parties
accredited for specific purposes they can automatically pass
this test.<u></u><u></u></span></p>
<p class="MsoNormal" style="text-align:justify"><span style="color:rgb(79,129,189)">For the necessity test you need to
prove that there is no other logical, less intrusive way to
achieve your purpose, again if you have parties accredited
for specific purposes this test can also be automated.<u></u><u></u></span></p>
<p class="MsoNormal" style="text-align:justify"><span style="color:rgb(79,129,189)">For the balancing test you need to
prove that the interests of the data subject does not
override the interests of the requestor and again under
similar contexts and circumstances maybe this could be
possible.<u></u><u></u></span></p>
<p class="MsoNormal" style="text-align:justify"><span style="color:rgb(79,129,189)"><u></u> <u></u></span></p>
<p class="MsoNormal" style="text-align:justify"><span style="color:rgb(79,129,189)">I am not trying now to decide what can
or cannot be automated as this will need thorough studying,
but what I am trying to say that it is not useful to anyone
to just decide that automatic disclosure would be
impossible. We might be wasting good implementation
solutions and practices if we come up with a policy that
states so.
<u></u><u></u></span></p>
<p class="MsoNormal" style="text-align:justify"><span style="color:rgb(79,129,189)"><u></u> <u></u></span></p>
<p class="MsoNormal" style="text-align:justify"><span style="color:rgb(79,129,189)">Best<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(79,129,189)">Hadia<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-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">mailto:gnso-epdp-team-bounces@icann.org</a>]
<b>On Behalf Of </b>Amr Elsadr<br>
<b>Sent:</b> Monday, October 21, 2019 1:43 PM<br>
<b>To:</b> Volker Greimann<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] Notes and action
items - EPDP Meeting #25 - 17 Oct 2019<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Hi,<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I think we need to be very clear on what
we’re discussing, and what different groups might be seeking
or agreeing to. Alex pointed out a number of areas where
automation may be helpful in processing disclosure requests,
which we should take in to consideration.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">However, the notion of <b><i>“automatic
disclosure”</i></b> (which to me, includes the decision
and actual action/performance of disclosure) is not one that
I imagine could be worked out, without infringing on the
rights of registrants. I’m open to listening to why some
might find that to be incorrect or not a sufficient
deterrent, but right now, my view is likely the opposite of
the IPC’s. I don’t believe we should be recommending a
policy that allows for automatic disclosure under any
circumstance.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">So regarding action item 1, this part of
the discussion should not result in any update to the
Accreditation Building Block. Like Volker said, there is no
agreement on this specific point.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Amr<u></u><u></u></p>
<div>
<p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<div>
<p class="MsoNormal">On Oct 21, 2019, at 1:25 PM, Volker
Greimann <<a href="mailto:vgreimann@key-systems.net" target="_blank">vgreimann@key-systems.net</a>>
wrote:<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">Hi
JK,
<u></u><u></u></p>
<p class="MsoNormal">we
are not disagreeing here, I think, just trying to
clarify our understanding. I also agree to that
principle.<u></u><u></u></p>
<p class="MsoNormal">Best,<u></u><u></u></p>
<p class="MsoNormal">Volker<u></u><u></u></p>
<div>
<p class="MsoNormal">Am 21.10.2019 um 12:48 schrieb
Janis Karklins:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<p class="MsoNormal">Volker, <u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I had impression that the
principle that "SSAD should be as much automated
as possible and standardized for the rest" was
agreed by all groups in the Team already a while
ago.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">When we are thinking about
implementability and scaleability of the system,
ambiguities in formulations may not be helpful.
I understand that on some issues groups may have
divergent or even opposing opinions. We should
be as flexible as possible and as precise as
possible and look at the SSAD as a package of
different compromises by all groups. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">JK<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Mon, Oct 21, 2019 at 2:45
AM Volker Greimann <<a href="mailto:vgreimann@key-systems.net" target="_blank">vgreimann@key-systems.net</a>>
wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">Hi
Alex,
<u></u><u></u></p>
<p class="MsoNormal">thank
you for your response. I don't think that
anyone opposes the idea that certain aspects
of the system can and should be automated,
however that is not the general usage of the
term in this group so far. "To automate" was
always discussed in the context of automating
the disclosure decision, and in that context,
we cannot support this language.
<u></u><u></u></p>
<p class="MsoNormal">I
think it would be helpful if we were all more
clear in what we mean when we use certain
words.
<u></u><u></u></p>
<p class="MsoNormal">Automating
completeness, error checking and notices of
receipt makes sense and it would be very much
appreciated if the system takes care of that
for us, but that is not what we mean by
"automation".<u></u><u></u></p>
<p class="MsoNormal">To
your last points, I think we have established
that all requests will likely be those of the
6.1.f. variety, and those all include that
notorious balancing test which needs to take
into consideration facts that are not part of
the request and in my view cannot be
automated.
<u></u><u></u></p>
<p class="MsoNormal">My
personal position on this is that this point
can be left open:
<u></u><u></u></p>
<p class="MsoNormal">If
a disclosing CP feels that they can automate
that part as well, they should be able to do
so, but we should not mandate it. So by
striking the reference at this point, we do
not prohibit such automation, but we also do
not mandate it. That strikes me as a workable
compromise between our positions, won't you
agree?<u></u><u></u></p>
<p class="MsoNormal">Best,<u></u><u></u></p>
<p class="MsoNormal">Volker<u></u><u></u></p>
<div>
<p class="MsoNormal">Am 20.10.2019 um 19:02
schrieb Alex Deacon:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<div>
<div>
<div>
<p class="MsoNormal">Volker and all, <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Our thoughts on
the topic of automation. <br>
<br>
The IPC objects to any policy that
does not allow for the automation of
request/response processing. Once
again I remind everyone we are
defining policy for a *system* that
will be RDAP based - not a process
that is based on "old fashioned"
technology like smoke signals, wax
sealed correspondence written by
quill and ink, telex messages, faxes
or email. (We already did this in
Phase 1 Rec 18)<br>
<br>
Clearly we want a policy that allows
for the automation of syntax
checking of incoming requests,
resulting in an automatic response
that indicates the errors to the
requestor. This automation
addresses the risk of filling up the
request queues of the discloser with
malformed requests. <br>
<br>
Clearly we want a policy that allows
for the automation of checking that
the contents of a request is
complete, based on policy we are
setting in another building block,
resulting in an automatic response
that details what is be missing (per
policy). This automation allows
for the discloser to indicate -
without human intervention - what
additional information is required
per policy and enables the requestor
to address the error. <br>
<br>
Clearly we want a policy that allows
for the automation of an immediate
and synchronous response that
indicates the receipt of a valid
request and some indication that it
will be processed. Typically such
responses include a "ticket number"
or some kind of uniqueID to allow
for future queries (status, updates,
deletion, etc.). This automation
allows for efficient queue
management on the disclosers side
and assists in ensuring our
principal of "predictability" is met
for the requestor. <br>
<br>
It is important to note that in none
of the three points above do I state
or even suggest that automation will
or can result in the automatic
response of non-public data. <br>
<br>
However having said that - there is
no doubt in my mind that there will
exist some subset of well formed,
valid, complete, properly identified
and accredited requests for some
subset of legal basis and some
subset of purposes that indeed can
be automatically processed and
result in the disclosure of
non-public RDS data without human
intervention. The IPC would
object to any policy language that
would explicitly forbid this from
ever happening. <br>
<br>
Thanks. <br>
Alex<u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">___________ <u></u><u></u></p>
<div>
<p class="MsoNormal"><b>Alex
Deacon</b><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Cole Valley
Consulting<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><a href="mailto:alex@colevalleyconsulting.com" target="_blank">alex@colevalleyconsulting.com</a><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">+1.415.488.6009<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</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 Fri, Oct 18,
2019 at 1:01 PM Volker Greimann <<a href="mailto:vgreimann@key-systems.net" target="_blank">vgreimann@key-systems.net</a>>
wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal" style="margin-left:67.7pt"><span style="font-size:11pt;font-family:Calibri,sans-serif">Hi
Caitlin,</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:67.7pt"><span style="font-size:11pt;font-family:Calibri,sans-serif">I
don't think 4.B) Principle B:
</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:2in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span style="font:7pt "Times New Roman"">
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">What
does accreditation mean? The
group discussed the potential
for allowing for the automatic
disclosure where allowed under
the law suggest “and automation
of responses where possible
under applicable law”</span><u></u><u></u></p>
<div>
<div>
<div>
<p class="MsoNormal">truly
captures the content of our
disscussion. The draft
should only contain agreed
language and the inclusion
of "and automation of" was
very much not agreed. In
fact this language was
opposed by a large group and
therefore should be removed
unless approved. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</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: Alexander Siffrin<br>
<br>
Part of the CentralNic Group
PLC (LON: CNIC) a company
registered in England and
Wales with company number
8576358.<u></u><u></u></p>
</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 Fri, Oct
18, 2019 at 1:17 AM Caitlin
Tubergen <<a href="mailto:caitlin.tubergen@icann.org" target="_blank">caitlin.tubergen@icann.org</a>>
wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11pt">Dear
EPPD Team:</span><u></u><u></u></p>
<div>
<p class="MsoNormal"><span style="font-size:11pt"> </span><u></u><u></u></p>
</div>
<p class="MsoNormal"><span style="font-size:11pt">Please
find below the notes and
action items from today’s
EPDP Team meeting.</span><u></u><u></u></p>
<div>
<p class="MsoNormal"><span style="font-size:11pt"> </span><u></u><u></u></p>
</div>
<p class="MsoNormal"><span style="font-size:11pt">The
next EPDP Team meeting
will be
<b>Tuesday, 22 October</b>
at 14:00 UTC.</span><u></u><u></u></p>
<div>
<p class="MsoNormal"><span style="font-size:11pt"> </span><u></u><u></u></p>
</div>
<p class="MsoNormal"><span style="font-size:11pt">Best
regards,</span><u></u><u></u></p>
<div>
<p class="MsoNormal"><span style="font-size:11pt"> </span><u></u><u></u></p>
</div>
<p class="MsoNormal"><span style="font-size:11pt">Marika,
Berry, and Caitlin</span><u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<p class="MsoNormal"><b><span style="font-size:11pt">EPDP
Phase 2 - Meeting #25</span></b><u></u><u></u></p>
<p class="MsoNormal"><b><span style="font-size:11pt">Proposed
Agenda</span></b><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt">Thursday,
17 October 2019 at 14.00
UTC</span><u></u><u></u></p>
<div>
<p class="MsoNormal"><span style="font-size:11pt"> </span><u></u><u></u></p>
</div>
<p class="MsoNormal"><u><span style="font-size:11pt">Action
Items</span></u><u></u><u></u></p>
<ol start="1" type="1">
<li class="MsoNormal">
<span style="font-size:11pt;font-family:Calibri,sans-serif">Support
Staff to update the text
of the
<a href="https://docs.google.com/document/d/1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E/edit" target="_blank">
Accreditation Building
Block</a> and <a href="https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit" target="_blank">
Financial
Sustainability Block</a>
based on today’s
discussion. </span><u></u><u></u></li>
<li class="MsoNormal">
<span style="font-size:11pt;font-family:Calibri,sans-serif">EPDP
Team to provide
additional edits in the
<a href="https://docs.google.com/document/d/1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E/edit" target="_blank">
Accreditation Building
Block</a> re:
implementation guidance
and definitions by COB
tomorrow,
<b>Friday, 18 October</b>.</span><u></u><u></u></li>
<li class="MsoNormal">
<span style="font-size:11pt;font-family:Calibri,sans-serif">EPDP
Team to provide
additional edits from
today’s conversation to
the
<a href="https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit" target="_blank">
Financial
Sustainability Block</a>
by <b>Friday, 18
October</b>.</span><u></u><u></u></li>
<li class="MsoNormal">
<span style="font-size:11pt;font-family:Calibri,sans-serif">EPDP
Volunteers needed to
propose initial text for
<a href="https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4/edit" target="_blank">
Building Block M –
Terms of
Use/Disclosure
Agreements/Privacy
Policies</a> by <b>
Monday, 21 October</b>.</span><u></u><u></u></li>
</ol>
<p class="MsoNormal" style="margin-left:67.7pt"><span style="font-size:11pt;font-family:Calibri,sans-serif">1.
Roll Call & SOI
Updates (5 minutes)</span><u></u><u></u></p>
<div style="margin-left:67.7pt">
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif"> </span><u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-left:67.7pt"><span style="font-size:11pt;font-family:Calibri,sans-serif">2.
Confirmation of agenda
(Chair)</span><u></u><u></u></p>
<div style="margin-left:67.7pt">
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif"> </span><u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-left:67.7pt"><span style="font-size:11pt;font-family:Calibri,sans-serif">3.
Welcome and housekeeping
issues (Chair) (5 minutes)</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:1in"><span style="font-size:11pt;font-family:Calibri,sans-serif">a)
Update from legal
committee</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:1in"><span style="font-size:11pt;font-family:Calibri,sans-serif">b)
</span><a href="https://community.icann.org/x/k5ICBw" target="_blank"><span style="font-size:11pt;font-family:Calibri,sans-serif">Status
of building blocks</span></a><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:67.7pt"><span style="font-size:11pt;font-family:Calibri,sans-serif">4.
</span><a href="https://docs.google.com/document/d/1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY/edit" target="_blank"><span style="font-size:11pt;font-family:Calibri,sans-serif">Accreditation</span></a><span style="font-size:11pt;font-family:Calibri,sans-serif">
(building block f and j) –
second reading continued
(30 minutes) </span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:1.5in"><span style="font-size:11pt;font-family:Calibri,sans-serif">a)
Overview of implementation
guidance section</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:1.5in"><span style="font-size:11pt;font-family:Calibri,sans-serif">b)
Feedback from EPDP Team</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:1.5in"><span style="font-size:11pt;font-family:Calibri,sans-serif">Principle
b</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:2in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">Requirements
should be spelled out as
part of the policy
discussion</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:2in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">There
will be different types of
entities and may have
different documentation to
provide
</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:2in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">These
requirements should be as
uniform as possible</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:2in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">C
may need to come before B</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:2in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">There
needs to be an underlying
baseline of requirements
that are uniform.</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:2in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">Accreditation
is all about
identification; thought
the group agreed that
accreditation is at a
minimum about identity,
but it could also
establish other things as
well – such as law
enforcement, cyber
security, etc.</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:2in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">It
would be helpful to draw a
line b/w the accreditation
process and what needs to
be included in the
disclosure request –
parties seeking
accreditation should
probably not have to
include every scenario
where a law enforcement
would have to interface
with the SSAD – hoping the
Team can be more specific
with baseline requirements
for accreditation</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:2in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">Law
enforcement will likely
have a different
accreditation system than
other entities, so that
conversation should be
separate</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:2in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">What
does accreditation mean?
The group discussed the
potential for allowing for
the automatic disclosure
where allowed under the
law suggest “and
automation of responses
where possible under
applicable law”</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:2in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">Accreditation
does not equate to
automated response by
default – each query will
be decided upon on its own
merits</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:2in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">Certain
types of people (user
groups) may allow for
streamlining – some
categories may involve
more scrutiny – to that
extent, accreditation is
more than authentication
of identity</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:2in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">By
adding too much into one
subject, the discussion is
encumbered. The discussion
of accreditation and
authentication should be
decoupled.</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:2in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">The
small team for
accreditation agreed that
accreditation is not
authorization. It might be
desirable and helpful to
have attributes associated
with accreditation. The
only attribute that will
consistently make a
difference is whether it
is law enforcement or not.
With respect to cyber
security researchers, any
IT person could
legitimately claim to be
doing cyber security
research. There shouldn’t
be entry barriers that say
you are or are not cyber
security researchers. </span>
<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:2in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">The
building block includes a
list of definitions, which
the Team has not yet
discussed.</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:2in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">If
accreditation only proves
identity, the Team is
limiting what it can
discuss with regard to the
release of data.
</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:2in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">Support
Staff to try to analyze
what was said during the
conversation with respect
to Subpoint B and Subpoint
C for online consideration</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:1in"><span style="font-size:11pt">Principle
d</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:144.35pt">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">What
is the expectation for
what de-accreditation
means?</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:144.35pt">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">Accreditation
would be that the
accreditation is who they
say they are; as a result,
there is access to the
system without further
verification of identity.
If an entity is
de-accredited, it would
need to be re-accredited.</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:144.35pt">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">This
would mean that the
authority could revoke
access to the system, not
“de-accredit”.</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:67.5pt"><span style="font-size:11pt">Principle
g</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:1.5in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">What
is the accreditation
policy and requirements –
where is this?</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:1.5in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">The
accreditation policy and
associated requirements
have not been
drafted/implemented yet
</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:67.5pt"><span style="font-size:11pt">Principle
i</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:1.5in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">Issue
with replaced “must be
paid for service” with
“cost-recovery system” –
this could suggest that
the costs need to be
covered by another form.
The whole system is for
the benefit of third-party
users who would request
disclosure of registration
data – concerned with
costs being shifted to
registrants</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:1.5in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">Two
types of costs involved –
development and deployment
of the system and then the
cost of day-to-day running
of the system</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:1.5in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">The
costs need to be
considered in a
cost-recovery system. The
purpose of accreditation
is to lower these costs.
Whatever cost-recovery
system takes place – these
costs need to be recovered
from the users of the
system, not from
registrants or contracted
parties.</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:1.5in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">Have
issues with the terms
“significantly reduce”.
This is a separate system.
The Team really needs to
consider a cost-benefit
analysis of figuring out
someone’s ID – how much
will this actually cost?
Is it achievable?</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:1.5in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">Perhaps
the second sentence could
be moved to Block N.</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:1.5in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">There
are two sets of
development costs –
accreditation system and
SSAD. This paragraph
should be limited to the
development of the
accreditation system. Re:
development of SSAD – that
should be moved to
Building Block N.</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:1.5in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">Agree
with moving the second
sentence to Building Block
N. If the benefit exceeds
the cost, there needs to
be an escape valve in the
policy. As a policy
principle, it should be
the benefits of the SSAD
system must outweigh the
costs.</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:1.5in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">If
there are too many
requirements, the system
will be too expensive.
Avoid saying the costs
outweigh the benefits.
This language needs more
work to make it clear what
the team is after. </span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:1.5in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">Maintain
first sentence and delete
second sentence</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:1.5in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">This
conversation can be moved
to the financial building
block.</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:1.5in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">Registrants
do get something from the
SSAD – a reliable and
secure DNS. The SSAD is
not a clean slate – the
current system is the
registrars having to do
the work themselves, and
someone is paying for
this. </span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:1.5in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">There
is a clean and reliable
DNS system today – to say
“cleaner” and “more
reliable” would be
preferable. Costs may be
occurring in other areas
that are offset for a
system that doesn’t
currently exist is
problematic and
disproportionate.</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:67.5pt"><span style="font-size:11pt">Principle
k</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:103.5pt">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">The
use of the word “tagging”
is confusing
</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:103.5pt">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">Marc
to submit proposed updated
online</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:103.5pt">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">What
is the meaning b/w the
first and second sentence?</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:103.5pt">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">The
SSAD takes requests from
accredited and
unaccredited users, so
unaccredited users will be
treated a different way.
RDAP is a query response
protocol, where you query
the system and get a
response back. There will
now be instances where
some queries will be
responded to right away
and others will be queued
(for balancing tests have
to be conducted) and the
response will be returned
later – RDAP was not
designed to be used in
this way.</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:103.5pt">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">The
second sentence in k does
not make sense.
</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:67.5pt"><span style="font-size:11pt">Implementation
Guidance Feedback</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:103.5pt">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">Drafting
note c – legitimate and
lawful purpose described
above (stated)</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:103.5pt">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">Some
implementation belongs in
the policy – a and b could
be left in implementation
guidance. C and D could be
left in the policy
language as opposed to
implementation guidance.</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:103.5pt">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">De-accreditation
– this will depend on what
the specifics of
accreditation are and what
it would mean for someone
to be de-accredited</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:103.5pt">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">At
the F2F, the Team talked
about de-accreditation for
the users of the system
and the accrediting
entities. E and G are
potentially in conflict
with each other. </span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:103.5pt">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">What
does access to the system
mean? Even bad actors
should have access to the
public data.</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:103.5pt">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">This
hinges on unaccredited
users having access to the
system – is the SSAD being
used by everyone, or just
accredited users?</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:103.5pt">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">Can
the Team agree that the
SSAD could be used by both
accredited and
non-accredited users? The
difference is that
accredited entities will
query the system w/o
verification of the
entity. </span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:103.5pt">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">SSAD
should be usable by
everyone and not exclude
anyone</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:103.5pt">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">How
one does identity
verification is a decision
ICANN should be making in
the public interest.
</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:103.5pt">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">Concern
that individuals should
not be prevented from
getting access to data
they may need to protect
their domain name</span><u></u><u></u></p>
<div style="margin-left:67.5pt">
<p class="MsoNormal"><span style="font-size:11pt"> </span><u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-left:1.5in"><span style="font-size:11pt;font-family:Calibri,sans-serif">c)
Confirm next steps</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:2in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">Support
Staff to update the text
of the Accreditation
Building Block based on
today’s discussion. EPDP
Team to provide additional
edits in the Google Doc
for implementation
guidance and definitions
by COB tomorrow, Friday,
18 October.</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:67.7pt"><span style="font-size:11pt;font-family:Calibri,sans-serif">5.
</span><a href="https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit" target="_blank"><span style="font-size:11pt;font-family:Calibri,sans-serif">Financial
Sustainability</span></a><span style="font-size:11pt;font-family:Calibri,sans-serif">
(building block n) –
second reading</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:1in"><span style="font-size:11pt">a)
Overview of updates made
following first reading</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:1in"><span style="font-size:11pt">b)
Feedback from EPDP Team</span><u></u><u></u></p>
<div style="margin-left:1in">
<p class="MsoNormal"><span style="font-size:11pt"> </span><u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-left:2in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">Third
paragraph: cost-recovery
basis is used in multiple
places. The Team needs to
define this term.
Cost-recovery is a term of
art in accounting, and
that definition is
probably not what the Team
meant here.</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:2in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">Cost
recovery may mean
different things to
different people. Also,
what does “historic costs”
mean in this context? The
users of the system should
be sustaining the
capability of the system
on an ongoing basis.</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:2in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">Second
paragraph – object to
contracted parties bearing
the costs.</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:2in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">Different
parties will bear
different costs – this
language does not explain
that division of
responsibilities. For
example, accredited
entities will bear the
costs of getting
accredited. The parties
who are receiving the
queries that contracted
parties would be
responsible for setting up
their systems to receive
queries and respond to
them.</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:2in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">Registrants
being beneficiaries of the
system may be a tenuous
argument</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:2in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">Fourth
paragraph – in favor or
usage-based fees that
sustain the operation of
this system.
</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:2in">
<span style="font-size:10pt;font-family:Symbol"><span>·<span>
</span></span></span><span dir="LTR"></span><span style="font-size:11pt;font-family:Calibri,sans-serif">A
system cannot be costed
out unless we know what
the system is designed to
do.
</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:1in"><span style="font-size:11pt">c)
Confirm next steps</span><u></u><u></u></p>
<div>
<p class="MsoNormal"><span style="font-size:11pt"> </span><u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-left:67.7pt"><span style="font-size:11pt;font-family:Calibri,sans-serif">6.
</span><a href="https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4/edit" target="_blank"><span style="font-size:11pt;font-family:Calibri,sans-serif">Terms
of use / disclosure
agreements / privacy
policies</span></a><span style="font-size:11pt;font-family:Calibri,sans-serif">
(building block m) – first
reading</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:1in"><span style="font-size:11pt">a)
Review building block</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:1in"><span style="font-size:11pt">b)
Feedback from EPDP Team</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:1in"><span style="font-size:11pt">c)
Confirm next steps</span><u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-left:67.7pt"><span style="font-size:11pt;font-family:Calibri,sans-serif">7.
Wrap and confirm next EPDP
Team meeting (5 minutes):</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:1.5in"><span style="font-size:11pt">a)
Tuesday 22 October 2019 at
14.00 UTC</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:1in"><span style="font-size:11pt">b)
Confirm action items</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:1in"><span style="font-size:11pt">c)
Confirm questions for
ICANN Org, if any</span><u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<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>
</div>
</blockquote>
<div>
<p class="MsoNormal">-- <br>
Volker A. Greimann<br>
General Counsel and Policy Manager<br>
<strong>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">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.<u></u><u></u></p>
</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>
</blockquote>
<div>
<p class="MsoNormal">-- <br>
Volker A. Greimann<br>
General Counsel and Policy Manager<br>
<strong>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">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.<u></u><u></u></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</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">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">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>