<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Susan,<div class=""><br class=""></div><div class="">Responses inline. </div><div class=""><br class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 23 May 2018, at 21:26, Susan Kawaguchi <<a href="mailto:susankpolicy@gmail.com" class="">susankpolicy@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hello All, <div class=""><br class=""></div><div class="">I have given the potential ePDP much thought over the last two days. </div><div class=""><br class=""></div><div class="">To effectively do this work at the speed that it will require we need to focus the ePDP. As you all know this is a tremendous amount of work. </div><div class=""><br class=""></div><div class="">We need to address the following: </div><div class=""><br class=""></div><div class="">Including at the very least the GAC and SSAC in this ePDP will be critical. </div></div></div></blockquote><div class=""><br class=""></div>While this is still a GNSO ePDP, the fact that we will likely not run an open WG means that we should invite ACs, but I don't see why some ACs would be critical and others would not. </div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">The members of the team should be limited to 5-6 members of each SG/AC. </div></div></div></blockquote><div class=""><br class=""></div>I'm more inclined to a lesser number of members per SG, and even less from ACs, perhaps one each per AC.</div><div class=""><br class=""></div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Each member must agree to accept the fast paced extensive work load, participating on calls, subgroups and drafting when necessary. </div></div></div></blockquote><div class=""><br class=""></div>And to be willing to come to common grounds... which is the only way for this effort to not fail like all others before them have. </div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""> <br class=""></div><div class=""><br class=""></div><div class="">Understand that their work is representational of the community they are affiliated with and will receive endorsement to express views. </div></div></div></blockquote><div class=""><br class=""></div>I'm not sure of that; while I understand that idea, and this is how Council representation works for 3 of the 4 GNSO SGs, I'm afraid it could be not practical and hamper productivity, but I'm not ready yet to offer an alternative. </div><div class=""><br class=""></div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Create a leadership team with extensive knowledge and time to focus on this work. </div><div class=""><br class=""></div><div class="">Select a Chair that will have the time and skills to effectively manage the ePDP. </div></div></div></blockquote><div class=""><br class=""></div>Yeap. </div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Include a Board member for oversight and check ins on the team. <br class=""></div></div></div></blockquote><div class=""><br class=""></div>I believe Board liaison(s) would be helpful in not causing a delay by drafting a policy Board wouldn't be able to accept, but I wouldn't call them members. </div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">This ePDP should focus on the critical needs identified in the Annex of the Temporary Spec. first as these issues are of critical importance. (copied below for ease of reference) </div></div></div></blockquote><div class=""><br class=""></div><div class=""><br class=""></div>But if the main topics are not dealt with by the ePDP, temp spec will expire and lose effect... so I would rather see the opposite: taking first the items already included in the spec, bake all the uncontroversial ones into policy and begin implementation of them ASAP. Only after that first report, deal with controversial and further community action ones. Having parallel PDP/IRT teams also seem to be needed to achieve the ambitious timeframe imposed by the temp spec framework. </div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Rubens</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class=""><div class="gmail-page" title="Page 32" style="font-family: -webkit-standard;"><div class="gmail-layoutArea"><div class="gmail-column"><p class=""><span style="font-size:16pt;font-family:Calibri" class="">Annex: Important Issues for Further Community Action</span></p><p class=""><span style="font-size:12pt;font-family:Calibri" class="">The purpose of this Annex is to set forth implementation issues raised during the course of development of this Temporary Specification for which the ICANN Board encourages the community to continue discussing so that they may be resolved as quickly as possible after the effective date of the Temporary Specification. This Annex does not create new or modified requirements for Registrar or Registry Operator, nor is it intended to direct the scope of the Policy Development Process, </span><span style="font-size:12pt;font-family:Calibri" class="">which will be initiated as a result of the Board’s adoption of this</span><span style="font-size:12pt;font-family:Calibri" class="">Temporary Specification.</span></p><ol class=""><li style="font-size:12pt;font-family:Calibri" class=""><p class=""><span style="font-size:12pt" class="">Pursuant to Section 4.4, continuing community work to develop an accreditation and access model that complies with GDPR, while recognizing the need to obtain additional guidance from Article 29 Working Party/European Data Protection Board.</span></p></li><li style="font-size:12pt;font-family:Calibri" class=""><p class=""><span style="font-size:12pt" class="">Addressing the feasibility of requiring unique contacts to have a uniform anonymized email address across domain name registrations at a given Registrar, while ensuring security/stability and meeting the requirements of Section 2.5.1 of Appendix A.</span></p></li><li style="font-size:12pt;font-family:Calibri" class=""><p class=""><span style="font-size:12pt" class="">Developing methods to provide potential URS and UDRP complainants with sufficient access to Registration Data to support good-faith filings of complaints.</span></p></li><li style="font-size:12pt;font-family:Calibri" class=""><p class=""><span style="font-size:12pt" class="">Consistent process for continued access to Registration Data, including non- public data, for users with a legitimate purpose, until the time when a final accreditation and access mechanism is fully operational, on a mandatory basis for all contracted parties.</span></p></li><li style="font-size:12pt;font-family:Calibri" class=""><p class=""><span style="font-size:12pt" class="">Distinguishing between legal and natural persons to allow for public access to the Registration Data of legal persons, which are not in the remit of the GDPR.</span></p></li><li style="font-size:12pt;font-family:Calibri" class=""><p class=""><span style="font-size:12pt" class="">Limitations in terms of query volume envisaged under an accreditation program balanced against realistic investigatory cross-referencing needs.</span></p></li><li style="font-size:12pt;font-family:Calibri" class=""><p class=""><span style="font-size:12pt" class="">Confidentiality of queries for Registration Data by law enforcement authorities.</span></p><p class="">Looking forward to discussing further tonight. </p><p class="">Susan Kawaguchi </p><p class="">BC Councilor. </p><p class=""><br class=""></p></li></ol></div></div></div></div><div class=""><br class=""></div><div class=""><br class=""></div></div>
_______________________________________________<br class="">council mailing list<br class=""><a href="mailto:council@gnso.icann.org" class="">council@gnso.icann.org</a><br class=""><a href="https://mm.icann.org/mailman/listinfo/council" class="">https://mm.icann.org/mailman/listinfo/council</a><br class=""></div></blockquote></div><br class=""></div></div></div></body></html>