Page History

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.here.

1. Roll call / SOI

• Roll call will be taken from Adobe Connect
• Please remember to keep your SOIs up to date

2. Recap approach for key concepts deliberation

• First deliberate on key concepts as outlined during last week's meeting
• Key concepts are taken from sub-questions from charter, taking three areas earlier identified (users/purposes, data elements & privacy)
• Iterative look at these three areas - bounce back and forth as needed to make sure that dependencies and interrelationships are addressed.
• Other questions will be addressed following the work on these three questions.
• Once sufficient agreement has been reached on a question (rough consensus) then the WG will move onto the next question.
• After reaching rough consensus on key concepts, then go through possible requirements identified by WG.

3. Commence deliberations with question 2.1: 'Should gTLD registration data be accessible for any purpose or only for specific purposes?'

• Note starting point taken from EWG Report (see section 2.1.1.)
• Should any gTLD registration data be made available without a purpose? EWG response: 'no' should only be made available with a specific purpose. Purposes need to be defined by policy and stated at the time of a query. 

a) Address question for thin data as defined by Thick WHOIS report ("A thin registry only stores and manages the information associated with the domain name. This set includes data sufficient to identify the sponsoring registrar, status of the registration, creation and expiration dates for each registration, name server data, the last time the record was updated in its Whois data store, and the URL for the registrar’s Whois service.")

• Start with a smaller, hopefully less controversial set of registration data, namely 'thin' registration data. At the end, all registration need to be covered, but this forms a starting point for deliberation.
• A thin registry only stores and manages the information associated with the domain name. This set includes data sufficient to identify the sponsoring registrar, status of the registration, creation and expiration dates for each registration, name server data, the last time the record was updated in its Whois data store, and the URL for the registrar’s Whois service.
• EWG report also classified data that can be considered 'thin' data. EWG report said some data should always be public, but does purpose still need to be stated when this data is queried? Yes, that is what the EWG recommended - no authentication or verification but still need to state which domain name is queried and purpose for query. How would this be enforceable? EWG first looked at permissable purposes, then at data sets used for these purposes to determine what minimal information would / should be available publicly.
• What is the purpose of thin gTLD data? See page 46 of EWG report "To meet basic domain control needs, the following Registrant-supplied data, which is mandatory to collect and low-risk to disclose, must be included in the minimum public data set:a. Domain Nameb. DNS Serversc. Registrant Typed. Registrant Contact ID (further defined in Section V)e. Registrant Email Addressf. Tech Contact IDg. Admin Contact IDh. Legal Contact IDi. Abuse Contact IDj. Privacy/Proxy Provider Contact ID (mandatory only if Registrant Type = Privacy/Proxy Provider)k. Business Contact ID (mandatory only if Registrant Type = Legal Person)" (EWG report, page 46)
• In EWG report, Domain Name Control includes tasks such as "Creating, managing and monitoring a Registrant’s own domain name (DN), including creating the DN, updating information about the DN, transferring the DN, renewing the DN, deleting the DN, maintaining a DN portfolio, and detecting fraudulent use of the Registrant’s own contact information."
• Is there a purpose to having registrar information? Yes, only way to get to further information (in current environment). Necessary for domain name control. Legal significance of having access to registrar name as it can determine jurisdiction for example in UDRP. Also, in case of hijack, you need to find out the new registrar to get it back.
• Is there any thin data that does not have a purpose? Yes, although one could debate whether this information needs to be publicly available. Not discussing yet who should have access or whether it should be publicly available.
• No registration data should be accessible without having a purpose? All data should have a purpose. Are we recommending that public access is to be terminated? Not close yet to making that decision. Requiring a purpose does not necessarily mean making data non-public. Think for example about web-sites by liquor companies asking to click a box that you meet the legal age to access the web-site (which is not verified in any other way). Every field currently in WHOIS has a purpose.
• Should gTLD thin data be accessible for any purpose, regardless of what it is? Binary nature of the question makes it difficult to answer.
• Next question is 2.2           For what specific purposes should gTLD registration data be collected, maintained, and made accessible? Who should be permitted to use gTLD registration data for those purposes?
• Do you build a negative list (not allowed for these purposes) or not accessbile unless purpose is on a positive list, or allow for any purpose? Difficult to build a list that includes all permissible purposes as new ones may be added over time. 
• Is there one element of these thin elements that does not have one legitimate purpose?
• Does WG needs to cover question 2.2 before going to data elements question? Input welcome.

Action item: Staff to develop a question(s) that can be used to poll the WG to assess view points following this discussion.

Action item: WG members to respond to poll when available.

b) Address question for other data (time permitting)

4. Confirm next meeting - Wednesday 21 December at 6.00 UTC

Review poll results

• See Poll Results Final - 13 December RDS PDP WG call.pdf
  

