April 27, 2017
2:44 p.m.
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@verisign.com> Date: Thursday, April 27, 2017 at 3:26 PM To: Paul Keating <paul@law.es>, "lisa@corecom.com" <lisa@corecom.com>, "amr.elsadr@icann.org" <amr.elsadr@icann.org>, "gnso-rds-pdp-wg@icann.org" <gnso-rds-pdp-wg@icann.org> Subject: RE: [gnso-rds-pdp-wg] IMPORTANT: Action Items and Notes from Next-Generation RDS PDP Working Group Call - 25 April 2017 > Paul, > > As became clear in our meeting earlier this week and the discussions that have > followed, we will have to be very clear about what we mean by gated. It is my > opinion right now that we will probably need to treat the following types of > gating differently: operational gating such as rate limiting and Captcha and > what you mention as ‘purpose’ gating. I think you are correct that these can > be thought of as a form of gating but I don’t believe that they are what we > need to focus on. I believe the Gated Access that we need to focus on relates > to restricting access to certain categories of users to information that is > not available to the general public. > > Does that make sense? > > Purpose based access is a key element of the EWG Report and the GDPR. > > Chuck > > > From: Paul Keating [mailto:Paul@law.es] > Sent: Wednesday, April 26, 2017 9:05 AM > To: Gomes, Chuck <cgomes@verisign.com>; lisa@corecom.com; > amr.elsadr@icann.org; gnso-rds-pdp-wg@icann.org > Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] IMPORTANT: Action Items and Notes > from Next-Generation RDS PDP Working Group Call - 25 April 2017 > > > Chuck, > > > > I am having issues with the language being used. > > > > Gated to mean indicates ANY restriction to access. Thus, even a Captcha would > be gated (albeit not a very strong gate). > > > > It thus seems inconsistent to me to state: > > > > No more anonymous access by anyone BUT > > > > Some data will be available to everyone BUT only for legitimate purposes > > Other data will be “gated”. > > > > The requirement of a “legitimate” purpose is nothing but a gating concept. > > > > When I read the EWG text there is no mention of “legitimacy” and thus whatever > data set was recommended to be available to the public was without restriction > action (e.g. No gate). > > > > Thank you > > > > From: <gnso-rds-pdp-wg-bounces@icann.org> on behalf of "Gomes, Chuck via > gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> > Reply-To: "Gomes, Chuck" <cgomes@verisign.com> > Date: Wednesday, April 26, 2017 at 12:05 AM > To: "lisa@corecom.com" <lisa@corecom.com>, "amr.elsadr@icann.org" > <amr.elsadr@icann.org>, "gnso-rds-pdp-wg@icann.org" > <gnso-rds-pdp-wg@icann.org> > Subject: Re: [gnso-rds-pdp-wg] IMPORTANT: Action Items and Notes from > Next-Generation RDS PDP Working Group Call - 25 April 2017 > > >> >> Thanks Lisa. I should have focused on the second sentence instead of just >> the first because the second sentence is clearer in my opinion. >> >> Chuck >> >> >> From: Lisa Phifer [mailto:lisa@corecom.com] >> Sent: Tuesday, April 25, 2017 5:59 PM >> To: Gomes, Chuck <cgomes@verisign.com>; amr.elsadr@icann.org; >> gnso-rds-pdp-wg@icann.org >> Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] IMPORTANT: Action Items and Notes >> from Next-Generation RDS PDP Working Group Call - 25 April 2017 >> >> Chuck, >> >> The bullet states that in the second sentence: >> >> In answer to this charter question, the EWG recommended that entirely public >> anonymous access by anyone for any purpose be abandoned. Instead, some data >> elements would be made public, to anyone for every legitimate purpose, while >> other data elements would be gated – that is, avaailable to authenticated >> requestors for authorized purposes only. Refer to the Working Document new >> Section 5 for a few relevant excerpts and key concepts from the EWG Report. >> >> I paraphrased this bullet from the EWG Report excerpts that appear in the new >> Section 5 in our working document, but perhaps I should have quoted the EWG >> Report verbatim: >> >> "The EWG recommends that a new approach be taken for registration data >> access, abandoning entirely anonymous access by everyone to everything in >> favor of a new paradigm that combines public access to some data with gated >> access to other data." >> >> This is further illustrated as "unauthenticated public registration data >> access" and "gated registration data access" on pages 61-62 of the EWG >> report. Apologies if my paraphrasing led to any confusion. >> >> Best, Lisa >> >> >> >> At 03:31 PM 4/25/2017, Gomes, Chuck via gnso-rds-pdp-wg wrote: >> >> >>> >>> Content-Language: en-US >>> Content-Type: multipart/alternative; >>> >>> boundary="_000_6DCFB66DEEF3CF4D98FA55BCC43F152E74B23899BRN1WNEXMBX02vc_" >>> >>> Thanks Amr. The second to last bullet under item 3 below says “the EWG >>> recommended that entirely public anonymous access by anyone for any purpose >>> be abandonedâ€. I am not sure that this is worded accurately; it could be >>> interpreted to mean that the EWG recommended that no data elements should be >>> anonymously accessible by anyone and I do not believe that the EWG said >>> that. I think they said that “the practice of anonymous public access for >>> all data elements should be abandonedâ€. >>> >>> I invite those who were on the EWG to correct me if I am wrong. >>> >>> Chuck >>> >>> From: gnso-rds-pdp-wg-bounces@icann.org [ >>> mailto:gnso-rds-pdp-wg-bounces@icann.org >>> <mailto:gnso-rds-pdp-wg-bounces@icann.org> ] On Behalf Of Amr Elsadr >>> Sent: Tuesday, April 25, 2017 3:50 PM >>> To: gnso-rds-pdp-wg@icann.org >>> Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] IMPORTANT: Action Items and Notes >>> from Next-Generation RDS PDP Working Group Call - 25 April 2017 >>> Importance: High >>> >>> Hello again, >>> >>> Apologies for the duplication and any confusion, but some revisions in the >>> Action Items and Notes below. Please disregard the first set. >>> >>> Thanks again. >>> >>> Amr >>> >>> >>> These high-level notes are designed to help PDP WG members navigate through >>> the content of the call and are not meant as a substitute for the transcript >>> and/or recording. The MP3, transcript, and chat are provided separately and >>> are posted on the wiki here: https://community.icann.org/x/DcPRAw >>> >>> Action Items: >>> >>> 1. Susan Kawaguchi to send list of questions to the full Working Group for >>> review following the Working Group call, with the goal of finalizing the >>> list for transmission to selected ccTLDs following next WG call >>> 2. Working Group members should review the proposed questions to ccTLD >>> operators, and send any feedback on-list prior to next Working Group call >>> 3. David Cake will communicate to the full Working Group by the end of this >>> week proposed definitions/concepts to replace the term "authoritative" >>> proposed new term(s) to reflect this >>> 4. Working Group members should review the proposed term(s) and >>> definition(s) and provide any feedback on-list, preferably prior to next >>> Working Group call >>> 5. all WG members to review the new section 5 found here: >>> https://community.icann.org/download/attachments/56986791/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@icann.org >>> <mailto:gnso-rds-pdp-wg-bounces@icann.org> > on behalf of Amr Elsadr >>> <amr.elsadr@icann.org> >>> Date: Tuesday, April 25, 2017 at 9:15 PM >>> To: " gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> " < >>> gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> > >>> Subject: [gnso-rds-pdp-wg] IMPORTANT: Action Items and Notes from >>> Next-Generation RDS PDP Working Group Call - 25 April 2017 >>> >>> Dear Working Group Members, >>> >>> Below are the Action Items and Notes from today’s call. Please keep an eye >>> out for emails from Susan Kawaguchi concerning the proposed questions to >>> ccTLD registry operators’ measures to comply with the GDPR, as well as >>> from David Cake on an update regarding the Working Group’s working >>> definition of “authoritativeâ€. >>> >>> Thanks. >>> >>> Amr >>> >>> >>> Action Items: >>> >>> 1. Susan Kawaguchi to send list of questions to the full Working Group for >>> review following the Working Group call, with the goal of finalizing the >>> list for transmission to selected ccTLDs following next WG call >>> 2. Working Group members should review the proposed questions to ccTLD >>> operators, and send any feedback on-list prior to next Working Group call >>> 3. David Cake will communicate to the full Working Group by the end of this >>> week proposed definitions/concepts to replace the term "authoritative" >>> proposed new term(s) to reflect this >>> 4. Working Group members should review the proposed term(s) and >>> definition(s) and provide any feedback on-list, preferably prior to next >>> Working Group call >>> >>> Notes: >>> >>> 1. Plan to complete in-progress tasks >>>> * ccTLD questions >>>>> * Small team has a list of 13 questions for ccTLD Registries >>>>> * Growing list of Registries, seeking contacts to reach out to them >>>>> * ACTION ITEM: Susan Kawaguchi to send list of questions to the full >>>>> Working Group for review, with the goal of finalizing the list for >>>>> transmission to selected ccTLDs following next WG call >>>>> * ACTION ITEM: Working Group members should review the questions, and send >>>>> any feedback on-list prior to next Working Group call >>>> * Definition of authoritative >>>>> * Small team has found the word "authoritative" to be confusing, and is >>>>> suggesting not using it >>>>> * Definition in the DNS context is not useful, conflict between legal and >>>>> technical use of the word >>>>> * Small team suggests that full Working Group attempt to find an >>>>> alternative word(s) to reflect concepts that the WG was trying reflect in >>>>> its statement of purpose >>>>> * ACTION ITEM: David Cake will communicate to the full Working Group by >>>>> the end of this week proposed definitions/concepts to replace the term >>>>> "authoritative" proposed new term(s) to reflect this >>>>> * ACTION ITEM: Working Group members should review the proposed term(s) >>>>> and definition(s) and provide any feedback on-list, preferably prior to >>>>> next Working Group call >>> 2. Revised Task 12 sequence and timeline >>> See >>> https://community.icann.org/download/attachments/56986784/RDSPDP-Task12-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@icann.org >>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg >> _______________________________________________ gnso-rds-pdp-wg mailing list >> gnso-rds-pdp-wg@icann.org >> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg