<div dir="ltr">
<p class="MsoNormal"><span style="font-size:11pt;font-family:"-webkit-standard",serif;color:black">Hi Ben,</span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:"-webkit-standard",serif;color:black">some comments on SSACs comments:<br></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:"-webkit-standard",serif;color:black"><br></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:"-webkit-standard",serif;color:black">Rec 6:
That would have been a better comment had it come at the time we were discussing priority levels. We had all come to the agreement on what constitutes an Urgent-Type request and coming back after months and voicing dissatisfaction is not helpful. I also want to point out (again) that registration data requests will not resolve phishing and malware attacks - abuse complaints will. But when you only have a hammer, all problems will start looking like nails, I guess. <br></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:"-webkit-standard",serif;color:black">Rec 10: This seems to sound like the SSAC did not understand the concept of our SLA proposal. At all! Priority 3requests do not "go from 5 days to 10 days". The 5 day goal remains at 5 days in Phase 2, we are just adding another goal that has enforcement teeth in Phase 10 that is set at 10 days. The 5 day goal stays where it is in Phase 2 and will still provide a warning to tardy responders. Hopefully you can explain this to your SSAC colleagues. <br></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:"-webkit-standard",serif;color:black">Rec 12: Yes, this is a basic principle and right data subjects have: To be informed how and by whom their data is processed. Unless there is an overriding interest, for example for law enforcement, who are free to request non-disclosure based on their legal abilities to do so. So your argument as it relates to law enforcement is missing the target as this is one of the groups that actually can get around this. <br></span></p><div>Rec 14: Someone has to pay for it and making those who use the system pay for it was the logical choice TANSTAAFL, and all that! Instead of the opponents of this recommendation criticising the proposed solution, I would have loved to see a fully baked alternative proposal that could be discussed and agreed upon. But throughout our discussion, no such proposal was made, at least none that could be even remotely acceptable to some of the parties in the room. So where is the money to build and operate this system going to come from? This was the compromise we found and agreed to at the time. No backsies!<br></div><div><br></div><div>Best regards,<br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><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: Oliver Fries and Robert Birkner<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></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 30, 2020 at 1:53 AM Ben Butler <<a href="mailto:bbutler@godaddy.com">bbutler@godaddy.com</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 class="gmail-m_4918098430538275260WordSection1">
<p class="MsoNormal"><span style="font-size:11pt;font-family:"-webkit-standard",serif;color:black">Dear Rafik, Staff, and ePDP team,<br>
<br>
Per the deadline for consensus designations, the SSAC EPDP Work Party has reviewed and discussed the finalized language and would like to flag that we cannot support, as written, the following four recommendations. Please update the listed consensus designations
accordingly. A brief rationale is provided for each, and we will provide more information in a minority statement including the nuances of where each recommendation falls short of achieving our support even if the intent was aligned with addressing our concerns.
Beyond further information on these particular recommendations, that minority statement will contain concerns about some of the other recommendations that we can support, as well as our overall concerns with issues that remain unaddressed that the EPDP was
originally chartered to handle. The SSAC’s EPDP team decisions on support/non-support for various recommendations are based on issues that were previously identified and documented in SAC101v2 and more recently SAC111 which contain the full SSAC consensus
on those issues.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"-webkit-standard",serif;color:black"> <u></u><u></u></span></p>
<ul style="margin-top:0in" type="disc">
<li class="gmail-m_4918098430538275260MsoListParagraph" style="color:black;margin-left:0in">
<span style="font-size:11pt;font-family:"-webkit-standard",serif">Recommendation 6: Priority Levels<u></u><u></u></span></li><ul style="margin-top:0in" type="circle">
<li class="gmail-m_4918098430538275260MsoListParagraph" style="color:black;margin-left:0in">
<span style="font-size:11pt;font-family:"-webkit-standard",serif">We do not feel that operational and network security investigations should be seen as Priority 3 with the corresponding SLA. Things like phishing and malware attacks need to be resolved much
more quickly than this would promote.<u></u><u></u></span></li></ul>
<li class="gmail-m_4918098430538275260MsoListParagraph" style="color:black;margin-left:0in">
<span style="font-size:11pt;font-family:"-webkit-standard",serif">Recommendation 10: Determining Variable SLAs for response times for SSAD<u></u><u></u></span></li><ul style="margin-top:0in" type="circle">
<li class="gmail-m_4918098430538275260MsoListParagraph" style="color:black;margin-left:0in">
<span style="font-size:11pt;font-family:"-webkit-standard",serif">Having SLAs for requests like Priority 3 go from 5 days to 10 days in Phase 2 is moving the needle in the wrong direction. The hope should be to strive for improvements that will make legitimate
requests through the SSAD more efficient, not less.<u></u><u></u></span></li></ul>
<li class="gmail-m_4918098430538275260MsoListParagraph" style="color:black;margin-left:0in">
<span style="font-size:11pt;font-family:"-webkit-standard",serif">Recommendation 12: Disclosure Requirement<u></u><u></u></span></li><ul style="margin-top:0in" type="circle">
<li class="gmail-m_4918098430538275260MsoListParagraph" style="color:black;margin-left:0in">
<span style="font-size:11pt;font-family:"-webkit-standard",serif">The language in this Recommendation allows a disclosing party to provide a data subject with the identity of the specific entity making a request for the RDS data. The disclosing party should
be prohibited from revealing the identity of a data requestor unless the data requestor goes through appropriate legal process. 1) The European Data Protection Board (EDPB) has told ICANN Org that revealing requestor data to data subjects is a problem. 2)
Revealing the identities of requestors will compromise investigations, including those of law enforcement, and may place some data requestors in danger. 3) Per GDPR and the Temp Spec, it is sufficient for data controllers to inform data subjects about the
types of groups to whom disclosure may occur.<u></u><u></u></span></li></ul>
<li class="gmail-m_4918098430538275260MsoListParagraph" style="color:black;margin-left:0in">
<span style="font-size:11pt;font-family:"-webkit-standard",serif">Recommendation 14: Financial Sustainability<u></u><u></u></span></li><ul style="margin-top:0in" type="circle">
<li class="gmail-m_4918098430538275260MsoListParagraph" style="color:black;margin-left:0in">
<span style="font-size:11pt;font-family:"-webkit-standard",serif">SSAC has several issues with the this Recommendation. We share concerns flagged in this consensus designation process by the ALAC, as well as concerns previously noted in SAC101v2 and more
recently SAC111.<u></u><u></u></span></li></ul>
</ul>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thank you to all for the diligent efforts thus far, and we look forward in good faith to continuing to support and improve the SSAD.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;color:black">Thank You.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;color:black">Ben Butler (on behalf of the SSAC ePDP Work Party)</span><u></u><u></u></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>