The next GNSO Next-Gen RDS PDP Working Group teleconference will take place on Wednesday, 19 April at 05:00 UTC for 90 minutes. 

22:00 PDT (Tuesday), 01:00 EDT, 06:00 London, 07:00 CET 

For other times:

PROPOSED AGENDA: 

1) Roll Call/SOI Updates

2) Updates on in-progress tasks
   a) ccTLD questions
   b) Definition of authoritative

3) Start discussion of privacy expert answers (30 minutes)
   a) Review poll results Q3 & Q4
   b) Discuss possible key concepts and follow-up questions
        See ICANN58-Privacy-Panel-Responses-Draft-7April2017.pdf
        and Annotated Summary Poll Results
   c) Continue deliberation on the charter question/subquestion 4.1:

      For thin data only -- Do existing gTLD RDS policies sufficiently
      address compliance with applicable data protection, privacy, and free
      speech laws within each jurisdiction? If not, what requirements might
      those laws place on RDS policies regarding purposes associated with thin data?

4) Continue 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 Q2 poll response and Merged-ThinDataPurposes-v1.pdf

5) Confirm action items and proposed decision points
6) Confirm next meeting date: 25 April, 2017 at 16:00 UTC 


Apologies: Holly Raiche, Greg Aaron, Andrew Sullivan, Steve Metalitz, Geoffrey Noakes, Michael Hammer, Sara Bockey, Marika Konings, Michele Neylon


Notes RDS PDP WG Meeting 

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: Susan Kawaguchi

2) Updates on in-progress tasks

a) ccTLD questions

  • Have gathered 10-12 questions
  • Small team is reviewing, hope to have draft for entire WG to review in next day or so

b) Definition of authoritative

  • Probably not going to define "authoritative" but instead choose a different term to capture concept as needed for this WG
  • Aim to have definition for full WG review before next WG call

3) Start discussion of privacy expert answers (30 minutes)

a) Review poll results Q3 & Q4

b) Discuss possible key concepts and follow-up questions

  • See ICANN58-Privacy-Panel-Responses-Draft-7April2017.pdf and Annotated Summary Poll Results
  • Starting with Poll Question 4: Key concepts from expert answers to WG question #2
  • Key concepts summarized by staff from poll question responses at bottom of page 9
  • General concern: Key concepts should not be assessed in an isolated manner, but rather taking into consideration the WG’s question being answered and the other key concepts provided within the same answer
  • Discussion for each possible key concept:

Possible key concept a):
"Allowing people to get in touch with a domain name holder is a legitimate purpose"

  • Extracting key concepts might disentangle them from caveats in data protection experts' answers to the WG’s questions
  • Enabling contact with a registrant may be a legitimate purpose, but this is not necessarily a requirement for direct contact (example: contact could be via registrar)
  • Possible alternative: Allowing contact with a domain name holder, or his/her representative for each specific purpose, is a legitimate purpose
  • Agreement on general concept of allowing people to contact domain name holder, but with caveats – the devil is in the detail of how to enable contact, with whom, why, etc.

Possible key concept b):
 "Proportionality needs be assessed in relation to each data user"

  • Not much agreement with this key concept from those on this call
  • Proportionality needs to be assessed for everything, not just in relation to each user
  • Possible alternative: Proportionality needs to be assessed in relation to each data element and user?

