Dear All, Please find below the notes and action items from today’s RDS PDP WG meeting. Best regards, Marika Notes & Action Items – RDS PDP WG Meeting – 9 August 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 updates · Attendance call will be taken from Adobe Connect room · Please state your name for transcription purposes · Reminder to mute your microphones when not speaking 2) Brief status update on problem statement, possible requirements & triage · Problem statement: Updated problem statement has been produced which blends the two previous statements. This updated problem statement is currently under review by the small team. Small team asks leadership team for an additional week to finalise the problem statement which is intended to be shared ahead of next week's meeting. · Possible requirements & triage: activities continuing in parallel, still a number of outstanding assignments to collect requirements from key input documents. May need some help in back-filling on IRD related documents. Staff will reach out to possible volunteers. At the same time adding possible requirements that have been previously submitted. Triage still in progress, further updates expected during next week's meeting. 3) Continue review of example use cases: 13-Services required by Registry agreement (Maxim Alzoba) · See use case submitted (https://community.icann.org/x/JA6bAw) · Questions/comments: have providers same access? Each of 4 types of parties have contracts at hand which describe what they can and cannot do. Not same level of access that public will have. Registry escrow provider has one contract with registry and one with ICANN. Audit company also have contract for this kind of access. Assume that all these parties have NDAs in place and what they can access as well as what to do with the date after the activity has been completed (e.g. audit). Looking at URS and UDRP - where does the complainant fit in? Don't they need access to this type of information to prepare their case? Is that a different use case or does it belong here? Probably registrant should be added as a stakeholder as well. URS and UDRP complainants could use public RDS, similar to third parties as they do not have any contractual obligation with regards to Ry/Rr or ICANN. Does escrow provider have access and look at data or only confirms receipt of data? Key to encrypted files are sent with the data files. Might be three use cases interwined in this use case - escrow, audit and UDRP/URS, including related use cases. Maybe would be worth identifying what data is needed for each of these use cases and whether that information comes from the current WHOIS. Publication of information in relation to UDRP case could also result in disclosure of personal information, even if defendant is not found at fault. Escrow agents are not obligated to confirm that any of the records which appear in the deposit actually exist or that they match what is in the RDS. 16-WHOIS misused to shame, anger, or scare a registrant · See use case submitted (https://community.icann.org/x/JA6bAw) · Questions/comments: what does 'repeating to obtain information about the registrant's friends or family'? How does this relate to the registration data? Only be if friends or family would be a domain name registrant and present in RDS. Useful to separate use case and proposed solution. Conclusion could also be that there need to be limitations to how much data is made available and to whom instead of not including any PII. The following study might also be of interest in this context: WHOIS misuse study link http://whois.icann.org/sites/default/files/files/misuse-study-final-13mar14-.... For example, looks at which specific data elements are misused. Certain elements may have a higher level impact, for example, spam is caught by spam filters, while phone numbers might have a higher level impact on someone's life. Certain information will need to be available to address a number of issues that come up, such as transfers. Need to distinguish "getting data out easily/freely/without authentication" and "whether the data is in there". Important to balance the different needs that may be competing - that balance will hopefully result in finding solutions. 12-Trademark Infringement (Mark Svancarek) · See use case submitted (https://community.icann.org/x/JA6bAw) · Questions/comments: are those data elements of the registrant, admin contact, tech contact, or all of those? Likely collects everything that is available and uses what is appropriate. Not clear whether the ultimate "success rate" in variant 2 is relevant -- the requirement to identify/contact the registrant is the same -- isn't it? Merely to show that success may be limited, just a data point. When doing trademark infringement analysis, need more data than just contactability. Need to go into who it is, how long have they been doing it, where they are. If you are operating in a jurisdiction that has data protection law, information may need to be available as part of disclosure requirements to individual under investigation. Wide variety around the world - in certain cases you may need to contact individuals whose data is being held in others you may not. 08-Real-World Contact (Fabricio Vayra) · See use case submitted (https://community.icann.org/x/JA6bAw) · Questions/comments: might be limited use of this use case, but that does not mean it could not be used widely, for example app or web-sites providing consumer info. Might also be of interest to the seller to have this information publicly available - if this is of use to consumers. EV certificates serve the function of ensuring that the person who says they are in control of the name servers are in control. Using this data for this purpose may be misleading. Additional education may be necessary, especially in relation to certifications. WHOIS is used to create reputation metrics (e.g. web of trust, browser-add ins). This also includes correlation searches which may result in downgrading if other registrations with same information where found to be not trustworthy. 15-Fraudulent contact information (Susan Kawaguchi) · See use case submitted (https://community.icann.org/x/JA6bAw) · Questions / comments: not that data was invalid, it is valid, but it belongs to someone else. This is possible because anyone can add anyone's information to date as there is currently no verification that the person entering the information is entitled to enter that information (e.g. related to company they work for or represent). Action item: Staff to confirm with volunteers that all pending use case assignments will be completed and ready for discssion in the next week or so Action item: WG members to review example use cases and identify any gaps that should be filled - preferably volunteering to draft and present them Action item: Rod and Michele to determine whether the cases they originally introduced as example should be presented for WG discussion in the next WG call or two 5) Confirm Next Meeting - Wednesday 17 August 05.00 UTC Marika Konings Senior Policy Director & Team Leader for the GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings@icann.org Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses and visiting the GNSO Newcomer pages.