For those who were not able to participate in the meeting (whether in-person or remotely), please note Action Item #5: All WG members are asked to review F2F meeting recordings Part 2 and/or transcript Part 3 to ensure that all WG members are up to date with the discussions that took place in Helsinki. Please do this as soon as possible. Several other actions will apply when the applicable updated documents are distributed and a few actions have already been done by staff. Chuck From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Lisa Phifer Sent: Thursday, June 30, 2016 9:24 AM To: gnso-rds-pdp-wg@icann.org Subject: [gnso-rds-pdp-wg] Notes and Action Items - RDS PDP WG F2F Meeting - 28 June 2016 Dear all, The following notes summarize key points of discussion, agreements, and action items from the RDS PDP WG F2F meeting on 28 June at ICANN56. All WG members - especially those who were unable to attend the meeting - are asked, prior to providing their input, to review the official transcript and recordings of the meeting: · Transcript GNSO RDS Part 1 28 June Helsinki<http://schd.ws/hosted_files/icann562016/f0/Transcript%20RDS%201%2028%20June%...> · Transcript GNSO RDS Part 2 28 June Helsinki <http://schd.ws/hosted_files/icann562016/29/Transcript%20GNSO%20RDS2%2028%20J...> · Transcript GNSO RDS Part 3 28 June Helsinki<http://schd.ws/hosted_files/icann562016/cd/Transcript%20GNSO%20RDS3%2028%20J...> · Adobe Connect Recording Multimedia Session Recording<https://icann.adobeconnect.com/p3qr9nmm42k/> Part 1 · Adobe Connect Recording Multimedia Session Recording Part 2<https://icann.adobeconnect.com/p3ty476eer8/> · English Audio Session Recording Part 1<http://audio.icann.org/meetings/hel56/hel56-OPEN-2016-06-28-T0425-hallb-IC3B...> · English Audio Session Recording Part 2<http://stream.icann.org:8000/hel56-hallb-en.m3u> In particular, refer to Transcript Part 3 (Adobe Connect Session Recording Part 2) for significant discussion of how the WG will begin deliberation to reach consensus. After brief initial deliberation on a few possible requirements, participants agreed to revamp the proposed approach by starting with a statement of purpose and use cases to establish a foundation for deliberation on specific possible requirements. This proposed approach will be circulated to the full WG for comment by 7 July. 1. Introductions · WG members in attendance introduced themselves. · No SOI updates were noted. 2. PDP Work Plan: Accomplishments and Status · Current Work Plan: https://community.icann.org/x/oIxlAw · Reviewed WG progress on recent tasks o Task 7e: Outreach #1 - Review & Analyze inputs using Comment Review Tool (16 June) - Task completed at this meeting (see agenda item 3 below) o Task 9c: Outreach #2 - Request additional Possible Requirements (11-27 June) - Additions received from RySG, response with no further inputs at this time received from NCSG, GAC expects to respond by end of July. o Task 11: Decide how and when the WG will try to reach consensus - Task continued in this meet (see agenda item 3 below) · Approved Work Plan was relayed to GNSO Council by liaison Stephanie Perrin to inform them of this WG's initial plans. · Timeline for completing phase 1? Task 11 will determine approach to reaching consensus during phase 1; this will help us get a better handle on timeline, but phase 1 will take a while. · If an SO/AC/SG/C doesn't have any input at this point, it would still be helpful if they indicate this now to facilitate planning of WG activities. 3. PDP Work Plan: Next Steps and Working Session Task 7f: Outreach #1 - Finalize Comment Review Tool · The WG reviewed the draft Comment Review Tool: Outreach #1 - Public Comment Review Tool - 25 June 2016 .docx<https://community.icann.org/download/attachments/59641480/Outreach%20%231%20...> · Q2-RySG - Add text under Action Items: WG members should be tasked with extracting possible requirements from the RySG comments provided here · Responses that refer to deliberating upon possible requirements should note that the WG is currently developing a phase 1 process for deliberating on all possible requirements · How will the GAC be engaged in this PDP so that concerns are not raised at the end of the process? * It is important to address any differences between PDP advice and GAC advice throughout the PDP process, so that there is no need for board to consider over-riding policy recommendations. * Steps have already been taken to facilitate this - for example, the GAC has provided input through outreach #1 - and it is important that input is taken into consideration by the WG. We have an active liaison to the GAC PSWG (Greg Mounier) to facilitate on-going interaction. There may still be situations where the GAC does not agree with GNSO consensus policy but hopefully there will be fewer with early/on-going engagement. · To answer the question of is a new RDS needed we need to take into consideration the outcome of parallel WHOIS improvements - it is part of this WG's charter to do so. If improvements haven't yet been implemented, may need to reflect any assumptions in the WG's initial report. · Q2-GAC - Vicky Scheckler volunteered to extract possible requirements from the GAC's suggested inputs. Adjust action item text to reflect this. · Noted that some EWG member statements and blogs still need volunteers to extract possible requirements. Ayden Ferdeline and Stacie Walsh volunteered to do so. · Q4-SSAC response - Revise to indicate that the WG is in the process of gathering possible requirements to help define the problem. · Q4 SSAC response - A Problem Statement drafting team was formed to help develop a very concise and tight problem statement, drawing from the Issue Report and Charter. This should be a conceptual problem statement; it should not redefine the issue or charter or go into details and/or solutions. This drafting will be done in parallel to ongoing work. · Volunteers for this drafting team are: * Stephanie Perrin * James Gannon. * Alex Deacon * Nick Shore * Shane Kerr * Ayden Federline * Susan Kawaguchi (leadership liaison) * Mark Svancarek * Daniel Nanghanki * Marina A. Lewis · With respect to RDAP, this WG may recommend that RDAP be used to implement policy, but any policy needs requiring RDAP extension will need to be relayed to the IETF for consideration. Action Item #1: The sign-up sheet will be updated to reflect the following volunteers will review these documents to extract possible requirements: · Additional GAC-suggested documents - Vicky Sheckler · Dissenting Report from Stephanie Perrin - Ayden Ferdeline · Where Do Old Protocols Go To Die? by Scott Hollenbeck - Stacie Walsh · Building a Better WHOIS for the Individual Registrant - Stacie Walsh Action Item #2: Staff to update draft Comment Tool to reflect noted change and circulate to WG for final approval within two weeks. Action Item #3: Staff to create a mailing list for the Problem Statement drafting team. Concise Problem Statement to be drafted by team for WG consideration. Task 9e: Outreach #2 - Incorporate additional Possible Requirements · Possible requirements from Cross-Community RDS session were posted to mailing list, see: http://mm.icann.org/pipermail/gnso-rds-pdp-wg/2016-June/000933.html · All additions suggested during Cross-Community RDS session to be added to the next draft of the WG's ongoing Possible Requirements List after confirming with transcript · Also expect to incorporate any additional Possible Requirements gathered during Outreach #2, as well as those to be extracted by WG members from documents identified during Outreach #1 (see above) and suggested during this F2F meeting · Additional possible requirements that are not already on the list will be added to Draft 4 · Draft 4 will be produced after Draft 3 triage effort has been completed · For a description of triage goals, see Task 11 approach Finalize Task 11: Decide how and when the WG will try to reach consensus · The proposed approach to reach consensus (v12) was reviewed by the WG, see: Possible approach to consensus 24 Jun 16 WG v12 clean.docx<https://community.icann.org/download/attachments/59648535/Possible%20approac...> (24 Jun 2016) · There were no additional questions or concerns raised on items 1 & 2 · Questions were raised on item 3 (where to start deliberation) on Chuck's proposal to start by identifying a subset of possible requirements "that would apply to the RDS in all circumstances" · Chuck explained that the aim of item 3 was to commence discussions today on any possible requirements that may apply in all circumstances, regardless of users, jurisdiction, etc. · Should the WG consider sending regular questions to the GAC via the PSWG on some of the constitutional or data protection requirements that may apply in the different countries? Could help with the research on this topic. This should not hold up deliberations of the WG. Is that information needed now, if we design a system that respects the laws of each land, that would need to be dealt with in the implementation phase. The possible requirements could say something like 'the system would allow for respecting the laws of each country' which would translate in the implementation phase to a system that would accommodate this and where this information will be needed. · Should be cognizant of possible legal requirements when developing possible requirements, but recognize that these may be dealt with in the implementation phase. · Are there certain requirements that would apply in all circumstances and which the WG would agree with? Meeting participants brainstormed this question with the following suggestions: o RDS needs to comply with international standards and legislation - for example UN Law on corporate social responsibility which includes a whole chapter on human rights, International convention for data protection & privacy which has been signed by all Council of Europe countries and Turkey and Uruguay. o Registration data collection needs to reflect necessity, proportionality, & be purpose bound - 108 countries that currently have data protection / privacy legislation which are expressed as principles. This may not be a universal requirement as it is not necessarily subscribed to by all countries. § Discussion: Does this apply in all circumstances? At high level yes, but would need more definition on what it means in practice. o Must prevent leaks of RDS information § Discussion: If all information were publicly available then would no leaks be possible? No, there is some information related to the system itself which you do not want to see public, for example, ID and password or information enabling corruption of the database. Change to: Ensure system security and secure administration. May need to provide examples to broader community. May need to differentiate between system and user security? o RDS needs to be a properly-designed secure, stable, and resilient system o Registration data elements must include domain name and its status o RDS needs to be resilient against single point of failure (e.g., Backup of information) o RDS must provide the name of the registrant, and a physical address and email address for the registrant that should be accurate and contactable o RDS needs to collect registrar name o RDS needs to be accessible for purposes identified § Discussion: Elements of security and administration would need to be in place to accomplish this (see also earlier requirements). o RDS needs to include name server information § Discussion: Does this need to be in the RDS? The information is already available in the DNS and you do not need a name server to registrar a domain name. o RDS needs to include standard information that is required for registrars to meet contractual obligations such as domain name registration transfers o RDS needs to support IDNs o RDS needs to avoid out of sync information between different systems that may interact or contain the same information (e.g. DNS and RDS) o RDS needs informed consent - Individual consent concerning information that is collected as well as options for redress · After the WG discussed the above possible requirements, the question was asked: Should the WG first deal with the policy and then system requirements? If so, how? · It was suggested that the WG start by examining use cases - talk about users, their purposes, the data involved, and privacy impacts at a principle level, separate out the principles from the actual data to be collected and the system requirements. Continue to refine each use case until enough use cases have been considered to understand the purpose of registration data. · Expert WG took a similar approach, by starting with use cases. · The WHOIS 2007 Task Force also examined use cases, should consider those as well. · Attendees agreed that there was a need to find an approach that is efficient for deliberating on possible requirements and discussed whether the use case approach would facilitate this. · How to ensure that a sufficient set of use cases are identified? Does the approach presuppose that information currently collected will continue to be collected? Would the use case approach prevent starting from a clean slate? · Note that use cases examined could include those that shouldn't be a valid use case under a next generation RDS. Need to be careful on how use cases are defined - shouldn't be about specific business models. · Consider splitting use cases to examine both user and technical requirements - but need to be careful not to start designing the system. Need use cases to focus on policy requirements, which may include some high level technical requirements. · Need to consider possible constraints on the use of the data - in some jurisdictions data can also be used for previously agreed upon cases · Use cases are not a one-to-one relationship to a solution that is then implemented. Broad concepts will come forward from use cases such as cases that could be supported by gated or non-gated access. The same solutions may apply to other uses cases, even those that may not have been identified yet. · Do we need to come to rough consensus on "purpose" before looking at use cases? · Starting with "purpose" is key to making progress. Action Item #4: Circulate EWG statement on purpose that was originally drafted by Stephanie as an example and possible starting point for this WG to answer the question of "What is the purpose of collecting, maintaining, and providing access to registration data?" · Avoids repeating work that has already been done - that doesn't mean that work is accepted as is, but at least it provides a starting point. · Identifying use cases does not mean endorsing that case - it may actually do the opposite (e.g. not a use that the system should facilitate). A spectrum of use cases (from permissible to illegal) were also identified as part of the EWG's analysis of use cases. · There was no disagreement among meeting participants to approach deliberations by beginning with a statement of Purpose. Action Item #5: All WG members are asked to review F2F meeting recordings Part 2 and/or transcript Part 3 to ensure that all WG members are up to date with the discussions that took place in Helsinki. Action item #6: Leadership team to update Task 11 item 3 to reflect direction given in this meeting to circulate the EWG report's Purpose statement as an example and pursue use case methodology as a possible starting point prior to deliberating upon individual possible requirements. Action item #7: After listening to recording or reviewing transcript of F2F discussion of Task 11, WG members are asked to review/comment on updated Task 11 approach by 7 July, in preparation for further discussion and finalization during the 12 July WG call. 4. Confirm Action Items, Next Steps, Next Meeting · No WG meeting week of 3 July · Next WG meeting will be 12 July 16.00 UTC · Next steps and call agenda to be circulated to WG mailing list Meeting Materials: RDS PDP WG Wiki: https://community.icann.org/x/rjJ-Ag WG Email Archive: http://mm.icann.org/pipermail/gnso-rds-pdp-wg Work Plan: https://community.icann.org/x/oIxlAw SO/AC/SG/C Outreach and Inputs: https://community.icann.org/x/pYxlAw Phase 1 Documents: https://community.icann.org/x/p4xlAw, including Initial List of Possible Requirements (10 June 2016)