Hello all, I’ve worked through the questions Sebastien posed and have the following responses. Looking forward to our meeting tomorrow! 1. What is such a pilot expected to prove / disprove? The most important data gap in the ODA is the unknown volume of use for the SSAD. If we had a more clear/reliable volume estimate, we'd be able to more accurately anticipate costs for building and operating the SSAD. We need to ensure any pilot project will address this gap by providing accurate and useable data disclosure request volumes which include all Contracted Parties and Requestors rather than just a subset of either. 2. Which aspects of the SSAD recommendations would need to be part of such a pilot to provide essential insights, which ones are nice to have, and which ones are not relevant for a pilot? Necessary: (Note there would need to be some adjustments due to interconnection of recs, e.g. criteria is relevant but includes info about accreditation which is not relevant, and e.g. to create more tailored/targeted/relevant Terms & Conditions, etc) Recommendation #3. Criteria and Content of Requests Recommendation #4. Acknowledgement of receipt and relay of the disclosure request Recommendation #5. Response Requirements Recommendation #6. Priority Levels Recommendation #8. Contracted Party Authorization. Recommendation #10. Determining Variable SLAs for response times for SSAD Recommendation #11. SSAD Terms and Conditions Recommendation #12. Disclosure Requirement Recommendation #15. Logging Recommendation #17. Reporting Requirements Nice to have: Recommendation #7. Requestor Purposes Recommendation #13. Query Policy Not relevant: Recommendation #1. Accreditation Recommendation #2. Accreditation of governmental entities Recommendation #9. Automation of SSAD Processing Recommendation #14. Financial Sustainability Recommendation #16. Audits Recommendation #18. Review of implementation of policy recommendations concerning SSAD using a GNSO Standing Committee 3. Which parties would need to partake in such a pilot to make the findings useful? ICANN would update the existing ticketing system and then continue to track/distribute tickets appropriately Contracted parties would continue to receive tickets sent to them via the ticketing system, and would respond to the requestor directly Requestors would submit requests to the ticketing system 4. What would be the success factors of such a pilot (i.e. what type of information must be part of the results of the pilot to allow for a determination on the cost/benefit of SSAD and/or what modifications could / should be made to change that balance, if deemed necessary and desirable)? This pilot should run for a period of time sufficient to gather a representative picture of the request volume (proposed minimum 6 months maximum 2 years). All requests which would otherwise be submitted to the SSAD would instead be processed through this ticketing system. (note: requests may also be sent directly to the CP under Phase1 Rec18; there’s no way to prevent that.) Thanks, -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld@tucows.com From: Sebastien@registry.godaddy Sent: March 9, 2022 8:28 AM To: gnso-epdpp2-smallteam@icann.org Subject: [GNSO-EPDPP2-SmallTeam] EPDP Phase 2 Small Team update Dear Small Team members, I hope you are having an informative and productive ICANN73. In preparation for our meeting next week, I wanted to share a couple of things with you and ask you to start thinking about our next conversation. • First of all, thank you for the ODA clarifying questions. These have been shared with the ICANN org ODP Team. We hope to get some feedback on these in the next week or so. • Following the ICANN Board – GNSO Council meeting and the positive reaction from the ICANN Board to schedule an informal meeting between interested Board members and the small team, I’ve reached out to Becky Burr to get this scheduled. As we are aiming to provide our feedback to the GNSO Council by the end of March, I’ve suggested the following sequence of meetings: o Wednesday 16 March Small team meeting (already scheduled) o Monday 21 March joint meeting with GDPR Board Caucus / interested Board members o Wednesday 23 March Small team meeting o Monday 28 March joint meeting with GDPR Board Caucus / interested Board members o Wednesday 30 March small team meeting to finalize response to Council Of course, if in the end additional time and/or additional meetings are needed, we can adjust accordingly but for now I hope we are all willing to work towards the timeline we shared with the GNSO Council prior to ICANN73. To prepare for our conversation next week, I would like to encourage you all to review the input that has been received in the google doc. As I shared in my high-level summary last week, most small team members seem to be of the view that the ODA does not provide enough information to confidently determine the cost / benefit. Some point to the inability to predict costs based on usage, the high variability and range of costs and lack of information on the specific costs of the different components of the system. This in my mind raises the question of what further information is needed and how can it be obtained, to allow the GNSO Council as well as the ICANN Board to confidently determine the cost / benefit and/or determine if modifications need to be made. Some have suggested that a pilot / ticketing system could assist in that regard. However, before we dive into what such a pilot / ticketing system could/should look like, I think we need to take a step back and ask ourselves some of the following questions. Assuming for a moment that there is support at Council level as well as the ICANN Board level for conducting a pilot of some kind to gather further information: 5. What is such a pilot expected to prove / disprove? 6. Which aspects of the SSAD recommendations would need to be part of such a pilot to provide essential insights, which ones are nice to have, and which ones are not relevant for a pilot? 7. Which parties would need to partake in such a pilot to make the findings useful? 8. What would be the success factors of such a pilot (i.e. what type of information must be part of the results of the pilot to allow for a determination on the cost/benefit of SSAD and/or what modifications could / should be made to change that balance, if deemed necessary and desirable)? I know that these are not easy questions to answer that is why I would like you to start thinking about these, and ideally, share any thoughts you may have with the list so we can start this conversation prior to our next meeting. We obviously need to be conscious of the fact that a pilot is a pilot - it cannot prove everything to everyone, because by the time to have everything in place to test, you will have the final product. The pilot needs to be the result of what we want to test, and the pilot in turn will be the tool to provide the answers to that test. I think this will also be an important part of our informal conversation with the ICANN Board, because if this turns out to be the direction the small team wants to take, we do want to make sure that any pilot has the ability to either confirm or disprove the concerns that the Board expressed in its letter so that it helps inform a decision on how to proceed. I hope this is helpful. Of course, if there is any other information and/or ideas that have emerged from discussions during ICANN73 that may be helpful, please feel free to share these with the group. Kindly, Sebastien Ducos GoDaddy Registry | Senior Client Services Manager +33612284445 France & Australia sebastien@registry.godaddy
