Dear all, Below please find notes from our F2F WG meeting, along with links to meeting materials. Deliberations will continue in our next WG meeting (Tuesday, 22 November 2016); additional materials for that meeting will be distributed in advance of that call. Best, Lisa RDS PDP WG F2F Meeting - 3 November 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/NAe4Aw> https://community.icann.org/x/NAe4Aw 1) Introduction & SOI Updates . Roll call will be taken from AC . Please remember to update your SOI 2) Accomplishments and Status . What have we accomplished so far? . See slides presented during the meeting <https://community.icann.org/download/attachments/62392116/ICANN57-RDS-PDP-W G-Slides-Draft8.pptx> 3) Next steps & Working Session . See slides presented during the meeting <https://community.icann.org/download/attachments/62392116/ICANN57-RDS-PDP-W G-Slides-Draft8.pptx> . Commence deliberations on possible requirements during today's meeting, focusing on first three areas (privacy, users and purposes, data elements) Start discussions today, using a randomized iterative approach: . Sort possible requirements for phase 1 requirements only. . Randomly order the three questions: Users/Purposes, Data Elements & Privacy. . For the first round, start with the first randomly selected question, followed by the second, and then the third, discussing a subset of possible requirements, using the Prerequisites/Dependencies, Codes, and Keywords to select subsets for deliberation. . For the next round, rotate the order of questions so that the second becomes the first, the third becomes second, and the first becomes third, iterating on step 3. Approach to reach consensus in phase 1 . See meeting materials: Approach to reach consensus during Phase 1 <https://community.icann.org/download/attachments/62392116/RDS%20PDP%20WG%20 Approach%20for%20Consensus%20-%2027%20October%202016.docx> . Start by deriving rough informal consensus on policy requirements after deliberation on first 3 questions as well as GA, DA and Other Questions . Following this deliberation, the foundational question is expected to be answered: Is a new RDS policy framework needed or can the current WHOIS policy framework be adjusted to meet requirements? . This initial answer and rationale to be published in the first Initial Report for public comment. WG to review all input received and then review other questions in the charter which will lead to a second Initial Report that will be published for public comment. . Only at this stage will formal consensus be sought using process defined in Section IV of Charter. . Consensus recommendations and statements will be published in the Final Report for Phase 1. . After considering this WG's recommendations in the Final Report for Phase 1, GNSO Council will decide on next steps, which depend on the answer to the foundational question. For today's meeting: . Cover the first subset of Phase 1 Code=A possible requirements without dependencies in this randomly selected order: users and purposes; data elements; privacy . Iterative process - no final decisions during today's meeting. Just a starting point to move forward from and build informal consensus, hopefully leading to formal consensus at the end of Phase 1. . Subset of possible requirements for discussion were circulated prior to today's meeting: <https://community.icann.org/download/attachments/62392116/PRSpreadsheets-D5 -CodeAOnly-NoDependencies.pdf?version=1&modificationDate=1477710647000&api=v 2> PRSpreadsheets-D5-CodeAOnly-NoDependencies [PDF] and <https://community.icann.org/download/attachments/62392116/PRSpreadsheets-D5 -CodeAOnly-NoDependencies.xlsx?version=1&modificationDate=1477710695000&api= v2> [XLS] . Depending on progress today, determination will be made on what will get covered during the upcoming meetings, rotating the order of deliberation on the first three charter questions. Initial Deliberations . Initial Subset for Deliberation: <https://community.icann.org/download/attachments/62392116/PRSpreadsheets-D5 -CodeAOnly-NoDependencies.pdf?version=1&modificationDate=1477710647000&api=v 2> PRSpreadsheets-D5-CodeAOnly-NoDependencies [PDF] and <https://community.icann.org/download/attachments/62392116/PRSpreadsheets-D5 -CodeAOnly-NoDependencies.xlsx?version=1&modificationDate=1477710695000&api= v2> [XLS] . Displayed List of PRs without Dependencies: <https://community.icann.org/download/attachments/62392116/Initial-Deliberat ion-List-v2.pdf?version=1&modificationDate=1478231277181&api=v2> Initial-Deliberation-List [PDF] and <https://community.icann.org/download/attachments/62392116/Initial-Deliberat ion-List-v2.docx?version=1&modificationDate=1478231349204&api=v2> [DOC] UP-D01-R01: "In support of ICANN's mission to coordinate the global Internet's system of unique identifiers, and to ensure the stable and secure operation of the Internet's unique identifier system, information about gTLD domain names is necessary to promote trust and confidence in the Internet for all stakeholders." (p. 16, Section IIb, Purpose) . Source: EWG Final Report <https://www.icann.org/en/system/files/files/final-report-06jun14-en.pdf> . Three possible requirements within this PR: support the stable and secure operations, support the unique identifier system, and to promote trust and confidence in the system . The RDS system as updated should promote consumer trust and confidence in the Internet. . Information is necessary for those registering domain names, but is it necessary to promote trust and confidence? Some agree, some disagree whether information promotes trust and confidence . What information is necessary? To be examined as we move forward iteratively . Need to be clear about the purpose of any recommendation - in this case this PR is a general requirement - foundational and high level - not specific . Define "stakeholders" or drop phrase "all stakeholders" . This PR is great as an aspirational statement but is too subject to interpretation, would prefer to label as a goal or aspiration. A purpose has to be specific, limited, and proportionate. . An option is to incorporate this PR within the statement of purpose rather than capture it as a requirement UP-D01-R02: "gTLD registration data [must be] collected, validated and disclosed for permissible purposes only." (p. 21, p. 31 Principle 6) . Source: EWG Final Report <https://www.icann.org/en/system/files/files/final-report-06jun14-en.pdf> . Key phrase is "for permissible purposes only" . Collection and disclosure or permissible purposes only is fine, but you don't validate for a purpose - must be accurate enough for a given purpose . Information disclosed should be validated - disclosing false information defeats the purpose . "For permissible purposes" applies to all three or just disclosure . Noted that registrars collect additional information that may not be for a permissible purpose, but that is not part of the RDS policy being defined here . Does validation for a particular purpose occur only when data is requested, or when it is collected? (the latter) . Do possible requirements fall into different categories? General principles vs specific purposes. For example, data processing standards depend on specific purposes (not general principles) . Removing validation from this PR does not mean validation is not important but it may be covered elsewhere (for example, in PRs for accuracy) . "gTLD registration data must be collected for permissible purposes only"; (2) gTLD registration data must be validated; (3) gTLD registration data must disclosed for permissible purposes only. Of course, each of these could be supplemented with additional more detailed but still granular requirements (such as about what types or level of validation should be applied) . I think (1) would mean that the purposes for collection of the data would be presented to the registrant (and permission would be gained) prior to collection Permissible purpose for collection not necessarily the same as permissible purpose for disclosure . Is it possible to register a domain name which is missing data required for a permissible purpose? DE-D01-R01: The [gTLD registration directory service] must accommodate purpose-driven disclosure of data elements. . Source: EWG Final Report <https://www.icann.org/en/system/files/files/final-report-06jun14-en.pdf> . Like this requirement (DE-D01-R01) because it is worded simply and to my mind doesn't result in multiple, diverging interpretations . Disclosure does not necessarily refer to public data - needs to be precise about which data is public (e.g., DNS Name Servers) and which data is disclosed for a specific purpose (e.g., contact data) . If there are too many purposes, does that make all data accessible? Purposes need to be specific, and access for a given purpose must be controlled. . don't read this requirement as implicitly allowing all purposes to be valid. so the presumption that many purposes== many accesses may be misplaced . "Purpose-driven disclosure" must be defined . The system has to allow disclosure to [law enforcement or another requestor] for a specific purpose/specific purposes, yet to be defined. DE-D01-R22: Validators, Registries and Registrars may collect, store, or disclose additional data elements for internal use that is never shared with the [gTLD registration directory service]. . Source: EWG Final Report <https://www.icann.org/en/system/files/files/final-report-06jun14-en.pdf> . Registrars clearly collect data not shared with the RDS but that is necessary for its business (e.g., credit card data) . Need to clearly differentiate between ICANN-mandated data that must be collected (via RAA) and customer relationship data (which is not the subject of the RAA) - both in accordance with local law . "should collect" as one piece, "should display" as another piece . what is collected beyond [the RIA and RAA requirements] are not ICANN's business . What about registry-specific data? (e.g., proof provided to registrars for certain gTLDs)? Would this be relayed from registrar to registry even if not disclosed through the RDS? . Don't need to explicitly state that some data is outside the scope if the default position is that only data specifically required is within scope (rewrite this negative requirement as a positive principle?) DE-D12-R02: The [gTLD registration directory service] should collect and display uniform sets of data regardless of the registry involved. (sec. 5.2) . Source: <http://gnso.icann.org/en/issues/whois/thick-final-21oct13-en.pdf> GNSO PDP on Thick WHOIS Final Report (2013) . Uniformity requirement in Thick Whois has been commented on by DP commissioners - "uniformity" is a dangerous word because it can imply uniform disclosure - consistent labeling and display is narrower . Further clarification may be needed on Thick WhoIs before determining this . Must be some carve outs for differences between registries . Consistent labeling and display - this is the intent of "uniform" in this PR, but there may be a need to display different data (in addition to consistent display of common data) that is not precluded . Uniformity is important for interoperability, but it is not necessarily more important than having the right data for the right purpose(s) DE-D19-R01: Based on the ICANN Governmental Advisory Committee (GAC) proposed principles, gTLD [registration directory] services "should provide sufficient and accurate data about domain name registrations and registrants (.)" (para 3.3) . Source: GAC Principles regarding gTLD WHOIS Services <http://whois.icann.org/en/link/gac-principles-regarding-gtld-whois-services
(28 March 2007)
. This requirement (d19-01) needs more precision. left as is it actually concerns me . Seems more like a principle than a requirement . This statement wasn't drafted with this purpose in mind and is too vague . Phase 1 may define requirements on policy that are guiding principles, to be supported through policies to be defined in detail during Phase 2 PR-D30-R05: The requirement for a third country to ensure an adequate level of data protection was further defined by the CJEU in Schrems.It also indicated that the wording 'adequate level of protection' must be understood as "requiring the third country in fact to ensure, by reason of its domestic law or its international commitments, a level of protection of fundamental rights and freedoms that is essentially equivalent to that guaranteed within the European Union by virtue of the Directive read in the light of the Charter" pg.10 . Source: <http://ec.europa.eu/justice/data-protection/article-29/documentation/opinio n-recommendation/files/2016/wp238_en.pdf> Opinion 01/2016 on the EU-U.S. Privacy Shield draft adequacy decision of the Article 29 WP 238 . What does third country mean in this context? Applies to forward transfer of data from country which the data was collected or the subject of the data . It is almost impossible to transfer data while guaranteeing constitutional protections without treaty - becomes more aspirational . Should requirement be higher level statement such as RDS policy should allow contracted parties to comply with applicable law? . Should requirement state the implicit requirement that the RDS should provide adequate data protection? 4) Action items & Next meeting Action: Staff to distribute notes from today's meeting for further use in drafting WG recommendations. All WG members to review these materials to prepare for deliberation in our next meeting. Next meeting date: Tuesday, 22 November 2016 at 17:00 UTC Meeting Materials: . RDS PDP WG Wiki: <https://community.icann.org/x/rjJ-Ag> https://community.icann.org/x/rjJ-Ag . WG Email Archive: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/> http://mm.icann.org/pipermail/gnso-rds-pdp-wg . Phase 1 Documents: <https://community.icann.org/x/p4xlAw> https://community.icann.org/x/p4xlAw . <https://community.icann.org/download/attachments/62392116/RDS%20PDP%20WG%20 Approach%20for%20Consensus%20-%2027%20October%202016.docx?version=1&modifica tionDate=1477710631000&api=v2> Approach to reach consensus during Phase 1 . <https://community.icann.org/download/attachments/62392116/PRSpreadsheets-D5 -CodeAOnly-NoDependencies.pdf?version=1&modificationDate=1477710647000&api=v 2> PRSpreadsheets-D5-CodeAOnly-NoDependencies [PDF] and <https://community.icann.org/download/attachments/62392116/PRSpreadsheets-D5 -CodeAOnly-NoDependencies.xlsx?version=1&modificationDate=1477710695000&api= v2> [XLS] . <https://community.icann.org/download/attachments/62392116/ICANN57-RDS-PDP-W G-Slides-Draft8.pptx?version=1&modificationDate=1478144990000&api=v2> ICANN57-RDS-PDP-WG-Slides.pptx . <https://community.icann.org/download/attachments/62392116/Initial-Deliberat ion-List-v2.pdf?version=1&modificationDate=1478231277181&api=v2> Initial-Deliberation-List [PDF] and <https://community.icann.org/download/attachments/62392116/Initial-Deliberat ion-List-v2.docx?version=1&modificationDate=1478231349204&api=v2> [DOC]