<html>

<body>

Chuck, <br><br>

The bullet states that in the second sentence:<br><br>

<i>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.<br><br>

</i>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:<br><br>

<i>&quot;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.&quot;<br><br>

</i>This is further illustrated as &quot;unauthenticated public

registration data access&quot; and &quot;gated registration data

access&quot; on pages 61-62 of the EWG report. Apologies if my

paraphrasing led to any confusion.<br><br>

Best, Lisa<br><br>

<br><br>

At 03:31 PM 4/25/2017, Gomes, Chuck via gnso-rds-pdp-wg wrote:<br>

<blockquote type=cite class=cite cite="">Content-Language: en-US<br>

Content-Type: multipart/alternative;<br>

<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>

boundary=&quot;_000_6DCFB66DEEF3CF4D98FA55BCC43F152E74B23899BRN1WNEXMBX02vc_&quot;<br>

<br>

Thanks Amr.&nbsp; 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”.&nbsp; 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.&nbsp; I think they said that “the

practice of anonymous public access for all data elements should be

abandoned”.<br>

&nbsp;<br>

I invite those who were on the EWG to correct me if I am wrong.<br>

&nbsp;<br>

Chuck<br>

<a name="_MailEndCompose"></a>&nbsp;<br>

<b>From:</b> gnso-rds-pdp-wg-bounces@icann.org

[<a href="mailto:gnso-rds-pdp-wg-bounces@icann.org" eudora="autourl">

mailto:gnso-rds-pdp-wg-bounces@icann.org</a>] <b>On Behalf Of </b>Amr

Elsadr<br>

<b>Sent:</b> Tuesday, April 25, 2017 3:50 PM<br>

<b>To:</b> gnso-rds-pdp-wg@icann.org<br>

<b>Subject:</b> [EXTERNAL] Re: [gnso-rds-pdp-wg] IMPORTANT: Action Items

and Notes from Next-Generation RDS PDP Working Group Call - 25 April

2017<br>

<b>Importance:</b> High<br>

&nbsp;<br>

Hello again,<br>

&nbsp;<br>

Apologies for the duplication and any confusion, but some revisions in

the Action Items and Notes below. Please disregard the first set.<br>

&nbsp;<br>

Thanks again.<br>

&nbsp;<br>

Amr<br>

&nbsp;<br>

&nbsp;<br>

<i>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:

<a href="https://community.icann.org/x/DcPRAw">

https://community.icann.org/x/DcPRAw</a><br>

</i>&nbsp;<br>

Action Items:<br>

&nbsp;

<ol>

<li>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

<li>Working Group members should review the proposed questions to ccTLD

operators, and send any feedback on-list prior to next Working Group

call

<li>David Cake will communicate to the full Working Group by the end of

this week proposed definitions/concepts to replace the term

&quot;authoritative&quot; proposed new term(s) to reflect this

<li>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

<li>all WG members to review the new section 5 found here:

<a href="https://community.icann.org/download/attachments/56986791/KeyConceptsDeliberation-WorkingDraft-21April2017.pdf">

https://community.icann.org/download/attachments/56986791/KeyConceptsDeliberation-WorkingDraft-21April2017.pdf</a>

, which reflects how the EWG broke apart this complex question into a few

key concepts

</ol>&nbsp;<br>

Notes:<br>

&nbsp;

<ol>

<li>Plan to complete in-progress tasks 

<ol>

<li>ccTLD questions 

<ul>

<li>Small team has a list of 13 questions for ccTLD Registries

<li>Growing list of Registries, seeking contacts to reach out to them

<li>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

<li>ACTION ITEM: Working Group members should review the questions, and

send any feedback on-list prior to next Working Group call

</ul>

<li>Definition of authoritative 

<ul>

<li>Small team has found the word &quot;authoritative&quot; to be

confusing, and is suggesting not using it

<li>Definition in the DNS context is not useful, conflict between legal

and technical use of the word

<li>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

<li>ACTION ITEM: David Cake will communicate to the full Working Group by

the end of this week proposed definitions/concepts to replace the term

&quot;authoritative&quot; proposed new term(s) to reflect this

<li>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

</ul>

