[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:45:10 UTC 2017
I prefer Chuck’s approach.
From: allison nixon <elsakoo at gmail.com>
Date: Thursday, April 27, 2017 at 3:53 PM
To: "Gomes, Chuck" <cgomes at verisign.com>
Cc: "amr.elsadr at icann.org" <amr.elsadr at icann.org>, Paul Keating
<paul at law.es>, "gnso-rds-pdp-wg at icann.org" <gnso-rds-pdp-wg at icann.org>,
"lisa at corecom.com" <lisa at 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 at 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 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/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 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-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 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
>>
>> _______________________________________________
>> 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/ece34179/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list