<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi JK, <br>
</p>
<p>we are not disagreeing here, I think, just trying to clarify our
understanding. I also agree to that principle.</p>
<p>Best,</p>
<p>Volker<br>
</p>
<div class="moz-cite-prefix">Am 21.10.2019 um 12:48 schrieb Janis
Karklins:<br>
</div>
<blockquote type="cite"
cite="mid:CAO3s21SY44qHPEKHMX02BQttcV6Yi1=tHFSG6aU9BnNZoLSVrA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Volker,
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>JK</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Oct 21, 2019 at 2:45
AM Volker Greimann <<a
href="mailto:vgreimann@key-systems.net"
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 bgcolor="#FFFFFF">
<p>Hi Alex, <br>
</p>
<p>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. <br>
</p>
<p>I think it would be helpful if we were all more clear in
what we mean when we use certain words. <br>
</p>
<p>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".</p>
<p>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. <br>
</p>
<p>My personal position on this is that this point can be
left open: <br>
</p>
<p>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?</p>
<p>Best,</p>
<p>Volker<br>
</p>
<div>Am 20.10.2019 um 19:02 schrieb Alex Deacon:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>Volker and all, </div>
<div><br>
</div>
<div>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</div>
<div>
<div dir="ltr">
<div dir="ltr">___________
<div><b>Alex Deacon</b></div>
<div>Cole Valley Consulting</div>
<div><a
href="mailto:alex@colevalleyconsulting.com"
target="_blank" moz-do-not-send="true">alex@colevalleyconsulting.com</a></div>
<div>+1.415.488.6009</div>
<div><br>
</div>
</div>
</div>
</div>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Oct 18,
2019 at 1:01 PM 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 dir="ltr">
<p
style="margin-right:0in;margin-left:67.7pt;margin-bottom:0.0001pt"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:black"><span>Hi
Caitlin,</span></span></p>
<p
style="margin-right:0in;margin-left:67.7pt;margin-bottom:0.0001pt"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:black"><span>I
don't think 4.B) Principle B: <br>
</span></span></p>
<ul type="disc">
<li style="color:black;margin-left:1.5in"><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></li>
</ul>
<div>
<div dir="ltr">
<div><span lang="EN-US">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. <br>
</span></div>
<div dir="ltr"><span lang="EN-US"><br>
</span></div>
<div dir="ltr"><span lang="EN-US">-- <br>
Volker A. Greimann<br>
General Counsel and Policy Manager<br>
<b>KEY-SYSTEMS GMBH</b><br>
<br>
T: +49 6894 9396901<br>
M: +49 6894 9396851<br>
F: +49 6894 9396851<br>
W: </span><a
href="http://www.key-systems.net/"
style="color:rgb(17,85,204)"
target="_blank" moz-do-not-send="true"><span
lang="EN-US">www.key-systems.net</span></a><span
lang="EN-US"><br>
<br>
Key-Systems GmbH is a company registered
at the local court of Saarbruecken,
Germany with the registration no. HR B
18835<br>
CEO: Alexander Siffrin<br>
<br>
Part of the CentralNic Group PLC (LON:
CNIC) a company registered in England
and Wales with company number 8576358.</span><br>
</div>
</div>
</div>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Oct
18, 2019 at 1:17 AM Caitlin Tubergen <<a
href="mailto:caitlin.tubergen@icann.org"
target="_blank" moz-do-not-send="true">caitlin.tubergen@icann.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div lang="EN-US">
<div>
<p class="MsoNormal"><span
style="font-size:11pt">Dear EPPD Team:</span></p>
<p class="MsoNormal"><span
style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span
style="font-size:11pt">Please find
below the notes and action items from
today’s EPDP Team meeting.</span></p>
<p class="MsoNormal"><span
style="font-size:11pt"> </span></p>
<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></p>
<p class="MsoNormal"><span
style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span
style="font-size:11pt">Best regards,</span></p>
<p class="MsoNormal"><span
style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span
style="font-size:11pt">Marika, Berry,
and Caitlin</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><b><span
style="font-size:11pt;color:black">EPDP
Phase 2 - Meeting #25</span></b><span
style="color:black"></span></p>
<p class="MsoNormal"><b><span
style="font-size:11pt;color:black">Proposed
Agenda</span></b><span
style="color:black"></span></p>
<p class="MsoNormal"><span
style="font-size:11pt;color:black">Thursday,
17 October 2019 at 14.00 UTC</span></p>
<p class="MsoNormal"><span
style="font-size:11pt;color:black"> </span></p>
<p class="MsoNormal"><u><span
style="font-size:11pt;color:black">Action
Items</span></u></p>
<ol start="1" type="1">
<li style="color:black"><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"
moz-do-not-send="true">Accreditation
Building Block</a> and <a
href="https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit"
target="_blank"
moz-do-not-send="true">Financial
Sustainability Block</a> based on
today’s discussion. </span></li>
<li style="color:black"><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"
moz-do-not-send="true">Accreditation
Building Block</a> re:
implementation guidance and
definitions by COB tomorrow, <b>Friday,
18 October</b>.</span></li>
<li style="color:black"><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"
moz-do-not-send="true">Financial
Sustainability Block</a> by <b>Friday,
18 October</b>.</span><u><span
style="font-family:Calibri,sans-serif"></span></u></li>
<li style="color:black"><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"
moz-do-not-send="true">Building
Block M – Terms of Use/Disclosure
Agreements/Privacy Policies</a> by
<b>Monday, 21 October</b>.</span><u><span
style="font-family:Calibri,sans-serif"></span></u></li>
</ol>
<p
style="margin-right:0in;margin-left:67.7pt;margin-bottom:0.0001pt"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:black"><span>1.<span>
</span></span></span><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:black">Roll
Call & SOI Updates (5 minutes)</span><span
style="font-family:Calibri,sans-serif;color:black"></span></p>
<p
style="margin-right:0in;margin-left:67.7pt;margin-bottom:0.0001pt"><span
style="font-family:Calibri,sans-serif;color:black"> </span></p>
<p
style="margin-right:0in;margin-left:67.7pt;margin-bottom:0.0001pt"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:black"><span>2.<span>
</span></span></span><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:black">Confirmation
of agenda (Chair)</span><span
style="font-family:Calibri,sans-serif;color:black"></span></p>
<p
style="margin-right:0in;margin-left:67.7pt;margin-bottom:0.0001pt"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:black"> </span></p>
<p
style="margin-right:0in;margin-left:67.7pt;margin-bottom:0.0001pt"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:black"><span>3.<span>
</span></span></span><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:black">Welcome
and housekeeping issues (Chair) (5
minutes)</span></p>
<p style="margin-left:1in"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:black"><span>a)<span>
</span></span></span><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:black">Update
from legal committee</span></p>
<p style="margin-left:1in"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:black"><span>b)<span>
</span></span></span><a
href="https://community.icann.org/x/k5ICBw"
target="_blank" moz-do-not-send="true"><span
style="font-size:11pt;font-family:Calibri,sans-serif">Status of building
blocks</span></a><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:black"></span></p>
<p
style="margin-right:0in;margin-left:67.7pt;margin-bottom:0.0001pt"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:black"><span>4.<span>
</span></span></span><a
href="https://docs.google.com/document/d/1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY/edit"
target="_blank" moz-do-not-send="true"><span
style="font-size:11pt;font-family:Calibri,sans-serif">Accreditation</span></a><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:black">
(building block f and j) – second
reading continued (30 minutes) </span></p>
<p
style="margin-right:0in;margin-left:1.5in;margin-bottom:0.0001pt"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:black"><span>a)<span>
</span></span></span><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:black">Overview
of implementation guidance section</span></p>
<p style="margin-left:1.5in"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:black"><span>b)<span>
</span></span></span><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:black">Feedback
from EPDP Team</span></p>
<p style="margin-left:1.5in"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:black">Principle
b</span></p>
<ul type="disc">
<li
style="color:black;margin-left:1.5in"><span
style="font-size:11pt;font-family:Calibri,sans-serif">Requirements
should be spelled out as part of the
policy discussion</span></li>
<li
style="color:black;margin-left:1.5in"><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></li>
<li
style="color:black;margin-left:1.5in"><span
style="font-size:11pt;font-family:Calibri,sans-serif">These requirements
should be as uniform as possible</span></li>
<li
style="color:black;margin-left:1.5in"><span
style="font-size:11pt;font-family:Calibri,sans-serif">C may need to come
before B</span></li>
<li
style="color:black;margin-left:1.5in"><span
style="font-size:11pt;font-family:Calibri,sans-serif">There needs to be
an underlying baseline of
requirements that are uniform.</span></li>
<li
style="color:black;margin-left:1.5in"><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></li>
<li
style="color:black;margin-left:1.5in"><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></li>
<li
style="color:black;margin-left:1.5in"><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></li>
<li
style="color:black;margin-left:1.5in"><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></li>
<li
style="color:black;margin-left:1.5in"><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></li>
<li
style="color:black;margin-left:1.5in"><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></li>
<li
style="color:black;margin-left:1.5in"><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></li>
<li
style="color:black;margin-left:1.5in"><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></li>
<li
style="color:black;margin-left:1.5in"><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></li>
<li
style="color:black;margin-left:1.5in"><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></li>
<li
style="color:black;margin-left:1.5in"><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></li>
</ul>
<p class="MsoNormal"
style="margin-left:1in"><span
style="font-size:11pt;color:black">Principle
d</span></p>
<ul type="disc">
<li
style="color:black;margin-left:108.35pt"><span
style="font-size:11pt;font-family:Calibri,sans-serif">What is the
expectation for what
de-accreditation means?</span></li>
<li
style="color:black;margin-left:108.35pt"><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></li>
<li
style="color:black;margin-left:108.35pt"><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></li>
</ul>
<p class="MsoNormal"
style="margin-left:67.5pt"><span
style="font-size:11pt;color:black">Principle
g</span></p>
<ul type="disc">
<li style="color:black;margin-left:1in"><span
style="font-size:11pt;font-family:Calibri,sans-serif">What is the
accreditation policy and
requirements – where is this?</span></li>
<li style="color:black;margin-left:1in"><span
style="font-size:11pt;font-family:Calibri,sans-serif">The accreditation
policy and associated requirements
have not been drafted/implemented
yet </span></li>
</ul>
<p class="MsoNormal"
style="margin-left:67.5pt"><span
style="font-size:11pt;color:black">Principle
i</span></p>
<ul type="disc">
<li style="color:black;margin-left:1in"><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></li>
<li style="color:black;margin-left:1in"><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></li>
<li style="color:black;margin-left:1in"><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></li>
<li style="color:black;margin-left:1in"><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></li>
<li style="color:black;margin-left:1in"><span
style="font-size:11pt;font-family:Calibri,sans-serif">Perhaps the second
sentence could be moved to Block N.</span></li>
<li style="color:black;margin-left:1in"><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></li>
<li style="color:black;margin-left:1in"><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></li>
<li style="color:black;margin-left:1in"><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></li>
<li style="color:black;margin-left:1in"><span
style="font-size:11pt;font-family:Calibri,sans-serif">Maintain first
sentence and delete second sentence</span></li>
<li style="color:black;margin-left:1in"><span
style="font-size:11pt;font-family:Calibri,sans-serif">This conversation
can be moved to the financial
building block.</span></li>
<li style="color:black;margin-left:1in"><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></li>
<li style="color:black;margin-left:1in"><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></li>
</ul>
<p class="MsoNormal"
style="margin-left:67.5pt"><span
style="font-size:11pt;color:black">Principle
k</span></p>
<ul type="disc">
<li
style="color:black;margin-left:67.5pt"><span
style="font-size:11pt;font-family:Calibri,sans-serif">The use of the
word “tagging” is confusing </span></li>
<li
style="color:black;margin-left:67.5pt"><span
style="font-size:11pt;font-family:Calibri,sans-serif">Marc to submit
proposed updated online</span></li>
<li
style="color:black;margin-left:67.5pt"><span
style="font-size:11pt;font-family:Calibri,sans-serif">What is the
meaning b/w the first and second
sentence?</span></li>
<li
style="color:black;margin-left:67.5pt"><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></li>
<li
style="color:black;margin-left:67.5pt"><span
style="font-size:11pt;font-family:Calibri,sans-serif">The second
sentence in k does not make sense. </span></li>
</ul>
<p class="MsoNormal"
style="margin-left:67.5pt"><span
style="font-size:11pt;color:black">Implementation
Guidance Feedback</span></p>
<ul type="disc">
<li
style="color:black;margin-left:67.5pt"><span
style="font-size:11pt;font-family:Calibri,sans-serif">Drafting note c –
legitimate and lawful purpose
described above (stated)</span></li>
<li
style="color:black;margin-left:67.5pt"><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></li>
<li
style="color:black;margin-left:67.5pt"><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></li>
<li
style="color:black;margin-left:67.5pt"><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></li>
<li
style="color:black;margin-left:67.5pt"><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></li>
<li
style="color:black;margin-left:67.5pt"><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></li>
<li
style="color:black;margin-left:67.5pt"><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></li>
<li
style="color:black;margin-left:67.5pt"><span
style="font-size:11pt;font-family:Calibri,sans-serif">SSAD should be
usable by everyone and not exclude
anyone</span></li>
<li
style="color:black;margin-left:67.5pt"><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></li>
<li
style="color:black;margin-left:67.5pt"><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></li>
</ul>
<p class="MsoNormal"
style="margin-left:67.5pt"><span
style="font-size:11pt;color:black"> </span></p>
<p style="margin-left:1.5in"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:black"><span>c)<span>
</span></span></span><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:black">Confirm
next steps</span></p>
<ul type="disc">
<li
style="color:black;margin-left:1.5in"><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></li>
</ul>
<p
style="margin-right:0in;margin-left:67.7pt;margin-bottom:0.0001pt"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:black"><span>5.<span>
</span></span></span><a
href="https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit"
target="_blank" moz-do-not-send="true"><span
style="font-size:11pt;font-family:Calibri,sans-serif">Financial
Sustainability</span></a><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:black">
(building block n) – second reading</span></p>
<p class="MsoNormal"
style="margin-left:1in"><span
style="font-size:11pt;color:black"><span>a)<span>
</span></span></span><span
style="font-size:11pt;color:black">Overview
of updates made following first
reading</span></p>
<p class="MsoNormal"
style="margin-left:1in"><span
style="font-size:11pt;color:black"><span>b)<span>
</span></span></span><span
style="font-size:11pt;color:black">Feedback
from EPDP Team</span></p>
<p class="MsoNormal"
style="margin-left:1in"><span
style="font-size:11pt;color:black"> </span></p>
<ul type="disc">
<li
style="color:black;margin-left:1.5in"><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></li>
<li
style="color:black;margin-left:1.5in"><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></li>
<li
style="color:black;margin-left:1.5in"><span
style="font-size:11pt;font-family:Calibri,sans-serif">Second paragraph –
object to contracted parties bearing
the costs.</span></li>
<li
style="color:black;margin-left:1.5in"><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></li>
<li
style="color:black;margin-left:1.5in"><span
style="font-size:11pt;font-family:Calibri,sans-serif">Registrants being
beneficiaries of the system may be a
tenuous argument</span></li>
<li
style="color:black;margin-left:1.5in"><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></li>
<li
style="color:black;margin-left:1.5in"><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></li>
</ul>
<p class="MsoNormal"
style="margin-left:1in"><span
style="font-size:11pt;color:black"><span>c)<span>
</span></span></span><span
style="font-size:11pt;color:black">Confirm
next steps</span></p>
<p class="MsoNormal"><span
style="font-size:11pt;color:black"> </span></p>
<p
style="margin-right:0in;margin-left:67.7pt;margin-bottom:0.0001pt"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:black"><span>6.<span>
</span></span></span><a
href="https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4/edit"
target="_blank" moz-do-not-send="true"><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;color:black">
(building block m) – first reading</span></p>
<p class="MsoNormal"
style="margin-left:1in"><span
style="font-size:11pt;color:black"><span>a)<span>
</span></span></span><span
style="font-size:11pt;color:black">Review
building block</span></p>
<p class="MsoNormal"
style="margin-left:1in"><span
style="font-size:11pt;color:black"><span>b)<span>
</span></span></span><span
style="font-size:11pt;color:black">Feedback
from EPDP Team</span></p>
<p class="MsoNormal"
style="margin-left:1in"><span
style="font-size:11pt;color:black"><span>c)<span>
</span></span></span><span
style="font-size:11pt;color:black">Confirm
next steps</span></p>
<p class="MsoNormal"><span
style="color:black"> </span></p>
<p
style="margin-right:0in;margin-left:67.7pt;margin-bottom:0.0001pt"><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:black"><span>7.<span>
</span></span></span><span
style="font-size:11pt;font-family:Calibri,sans-serif;color:black">Wrap
and confirm next EPDP Team meeting (5
minutes):</span><span
style="font-family:Calibri,sans-serif;color:black"></span></p>
<p class="MsoNormal"
style="margin-left:1.5in"><span
style="font-size:11pt;color:black"><span>a)<span>
</span></span></span><span
style="font-size:11pt;color:black">Tuesday
22 October 2019 at 14.00 UTC</span></p>
<p class="MsoNormal"
style="margin-left:1in"><span
style="font-size:11pt;color:black"><span>b)<span>
</span></span></span><span
style="font-size:11pt;color:black">Confirm
action items</span></p>
<p class="MsoNormal"
style="margin-left:1in"><span
style="font-size:11pt;color:black"><span>c)<span>
</span></span></span><span
style="font-size:11pt;color:black">Confirm
questions for ICANN Org, if any</span></p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"> </p>
</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>
_______________________________________________<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>
</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"
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>