The next GNSO Next-Gen RDS PDP Working Group teleconference will take place on Tuesday, 06 June at 16:00 UTC for 90 minutes.
09:00 PDT, 12:00 EDT, 17:00 London, 18:00 CET
For other times:
PROPOSED AGENDA:
1) Roll Call/SOI Updates
2) Complete deliberation on: What steps should be taken to control "thin data" access?
a) Review poll results: AnnotatedResults-Poll-from-30MayCall-v2.pdf
b) Consider possible principle on proportionality
c) Action item proposal from Rod Rasmussen and Vaibhav Aggarwal
3) Resume deliberation on Data Elements for "thin data" only
See RDSPDP-Handout-For6JuneCall.pdf
4) Brief updates on:
a) Legal analysis
b) ICANN59 plans: 26 June Cross-Community session, 28 June WG F2F session
5) Confirm action items and proposed decision points
6) Confirm next meeting date: 13 June 2017 at 16:00 UTC
Apologies: Holly Raiche, Farell Folly, Paul Keating, Nathalie Coupet, Tjabbe Bos
Transcript
Meeting Materials
30 May Call Poll Results -
Action Items:
- Staff to add the following WG agreements to working document:
- WG Agreement: At least a defined set of "thin data" elements must be accessible by unauthenticated RDS users
- WG Agreement: RDS policy must state purpose(s) for public access to "thin data.”
- Rod/VA to complete action item assigned during 23 May call, sending proposed resolution to WG mailing list before next WG call.
- Staff to develop poll to test the following proposed WG agreements. All WG members to participate in poll no later than COB Saturday 10 June:
- Expiration Data should be removed as a "thin data" element to be made accessible without authentication.
- DNSSEC should be added as a "thin data "element accessible without authentication.
- All WG members to plan to attend ICANN59 Cross Community and F2F WG sessions (see links above), either in-person or via remote participation.
- All WG members encouraged to share the GNSO Next-Generation RDS PDP WG April/May 2017 newsletter (found on this page: https://community.icann.org/x/_RmOAw) with their own Stakeholder Groups, Constituencies, Supporting Organizations and Advisory Committees in preparation for the cross-community discussion scheduled to take place at ICANN 59 in Johannesburg
Notes:
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 here: https://community.icann.org/x/IsPRAw
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: none
2) Complete deliberation on the charter question: What steps should be taken to control "thin data" access?
a) Review poll results
- Annotated Results: https://community.icann.org/download/attachments/64078626/AnnotatedResults-Poll-from-30MayCall-v2.pdf
- Q2:
- Rough consensus support at 91%
- WG Agreement: At least a defined set of "thin data" elements must be accessible by unauthenticated RDS users.
- Q3:
- Majority support at 75%
- WG Agreement: RDS policy must state purpose(s) for public access to "thin data.”
- Comments from 4 participants who disagreed with this agreement from last week's call
- Concern expressed that thin data should be freely available without stating a purpose, as stating purpose has implications
- We can enumerate broad reasons that thin data should be made available rather than narrowly defined purposes
- Need to avoid defining purpose for collection in such a way that is limiting purpose for access - purpose for which data might be disseminated later must be disclosed at time of collection and gaining consent
- The data elements must be provided for certain purposes - for example, a simple purpose for thin data may be anti-abuse
- Not stating that the registrant had to state the purpose for which their data could be accessed. Rather expressing concern that the registrant's knowledge of the purpose for collection and/or access may limit the purpose for which the data will be accessed down the road.
- Accepting this WG agreement as rough consensus for now, subject to refinement during continuing deliberation
- Q4:
- Support at 61% but unclear how many disagreed with non-discriminatory concept
- Several comments expressed concern about the phrase "legitimate purposes"
- Comment #4 - Does this add much given previous agreements? What else could you do to discriminate, given that access is unauthenticated?
- In last week's poll, 10 participants responded this agreement didn't apply to thin data, while a similar number supported an agreement that evolved into this text.
- Note that operational controls (such as anti-DoS throttling) are addressed by a separate WG agreement - see agenda item 2(c), which is pending inputs before a proposal can be provided to the WG mailing list
- Should "non discriminatory" be "non-preferential"?
- Note this applies to RDS policies and not user interface design or operational controls
- Proposed alternative: RDS policies for access to "thin data" must be non-discriminatory (i.e., RDS policies must not be designed to give anyone preferential access).
- Decision: Put the proposed agreement on hold, pending resolution of action item 2(c)
- Action Item: Staff to add above-noted WG agreements to working document.
b) Consider possible principle on proportionality
- See handout slide 2
- Consider tests of proportionality against public access to "thin data"
- Could this four-part test be applied to “thin data” access, for example:
- Is there at least one legitimate purpose for providing public access* to “thin data”?
- Is public access to “thin data” suitable to achieve those legitimate purpose(s)?
- Is public access to “thin data” necessary to achieve those legitimate purpose(s), that there cannot be any less onerous way of doing it?
- Is public access to “thin data” reasonable, considering the competing interests of different groups at hand?
- Could the WG consider that principles agreed to so far on "thin data" meet the proportionality requirements (or will meet the requirements)?
- The proportionality principle is relevant to PII, so does it need to be applicable to access to "thin data"
- Can the 4 tests on the principle of proportionality apply to access to "thin data" without acknowledging that the principle itself is applicable to "thin data" access
- Proportionality principle should be broadly applicable - "thin data" that MUST be publicly accessible against the 4 tests should be examined
- Some argue that thin data elements could be treated in some cases as personal data because it can be linked to an individual, and so passing the proportionality test allows making this data public even in those cases
- Conclusion: Put this possible principle aside for now, pending further deliberation
c) Action item proposal from Rod Rasmussen and Vaibhav Aggarwal
- Action Item: Rod/VA to complete action item assigned during 23 May call, sending proposed resolution to WG mailing list before next WG call.
3) Resume deliberation on Data Elements for "thin data" only
"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.“
- Which gTLD registration data elements should be included in “thin data”?
- Are today's gTLD WHOIS registration data elements classified as "thin" sufficient at this time?
- Are any elements listed here NOT required as "thin data" accessible through an RDS?
- Are any NEW elements required as "thin data" elements to be accessible through an RDS?
- Why do "status" and "date(s)" information need to be included in "thin data"?
- Should DNSSEC information be included in "thin data"? DNSSEC provides useful information to confirm what's in the DNS, and does not include any PII
- Additional fields defined in RAA now include Registrar Abuse Contact Email and phone number, DNSSEC, and URL of the ICANN WHOIS Data Problem Reporting System
- Expiration date might be considered PII, if associated with a registrant's choice of when to renew during the registration process
- Suggestion to remove the expiration date from "thin data", and at least examine it against the 4 tests of the proportionality principle
- Is there an overwhelming need to have that data? not because it might be personal data, but because of its use in abuse
- So "thin data" elements in this context does not mean today's thin data but rather the set of data elements to be made available without authentication, accessible publicly to all
- There are many reasons why "thin data" is useful for legitimate purposes, including the expiration date - if not linked to PII, it should remain in the "thin data" set
- The working definition of "thin data" was never agreed to - agreement was to tentatively use it, and revisit - WG not going around in circles when trying to determine what data elements are included in "thin data"
- Should a distinction be made between "thin data" for natural persons and commercial or legal persons?
- NORC Registrant Identification Study Report: http://gnso.icann.org/en/issues/whois/registrant-identification-summary-23may13-en.pdf[gnso.icann.org]
- If the WG is going to be making conclusions on what is included in "thin data", then developing a definition for "thin data" might be required
- Proposed WG agreement (to be tested by poll): Expiration Data should be removed as a "thin data" element to be made accessible without authentication.
- Proposed WG agreements (to be tested by poll): DNSSEC should be added as a "thin data "element accessible without authentication.
- Action Item: Staff to develop poll to test above-noted proposed WG agreements. All WG members to participate in poll no later than COB Saturday 10 June.
4) Brief updates on:
a) Legal analysis
- Leadership Team is starting the process to retain a legal analysis in time to take advantage of the FY17 budget
b) ICANN59 plans: 26 June Cross-Community session, 28 June WG F2F session
5) Confirm action items and proposed decision points
- Working Group Agreements:
- WG Agreement: At least a defined set of "thin data" elements must be accessible by unauthenticated RDS users
- WG Agreement: RDS policy must state purpose(s) for public access to "thin data.”
- Decision: Put the proposed agreement “RDS policies for access to"thin data" must be non-discriminatory for all legitimate purposes.” on hold, pending resolution of action item 2(c) in the notes above
- Decision: Put the Principle of Proportionality aside for now, pending further deliberation
- Action Items:
- Staff to add above-noted WG agreements to working document.
- Rod/VA to complete action item assigned during 23 May call, sending proposed resolution to WG mailing list before next WG call.
- Staff to develop poll to test the following proposed WG agreements. All WG members to participate in poll no later than COB Saturday 10 June:
- Expiration Data should be removed as a "thin data" element to be made accessible without authentication.
- DNSSEC should be added as a "thin data "element accessible without authentication.
- All WG members to plan to attend ICANN59 Cross Community and F2F WG sessions (see links above), either in-person or via remote participation.
- All WG members encouraged to share the GNSO Next-Generation RDS PDP WG April/May 2017 newsletter (found on this page: https://community.icann.org/x/_RmOAw) with their own Stakeholder Groups, Constituencies, Supporting Organizations and Advisory Committees in preparation for the cross-community discussion scheduled to take place at ICANN 59 in Johannesburg