Possible key concept c):
 "ICANN needs to distinguish between individual person and legal person registration data"

  • This key concept does not distinguish between local and global applicability
  • Most key concepts [about data protection and privacy] will not explicitly apply globally, due to different applicable laws in different jurisdictions
  • Possible alternative: ICANN needs to distinguish between individual person and legal person registration data, as required by applicable law (or "where required by applicable law")
  • Terminology: “Natural person” refers to an individual human being, as opposed to a “Legal person” which may be a corporation or other legal entity (e.g., business, NGO)
  • Why is it necessary to distinguish between natural persons and legal persons?
  • GDPR and other laws confer data protection and privacy rights to natural persons
  • We need to know if the domain name holder is a Natural person or not when data is collected so that the publication can be properly processed. However, does this imply that whether a registrant is a “natural person” should be a published data element?
  • Distinction between natural person and legal person is a valid key concept, at least in the context of EU privacy/data protection law
  • May also be necessary to associate domain name holder with purpose of domain name registration (example: corporate representative registering domain name on behalf of employer vs. that same individual registering domain name for private use) – different laws may be applicable to individuals acting on behalf of employer
  • Working Group should also consider overarching question of whether ICANN should actually treat natural person and legal person registrants differently. Differentiating between natural and legal persons at time of data collection makes it possible to develop such policies, but it does not require treating them differently - may require key concept of its own
  • EWG approach allowed legal persons to self-identify as legal persons, natural persons to self-identify as natural persons, and to treat registrants as if they were natural persons otherwise
  • If a domain name holder self-identifies as a legal person, this should be displayed and data should be treated in a manner that complies with applicable laws for legal persons
  • Distinction should be made between collection, processing and publication of data identifying a domain name holder as a legal or natural person
  • Distinction between legal and natural person is necessary to identify what data protection and privacy laws apply to the domain name holder and all registration data elements containing personal information
  • Are there laws that impose publication/transparency requirements on legal persons, for which this distinction between natural and legal persons would also be needed?

Possible key concept d):
"There should be layered/gated access to gTLD registration data"

  • To be deliberated by this WG when we get to the charter question on gated access
  • This answer implies that access to some data must be limited in some way (that is, not entirely public) - this makes it harder to investigate attacks
  • Need to eventually resolve any conflicts between legitimate purposes in access to data in the RDS with applicable law that may not permit access to every registration data element - this cannot be done using current WHOIS model of entirely public access
  • From AC chat: Article 29 WP 76 Opinion 2/2003 (http://ec.europa.eu/justice/policies/privacy/docs/wpdocs/2003/wp76_en.pdf) "registration of domain names by individuals raises different legal considerations than that of companies or other legal persons registering domain names" ... "the publication of certain information about the company or organisation (such as their identification and their physical address) is often a requirement by law in the framework of the commercial or professional activities they perform"
  • Premature to discuss differentiated access right now - solution in search of a problem
  • The problem this answer is addressing is today’s requirement that all registration data be public
  • Differentiated access should allow for credential provision to those with legitimate purposes for access to registration data
  • Need to identify different fields/registration data elements that require protection/gated access, and not create a general requirement that covers all data
  • WG may need to move ahead to deliberating on the gated access charter question before we can make progress on other questions with answers that depend upon whether all registration data continues to be public

Possible key concept e):
 "There is a need to identify and document query purposes; collection/derivation only for legit purposes"

  • Purposes for collection and processing of data not the same as purposes for disclosure - "unpack" meaning of layered/differentiated/gated/tiered access
  • From AC chat: let's identify the problem (not all data should be public) and then let's consider the best way to solve that problem.  differentiated access is simply one possible solution

Possible key concept f):
"Personal data is not (cannot be?) publicly published"

  • If there are registration data elements that are personal data, many data protection laws prevent that personal data from being published

Defer review of Poll Question 3: Key concepts from expert answers to WG question #1

c) Continue deliberation on the charter question/subquestion 4.1:

For thin data only -- Do existing gTLD RDS policies sufficiently address compliance with applicable data protection, privacy, and free speech laws within each jurisdiction? If not, what requirements might those laws place on RDS policies regarding purposes associated with thin data?

  • See https://community.icann.org/download/attachments/64078512/Merged-ThinDataPurposes-v1.pdf
  • Review answers to poll question 2
  • 74% supported this possible agreement, only one poll respondent disagreed
  • However, a couple of comments suggested rewording
  • Based on comment 4, this alternative possible agreement was discussed:
    "Every legitimate purpose requires a domain name registration data element"
  • Agreement that domain name is a primary data element - needs to be collected
  • However, is domain name always needed for access? Some gTLD DN WHOIS queries are not based on DN, such as name server and registrar queries

5) Confirm action items and proposed decision points

  • No action items or proposed decision points identified in today’s meeting
  • Need to find an effective way to make use of data protection expert answers to WG questions
  • Possibly review answers in their entirety rather than picking answers apart into key concepts?
  • May not be a poll this week – leadership to consider an approach to continue applying these answers during next week’s meeting to help the WG develop and agree upon key concepts

6) Confirm next meeting date: 25 April, 2017 at 16:00 UTC

 

Meeting Materials

 

  • No labels