Dear All, Please find below the notes & action items from today’s RDS PDP WG meeting. Best regards, Marika Notes RDS PDP WG Meeting – 12 July 2016 These high-level notes are designed to help PDP WG members navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/C4xlAw. 1. Roll Call / SOI · Attendance will be taken from Adobe Connect · Please state your name before speaking for transcription purposes and remember to mute your microphones / phones when not speaking · Updates to SOIs: Andrew Sullivan updated his SOI to reflect recent changes, Mark to review his SOI and update if needed, Volker Greimann to update SOI to reflect recent changes. · Reminder: please remember to review and update your SOI if needed 2. Helsinki Meeting Action Item Progress Updates (see attached), including: a. Public comment review tool outreach message #1 - deadline for comments 15 July Action item #1: please provide any input on the public comment review tool on outreach message #1 you may have by 15 July at the latest. b. Status update problem statement drafting team · Update to be provided by James Gannon (not on the call due to travel issues) · Discussions are ongoing and a draft statement is being worked on, although it is not in a problem statement format yet. · The draft problem statement is here - https://etherpad.wikimedia.org/p/gnso-rds-pbstatement-0 - but it is a work in progress · Further work expected to be undertaken later this week - other work will not stop while this work is underway. Action item #2: Susan to reach out to James to obtain input on next steps and expected timeline, to include sharing a draft with the full WG for review. c. Possible F2F meeting at ICANN57 - doodle poll to assess availability · GNSO Council to consider options for F2F PDP WG meetings to take place at ICANN57, whether it is a full day for one group or two blocks of 4 hours to allow two PDP WGs to meet · In order to assess interest and availability of WG members to participate in a potential F2F meeting either in person or remotely, which would likey take place on day 1 of the ICANN meeting, a doodle poll will be circulated amongst the WG membership. · The GNSO Council is expected to review & discuss the schedule for ICANN57 during its meeting next Thursday (21 July) Action item #3: Staff to circulate doodle poll Action item #4: WG members to fill out the poll to indicate their availability to participate either in person or remotely 3. Continue discussion on Task 11: Method for reaching consensus in deliberations (see latest version attached) problem statement for WG, statement of purpose for RDS, use case methodology, triaging the possible requirements list · See latest version (version 13, 8 July 2016) · Main changes in section 3 · Steps 1 & 2: How to ensure that consultations can take place on the details and not only the high level concepts? Important to consider this going forward. · Step 3: · Overview of Use Case Methodology - the EWG used this approach to discuss several aspects at once, including data elements, purposes, users, and dependencies (constraints, requirements) and to balance out factors that would tend to compete with each other · The idea was for each Use Case to describe primary goals, primary actors, stakeholders, needed data elements to accomplish goals · Use Cases are commonly used to develop stories in system and software development - to walk through scenarios that might occur and expose issues such as legal limitations so that they can be addressed · Use Cases are also used to describe scenarios that you don't want to happen - for example, exploits that you want to design a system to prevent (eg hacker trying to get into database, someone trying to access data they should not have access to) · Use Cases can be used in a variety of ways to explore possible requirements and limiting factors so that you can address policy and technical solutions to balance · Sometimes it is good to explicitly describe non-goals - as we discuss things we might do, sometimes it is good to also make explicit things we think should not be done, to maintain a comprehensive list of things that were discussed to reduce the need to revisit them · If the WG agrees on certain use cases and then build a system to support them, how quickly can the RDS (or RDAP) be modified to prevent a use case that becomes illegal at a later time · Part of the benefit of Use Cases is to describe when there are constraints such as laws that apply in certain jurisdictions or in certain storage models, so that you can consider how to accommodate this and the implications on goals, data, etc · Noted that it is not clear RDAP extensions would be needed to prevent a certain use case and the RDAP protocol is designed for flexibility (see chat) · If you have different things you are trying to accomplish and they appear in several Use Cases, it allows you to identify commonality and functions or data that you might want to provide (or prevent) to meet the goals of many Use Cases · Our task is still to develop policy requirements but Use Cases are a methodology to help us discuss them and organize our work - Use Cases are a useful tool to bring all of the things you may need together into a coherent story that can be discussed among people with different backgrounds. However Use Cases are not themselves possible requirements - they inform the WG's work on possible requirements. · Example Use Case included in the EWG's final report and appended to the Task 11 approach draft covers Technical Issue Resolution - someone trying to resolve an operational or technical problem with a registered domain name · Chat comment: At the end of the exercise, I believe we will have lists of (a) desired behaviors to enable (b) undesirable behavior to actively prevent (c) "nice to have" behavior that we can postpone or cut entirely from scope · How would Use Cases help us in terms of developing policy requirements in phase 1? UCs expose things you need to consider like data elements, access to data, considerations that apply to all/many use cases. For example, if you have a data element needed in only one use case, is that data element really required or can the goal be met in another way, etc. This may help the WG determine requirements that are really important because they support many use cases, and those that may not be. · Purpose of use cases is to force people who want some behavior to describe that behavior in sufficient detail that others can understand what it would take to satisfy that requirement. Sometimes you can find out that goals can be satisfied in another way. By covering both uses and non/anti-uses, you can understand and better agree upon possible requirements. · Keeping in mind that we are not now trying to design a NG RDS system - we are still trying to agree upon policy requirements that will drive system design. The WG shouldn't get hung up on computer system architecture yet. · Also noted that the IETF has defined a protocol (RDAP) that gives us the tools to support requirements and policies that fulfill those requirements - designing a protocol (or system implementation that uses the protocol) is not our task · Latest version of triaged list will be circulated to WG shortly after this meeting, but is still work in progress. Note the triaged list will be open for WG review and comments - it is intended to serve as a starting point. · While work is ongoing on the possible requirements list (both word format as well as excel), the WG will start discussing use cases. · Examples should be taken as nothing more than examples at this stage (note that some of the previous examples have been deleted to avoid confusion). · Reasonable support for moving forward as outlined in this document, noting that refinements may be needed throughout the process. · Consider task 11 completed for now. · Volunteers to start working on use-cases: Fabricio Vayra, Nathalie Coupet, Ayden Ferdeline. Consider starting with EWG use cases. Ideally volunteers have direct experience with some of the use cases. Action item #5: Clean up possible approach to consensus document and circulate to the list as 'final' version. Action item #6: WG members to review triage document and provide feedback on the overall organisation (e.g. possible improvements, questions). Action item #7: those interested to volunteer to work on use cases to identify themselves. Action item #8: Staff to distribute EWG use cases to the mailing list 4. Confirm next meeting – Wednesday, 20 July 2016 at 05:00 UTC · During next week's meeting, allow for time to review and discuss triage of possible requirements document; update on problem statement; start work on purpose and use cases. Marika Konings Senior Policy Director & Team Leader for the GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings@icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<http://learn.icann.org/courses/gnso> and visiting the GNSO Newcomer pages<http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-e...>.