</ul>

<li>Revised Task 12 sequence and timeline

</ul>See

<a href="https://community.icann.org/download/attachments/56986784/RDSPDP-Task12-Revised21April2017.pdf">

https://community.icann.org/download/attachments/56986784/RDSPDP-Task12-Revised21April2017.pdf</a>

<ul>

<li>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.

<li>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

&quot;thin&quot; data discussed thus far in Task 12.a)

<li>Working Group has had difficulty in agreeing on key concepts without

knowing what kind of access will be permitted --&gt; 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.&nbsp; 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.

<li>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

<li>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 &quot;thin&quot; data alone, Working Group may adjust plan to

address access to both &quot;thin&quot; and &quot;thick&quot; data in

Task 12.b.

<li>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)

<li>Refer to Working Group Charter on &quot;rules of engagement&quot; in

order to settle differences of opinion:

<a href="https://community.icann.org/display/gTLDRDS/WG+Charter">

https://community.icann.org/display/gTLDRDS/WG+Charter</a>

<li>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:

<a href="http://www.icann.org/en/about/governance/bylaws#AnnexA">

http://www.icann.org/en/about/governance/bylaws#AnnexA</a> 

<li>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

&quot;thin&quot; vs &quot;thick&quot;

<li>Start deliberation on the charter question/subquestion 5.1:&nbsp;

Should gTLD registration “thin” data be entirely public or should

access be controlled?

</ol>See

<a href="https://community.icann.org/download/attachments/64078605/NewSection5-Intro-KeyConcepts-21April2017.pdf">

https://community.icann.org/download/attachments/64078605/NewSection5-Intro-KeyConcepts-21April2017.pdf</a>

<ul>

<li>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

<li>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

<li>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?

<li>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?

</ul>&nbsp;<br>

-- What are the guiding principles that should be used to determine

level(s) of access (including law enforcement access)?

<ul>

<li>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.

<li>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

<li>From AC Chat: to me, the answer is &quot;both&quot;.&nbsp; it should

be public, but controls for access should be available to limit rates and

so on.&nbsp; 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.

<li>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

<li>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).

</ul>&nbsp;<br>

-- Question to Working Group members: If the Working Group can identify

legitimate purposes to collect &quot;thin&quot; 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?

<ul>

<li>Reminder: This WG is basing deliberation on the Thick WHOIS

Definition of &quot;thin&quot; data as a starting point: <i>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</i>.

<li>Today's WHOIS publishes both &quot;thin&quot; and &quot;thick&quot;

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.&nbsp; Rate limiting is a separate anti-abuse

measure that can be applied to either public or gated access.

<li>From the AC Chat: There are many ways one can &quot;gate&quot; access

- but the question on the table is should access remain NON gated (that

is, entirely public)

<li>Reason for not displaying &quot;thin&quot; 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

<li>Can the need to publish &quot;thin&quot; 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?

<li>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?

<li>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?

<li>Some believe that the only people who need access to &quot;thin&quot;

data are the one's operating the domain name, but the reason why WHOIS

&quot;thin&quot; 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

&quot;thin&quot; data

<li>&quot;thin&quot; 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?

<li>The Working Group needs to answer the question of gated access to

&quot;thin&quot; data using some assumptions, such as that there is a

legitimate purpose in collection of &quot;thin&quot; data

<li>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.

<li>Working Group members need to provide specific and concrete reasons

why &quot;thin&quot; data elements should not be publicly displayed

(under the assumption that there is a legitimate purpose to collect and

process this data)

<li>Confirm next meeting date: 2 May 2017 at 16:00 UTC

</ol>&nbsp;<br>

<b>&nbsp;<br>

