<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">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">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">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"><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">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">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></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">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">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">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"><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"><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"><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"><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">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>
_______________________________________________<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>
</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>