[gnso-rds-pdp-wg] IMPORTANT: Action Items and Notes from Next-Generation RDS PDP Working Group Call - 25 April 2017

Paul Keating Paul at law.es
Thu Apr 27 14:44:53 UTC 2017 

Perfect thanks.

Can we ask Staff to maintain a vocabulary list with definitions for ease in
reference (not a joke).?

Also, can we consider retaining an expert to give us information as to the
various privacy laws that people are referencing?  I have participated in
other WGs where this was done with great success.

Regards,
Paul

From:  "Gomes, Chuck" <cgomes at verisign.com>
Date:  Thursday, April 27, 2017 at 3:26 PM
To:  Paul Keating <paul at law.es>, "lisa at corecom.com" <lisa at corecom.com>,
"amr.elsadr at icann.org" <amr.elsadr at icann.org>, "gnso-rds-pdp-wg at icann.org"
<gnso-rds-pdp-wg at icann.org>
Subject:  RE: [gnso-rds-pdp-wg] IMPORTANT: Action Items and Notes from
Next-Generation RDS PDP Working Group Call - 25 April 2017

> 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 at law.es]
> Sent: Wednesday, April 26, 2017 9:05 AM
> To: Gomes, Chuck <cgomes at verisign.com>; lisa at corecom.com;
> amr.elsadr at icann.org; gnso-rds-pdp-wg at 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 at icann.org> on behalf of "Gomes, Chuck via
> gnso-rds-pdp-wg" <gnso-rds-pdp-wg at icann.org>
> Reply-To: "Gomes, Chuck" <cgomes at verisign.com>
> Date: Wednesday, April 26, 2017 at 12:05 AM
> To: "lisa at corecom.com" <lisa at corecom.com>, "amr.elsadr at icann.org"
> <amr.elsadr at icann.org>, "gnso-rds-pdp-wg at icann.org"
> <gnso-rds-pdp-wg at 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 at corecom.com]
>> Sent: Tuesday, April 25, 2017 5:59 PM
>> To: Gomes, Chuck <cgomes at verisign.com>; amr.elsadr at icann.org;
>> gnso-rds-pdp-wg at 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 at icann.org [
>>> mailto:gnso-rds-pdp-wg-bounces at icann.org
>>> <mailto:gnso-rds-pdp-wg-bounces at icann.org> ] On Behalf Of Amr Elsadr
>>> Sent: Tuesday, April 25, 2017 3:50 PM
>>> To: gnso-rds-pdp-wg at 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/KeyConceptsDeliber
>>> ation-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-Revi
>>> sed21April2017.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-Rev
>>> ised-21April2017.pdf?version=1&modificationDate=1492802630734&api=v2>
>>> 2. NewSection5-Intro-KeyConcepts-21April2017.pdf
>>> <https://community.icann.org/download/attachments/64078605/NewSection5-Intro
>>> -KeyConcepts-21April2017.pdf?version=1&modificationDate=1492802791000&api=v2
>>> >  - excerpted from
>>> 3. KeyConceptsDeliberation-WorkingDraft-21April2017.pdf
>>> <https://community.icann.org/download/attachments/56986791/KeyConceptsDelibe
>>> ration-WorkingDraft-21April2017.pdf?version=1&modificationDate=1492966757152
>>> &api=v2>  and doc
>>> <https://community.icann.org/download/attachments/56986791/KeyConceptsDelibe
>>> ration-WorkingDraft-21April2017.docx?version=1&modificationDate=149296673570
>>> 4&api=v2>  
>>> 4. ICANN58-Privacy-Panel-Responses-Draft-7April2017.pdf
>>> <https://community.icann.org/download/attachments/64078601/ICANN58-Privacy-P
>>> anel-Responses-Draft-7April2017.pdf?version=1&modificationDate=1491837560000
>>> &api=v2>  and doc
>>> <https://community.icann.org/download/attachments/64078601/ICANN58-Privacy-P
>>> anel-Responses-Draft-7April2017.docx?version=1&modificationDate=149183975600
>>> 0&api=v2>  
>>>  
>>>  
>>> From: < gnso-rds-pdp-wg-bounces at icann.org
>>> <mailto:gnso-rds-pdp-wg-bounces at icann.org> > on behalf of Amr Elsadr
>>> <amr.elsadr at icann.org>
>>> Date: Tuesday, April 25, 2017 at 9:15 PM
>>> To: " gnso-rds-pdp-wg at icann.org <mailto:gnso-rds-pdp-wg at icann.org> " <
>>> gnso-rds-pdp-wg at icann.org <mailto:gnso-rds-pdp-wg at 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-Revi
>>> sed21April2017.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 at icann.org
>>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>> _______________________________________________ gnso-rds-pdp-wg mailing list 
>> gnso-rds-pdp-wg at icann.org 
>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170427/b68c6696/attachment-0001.html>

More information about the gnso-rds-pdp-wg mailing list