April 27, 2017
2:45 p.m.
I prefer Chuck’s approach. From: allison nixon <elsakoo@gmail.com> Date: Thursday, April 27, 2017 at 3:53 PM To: "Gomes, Chuck" <cgomes@verisign.com> Cc: "amr.elsadr@icann.org" <amr.elsadr@icann.org>, Paul Keating <paul@law.es>, "gnso-rds-pdp-wg@icann.org" <gnso-rds-pdp-wg@icann.org>, "lisa@corecom.com" <lisa@corecom.com> Subject: Re: [gnso-rds-pdp-wg] IMPORTANT: Action Items and Notes from Next-Generation RDS PDP Working Group Call - 25 April 2017 > > Captcha is an aspect of gating that we need to include in the discussions. > This impacts the consistency of whois and ability to machine process the data > for those without big wallets. > > On Apr 27, 2017 9:26 AM, "Gomes, Chuck via gnso-rds-pdp-wg" > <gnso-rds-pdp-wg@icann.org> wrote: >> Paul, >> >> As became clear in our meeting earlier this week and the discussions that >> have followed, we will have to be very clear about what we mean by gated. It >> is my opinion right now that we will probably need to treat the following >> types of gating differently: operational gating such as rate limiting and >> Captcha and what you mention as ‘purpose’ gating. I think you are correct >> that these can be thought of as a form of gating but I don’t believe that >> they are what we need to focus on. I believe the Gated Access that we need to >> focus on relates to restricting access to certain categories of users to >> information that is not available to the general public. >> >> Does that make sense? >> >> Purpose based access is a key element of the EWG Report and the GDPR. >> >> Chuck >> >> >> From: Paul Keating [mailto:Paul@law.es] >> Sent: Wednesday, April 26, 2017 9:05 AM >> To: Gomes, Chuck <cgomes@verisign.com>; lisa@corecom.com; >> amr.elsadr@icann.org; gnso-rds-pdp-wg@icann.org >> Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] IMPORTANT: Action Items and Notes >> from Next-Generation RDS PDP Working Group Call - 25 April 2017 >> >> >> Chuck, >> >> >> >> I am having issues with the language being used. >> >> >> >> Gated to mean indicates ANY restriction to access. Thus, even a Captcha >> would be gated (albeit not a very strong gate). >> >> >> >> It thus seems inconsistent to me to state: >> >> >> >> No more anonymous access by anyone BUT >> >> >> >> Some data will be available to everyone BUT only for legitimate purposes >> >> Other data will be “gated”. >> >> >> >> The requirement of a “legitimate” purpose is nothing but a gating concept. >> >> >> >> When I read the EWG text there is no mention of “legitimacy” and thus >> whatever data set was recommended to be available to the public was without >> restriction action (e.g. No gate). >> >> >> >> Thank you >> >> >> >> From: <gnso-rds-pdp-wg-bounces@icann.org> on behalf of "Gomes, Chuck via >> gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> >> Reply-To: "Gomes, Chuck" <cgomes@verisign.com> >> Date: Wednesday, April 26, 2017 at 12:05 AM >> To: "lisa@corecom.com" <lisa@corecom.com>, "amr.elsadr@icann.org" >> <amr.elsadr@icann.org>, "gnso-rds-pdp-wg@icann.org" >> <gnso-rds-pdp-wg@icann.org> >> Subject: Re: [gnso-rds-pdp-wg] IMPORTANT: Action Items and Notes from >> Next-Generation RDS PDP Working Group Call - 25 April 2017 >> >> >>> >>> Thanks Lisa. I should have focused on the second sentence instead of just >>> the first because the second sentence is clearer in my opinion. >>> >>> Chuck >>> >>> >>> From: Lisa Phifer [mailto:lisa@corecom.com] >>> Sent: Tuesday, April 25, 2017 5:59 PM >>> To: Gomes, Chuck <cgomes@verisign.com>; amr.elsadr@icann.org; >>> gnso-rds-pdp-wg@icann.org >>> Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] IMPORTANT: Action Items and Notes >>> from Next-Generation RDS PDP Working Group Call - 25 April 2017 >>> >>> Chuck, >>> >>> The bullet states that in the second sentence: >>> >>> 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. >>> >>> I paraphrased this bullet from the EWG Report excerpts that appear in the >>> new Section 5 in our working document, but perhaps I should have quoted the >>> EWG Report verbatim: >>> >>> "The EWG recommends that a new approach be taken for registration data >>> access, abandoning entirely anonymous access by everyone to everything in >>> favor of a new paradigm that combines public access to some data with gated >>> access to other data." >>> >>> This is further illustrated as "unauthenticated public registration data >>> access" and "gated registration data access" on pages 61-62 of the EWG >>> report. Apologies if my paraphrasing led to any confusion. >>> >>> Best, Lisa >>> >>> >>> >>> At 03:31 PM 4/25/2017, Gomes, Chuck via gnso-rds-pdp-wg wrote: >>> >>> >>>> >>>> Content-Language: en-US >>>> Content-Type: multipart/alternative; >>>> >>>> boundary="_000_6DCFB66DEEF3CF4D98FA55BCC43F152E74B23899BRN1WNEXMBX02vc_" >>>> >>>> Thanks Amr. The second to last bullet under item 3 below says “the EWG >>>> recommended that entirely public anonymous access by anyone for any purpose >>>> be abandoned†. I am not sure that this is worded accurately; it could be >>>> interpreted to mean that the EWG recommended that no data elements should >>>> be anonymously accessible by anyone and I do not believe that the EWG said >>>> that. I think they said that “the practice of anonymous public access >>>> for all data elements should be abandoned†. >>>> >>>> I invite those who were on the EWG to correct me if I am wrong. >>>> >>>> Chuck >>>> >>>> From: gnso-rds-pdp-wg-bounces@icann.org [ >>>> mailto:gnso-rds-pdp-wg-bounces@icann.org >>>> <mailto:gnso-rds-pdp-wg-bounces@icann.org> ] On Behalf Of Amr Elsadr >>>> Sent: Tuesday, April 25, 2017 3:50 PM >>>> To: gnso-rds-pdp-wg@icann.org >>>> Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] IMPORTANT: Action Items and Notes >>>> from Next-Generation RDS PDP Working Group Call - 25 April 2017 >>>> Importance: High >>>> >>>> Hello again, >>>> >>>> Apologies for the duplication and any confusion, but some revisions in the >>>> Action Items and Notes below. Please disregard the first set. >>>> >>>> Thanks again. >>>> >>>> Amr >>>> >>>> >>>> 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/DcPRAw >>>> >>>> Action Items: >>>> >>>> 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 >>>> 2. Working Group members should review the proposed questions to ccTLD >>>> operators, and send any feedback on-list prior to next Working Group call >>>> 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 >>>> 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 >>>> 5. all WG members to review the new section 5 found here: >>>> https://community.icann.org/download/attachments/56986791/KeyConceptsDelibe >>>> ration-WorkingDraft-21April2017.pdf , which reflects how the EWG broke >>>> apart this complex question into a few key concepts >>>> >>>> Notes: >>>> >>>> 1. Plan to complete in-progress tasks >>>>> 1. 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 >>>>> 2. 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://community.icann.org/download/attachments/56986784/RDSPDP-Task12-Rev >>>> ised21April2017.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://community.icann.org/display/gTLDRDS/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" >>>> §Start deliberation on the charter question/subquestion 5.1: Should gTLD >>>> registration “thin†data be entirely public or should access be >>>> controlled? >>>> See >>>> https://community.icann.org/download/attachments/64078605/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, available to >>>> aauthenticated 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) >>>> * Confirm next meeting date: 2 May 2017 at 16:00 UTC >>>> >>>> >>>> Meeting Materials (all posted at https://community.icann.org/x/DcPRAw) >>>> 1. RDSPDP-Task12-Revised-21April2017.pdf >>>> <https://community.icann.org/download/attachments/56986784/RDSPDP-Task12-Re >>>> vised-21April2017.pdf?version=1&modificationDate=1492802630734&api=v2> >>>> 2. NewSection5-Intro-KeyConcepts-21April2017.pdf >>>> <https://community.icann.org/download/attachments/64078605/NewSection5-Intr >>>> o-KeyConcepts-21April2017.pdf?version=1&modificationDate=1492802791000&api= >>>> v2> - excerpted from >>>> 3. KeyConceptsDeliberation-WorkingDraft-21April2017.pdf >>>> <https://community.icann.org/download/attachments/56986791/KeyConceptsDelib >>>> eration-WorkingDraft-21April2017.pdf?version=1&modificationDate=14929667571 >>>> 52&api=v2> and doc >>>> <https://community.icann.org/download/attachments/56986791/KeyConceptsDelib >>>> eration-WorkingDraft-21April2017.docx?version=1&modificationDate=1492966735 >>>> 704&api=v2> >>>> 4. ICANN58-Privacy-Panel-Responses-Draft-7April2017.pdf >>>> <https://community.icann.org/download/attachments/64078601/ICANN58-Privacy- >>>> Panel-Responses-Draft-7April2017.pdf?version=1&modificationDate=14918375600 >>>> 00&api=v2> and doc >>>> <https://community.icann.org/download/attachments/64078601/ICANN58-Privacy- >>>> Panel-Responses-Draft-7April2017.docx?version=1&modificationDate=1491839756 >>>> 000&api=v2> >>>> >>>> >>>> From: < gnso-rds-pdp-wg-bounces@icann.org >>>> <mailto:gnso-rds-pdp-wg-bounces@icann.org> > on behalf of Amr Elsadr >>>> <amr.elsadr@icann.org> >>>> Date: Tuesday, April 25, 2017 at 9:15 PM >>>> To: " gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> " < >>>> gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> > >>>> Subject: [gnso-rds-pdp-wg] IMPORTANT: Action Items and Notes from >>>> Next-Generation RDS PDP Working Group Call - 25 April 2017 >>>> >>>> Dear Working Group Members, >>>> >>>> Below are the Action Items and Notes from today’s call. Please keep an >>>> eye out for emails from Susan Kawaguchi concerning the proposed questions >>>> to ccTLD registry operators’ measures to comply with the GDPR, as well as >>>> from David Cake on an update regarding the Working Group’s working >>>> definition of “authoritative†. >>>> >>>> Thanks. >>>> >>>> Amr >>>> >>>> >>>> Action Items: >>>> >>>> 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 >>>> 2. Working Group members should review the proposed questions to ccTLD >>>> operators, and send any feedback on-list prior to next Working Group call >>>> 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 >>>> 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 >>>> >>>> Notes: >>>> >>>> 1. Plan to complete in-progress tasks >>>>> * 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 >>>>> * 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 >>>> 2. Revised Task 12 sequence and timeline >>>> See >>>> https://community.icann.org/download/attachments/56986784/RDSPDP-Task12-Rev >>>> ised21April2017.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://community.icann.org/display/gTLDRDS/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" >>>> * Start deliberation on the charter question/subquestion 5.1: Should gTLD >>>> registration “thin†data be entirely public or should access be >>>> controlled? >>>> See >>>> https://community.icann.org/download/attachments/64078605/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, available to >>>> authenticcated 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. >>>> * Confirm action items and proposed decision points >>>>> * 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) >>>> * Confirm next meeting date: 2 May 2017 at 16:00 UTC >>>> >>>> _______________________________________________ >>>> gnso-rds-pdp-wg mailing list >>>> gnso-rds-pdp-wg@icann.org >>>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg >>> _______________________________________________ gnso-rds-pdp-wg mailing list >>> gnso-rds-pdp-wg@icann.org >>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg >> >> _______________________________________________ >> gnso-rds-pdp-wg mailing list >> gnso-rds-pdp-wg@icann.org >> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg