Notes RDS PDP WG Meeting

1. Roll Call/SOI Updates:

• Attendance will be taken from AC
• Please remember to state your name before speaking and remember to mute your microphones when not speaking
• SOI updates: Andrew Sullivan: Officially now an Oracle employee; Maxim Alzoba: Now a member of the GNSO SSC

2. Updates on in-progress tasks:

a. Response from privacy experts who participated in the ICANN58 privacy summit to questions from the working group:

• See https://community.icann.org/download/attachments/64078601/ICANN58-Privacy-Panel-Responses-Draft-7April2017.docx
• Poll questions will be circulated on the first two questions asked, and answers provided.
• WG members expected to individually go over the responses from the privacy experts within the next week.
• WG expected to discuss/go through the answers in detail, starting during next week's WG call.
• Key concepts identified as a result of responses from privacy experts, IP interests, LE, etc... (all competing interests), will all be taken into account to develop solutions (RDS requirements)
• The privacy experts are not RDS experts. The questions sent to them were developed by the WG for further our education on privacy/data protection law requirements, but this Q&A can be a two-way opportunity for the WG to also educate privacy experts on registration data and RDS.

Action #1: WG members to review answers from privacy experts participating in ICANN58 summit in preparation for next week's WG call

b. ccTLD Questions:

• Small team continuing work on developing the questions
• 4 - 5 questions already identified
• More questions will be identified by next week

c. Definition of "Authoritative"

• Small team working on definition, but not yet finished
• Looking at definition in RFC documents, but proving unhelpful for the WG's purpose
• From AC Chat: Andrew Sullivan's suggestion to the team is that we just pick a different term.  I wonder whether that would be acceptable to people?
• Refer to chat archive for further dialog on possible definitions

d.  Meeting request for ICANN59

• In addition to our regularly-scheduled F2F WG meeting, the leadership team is submitting a request for a 3 hours cross-community session to solicit feedback on WG's key concepts and points of rough consensus so far
• As this focus of ICANN59 is policy, this is an opportunity to obtain feedback from everyone to inform our work post-ICANN59 - including first initial report

Action #2: Staff to submit request for ICANN59 cross-community session

3) Start deliberation on the charter question/subquestion 3.1 (rephrased):

What are the purpose(s) of each existing gTLD thin registration data element? Do they sufficiently meet the needs of purposes identified as legitimate?

• See https://community.icann.org/download/attachments/64078512/Merged-ThinDataPurposes-v1.pdf
• This document reflects a merge of Andrew Sullivan's proposed approach for defining the purpose of each thin data element with the EWG's Annex D listing permissible purposes
• When EWG crafted its list of permissible purposes, it examines existing uses of registration data - explained in detail in Section III of EWG Report. Then took use cases for each purpose and related purposes to data elements involved in each purpose. That led to mapping of data elements to purposes in Annex D (reflected in the merged doc here). Considered mostly "permissible" or legitimate purposes, although the EWG also examined impermissible purposes.
• Suggestion: replace "All" with actual list of EWG purposes to make this document self-standing for reading by those not familiar with EWG's report
• List seems to be technical and inclusive. The WG should consider whether every data element is really needed or whether something could be accomplished in an easier or less intrusive way.
• Note that the EWG was not tasked with making policy - it explored issues and suggest ways forward, including alternative ways of doing things (e.g., validators concept, secure protected credentials, other processes to accomplish goals/use cases). EWG Report was not therefore limited to the standard thinking or old ways of doing things. It is up to this WG to take that information and other inputs and decide what are legitimate purposes and how do we accomplish the goals those purposes represent.

Domain Name

• Is there any disagreement that the domain name will be necessary for every legitimate purpose that the WG recommends? None expressed

Proposed WG Agreement: The domain name will be necessary for every legitimate purpose.

Registrar Name and IANA ID

• Should Registrar Name be a registration data element?
• That is, does anyone disagree that the Registrar Name should be (collected/derived) included as a registration data element for the purposes listed?
• Rational for opposing: If Registrar Name can be obtained by looking up the Registrar ID in IANA, does it really need to be in the RDS as well? Minimalist approach argues for collecting Registrar IANA ID not name
• Minimalist approach for publication is a separate question (someone may choose to display/send data not collected)
• Registrar Name only doesn't help because more than one IANA ID can bind to the same Registrar Name
• Note that these aren't really "collected" from a registrant and are populated by looking up the "friendly name" from the ID. Name isn't pushed from registrar to registry over EPP - it is derived during a transaction, ultimately pulled from another place (e.g., IANA)
• Should we discuss adding Reseller to thick or thin data? (discuss when we get to possible additions, for now focus on existing thin data elements)
• Do all of the listed EWG purposes apply to each data element as listed?
• Andrew Sullivan in his proposal Grouped Registrar and Sponsoring Registrar IANA ID together because they are similar and both needed for the same purpose(s)
• Refer to Chat archive for detailed discussion of how IANA ID and Registrar Name are related, derived, and used during a transaction

Comments about purposes listed

• Note that purposes deliberated upon thus far by this WG are already listed in our working document, section 2.2.2, where we started from the purposes listed in the EWG Exec Summary. However, this WG only deliberated on these as purposes for thin data collection, and this WG still needs to more fully examine and define each purpose at some point - including looking at purposes from a privacy and data protection law perspective
• Have purposes been discussed in accordance with ICANN's remit? Not yet - but we need to
• For example, academic research may or may not be within ICANN's remit (or contrary to that remit) to support this purpose through an RDS (may depend on research goal). Need to watch out before drawing bright lines that divide some purposes into legitimate or not.
• Chat comment: In respect of the remit issues: this is why not everything discussed in Andrew Sullivan's email reflected EWG purposes, because once I had a single  reason why everyone needed the data,  other purposes didn't matter?
• Chat comment: For data collection, one "legitimate" purpose is probably sufficient (ignoring retention and other ancillary issues).  Full debate on the legitimacy of all purposes becomes much more important for discussions around what data is provided to data requestors and under what conditions (e.g. gated vs. open)
• Within the EWG's work, we tried to look at why people were using registration data and why, then categorize that into legitimate vs illegitimate - but we didn't look at this as does this fall within ICANN's remit at this purpose by purpose level
• It is also important to differentiate between purposes for collection and access - EWG's purposes may focus more on access (based on use cases) and not purposes for collection in the first place
• Chat comment: The "academic" question is actually quite nuanced and layered given ICANN's commitments to transparency and other responsibilities around competition, access, etc.  One of the ways you *can* do that is by providing data to researchers working under well-defined (and it is in the world today) academic guidelines and oversight to do studies on these various topics.  For example, can people in developing countries get access to domain registration services or are they priced out of the market, or do they not have local registrars available that provide local language services?  This kind of important question needs RDS-style data at scale to answer.  So one or our jobs may well be to answer that question.
• For example, is using data collected for one legitimate purpose for another purpose such as fighting child abuse legitimate and within ICANN's remit? May be legitimate given certain conditions, but need to raise these questions as we look at the purpose for each data element.

Action #3:  WG members to participate in this week's poll, which will include input of a couple of privacy expert question answers as well as one proposed agreement

4) Confirm action items and proposed decision points

Proposed WG Agreement: The domain name will be necessary for every legitimate purpose.

• Action #1: WG members to review answers from privacy experts participating in ICANN58 summit in preparation for next week's WG call
• Action #2: Staff to submit request for ICANN59 cross-community session
• Action #3:  WG members to participate in this week's poll, which will include input of a couple of privacy expert question answers as well as one proposed agreement
• In addition, ccTLD Questions and Authoritative Definition Actions carry over from last week's WG call

5) Confirm next meeting date: 18 April, 2017 at 05:00 UTC

Materials:

• KeyConceptsDeliberation-WorkingDraft-4April2017.pdf and doc
• ICANN58-Privacy-Panel-Responses-Draft-7April2017.pdf and doc
• Merged-ThinDataPurposes-v1.pdf (initial rough draft displayed during call)
• Sullivan-SuggestionForPurposeInDetail.pdf and doc
• Annex D of the EWG final report (thin data only) - excerpted from full EWG Final Report
• Latest RDS PDP WG Phase 1 Work Plan - as of April 2017 (posted 3 April 2017)