Dear All,

Please find below the notes and action items from today's meeting. Please note that our next WG call will be on 10 January.

Best regards,
Lisa

RDS PDP WG Meeting - 21 December 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/i6TDAw

1. Roll call / SOI

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

2. Review poll results

• Refer to poll results posted at https://community.icann.org/x/i6TDAw
• 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)..
• Refer to handout posted at https://community.icann.org/x/ i6TDAw
• 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


Meeting Materials:
https://community.icann.org/x/i6TDAw