The next GNSO Next-Gen RDS PDP Working Group teleconference will take place on Tuesday, 25 April at 16:00 UTC for 90 minutes.
09:00 PDT, 12:00 EDT, 17:00 London, 18:00 CET
For other times: http://tinyurl.com/k7ytazq
Proposed Agenda for RDS PDP WG Meeting
1) Roll Call/SOI Updates
2) Plan to complete in-progress tasks
a) ccTLD questions
b) Definition of authoritative
3) Revised Task 12 sequence and timeline
See RDSPDP-Task12-Revised-21April2017.pdf
4) Start deliberation on the charter question/subquestion 5.1:
Should gTLD registration "thin data" be entirely public or should access be controlled?
See NewSection5-Intro-KeyConcepts-21April2017.pdf
5) Confirm action items and proposed decision points
6) Confirm next meeting date: 2 May 2017 at 16:00 UTC
Apologies: Holly Raiche, Olévié Kouami, Greg Aaron, Stephanie Perrin, Susan Prosser, Mark Svancarek, Rod Rasmussen, Alan Greenberg, Victoria Sheckler, Benny Samuelsen, Michele Neylon, Viviane Gomes Vinagre
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: none
2) Updates on in-progress tasks
a) ccTLD questions
- Small team has a list of 13 questions for ccTLD Registries
- Growing list of Registries, seeking contacts to reach out to them
- ACTION ITEM: Susan Kawaguchi to send list of questions to the full Working Group for review, with the goal of finalizing the list for transmission to selected ccTLDs following next WG call
- ACTION ITEM: Working Group members should review the questions, and send any feedback on-list prior to next Working Group call
b) Definition of authoritative
- Small team has found the word "authoritative" to be confusing, and is suggesting not using it
- Definition in the DNS context is not useful, conflict between legal and technical use of the word
- Small team suggests that full Working Group attempt to find an alternative word(s) to reflect concepts that the WG was trying reflect in its statement of purpose
- ACTION ITEM: David Cake will communicate to the full Working Group by the end of this week proposed definitions/concepts to replace the term "authoritative" proposed new term(s) to reflect this
- ACTION ITEM: Working Group members should review the proposed term(s) and definition(s) and provide any feedback on-list, preferably prior to next Working Group call
3) Revised Task 12 sequence and timeline
- See https://icann-community.atlassian.net/wiki/download/attachments/101516113/RDSPDP-Task12-Revised21April2017.pdf
- Slide 1 has the Phase 1 workflow as agreed to in the WG’s work plan and reviewed in Hyderabad to first address the 5 charter questions, in order to answer the foundational question: whether a next-generation RDS needs to be developed or whether the existing WHOIS can be modified. These recommendations will be reflected in a first Initial Report to be distributed for Public Comment. The WG will then move on to consider the next 6 charter questions, producing a second Initial Report for Public Comment. Only after those reports are produced will the WG try to reach formal consensus to conclude Phase 1. Only if Phase 1 recommends that a Next-Gen RDS is needed, and the GNSO Council agrees, will the PDP move on to Phases 2/3 to develop policies and implementation/coexistence guidance for a Next-Gen RDS.
- Slide 2 shows the Task 12 subtasks in order that the Working Group will be attempting to address them (including key concepts on possible requirements for users/purposes, data elements and privacy of "thin" data discussed thus far in Task 12.a)
- Working Group has had difficulty in agreeing on key concepts without knowing what kind of access will be permitted --> Working Group Leadership has adjusted workplan to address Gated Access now as Task 12.b, then revisit users/purpose, data elements and privacy in Task 12.c. This re-ordering is in response to input from many WG members, to stop deferring the difficult question of whether all data will remain public, so that more progress can be made on other questions, based on the answer to 12.b.
- Slide 3 details target dates by which Working Group should try to reach rough consensus on answers to the first 5 questions prior to taking a second pass to frame key concepts as draft requirements, to be reflected in the first initial report which we hope to start drafting by ICANN60
- WG members expressed different points of view on whether to focus first on “thin†data only or to address access to “thin†and “thick†at the same time. If the Working Group stumbles on addressing access to "thin" data alone, Working Group may adjust plan to address access to both "thin" and "thick" data in Task 12.b.
- Deliberation on the charter question of gated access (balancing proposed privacy and access requirements) will be done by the Working Group - goal is to base Working Group decisions on rough consensus agreements for fundamental requirements, including objective data (example: applicable legal requirements)
- Refer to Working Group Charter on "rules of engagement" in order to settle differences of opinion: https://icann-community.atlassian.net/wiki/spaces/gTLDRDS/pages/101515360/WG+Charter
- For further guidance on how the PDP process is designed to deliberation upon multiple varying viewpoints to reach consensus policy recommendations, see also GNSO PDP Process: http://www.icann.org/en/about/governance/bylaws#AnnexA
- Possible to have a generic discussion on overall requirements for Gated Access before deciding which data elements will be public, and which will not - in that context, possible to defer discussion on "thin" vs "thick"
4) Start deliberation on the charter question/subquestion 5.1: Should gTLD registration “thin†data be entirely public or should access be controlled?
- See https://icann-community.atlassian.net/wiki/download/attachments/101516889/NewSection5-Intro-KeyConcepts-21April2017.pdf
- When determining whether all “thin data†should be public or access to some data elements should be controlled in some way, A balance needs to be achieved between complying with applicable privacy/data protection legal requirements, and preventing abuse
- GDPR will be enforced on contracted parties doing business with customers in the EU, so needs to be addressed using a flexible system that achieves a balance between compliance with applicable law and preventing abuse - cannot pick which laws the system will comply with
- The Working Group needs to move beyond theoretical discussion, and address the specifics of the issue (practical examples) in order to answer this and other Charter questions. For example, are there some “thin data†elements that cannot be made public (published and accessible to anyone, for any reasons) in some jurisdictions?
- Will the Working Group be able to address all concerns relating to all applicable legal jurisdictions? Does it need to in order to answer this charter question?
What are the guiding principles that should be used to determine level(s) of access (including law enforcement access)?
- From AC Chat: based on the discussion we’ve had to date, I believe all thin whois data should be publicly available as it is either not personally identifiable information, or, in extreme edge cases (such as a long domain name that includes personal information), then it is clear that that individual has chosen to make such information public.
- Privacy concerns apply to users of the Internet, but do they apply to registrants of domain names in the same way? If you register a domain name, are you subject to responsibilities normally associated with owners of other kinds of property? Is there a higher bar that requires more from registrants
- From AC Chat: to me, the answer is "both". it should be public, but controls for access should be available to limit rates and so on. Note that rate limits are today applied to entirely public access to WHOIS; rate limits could also be applied to gated access, but the charter question is really more about limiting who can access data and why as opposed to anyone accessing data for any reason.
- From AC Chat: Regarding the publication of thin data: Depends - I see no need to publish it, but there may be technical arguments for it. After all, ownership of phone numbers is not [always] public, land ownership data is [sometimes] gated, even company registration data is gated in some countries and public in others
- The concern raised above is whether there is a legitimate purpose for every data element. If there is no legitimate purpose for a given data element, it wouldn’t be published (publicly or otherwise).
Question to Working Group members: If the Working Group can identify legitimate purposes to collect "thin" data elements, are there reasons why any of those “thin data†elements should not be publicly displayed in a new RDS system as they are today in WHOIS? And if yes, why not?
- Reminder: This WG is basing deliberation on the Thick WHOIS Definition of "thin" data as a starting point: 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.
- Today's WHOIS publishes both "thin" and "thick" data elements, and allows anonymous WHOIS query to all of those data elements - Gated Access might limit access to both what data is accessible (e.g., for each purpose), as well as authenticating who is permitted this access. Rate limiting is a separate anti-abuse measure that can be applied to either public or gated access.
- From the AC Chat: There are many ways one can "gate" access - but the question on the table is should access remain NON gated (that is, entirely public)
- Reason for not displaying "thin" data publicly: Cannot answer the question without first determining whether there is a legitimate purpose that complies with applicable law to first collect the data
- Can the need to publish "thin" data be satisfied by other technical means other than publicly displaying it? For example, cell phone numbers are unlisted and that doesn't cause problems even though landline phone numbers are listed. People find other ways to accomplish their objectives without a directory. Possibly this applies to domain name thin data?
- There may be limitations in commercial purposes for access to data, depending upon jurisdiction and applicable law. - Question should be: Does one have a legitimate purpose in accessing the data?
- Note: This is charter question UP. For now assume there is some “thin†data with legitimate purpose; charter question GA asks: Should access to that data remain entirely public?
- Some believe that the only people who need access to "thin" data are the one's operating the domain name, but the reason why WHOIS "thin" data is publicly displayed is because other operators (operators of the infrastructure on the Internet) need the means to contact each other - possible reason for ungated public access to "thin" data
- "thin" data that does not include personally identifiable information still has value in terms of access for those who would like to determine which registrar is the sponsoring registrar, and when the domain name was registered - was it registered prior to an associated trademark is registered, and does the trademark holder have a legitimate reason to seek contact with the domain name registrant?
- The Working Group needs to answer the question of gated access to "thin" data using some assumptions, such as that there is a legitimate purpose in collection of "thin" data
- In answer to this charter question, the EWG recommended that entirely public anonymous access by anyone for any purpose be abandoned. Instead, some data elements would be made public, to anyone for every legitimate purpose, while other data elements would be gated – that is, avaailable to authenticated requestors for authorized purposes only. Refer to the Working Document new Section 5 for a few relevant excerpts and key concepts from the EWG Report.
- Working Group members need to provide specific and concrete reasons why "thin" data elements should not be publicly displayed (under the assumption that there is a legitimate purpose to collect and process this data)
- ACTION ITEM: All WG members to review the new section 5 found here: https://icann-community.atlassian.net/wiki/download/attachments/101515332/KeyConceptsDeliberation-WorkingDraft-21April2017.pdf, which reflects how the EWG broke apart this complex question into a few key concepts
5) Confirm action items and proposed decision points
- Action Item #1: Susan Kawaguchi to send list of questions to the full Working Group for review following the Working Group call, with the goal of finalizing the list for transmission to selected ccTLDs following next WG call
- Action Item #2: Working Group members should review the proposed questions to ccTLD operators, and send any feedback on-list prior to next Working Group call
- Action Item #3: David Cake will communicate to the full Working Group by the end of this week proposed definitions/concepts to replace the term "authoritative" proposed new term(s) to reflect this
- Action Item #4: Working Group members should review the proposed term(s) and definition(s) and provide any feedback on-list, preferably prior to next Working Group call
- Action Item #5: All WG members to review the new section 5 found here: https://icann-community.atlassian.net/wiki/download/attachments/101515332/KeyConceptsDeliberation-WorkingDraft-21April2017.pdf, which reflects how the EWG broke apart this complex question into a few key concepts
6) Confirm next meeting date: 2 May 2017 at 16:00 UTC
Meeting Materials