• Result Summary: Option (b) had greatest support, followed by options (a) and (e). Just two respondents agreed with option (c) – no limitation by purpose, and two respondents stated that their answers differed for subsets of thin data elements. No support for option (d) – eliminating access to “thin data” entirely.
• Consideration of poll results as a guide to find a productive path forward for deliberations
• 90% of respondents through purpose should play some kind of role in policy for "thin data" - strong indication the WG should consider legitimate/illegitmate purposes. Why shouldn't policy take purpose into consideration?
• Possible reasons: cost and effort involved in checking and enforcing purpose, limited benefit in return for that cost; not sure we can prevent sharing data after it was taken from the system; extra layers of access control may not be warranted for minimal data included in thin data
• Reactions: May want to separate anonymous access from identification or authentication for access to thin data - may not want to allow anonymous access? Privacy policies may require authentication but that may lead to logging access which may not be desirable
• Is the answer for thin data different than for other registration data? Purposes for thin data may be more technical, may not require PII, may pose less risk of abuse (and be dealt with using rate limiting, etc) because thin data includes few elements - so why should it be hidden? There are purpose(s) for thin data but access shouldn't be limited
• The language used in the poll questions may have led to results that are farther apart than we really are - I didn't find options satisfactory so I wrote option (e) to include anonymous access without declaring a purpose. The wording implied access controls to check purpose, which is why (e) is closer to (c) than (a).
• Re: "except for illegitimate purposes" - if someone does bad things, their access can be blocked - but what does that cost?
• Two of the thin data elements are already accessible anonymously - name servers, domain name - so the set of thin data elements you might control access to is very small
• How hard is it to authenticate requestors? Really hard for today's WHOIS or an open system
• Even with this limited number of responses, we have opposing views about whether purpose should play an inclusive or exclusive role in “thin data” policy. But further deliberation on specific purpose(s) and thin data elements may uncover common ground.
• We may be stumbling a bit over possible implementations when trying to visualize impact of potential policy requirements. For example, captive portal pages often offer both anonymous Internet access and authenticated access to more network resources – it is possible to implement both kinds of policies. While we need to consider whether implementation of potential policies is feasible, policy should drive implementation not the other way around

3. Continue deliberation on question 2.1, focusing on thin data

• Is there anyone who thinks we should not consider purpose at all?
• Agreement: Concluding that purpose is useful to consider further (without implying authentication, disclosure, or access control)..
• What is the purpose of collecting thin data elements? Specifically:
• What is the purpose of collecting the domain name's Sponsoring Registrar? It tells the registrant who is responsible for their domain name (but see note about Resellers below), required by policy to help facilitate registrar to registrar transfers; see also EWG pg 129-132 for purposes of any field
• There's also a contractual line through the reseller to the registrar; may have an optional Reseller field for registrars who wish to avail themselves of it
• What is the purpose of collecting the domain name registration's Status(es)?
• Could put "thin data" elements into a few categories - (1) Registrar/URL, (2) operational data - Name Servers, (3) rest are metadata about the domain registration such as dates, status
• Note that many thin data elements are not "collected" per se - the fields are populated but from the RDS/WHOIS perspective we refer to collection
• Agreement that for all thin data elements, there is at least one purpose for collection
• Referring to EWG report pages 129-131, the thin data elements are listed by purpose - are there comments on the purposes listed for "thin data" elements?
• Noted that purposes listed by EWG were not comprehensive - but they were recommended as "permissible"

Action: Staff to launch poll to confirm two main points of agreement and allow those not on call to weigh in; poll to remain open through the holidays with results aggregated for use in next WG call 10 January

4. Confirm next meeting date: Tuesday 10 January 2017 at 17.00 UTC

• (Note, no WG calls on 27 December 2016 or 3 January 2017)

Meeting materials: 

• KeyConceptsDeliberation-WorkingDraft-12Dec-1800.pdf and doc
• Q21-appliedto-ThinData-with-Example
• 13 Dec Call Poll on Purpose - Results discussed during Agenda Item 2:
  • PDF of Poll Questions
  Poll PDF
  • : Poll-on-Purpose-from-13DecCall
  .pdf (posted 14 Dec)
  • .pdf 
  • PDF of Poll Results: Poll Results Final - 13 December RDS PDP WG call.pdf
• Questions and examples reviewed during Agenda Item 3:  21DecMeeting-ThinData-Handout.pdf
• 21 Dec Call Poll on Purpose - Results to be discussed during 10 January call: 
  • Link to participate: closed Friday 6 January - see 10 January meeting page for results
  • PDF of Poll Questions: Poll-on-Purpose-from-21DecCall.pdf
  Poll Link to participate: https://www.surveymonkey.com/r/6BMJLB2