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


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

 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

WG Agreement: At least a defined set of "thin data" elements must be accessible by unauthenticated RDS users.

  • Q3: Majority support at 75%
    • 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

WG Agreement: RDS policy must state purpose(s) for public access to "thin data.”

  • Q4: Support at 61% but unclear how many disagreed with non-discriminatory concept
    • Several comments expressed concern about the phrase "legitimate purposes"
    • Proposed alternative from leadership team: RDS policies for access to "thin data" must be non-discriminatory (i.e., RDS policies must not be designed to give anyone preferential access).
    • 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
    • Conclusion:  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 RDSPDP-Handout-For6JuneCall.pdf slide 2
  • Consider tests of proportionality for 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

  • Deferred to next call

Action Item: Rod Rasmussen and Vaibhav Aggarwal to complete action assigned during 17 May call and distribute in advance of 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.“

  • Resume deliberation by trying to answer this question: 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 is the WG trying to answer to these questions?
    • The working definition of "thin data" from the Thick WHOIS Report was used to enable deliberation on other questions
    • However, this WG never agreed upon specific data elements that are required
    • We are now addressing that by returning to the Data Elements charter question
    • We are now trying to determine what data elements are included in "thin data"
    • Note: "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
  • Feedback from the WG in answer to these questions:
    • 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 2013 RAA include Registrar Abuse Contact Email and phone number, DNSSEC, and URL of the ICANN WHOIS Data Problem Reporting System
    • However, those additional 2013 RAA fields may not be "thin data"
    • 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 expiration date accessible via an RDS? Not because it might be personal data, but because of its use in abuse
    • 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
    • Comment from Chat: I'm not sure yet that I agree the status information needs to be there
    • Should a distinction be made between "thin data" for natural persons and legal persons?
    • NORC Registrant Identification Study Report examined percentage of domains registered by natural persons and legal persons: 
      http://gnso.icann.org/en/issues/whois/registrant-identification-summary-23may13-en.pdf
    • Same study examined percentage of domains used for commercial purposes (note: user of domain name may not be registrant)
    • 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 Date should be removed as a "thin data" element accessible without authentication.

Proposed WG agreement (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

Action Item: All WG members to plan to attend ICANN59 Cross Community and F2F WG sessions (see links above), either in-person or via remote participation.

Action Item: All WG members encouraged to share the GNSO Next-Generation RDS PDP WG April/May 2017 newsletter with their own SG/Cs and SO/ACs in preparation for the cross-community discussion at ICANN 59 in Johannesburg

5) Confirm action items and proposed decision points

  • 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.”

  • Proposed WG agreement (to be tested by poll): Expiration Date should be removed as a "thin data" element accessible without authentication.

  • Proposed WG agreement (to be tested by poll): DNSSEC should be added as a "thin data" element accessible without authentication.

  • Action Items:
    • Staff to add above-noted WG agreements to working document.
    • Rod Rasmussen and Vaibhav Aggarwal to complete action assigned during 17 May call and distribute in advance of next WG call.
    • 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.
    • 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 with their own SG/Cs and SO/ACs in preparation for the cross-community discussion at ICANN 59 in Johannesburg.

6) Confirm next meeting date: 13 June 2017 at 16:00 UTC


Meeting Materials

30 May Call Poll Results - 

6 June Call Poll

  • Link to participate: closed at COB Saturday 10 June
  • PDF of Poll Questions:  Poll-from-6JuneCall.pdf
  • Poll Results: to be discussed at 13 June RDS PDP meeting


  • No labels