<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body>
Thanks for this Volker. I admit I had not had a chance to review the document past the SSAD model description at the start. I am rather startled that there would be a proposal that the ALAC and NCSG jointly appoint a single member. I've checked and it is not
 April 1st.<br>
<br>
Alan<br>
<br>
At 22/01/2020 04:46 AM, Volker Greimann wrote:<br>
<br>
<blockquote type="cite" class="cite" cite="">Hello Marika,<br>
<br>
thank you for the new proposal. I note that there is a new proposal included, which is the recommendation of the formation of a steering committee. Where did this come from? If it rises to the level of a proposed recommendation in the draft, it should have
 originated from the community and seen some consensus amongst our groups, but I recall no such discussion.
<br>
<br>
I appreciate the apparent desire for something other than a full-fledged PDP to make modifications as time goes by and we learn more about the SSAD and its potential flaws, but I have my doubts that the community has sufficient resources in all groups to staff
 such a body (It sounds a bit like being condemned to "EPDP for life").<br>
<br>
The proposed make-up also seems unbalanced as the 4 CPH members could be outvoted by the 5 non-contracted members, and At-Large and NCSG share one seat (I have my doubts that this could lead to anything but a stalemate for that seat). As a majority is sufficient
 to send any proposal to the GNSO council (even though it requires a supermajority), this could be problematic.
<br>
<br>
With regard to Rec 15: Logging, I porpose to clarify that logging should not extend to any personal data disclosed through the system as part of any disclosure decision as that would open up another can of privacy worms.
<br>
<br>
Rec: 14: I Don't think the "must" in the first paragraph had consensus, or am I mistaken. "should" and "may" are fine, especially since it may not be known whether automation is legally permissible in any specific case unless it leaves the realm of automation
 and enters the realm of someone looking at the request and making the relevant determination. I am all for automating that which can be automated but ultimately that must be determined by the disclosing parties.<br>
<br>
Rec 12: Suggestion: Could we add something to the effect that requestors must/should state in their request for how long they will / expect to retain the data? Also, requestors must always state in their request that in case they intend to share the data with
 third parties, who those third parties are and what their purposes are. <br>
<br>
Best,<br>
<br>
Volker<br>
<br>
Am 21.01.2020 um 15:43 schrieb Marika Konings:<br>
<blockquote type="cite" class="cite" cite="">Dear EPDP Team,<br>
 <br>
Please find below the proposed agenda for the next EPDP Team meeting which is scheduled for Thursday 23 January at 14.00 UTC.
<br>
 <br>
Also, you will find attached the proposal for an SSAD Hybrid able to evolve to a Centralized and Automated Model. Please consider this proposal with your respective group and come prepared to Thursday’s meeting to share your groups feedback – this will be
 crucial to prepare for a productive F2F meeting.  Do note that updates to the preliminary recommendations in the proposal only relate to changes that would bring the preliminary recommendations in line with the proposal described in the document – other comments
 and/or highlights have been removed for ease of reading and will be considered after the group’s review of the proposal.
<br>
 <br>
Best regards,<br>
 <br>
Caitlin, Berry and Marika<br>
 <br>
 <br>
<b>EPDP Phase 2 - Meeting #41<br>
Proposed Agenda<br>
</b>Thursday, 23 January 2020 at 14.00 UTC<br>
 <br>
<br>
1.                            Roll Call & SOI Updates (5 minutes)<br>
<br>
 <br>
<br>
2.                            Confirmation of agenda (Chair)<br>
<br>
 <br>
<br>
3.                            Welcome and housekeeping issues (Chair) (5 minutes)<br>
a)                      Update from the legal committee<br>
b)                     ICANN follow up on Belgian DPA response to Strawberry letter – see questions suggested by Marc Anderson:<br>
·      Is ICANN expecting an additional communication on the Strawberry letter?<br>
·      Would ICANN org like feedback from the EPDP Team before it meets with the Belgian DPA?<br>
 <br>
<br>
4.       Introduction of Proposal for an SSAD Hybrid able to evolve to a Centralized and Automated Model (“The Chameleon”)<br>
a)                      Staff overview<br>
b)                     EPDP Team reactions<br>
c)                      Confirm next steps<br>
 <br>
5.                            Plans for F2F meeting in Los Angeles <br>
a)                     Leadership Priorities<br>
b)                     EPDP Team input<br>
c)                      Confirmation of expected homework / preparations by EPDP Team for the LA F2F meeting<br>
d)                     Confirm next steps<br>
 <br>
6.                            Continue review of issues list (those items not dependent on item #4), if time allows<br>
a)                     See highlighted items on the issue list (to be circulated)<br>
b)                     EPDP Team input<br>
c)                      Confirm next steps<br>
 <br>
<br>
7.                            Wrap and confirm next EPDP Team meeting (5 minutes):<br>
a)                      Monday 27 January 2020 at 9.00 local time at the ICANN office<br>
b)                     Confirm action items<br>
c)                      Confirm questions for ICANN Org, if any<br>
 <br>
<br>
<br>
<pre>_______________________________________________
Gnso-epdp-team mailing list
<a href="mailto:Gnso-epdp-team@icann.org">Gnso-epdp-team@icann.org</a>
<a href="https://mm.icann.org/mailman/listinfo/gnso-epdp-team" eudora="autourl">
https://mm.icann.org/mailman/listinfo/gnso-epdp-team</a>
_______________________________________________
By submitting your personal data, you consent to the processing of your
personal data for purposes of subscribing to this mailing list accordance
with the ICANN Privacy Policy
(<a href="https://www.icann.org/privacy/policy">
https://www.icann.org/privacy/policy</a>) and the website Terms of
Service
(<a href="https://www.icann.org/privacy/tos">
https://www.icann.org/privacy/tos</a>). You can visit the Mailman link
above to change your membership status or configuration, including
unsubscribing, setting digest-style delivery or disabling delivery
altogether (e.g., for a vacation), and so on.</pre>
</blockquote>
-- <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">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.<br>
_______________________________________________<br>
Gnso-epdp-team mailing list<br>
Gnso-epdp-team@icann.org<br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-epdp-team" eudora="autourl">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" eudora="autourl"> https://www.icann.org/privacy/policy</a>)
 and the website Terms of Service (<a href="https://www.icann.org/privacy/tos" eudora="autourl"> 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>
</body>
</html>