Meeting Materials (all posted at

<a href="https://community.icann.org/x/DcPRAw)">

https://community.icann.org/x/DcPRAw)</a></b>

<ol>

<li>

<a href="https://community.icann.org/download/attachments/56986784/RDSPDP-Task12-Revised-21April2017.pdf?version=1&amp;modificationDate=1492802630734&amp;api=v2">

RDSPDP-Task12-Revised-21April2017.pdf</a>

<li>

<a href="https://community.icann.org/download/attachments/64078605/NewSection5-Intro-KeyConcepts-21April2017.pdf?version=1&amp;modificationDate=1492802791000&amp;api=v2">

NewSection5-Intro-KeyConcepts-21April2017.pdf</a> - excerpted from

<li>

<a href="https://community.icann.org/download/attachments/56986791/KeyConceptsDeliberation-WorkingDraft-21April2017.pdf?version=1&amp;modificationDate=1492966757152&amp;api=v2">

KeyConceptsDeliberation-WorkingDraft-21April2017.pdf</a> and

<a href="https://community.icann.org/download/attachments/56986791/KeyConceptsDeliberation-WorkingDraft-21April2017.docx?version=1&amp;modificationDate=1492966735704&amp;api=v2">

doc</a>

<li>

<a href="https://community.icann.org/download/attachments/64078601/ICANN58-Privacy-Panel-Responses-Draft-7April2017.pdf?version=1&amp;modificationDate=1491837560000&amp;api=v2">

ICANN58-Privacy-Panel-Responses-Draft-7April2017.pdf</a> and

<a href="https://community.icann.org/download/attachments/64078601/ICANN58-Privacy-Panel-Responses-Draft-7April2017.docx?version=1&amp;modificationDate=1491839756000&amp;api=v2">

doc</a>

</ol>&nbsp;<br>

&nbsp;<br>

<b>From:

</b>&lt;<a href="mailto:gnso-rds-pdp-wg-bounces@icann.org">

gnso-rds-pdp-wg-bounces@icann.org</a>&gt; on behalf of Amr Elsadr

&lt;<a href="mailto:amr.elsadr@icann.org">amr.elsadr@icann.org</a>&gt;<br>

<b>Date: </b>Tuesday, April 25, 2017 at 9:15 PM<br>

<b>To:

</b>&quot;<a href="mailto:gnso-rds-pdp-wg@icann.org">

gnso-rds-pdp-wg@icann.org</a>&quot;

&lt;<a href="mailto:gnso-rds-pdp-wg@icann.org">

gnso-rds-pdp-wg@icann.org</a>&gt;<br>

<b>Subject: </b>[gnso-rds-pdp-wg] IMPORTANT: Action Items and Notes from

Next-Generation RDS PDP Working Group Call - 25 April 2017<br>

&nbsp;<br>

Dear Working Group Members,<br>

&nbsp;<br>

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”.<br>

&nbsp;<br>

Thanks.<br>

&nbsp;<br>

Amr<br>

&nbsp;<br>

&nbsp;<br>

Action Items:<br>

&nbsp;

<ol>

<li>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

<li>Working Group members should review the proposed questions to ccTLD

operators, and send any feedback on-list prior to next Working Group

call

<li>David Cake will communicate to the full Working Group by the end of

this week proposed definitions/concepts to replace the term

&quot;authoritative&quot; proposed new term(s) to reflect this

<li>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

</ol>&nbsp;<br>

Notes:<br>

&nbsp;

<ol>

<li>Plan to complete in-progress tasks 

<ul>

<li>ccTLD questions 

<ul>

<li>Small team has a list of 13 questions for ccTLD Registries

<li>Growing list of Registries, seeking contacts to reach out to them

<li>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

<li>ACTION ITEM: Working Group members should review the questions, and

send any feedback on-list prior to next Working Group call

</ul>

<li>Definition of authoritative 

<ul>

<li>Small team has found the word &quot;authoritative&quot; to be

confusing, and is suggesting not using it

<li>Definition in the DNS context is not useful, conflict between legal

and technical use of the word

<li>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

<li>ACTION ITEM: David Cake will communicate to the full Working Group by

the end of this week proposed definitions/concepts to replace the term

&quot;authoritative&quot; proposed new term(s) to reflect this

<li>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

</ul>

</ul>

<li>Revised Task 12 sequence and timeline

</ul>See

<a href="https://community.icann.org/download/attachments/56986784/RDSPDP-Task12-Revised21April2017.pdf">

https://community.icann.org/download/attachments/56986784/RDSPDP-Task12-Revised21April2017.pdf</a>

<ul>

<li>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