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/KeyConceptsDelibera >> tion-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-Revis >> ed21April2017.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-K >> eyConcepts-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-Revi >> sed-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/KeyConceptsDeliber >> ation-WorkingDraft-21April2017.pdf?version=1&modificationDate=1492966757152&a >> pi=v2> and doc >> <https://community.icann.org/download/attachments/56986791/KeyConceptsDeliber >> ation-WorkingDraft-21April2017.docx?version=1&modificationDate=1492966735704& >> api=v2> >> 4. ICANN58-Privacy-Panel-Responses-Draft-7April2017.pdf >> <https://community.icann.org/download/attachments/64078601/ICANN58-Privacy-Pa >> nel-Responses-Draft-7April2017.pdf?version=1&modificationDate=1491837560000&a >> pi=v2> and doc >> <https://community.icann.org/download/attachments/64078601/ICANN58-Privacy-Pa >> nel-Responses-Draft-7April2017.docx?version=1&modificationDate=1491839756000& >> 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-Revis >> ed21April2017.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-K >> eyConcepts-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
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<mailto:gnso-rds-pdp-wg-bounces@icann.org>> on behalf of "Gomes, Chuck via gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> Reply-To: "Gomes, Chuck" <cgomes@verisign.com<mailto:cgomes@verisign.com>> Date: Wednesday, April 26, 2017 at 12:05 AM To: "lisa@corecom.com<mailto:lisa@corecom.com>" <lisa@corecom.com<mailto:lisa@corecom.com>>, "amr.elsadr@icann.org<mailto:amr.elsadr@icann.org>" <amr.elsadr@icann.org<mailto:amr.elsadr@icann.org>>, "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: 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<mailto:cgomes@verisign.com>>; amr.elsadr@icann.org<mailto:amr.elsadr@icann.org>; gnso-rds-pdp-wg@icann.org<mailto: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<mailto: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... , 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... • 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-... * 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-Revi...> 2. NewSection5-Intro-KeyConcepts-21April2017.pdf<https://community.icann.org/download/attachments/64078605/NewSection5-Intro-...> - excerpted from 3. KeyConceptsDeliberation-WorkingDraft-21April2017.pdf<https://community.icann.org/download/attachments/56986791/KeyConceptsDeliber...> and doc<https://community.icann.org/download/attachments/56986791/KeyConceptsDeliber...> 4. ICANN58-Privacy-Panel-Responses-Draft-7April2017.pdf<https://community.icann.org/download/attachments/64078601/ICANN58-Privacy-Pa...> and doc<https://community.icann.org/download/attachments/64078601/ICANN58-Privacy-Pa...> 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<mailto: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... * 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-... * 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<mailto: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<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Captcha is an aspect of gating that we need to include in the discussions. This impacts the consistency of whois and ability to machine process the data for those without big wallets. On Apr 27, 2017 9:26 AM, "Gomes, Chuck via gnso-rds-pdp-wg" < gnso-rds-pdp-wg@icann.org> wrote:
Paul,
As became clear in our meeting earlier this week and the discussions that have followed, we will have to be very clear about what we mean by gated. It is my opinion right now that we will probably need to treat the following types of gating differently: operational gating such as rate limiting and Captcha and what you mention as ‘purpose’ gating. I think you are correct that these can be thought of as a form of gating but I don’t believe that they are what we need to focus on. I believe the Gated Access that we need to focus on relates to restricting access to certain categories of users to information that is not available to the general public.
Does that make sense?
Purpose based access is a key element of the EWG Report and the GDPR.
Chuck
*From:* Paul Keating [mailto:Paul@law.es] *Sent:* Wednesday, April 26, 2017 9:05 AM *To:* Gomes, Chuck <cgomes@verisign.com>; lisa@corecom.com; amr.elsadr@icann.org; gnso-rds-pdp-wg@icann.org *Subject:* [EXTERNAL] Re: [gnso-rds-pdp-wg] IMPORTANT: Action Items and Notes from Next-Generation RDS PDP Working Group Call - 25 April 2017
Chuck,
I am having issues with the language being used.
Gated to mean indicates ANY restriction to access. Thus, even a Captcha would be gated (albeit not a very strong gate).
It thus seems inconsistent to me to state:
No more anonymous access by anyone BUT
Some data will be available to everyone BUT only for legitimate purposes
Other data will be “gated”.
The requirement of a “legitimate” purpose is nothing but a gating concept.
When I read the EWG text there is no mention of “legitimacy” and thus whatever data set was recommended to be available to the public was without restriction action (e.g. No gate).
Thank you
*From: *<gnso-rds-pdp-wg-bounces@icann.org> on behalf of "Gomes, Chuck via gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> *Reply-To: *"Gomes, Chuck" <cgomes@verisign.com> *Date: *Wednesday, April 26, 2017 at 12:05 AM *To: *"lisa@corecom.com" <lisa@corecom.com>, "amr.elsadr@icann.org" < amr.elsadr@icann.org>, "gnso-rds-pdp-wg@icann.org" < gnso-rds-pdp-wg@icann.org> *Subject: *Re: [gnso-rds-pdp-wg] IMPORTANT: Action Items and Notes from Next-Generation RDS PDP Working Group Call - 25 April 2017
Thanks Lisa. I should have focused on the second sentence instead of just the first because the second sentence is clearer in my opinion.
Chuck
*From:* Lisa Phifer [mailto:lisa@corecom.com <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_6DCFB66DEEF3CF4D98FA55BCC43F15 2E74B23899BRN1WNEXMBX02vc_"
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 <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 <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/ KeyConceptsDeliberation-WorkingDraft-21April2017.pdf <https://community.icann.org/download/attachments/56986791/KeyConceptsDeliber...> , 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
1. 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-Revised21April2017.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) <https://community.icann.org/x/DcPRAw)>*
1. RDSPDP-Task12-Revised-21April2017.pdf <https://community.icann.org/download/attachments/56986784/RDSPDP-Task12-Revi...> 2. NewSection5-Intro-KeyConcepts-21April2017.pdf <https://community.icann.org/download/attachments/64078605/NewSection5-Intro-...> - excerpted from 3. KeyConceptsDeliberation-WorkingDraft-21April2017.pdf <https://community.icann.org/download/attachments/56986791/KeyConceptsDeliber...> and doc <https://community.icann.org/download/attachments/56986791/KeyConceptsDeliber...> 4. ICANN58-Privacy-Panel-Responses-Draft-7April2017.pdf <https://community.icann.org/download/attachments/64078601/ICANN58-Privacy-Pa...> and doc <https://community.icann.org/download/attachments/64078601/ICANN58-Privacy-Pa...>
*From: *< 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" < 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
1. Revised Task 12 sequence and timeline
See https://community.icann.org/download/attachments/56986784/ RDSPDP-Task12-Revised21April2017.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 <http://www.icann.org/en/about/governance/bylaws#AnnexA> - Possible to have a generic discussion on overall requirements for Gated Access before deciding which data elements will be public, and which will not - in that context, possible to defer discussion on "thin" vs "thick" - Start deliberation on the charter question/subquestion 5.1: Should gTLD registration “thin†data be entirely public or should access be controlled?
See https://community.icann.org/download/attachments/64078605/ NewSection5-Intro-KeyConcepts-21April2017.pdf
- When determining whether all “thin data†should be public or access to some data elements should be controlled in some way, A balance needs to be achieved between complying with applicable privacy/data protection legal requirements, and preventing abuse - GDPR will be enforced on contracted parties doing business with customers in the EU, so needs to be addressed using a flexible system that achieves a balance between compliance with applicable law and preventing abuse - cannot pick which laws the system will comply with - The Working Group needs to move beyond theoretical discussion, and address the specifics of the issue (practical examples) in order to answer this and other Charter questions. For example, are there some “thin data†elements that cannot be made public (published and accessible to anyone, for any reasons) in some jurisdictions? - Will the Working Group be able to address all concerns relating to all applicable legal jurisdictions? Does it need to in order to answer this charter question?
-- What are the guiding principles that should be used to determine level(s) of access (including law enforcement access)?
- From AC Chat: based on the discussion we’ve had to date, I believe all thin whois data should be publicly available as it is either not personally identifiable information, or, in extreme edge cases (such as a long domain name that includes personal information), then it is clear that that individual has chosen to make such information public. - Privacy concerns apply to users of the Internet, but do they apply to registrants of domain names in the same way? If you register a domain name, are you subject to responsibilities normally associated with owners of other kinds of property? Is there a higher bar that requires more from registrants - From AC Chat: to me, the answer is "both". it should be public, but controls for access should be available to limit rates and so on. Note that rate limits are today applied to entirely public access to WHOIS; rate limits could also be applied to gated access, but the charter question is really more about limiting who can access data and why as opposed to anyone accessing data for any reason. - From AC Chat: Regarding the publication of thin data: Depends - I see no need to publish it, but there may be technical arguments for it. After all, ownership of phone numbers is not [always] public, land ownership data is [sometimes] gated, even company registration data is gated in some countries and public in others - The concern raised above is whether there is a legitimate purpose for every data element. If there is no legitimate purpose for a given data element, it wouldn’t be published (publicly or otherwise).
-- Question to Working Group members: If the Working Group can identify legitimate purposes to collect "thin" data elements, are there reasons why any of those “thin data†elements should not be publicly displayed in a new RDS system as they are today in WHOIS? And if yes, why not?
- Reminder: This WG is basing deliberation on the Thick WHOIS Definition of "thin" data as a starting point: *A thin registry only stores and manages the information associated with the domain name. This set includes data sufficient to identify the sponsoring registrar, status of the registration, creation and expiration dates for each registration, name server data, the last time the record was updated in its Whois data store, and the URL for the registrar’s Whois service*. - Today's WHOIS publishes both "thin" and "thick" data elements, and allows anonymous WHOIS query to all of those data elements - Gated Access might limit access to both what data is accessible (e.g., for each purpose), as well as authenticating who is permitted this access. Rate limiting is a separate anti-abuse measure that can be applied to either public or gated access. - From the AC Chat: There are many ways one can "gate" access - but the question on the table is should access remain NON gated (that is, entirely public) - Reason for not displaying "thin" data publicly: Cannot answer the question without first determining whether there is a legitimate purpose that complies with applicable law to first collect the data - Can the need to publish "thin" data be satisfied by other technical means other than publicly displaying it? For example, cell phone numbers are unlisted and that doesn't cause problems even though landline phone numbers are listed. People find other ways to accomplish their objectives without a directory. Possibly this applies to domain name thin data? - There may be limitations in commercial purposes for access to data, depending upon jurisdiction and applicable law. - Question should be: Does one have a legitimate purpose in accessing the data? - Note: This is charter question UP. For now assume there is some “thin†data with legitimate purpose; charter question GA asks: Should access to that data remain entirely public? - Some believe that the only people who need access to "thin" data are the one's operating the domain name, but the reason why WHOIS "thin" data is publicly displayed is because other operators (operators of the infrastructure on the Internet) need the means to contact each other - possible reason for ungated public access to "thin" data - "thin" data that does not include personally identifiable information still has value in terms of access for those who would like to determine which registrar is the sponsoring registrar, and when the domain name was registered - was it registered prior to an associated trademark is registered, and does the trademark holder have a legitimate reason to seek contact with the domain name registrant? - The Working Group needs to answer the question of gated access to "thin" data using some assumptions, such as that there is a legitimate purpose in collection of "thin" data - In answer to this charter question, the EWG recommended that entirely public anonymous access by anyone for any purpose be abandoned. Instead, some data elements would be made public, to anyone for every legitimate purpose, while other data elements would be gated – that is, available to authenticcated requestors for authorized purposes only. Refer to the Working Document new Section 5 for a few relevant excerpts and key concepts from the EWG Report. - Confirm action items and proposed decision points
- Working Group members need to provide specific and concrete reasons why "thin" data elements should not be publicly displayed (under the assumption that there is a legitimate purpose to collect and process this data)
- Confirm next meeting date: 2 May 2017 at 16:00 UTC
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/ listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
I prefer Chuck’s approach. From: allison nixon <elsakoo@gmail.com> Date: Thursday, April 27, 2017 at 3:53 PM To: "Gomes, Chuck" <cgomes@verisign.com> Cc: "amr.elsadr@icann.org" <amr.elsadr@icann.org>, Paul Keating <paul@law.es>, "gnso-rds-pdp-wg@icann.org" <gnso-rds-pdp-wg@icann.org>, "lisa@corecom.com" <lisa@corecom.com> Subject: Re: [gnso-rds-pdp-wg] IMPORTANT: Action Items and Notes from Next-Generation RDS PDP Working Group Call - 25 April 2017 > > Captcha is an aspect of gating that we need to include in the discussions. > This impacts the consistency of whois and ability to machine process the data > for those without big wallets. > > On Apr 27, 2017 9:26 AM, "Gomes, Chuck via gnso-rds-pdp-wg" > <gnso-rds-pdp-wg@icann.org> wrote: >> Paul, >> >> As became clear in our meeting earlier this week and the discussions that >> have followed, we will have to be very clear about what we mean by gated. It >> is my opinion right now that we will probably need to treat the following >> types of gating differently: operational gating such as rate limiting and >> Captcha and what you mention as ‘purpose’ gating. I think you are correct >> that these can be thought of as a form of gating but I don’t believe that >> they are what we need to focus on. I believe the Gated Access that we need to >> focus on relates to restricting access to certain categories of users to >> information that is not available to the general public. >> >> Does that make sense? >> >> Purpose based access is a key element of the EWG Report and the GDPR. >> >> Chuck >> >> >> From: Paul Keating [mailto:Paul@law.es] >> Sent: Wednesday, April 26, 2017 9:05 AM >> To: Gomes, Chuck <cgomes@verisign.com>; lisa@corecom.com; >> amr.elsadr@icann.org; gnso-rds-pdp-wg@icann.org >> Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] IMPORTANT: Action Items and Notes >> from Next-Generation RDS PDP Working Group Call - 25 April 2017 >> >> >> Chuck, >> >> >> >> I am having issues with the language being used. >> >> >> >> Gated to mean indicates ANY restriction to access. Thus, even a Captcha >> would be gated (albeit not a very strong gate). >> >> >> >> It thus seems inconsistent to me to state: >> >> >> >> No more anonymous access by anyone BUT >> >> >> >> Some data will be available to everyone BUT only for legitimate purposes >> >> Other data will be “gated”. >> >> >> >> The requirement of a “legitimate” purpose is nothing but a gating concept. >> >> >> >> When I read the EWG text there is no mention of “legitimacy” and thus >> whatever data set was recommended to be available to the public was without >> restriction action (e.g. No gate). >> >> >> >> Thank you >> >> >> >> From: <gnso-rds-pdp-wg-bounces@icann.org> on behalf of "Gomes, Chuck via >> gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> >> Reply-To: "Gomes, Chuck" <cgomes@verisign.com> >> Date: Wednesday, April 26, 2017 at 12:05 AM >> To: "lisa@corecom.com" <lisa@corecom.com>, "amr.elsadr@icann.org" >> <amr.elsadr@icann.org>, "gnso-rds-pdp-wg@icann.org" >> <gnso-rds-pdp-wg@icann.org> >> Subject: Re: [gnso-rds-pdp-wg] IMPORTANT: Action Items and Notes from >> Next-Generation RDS PDP Working Group Call - 25 April 2017 >> >> >>> >>> Thanks Lisa. I should have focused on the second sentence instead of just >>> the first because the second sentence is clearer in my opinion. >>> >>> Chuck >>> >>> >>> From: Lisa Phifer [mailto:lisa@corecom.com] >>> Sent: Tuesday, April 25, 2017 5:59 PM >>> To: Gomes, Chuck <cgomes@verisign.com>; amr.elsadr@icann.org; >>> gnso-rds-pdp-wg@icann.org >>> Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] IMPORTANT: Action Items and Notes >>> from Next-Generation RDS PDP Working Group Call - 25 April 2017 >>> >>> Chuck, >>> >>> The bullet states that in the second sentence: >>> >>> In answer to this charter question, the EWG recommended that entirely public >>> anonymous access by anyone for any purpose be abandoned. Instead, some data >>> elements would be made public, to anyone for every legitimate purpose, while >>> other data elements would be gated – that is, avaailable to authenticated >>> requestors for authorized purposes only. Refer to the Working Document new >>> Section 5 for a few relevant excerpts and key concepts from the EWG Report. >>> >>> I paraphrased this bullet from the EWG Report excerpts that appear in the >>> new Section 5 in our working document, but perhaps I should have quoted the >>> EWG Report verbatim: >>> >>> "The EWG recommends that a new approach be taken for registration data >>> access, abandoning entirely anonymous access by everyone to everything in >>> favor of a new paradigm that combines public access to some data with gated >>> access to other data." >>> >>> This is further illustrated as "unauthenticated public registration data >>> access" and "gated registration data access" on pages 61-62 of the EWG >>> report. Apologies if my paraphrasing led to any confusion. >>> >>> Best, Lisa >>> >>> >>> >>> At 03:31 PM 4/25/2017, Gomes, Chuck via gnso-rds-pdp-wg wrote: >>> >>> >>>> >>>> Content-Language: en-US >>>> Content-Type: multipart/alternative; >>>> >>>> boundary="_000_6DCFB66DEEF3CF4D98FA55BCC43F152E74B23899BRN1WNEXMBX02vc_" >>>> >>>> Thanks Amr. The second to last bullet under item 3 below says “the EWG >>>> recommended that entirely public anonymous access by anyone for any purpose >>>> be abandoned†. I am not sure that this is worded accurately; it could be >>>> interpreted to mean that the EWG recommended that no data elements should >>>> be anonymously accessible by anyone and I do not believe that the EWG said >>>> that. I think they said that “the practice of anonymous public access >>>> for all data elements should be abandoned†. >>>> >>>> I invite those who were on the EWG to correct me if I am wrong. >>>> >>>> Chuck >>>> >>>> From: gnso-rds-pdp-wg-bounces@icann.org [ >>>> mailto:gnso-rds-pdp-wg-bounces@icann.org >>>> <mailto:gnso-rds-pdp-wg-bounces@icann.org> ] On Behalf Of Amr Elsadr >>>> Sent: Tuesday, April 25, 2017 3:50 PM >>>> To: gnso-rds-pdp-wg@icann.org >>>> Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] IMPORTANT: Action Items and Notes >>>> from Next-Generation RDS PDP Working Group Call - 25 April 2017 >>>> Importance: High >>>> >>>> Hello again, >>>> >>>> Apologies for the duplication and any confusion, but some revisions in the >>>> Action Items and Notes below. Please disregard the first set. >>>> >>>> Thanks again. >>>> >>>> Amr >>>> >>>> >>>> These high-level notes are designed to help PDP WG members navigate through >>>> the content of the call and are not meant as a substitute for the >>>> transcript and/or recording. The MP3, transcript, and chat are provided >>>> separately and are posted on the wiki here: >>>> https://community.icann.org/x/DcPRAw >>>> >>>> Action Items: >>>> >>>> 1. Susan Kawaguchi to send list of questions to the full Working Group for >>>> review following the Working Group call, with the goal of finalizing the >>>> list for transmission to selected ccTLDs following next WG call >>>> 2. Working Group members should review the proposed questions to ccTLD >>>> operators, and send any feedback on-list prior to next Working Group call >>>> 3. David Cake will communicate to the full Working Group by the end of this >>>> week proposed definitions/concepts to replace the term "authoritative" >>>> proposed new term(s) to reflect this >>>> 4. Working Group members should review the proposed term(s) and >>>> definition(s) and provide any feedback on-list, preferably prior to next >>>> Working Group call >>>> 5. all WG members to review the new section 5 found here: >>>> https://community.icann.org/download/attachments/56986791/KeyConceptsDelibe >>>> ration-WorkingDraft-21April2017.pdf , which reflects how the EWG broke >>>> apart this complex question into a few key concepts >>>> >>>> Notes: >>>> >>>> 1. Plan to complete in-progress tasks >>>>> 1. ccTLD questions >>>>>> * Small team has a list of 13 questions for ccTLD Registries >>>>>> * Growing list of Registries, seeking contacts to reach out to them >>>>>> * ACTION ITEM: Susan Kawaguchi to send list of questions to the full >>>>>> Working Group for review, with the goal of finalizing the list for >>>>>> transmission to selected ccTLDs following next WG call >>>>>> * ACTION ITEM: Working Group members should review the questions, and >>>>>> send any feedback on-list prior to next Working Group call >>>>> 2. Definition of authoritative >>>>>> * Small team has found the word "authoritative" to be confusing, and is >>>>>> suggesting not using it >>>>>> * Definition in the DNS context is not useful, conflict between legal and >>>>>> technical use of the word >>>>>> * Small team suggests that full Working Group attempt to find an >>>>>> alternative word(s) to reflect concepts that the WG was trying reflect in >>>>>> its statement of purpose >>>>>> * ACTION ITEM: David Cake will communicate to the full Working Group by >>>>>> the end of this week proposed definitions/concepts to replace the term >>>>>> "authoritative" proposed new term(s) to reflect this >>>>>> * ACTION ITEM: Working Group members should review the proposed term(s) >>>>>> and definition(s) and provide any feedback on-list, preferably prior to >>>>>> next Working Group call >>>> 3. Revised Task 12 sequence and timeline >>>> See >>>> https://community.icann.org/download/attachments/56986784/RDSPDP-Task12-Rev >>>> ised21April2017.pdf >>>> §Slide 1 has the Phase 1 workflow as agreed to in the WG’s work plan and >>>> reviewed in Hyderabad to first address the 5 charter questions, in order to >>>> answer the foundational question: whether a next-generation RDS needs to be >>>> developed or whether the existing WHOIS can be modified. These >>>> recommendations will be reflected in a first Initial Report to be >>>> distributed for Public Comment. The WG will then move on to consider the >>>> next 6 charter questions, producing a second Initial Report for Public >>>> Comment. Only after those reports are produced will the WG try to reach >>>> formal consensus to conclude Phase 1. Only if Phase 1 recommends that a >>>> Next-Gen RDS is needed, and the GNSO Council agrees, will the PDP move on >>>> to Phases 2/3 to develop policies and implementation/coexistence guidance >>>> for a Next-Gen RDS. >>>> §Slide 2 shows the Task 12 subtasks in order that the Working Group will be >>>> attempting to address them (including key concepts on possible requirements >>>> for users/purposes, data elements and privacy of "thin" data discussed thus >>>> far in Task 12.a) >>>> §Working Group has had difficulty in agreeing on key concepts without >>>> knowing what kind of access will be permitted --> Working Group Leadership >>>> has adjusted workplan to address Gated Access now as Task 12.b, then >>>> revisit users/purpose, data elements and privacy in Task 12.c. This >>>> re-ordering is in response to input from many WG members, to stop deferring >>>> the difficult question of whether all data will remain public, so that more >>>> progress can be made on other questions, based on the answer to 12.b. >>>> §Slide 3 details target dates by which Working Group should try to reach >>>> rough consensus on answers to the first 5 questions prior to taking a >>>> second pass to frame key concepts as draft requirements, to be reflected in >>>> the first initial report which we hope to start drafting by ICANN60 >>>> §WG members expressed different points of view on whether to focus first on >>>> “thin†data only or to address access to “thin†and “thick†at >>>> the same time. If the Working Group stumbles on addressing access to "thin" >>>> data alone, Working Group may adjust plan to address access to both "thin" >>>> and "thick" data in Task 12.b. >>>> §Deliberation on the charter question of gated access (balancing proposed >>>> privacy and access requirements) will be done by the Working Group - goal >>>> is to base Working Group decisions on rough consensus agreements for >>>> fundamental requirements, including objective data (example: applicable >>>> legal requirements) >>>> §Refer to Working Group Charter on "rules of engagement" in order to settle >>>> differences of opinion: >>>> https://community.icann.org/display/gTLDRDS/WG+Charter >>>> §For further guidance on how the PDP process is designed to deliberation >>>> upon multiple varying viewpoints to reach consensus policy recommendations, >>>> see also GNSO PDP Process: >>>> http://www.icann.org/en/about/governance/bylaws#AnnexA >>>> §Possible to have a generic discussion on overall requirements for Gated >>>> Access before deciding which data elements will be public, and which will >>>> not - in that context, possible to defer discussion on "thin" vs "thick" >>>> §Start deliberation on the charter question/subquestion 5.1: Should gTLD >>>> registration “thin†data be entirely public or should access be >>>> controlled? >>>> See >>>> https://community.icann.org/download/attachments/64078605/NewSection5-Intro >>>> -KeyConcepts-21April2017.pdf >>>> * When determining whether all “thin data†should be public or access >>>> to some data elements should be controlled in some way, A balance needs to >>>> be achieved between complying with applicable privacy/data protection legal >>>> requirements, and preventing abuse >>>> * GDPR will be enforced on contracted parties doing business with customers >>>> in the EU, so needs to be addressed using a flexible system that achieves a >>>> balance between compliance with applicable law and preventing abuse - >>>> cannot pick which laws the system will comply with >>>> * The Working Group needs to move beyond theoretical discussion, and >>>> address the specifics of the issue (practical examples) in order to answer >>>> this and other Charter questions. For example, are there some “thin >>>> data†elements that cannot be made public (published and accessible to >>>> anyone, for any reasons) in some jurisdictions? >>>> * Will the Working Group be able to address all concerns relating to all >>>> applicable legal jurisdictions? Does it need to in order to answer this >>>> charter question? >>>> >>>> -- What are the guiding principles that should be used to determine >>>> level(s) of access (including law enforcement access)? >>>> * From AC Chat: based on the discussion we’ve had to date, I believe all >>>> thin whois data should be publicly available as it is either not personally >>>> identifiable information, or, in extreme edge cases (such as a long domain >>>> name that includes personal information), then it is clear that that >>>> individual has chosen to make such information public. >>>> * Privacy concerns apply to users of the Internet, but do they apply to >>>> registrants of domain names in the same way? If you register a domain name, >>>> are you subject to responsibilities normally associated with owners of >>>> other kinds of property? Is there a higher bar that requires more from >>>> registrants >>>> * From AC Chat: to me, the answer is "both". it should be public, but >>>> controls for access should be available to limit rates and so on. Note >>>> that rate limits are today applied to entirely public access to WHOIS; rate >>>> limits could also be applied to gated access, but the charter question is >>>> really more about limiting who can access data and why as opposed to anyone >>>> accessing data for any reason. >>>> * From AC Chat: Regarding the publication of thin data: Depends - I see no >>>> need to publish it, but there may be technical arguments for it. After all, >>>> ownership of phone numbers is not [always] public, land ownership data is >>>> [sometimes] gated, even company registration data is gated in some >>>> countries and public in others >>>> * The concern raised above is whether there is a legitimate purpose for >>>> every data element. If there is no legitimate purpose for a given data >>>> element, it wouldn’t be published (publicly or otherwise). >>>> >>>> -- Question to Working Group members: If the Working Group can identify >>>> legitimate purposes to collect "thin" data elements, are there reasons why >>>> any of those “thin data†elements should not be publicly displayed in a >>>> new RDS system as they are today in WHOIS? And if yes, why not? >>>> * Reminder: This WG is basing deliberation on the Thick WHOIS Definition of >>>> "thin" data as a starting point: A thin registry only stores and manages >>>> the information associated with the domain name. This set includes data >>>> sufficient to identify the sponsoring registrar, status of the >>>> registration, creation and expiration dates for each registration, name >>>> server data, the last time the record was updated in its Whois data store, >>>> and the URL for the registrar’s Whois service. >>>> * Today's WHOIS publishes both "thin" and "thick" data elements, and allows >>>> anonymous WHOIS query to all of those data elements - Gated Access might >>>> limit access to both what data is accessible (e.g., for each purpose), as >>>> well as authenticating who is permitted this access. Rate limiting is a >>>> separate anti-abuse measure that can be applied to either public or gated >>>> access. >>>> * From the AC Chat: There are many ways one can "gate" access - but the >>>> question on the table is should access remain NON gated (that is, entirely >>>> public) >>>> * Reason for not displaying "thin" data publicly: Cannot answer the >>>> question without first determining whether there is a legitimate purpose >>>> that complies with applicable law to first collect the data >>>> * Can the need to publish "thin" data be satisfied by other technical means >>>> other than publicly displaying it? For example, cell phone numbers are >>>> unlisted and that doesn't cause problems even though landline phone numbers >>>> are listed. People find other ways to accomplish their objectives without a >>>> directory. Possibly this applies to domain name thin data? >>>> * There may be limitations in commercial purposes for access to data, >>>> depending upon jurisdiction and applicable law. - Question should be: Does >>>> one have a legitimate purpose in accessing the data? >>>> * Note: This is charter question UP. For now assume there is some “thin†>>>> data with legitimate purpose; charter question GA asks: Should access to >>>> that data remain entirely public? >>>> * Some believe that the only people who need access to "thin" data are the >>>> one's operating the domain name, but the reason why WHOIS "thin" data is >>>> publicly displayed is because other operators (operators of the >>>> infrastructure on the Internet) need the means to contact each other - >>>> possible reason for ungated public access to "thin" data >>>> * "thin" data that does not include personally identifiable information >>>> still has value in terms of access for those who would like to determine >>>> which registrar is the sponsoring registrar, and when the domain name was >>>> registered - was it registered prior to an associated trademark is >>>> registered, and does the trademark holder have a legitimate reason to seek >>>> contact with the domain name registrant? >>>> * The Working Group needs to answer the question of gated access to "thin" >>>> data using some assumptions, such as that there is a legitimate purpose in >>>> collection of "thin" data >>>> * In answer to this charter question, the EWG recommended that entirely >>>> public anonymous access by anyone for any purpose be abandoned. Instead, >>>> some data elements would be made public, to anyone for every legitimate >>>> purpose, while other data elements would be gated – that is, available to >>>> aauthenticated requestors for authorized purposes only. Refer to the >>>> Working Document new Section 5 for a few relevant excerpts and key concepts >>>> from the EWG Report. >>>> * Working Group members need to provide specific and concrete reasons why >>>> "thin" data elements should not be publicly displayed (under the assumption >>>> that there is a legitimate purpose to collect and process this data) >>>> * Confirm next meeting date: 2 May 2017 at 16:00 UTC >>>> >>>> >>>> Meeting Materials (all posted at https://community.icann.org/x/DcPRAw) >>>> 1. RDSPDP-Task12-Revised-21April2017.pdf >>>> <https://community.icann.org/download/attachments/56986784/RDSPDP-Task12-Re >>>> vised-21April2017.pdf?version=1&modificationDate=1492802630734&api=v2> >>>> 2. NewSection5-Intro-KeyConcepts-21April2017.pdf >>>> <https://community.icann.org/download/attachments/64078605/NewSection5-Intr >>>> o-KeyConcepts-21April2017.pdf?version=1&modificationDate=1492802791000&api= >>>> v2> - excerpted from >>>> 3. KeyConceptsDeliberation-WorkingDraft-21April2017.pdf >>>> <https://community.icann.org/download/attachments/56986791/KeyConceptsDelib >>>> eration-WorkingDraft-21April2017.pdf?version=1&modificationDate=14929667571 >>>> 52&api=v2> and doc >>>> <https://community.icann.org/download/attachments/56986791/KeyConceptsDelib >>>> eration-WorkingDraft-21April2017.docx?version=1&modificationDate=1492966735 >>>> 704&api=v2> >>>> 4. ICANN58-Privacy-Panel-Responses-Draft-7April2017.pdf >>>> <https://community.icann.org/download/attachments/64078601/ICANN58-Privacy- >>>> Panel-Responses-Draft-7April2017.pdf?version=1&modificationDate=14918375600 >>>> 00&api=v2> and doc >>>> <https://community.icann.org/download/attachments/64078601/ICANN58-Privacy- >>>> Panel-Responses-Draft-7April2017.docx?version=1&modificationDate=1491839756 >>>> 000&api=v2> >>>> >>>> >>>> From: < gnso-rds-pdp-wg-bounces@icann.org >>>> <mailto:gnso-rds-pdp-wg-bounces@icann.org> > on behalf of Amr Elsadr >>>> <amr.elsadr@icann.org> >>>> Date: Tuesday, April 25, 2017 at 9:15 PM >>>> To: " gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> " < >>>> gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> > >>>> Subject: [gnso-rds-pdp-wg] IMPORTANT: Action Items and Notes from >>>> Next-Generation RDS PDP Working Group Call - 25 April 2017 >>>> >>>> Dear Working Group Members, >>>> >>>> Below are the Action Items and Notes from today’s call. Please keep an >>>> eye out for emails from Susan Kawaguchi concerning the proposed questions >>>> to ccTLD registry operators’ measures to comply with the GDPR, as well as >>>> from David Cake on an update regarding the Working Group’s working >>>> definition of “authoritative†. >>>> >>>> Thanks. >>>> >>>> Amr >>>> >>>> >>>> Action Items: >>>> >>>> 1. Susan Kawaguchi to send list of questions to the full Working Group for >>>> review following the Working Group call, with the goal of finalizing the >>>> list for transmission to selected ccTLDs following next WG call >>>> 2. Working Group members should review the proposed questions to ccTLD >>>> operators, and send any feedback on-list prior to next Working Group call >>>> 3. David Cake will communicate to the full Working Group by the end of this >>>> week proposed definitions/concepts to replace the term "authoritative" >>>> proposed new term(s) to reflect this >>>> 4. Working Group members should review the proposed term(s) and >>>> definition(s) and provide any feedback on-list, preferably prior to next >>>> Working Group call >>>> >>>> Notes: >>>> >>>> 1. Plan to complete in-progress tasks >>>>> * ccTLD questions >>>>>> * Small team has a list of 13 questions for ccTLD Registries >>>>>> * Growing list of Registries, seeking contacts to reach out to them >>>>>> * ACTION ITEM: Susan Kawaguchi to send list of questions to the full >>>>>> Working Group for review, with the goal of finalizing the list for >>>>>> transmission to selected ccTLDs following next WG call >>>>>> * ACTION ITEM: Working Group members should review the questions, and >>>>>> send any feedback on-list prior to next Working Group call >>>>> * Definition of authoritative >>>>>> * Small team has found the word "authoritative" to be confusing, and is >>>>>> suggesting not using it >>>>>> * Definition in the DNS context is not useful, conflict between legal and >>>>>> technical use of the word >>>>>> * Small team suggests that full Working Group attempt to find an >>>>>> alternative word(s) to reflect concepts that the WG was trying reflect in >>>>>> its statement of purpose >>>>>> * ACTION ITEM: David Cake will communicate to the full Working Group by >>>>>> the end of this week proposed definitions/concepts to replace the term >>>>>> "authoritative" proposed new term(s) to reflect this >>>>>> * ACTION ITEM: Working Group members should review the proposed term(s) >>>>>> and definition(s) and provide any feedback on-list, preferably prior to >>>>>> next Working Group call >>>> 2. Revised Task 12 sequence and timeline >>>> See >>>> https://community.icann.org/download/attachments/56986784/RDSPDP-Task12-Rev >>>> ised21April2017.pdf >>>> * Slide 1 has the Phase 1 workflow as agreed to in the WG’s work plan and >>>> reviewed in Hyderabad to first address the 5 charter questions, in order to >>>> answer the foundational question: whether a next-generation RDS needs to be >>>> developed or whether the existing WHOIS can be modified. These >>>> recommendations will be reflected in a first Initial Report to be >>>> distributed for Public Comment. The WG will then move on to consider the >>>> next 6 charter questions, producing a second Initial Report for Public >>>> Comment. Only after those reports are produced will the WG try to reach >>>> formal consensus to conclude Phase 1. Only if Phase 1 recommends that a >>>> Next-Gen RDS is needed, and the GNSO Council agrees, will the PDP move on >>>> to Phases 2/3 to develop policies and implementation/coexistence guidance >>>> for a Next-Gen RDS. >>>> * Slide 2 shows the Task 12 subtasks in order that the Working Group will >>>> be attempting to address them (including key concepts on possible >>>> requirements for users/purposes, data elements and privacy of "thin" data >>>> discussed thus far in Task 12.a) >>>> * Working Group has had difficulty in agreeing on key concepts without >>>> knowing what kind of access will be permitted --> Working Group Leadership >>>> has adjusted workplan to address Gated Access now as Task 12.b, then >>>> revisit users/purpose, data elements and privacy in Task 12.c. This >>>> re-ordering is in response to input from many WG members, to stop deferring >>>> the difficult question of whether all data will remain public, so that more >>>> progress can be made on other questions, based on the answer to 12.b. >>>> * Slide 3 details target dates by which Working Group should try to reach >>>> rough consensus on answers to the first 5 questions prior to taking a >>>> second pass to frame key concepts as draft requirements, to be reflected in >>>> the first initial report which we hope to start drafting by ICANN60 >>>> * WG members expressed different points of view on whether to focus first >>>> on “thin†data only or to address access to “thin†and “thick†>>>> at the same time. If the Working Group stumbles on addressing access to >>>> "thin" data alone, Working Group may adjust plan to address access to both >>>> "thin" and "thick" data in Task 12.b. >>>> * Deliberation on the charter question of gated access (balancing proposed >>>> privacy and access requirements) will be done by the Working Group - goal >>>> is to base Working Group decisions on rough consensus agreements for >>>> fundamental requirements, including objective data (example: applicable >>>> legal requirements) >>>> * Refer to Working Group Charter on "rules of engagement" in order to >>>> settle differences of opinion: >>>> https://community.icann.org/display/gTLDRDS/WG+Charter >>>> * For further guidance on how the PDP process is designed to deliberation >>>> upon multiple varying viewpoints to reach consensus policy recommendations, >>>> see also GNSO PDP Process: >>>> http://www.icann.org/en/about/governance/bylaws#AnnexA >>>> * Possible to have a generic discussion on overall requirements for Gated >>>> Access before deciding which data elements will be public, and which will >>>> not - in that context, possible to defer discussion on "thin" vs "thick" >>>> * Start deliberation on the charter question/subquestion 5.1: Should gTLD >>>> registration “thin†data be entirely public or should access be >>>> controlled? >>>> See >>>> https://community.icann.org/download/attachments/64078605/NewSection5-Intro >>>> -KeyConcepts-21April2017.pdf >>>> * When determining whether all “thin data†should be public or access >>>> to some data elements should be controlled in some way, A balance needs to >>>> be achieved between complying with applicable privacy/data protection legal >>>> requirements, and preventing abuse >>>> * GDPR will be enforced on contracted parties doing business with customers >>>> in the EU, so needs to be addressed using a flexible system that achieves a >>>> balance between compliance with applicable law and preventing abuse - >>>> cannot pick which laws the system will comply with >>>> * The Working Group needs to move beyond theoretical discussion, and >>>> address the specifics of the issue (practical examples) in order to answer >>>> this and other Charter questions. For example, are there some “thin >>>> data†elements that cannot be made public (published and accessible to >>>> anyone, for any reasons) in some jurisdictions? >>>> * Will the Working Group be able to address all concerns relating to all >>>> applicable legal jurisdictions? Does it need to in order to answer this >>>> charter question? >>>> >>>> -- What are the guiding principles that should be used to determine >>>> level(s) of access (including law enforcement access)? >>>> * From AC Chat: based on the discussion we’ve had to date, I believe all >>>> thin whois data should be publicly available as it is either not personally >>>> identifiable information, or, in extreme edge cases (such as a long domain >>>> name that includes personal information), then it is clear that that >>>> individual has chosen to make such information public. >>>> * Privacy concerns apply to users of the Internet, but do they apply to >>>> registrants of domain names in the same way? If you register a domain name, >>>> are you subject to responsibilities normally associated with owners of >>>> other kinds of property? Is there a higher bar that requires more from >>>> registrants >>>> * From AC Chat: to me, the answer is "both". it should be public, but >>>> controls for access should be available to limit rates and so on. Note >>>> that rate limits are today applied to entirely public access to WHOIS; rate >>>> limits could also be applied to gated access, but the charter question is >>>> really more about limiting who can access data and why as opposed to anyone >>>> accessing data for any reason. >>>> * From AC Chat: Regarding the publication of thin data: Depends - I see no >>>> need to publish it, but there may be technical arguments for it. After all, >>>> ownership of phone numbers is not [always] public, land ownership data is >>>> [sometimes] gated, even company registration data is gated in some >>>> countries and public in others >>>> * The concern raised above is whether there is a legitimate purpose for >>>> every data element. If there is no legitimate purpose for a given data >>>> element, it wouldn’t be published (publicly or otherwise). >>>> >>>> -- Question to Working Group members: If the Working Group can identify >>>> legitimate purposes to collect "thin" data elements, are there reasons why >>>> any of those “thin data†elements should not be publicly displayed in a >>>> new RDS system as they are today in WHOIS? And if yes, why not? >>>> * Reminder: This WG is basing deliberation on the Thick WHOIS Definition of >>>> "thin" data as a starting point: A thin registry only stores and manages >>>> the information associated with the domain name. This set includes data >>>> sufficient to identify the sponsoring registrar, status of the >>>> registration, creation and expiration dates for each registration, name >>>> server data, the last time the record was updated in its Whois data store, >>>> and the URL for the registrar’s Whois service. >>>> * Today's WHOIS publishes both "thin" and "thick" data elements, and allows >>>> anonymous WHOIS query to all of those data elements - Gated Access might >>>> limit access to both what data is accessible (e.g., for each purpose), as >>>> well as authenticating who is permitted this access. Rate limiting is a >>>> separate anti-abuse measure that can be applied to either public or gated >>>> access. >>>> * From the AC Chat: There are many ways one can "gate" access - but the >>>> question on the table is should access remain NON gated (that is, entirely >>>> public) >>>> * Reason for not displaying "thin" data publicly: Cannot answer the >>>> question without first determining whether there is a legitimate purpose >>>> that complies with applicable law to first collect the data >>>> * Can the need to publish "thin" data be satisfied by other technical means >>>> other than publicly displaying it? For example, cell phone numbers are >>>> unlisted and that doesn't cause problems even though landline phone numbers >>>> are listed. People find other ways to accomplish their objectives without a >>>> directory. Possibly this applies to domain name thin data? >>>> * There may be limitations in commercial purposes for access to data, >>>> depending upon jurisdiction and applicable law. - Question should be: Does >>>> one have a legitimate purpose in accessing the data? >>>> * Note: This is charter question UP. For now assume there is some “thin†>>>> data with legitimate purpose; charter question GA asks: Should access to >>>> that data remain entirely public? >>>> * Some believe that the only people who need access to "thin" data are the >>>> one's operating the domain name, but the reason why WHOIS "thin" data is >>>> publicly displayed is because other operators (operators of the >>>> infrastructure on the Internet) need the means to contact each other - >>>> possible reason for ungated public access to "thin" data >>>> * "thin" data that does not include personally identifiable information >>>> still has value in terms of access for those who would like to determine >>>> which registrar is the sponsoring registrar, and when the domain name was >>>> registered - was it registered prior to an associated trademark is >>>> registered, and does the trademark holder have a legitimate reason to seek >>>> contact with the domain name registrant? >>>> * The Working Group needs to answer the question of gated access to "thin" >>>> data using some assumptions, such as that there is a legitimate purpose in >>>> collection of "thin" data >>>> * In answer to this charter question, the EWG recommended that entirely >>>> public anonymous access by anyone for any purpose be abandoned. Instead, >>>> some data elements would be made public, to anyone for every legitimate >>>> purpose, while other data elements would be gated – that is, available to >>>> authenticcated requestors for authorized purposes only. Refer to the >>>> Working Document new Section 5 for a few relevant excerpts and key concepts >>>> from the EWG Report. >>>> * Confirm action items and proposed decision points >>>>> * Working Group members need to provide specific and concrete reasons why >>>>> "thin" data elements should not be publicly displayed (under the >>>>> assumption that there is a legitimate purpose to collect and process this >>>>> data) >>>> * Confirm next meeting date: 2 May 2017 at 16:00 UTC >>>> >>>> _______________________________________________ >>>> gnso-rds-pdp-wg mailing list >>>> gnso-rds-pdp-wg@icann.org >>>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg >>> _______________________________________________ gnso-rds-pdp-wg mailing list >>> gnso-rds-pdp-wg@icann.org >>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg >> >> _______________________________________________ >> gnso-rds-pdp-wg mailing list >> gnso-rds-pdp-wg@icann.org >> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
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
participants (3)
-
allison nixon -
Gomes, Chuck -
Paul Keating