October 2019 - Gnso-epdp-team

FW: Updated Language Regarding Purposes
by Margie Milam Oct. 10, 2019

Oct. 10, 2019

Ugh—suggestions for dealing with this? From: Amr Elsadr <aelsadr(a)icannpolicy.ninja> Reply-To: Amr Elsadr <aelsadr(a)icannpolicy.ninja> Date: Wednesday, October 9, 2019 at 4:34 AM To: Margie Milam <margiemilam(a)fb.com> Subject: Re: Updated Language Regarding Purposes Hi Margie, Thanks for this. I’m still having trouble with the reference to Article 5.1.b, and its applicability here. The ICO guidance on the purpose limitation principle has only reinforced this (https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-…<https://urldefense.proofpoint.com/v2/url?u=https-3A__ico.org.uk_for-2Dorgan…>). The explanation of what the principle is, as well as the checklist associated with it all indicate to me that it is applicable to the Data Controller, not a 3rd party/Requestor for disclosure/access. My thinking is that if we are to proceed as you have suggested in your email below, the process needs to loop in the Data Controller, somehow. Some reasons why this might be necessary: 1. It shouldn’t be up to the 3rd party to determine what additional purposes are or are not compatible. Ultimately, the Data Controller and Processor will be held accountable by the data subject, and possibly liable by a DPA for errors in judgment on this, so should be looped in. 2. If the Controller is not (at a minimum) informed of additional purposes for which the personal data will be processed, I’m not sure how the Controller will track and keep records of how the data that was disclosed will be or was processed. 3. If the Data Subject requests access to a report on how its personal data has been processed, it would need to make this request to the Controller with which it is familiar (likely the registrar). If the Controller is not involved in the decision to process the personal data for additional compatible purposes, it will not be in a position to provide the Data Subject with a complete report on how the data was, or is being, processed, at least not until (or if) an audit is conducted. So let’s say there is a scenario where a Requestor has been granted disclosure/access to the personal data for a specific purpose, then discovers that there is(are) additional purpose(s) for which the personal data needs to be processed further. This could be for compatible purposes, or other unrelated ones (but still fulfilling the requirements of a legitimate interest of the Requestor and supported by a legal basis). It’d make sense to me, that in this kind of scenario, some follow-up to the original request for disclosure be available where the Requestor communicates the need for further processing in the SSAD, and that there is some need for the Controller to make a decision on wether to grant permission for this additional processing. Also, since this would be a follow-up to a previously approved disclosure request, it might make sense that the follow-up is flagged for a quicker response time of the request for additional processing of the personal data for additional purposes (compatible or unrelated). This could possibly be reflected in Building Blocks G and K? I know this adds an administrative layer, and slightly slows things down, but it provides more certainty in the process as a whole, doesn’t it? I believe it would be necessary in order to protect the rights of all parties involved, as well as provide the transparency in processing that you referred to in your proposed amendment to subsection C of Building Block D. If you agree with any of this, in principle, we can try some wordsmithing of the proposed amendment. If you have concerns, let’s try to address them first. Thanks again, Margie. Amr On Oct 8, 2019, at 6:53 PM, Margie Milam <margiemilam(a)fb.com<mailto:margiemilam@fb.com>> wrote: Hi Amr – Following up on today’s homework – here’s a link to information from the UK Information Office that can help guide the drafting of this section: https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-…<https://urldefense.proofpoint.com/v2/url?u=https-3A__ico.org.uk_for-2Dorgan…> Here’s what I suggest: The building block should use this language: “not incompatible with the original purpose, provided the new purpose is fair, lawful and transparent.” The policy recommendation would also need to include specific disclosures to the registrant, describing the common purposes for 3rd party access, so that the transparency requirement is met. Margie

4 3

RySG comments on lawful basis matrix
by Crossman, Matthew Oct. 10, 2019

Oct. 10, 2019

All, Attached are the RySG comments on the lawful basis / building blocks matrix. Best, Matt Matthew Crossman | Amazon Corporate Counsel gTLD Registry, IP P: 206-266-1103 | C: 530-574-2956 Email: mmcross(a)amazon.com<mailto:mmcross@amazon.com>

1 0

Re: [Gnso-epdp-team] Updated Language Regarding Purposes
by Margie Milam Oct. 9, 2019

Oct. 9, 2019

Message Recall Sent from my iPhone > On Oct 9, 2019, at 11:37 AM, Margie Milam <margiemilam(a)fb.com> wrote: >

1 0

Re: [Gnso-epdp-team] FW: Updated Language Regarding Purposes
by James M. Bladel Oct. 9, 2019

Oct. 9, 2019

Not sure about everyone, but I plan to read (after lunch, of course) and maybe tee up some question for Amr during our call tomorrow. J. ------------- James Bladel GoDaddy From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of Margie Milam <margiemilam(a)fb.com> Date: Wednesday, October 9, 2019 at 13:37 To: "Mark Svancarek (CELA) via Gnso-epdp-team" <gnso-epdp-team(a)icann.org>, "King, Brian" <Brian.King(a)markmonitor.com>, "alexATcolevalleyconsulting.com" <alex(a)colevalleyconsulting.com>, "sdelbiancoATnetchoice.org" <sdelbianco(a)netchoice.org>, Jennifer Gore <Jennifer(a)winterfeldt.law> Subject: [Gnso-epdp-team] FW: Updated Language Regarding Purposes Notice: This email is from an external sender. Ugh—suggestions for dealing with this? From: Amr Elsadr <aelsadr(a)icannpolicy.ninja> Reply-To: Amr Elsadr <aelsadr(a)icannpolicy.ninja> Date: Wednesday, October 9, 2019 at 4:34 AM To: Margie Milam <margiemilam(a)fb.com> Subject: Re: Updated Language Regarding Purposes Hi Margie, Thanks for this. I’m still having trouble with the reference to Article 5.1.b, and its applicability here. The ICO guidance on the purpose limitation principle has only reinforced this (https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-…<https://urldefense.proofpoint.com/v2/url?u=https-3A__ico.org.uk_for-2Dorgan…>). The explanation of what the principle is, as well as the checklist associated with it all indicate to me that it is applicable to the Data Controller, not a 3rd party/Requestor for disclosure/access. My thinking is that if we are to proceed as you have suggested in your email below, the process needs to loop in the Data Controller, somehow. Some reasons why this might be necessary: 1. It shouldn’t be up to the 3rd party to determine what additional purposes are or are not compatible. Ultimately, the Data Controller and Processor will be held accountable by the data subject, and possibly liable by a DPA for errors in judgment on this, so should be looped in. 2. If the Controller is not (at a minimum) informed of additional purposes for which the personal data will be processed, I’m not sure how the Controller will track and keep records of how the data that was disclosed will be or was processed. 3. If the Data Subject requests access to a report on how its personal data has been processed, it would need to make this request to the Controller with which it is familiar (likely the registrar). If the Controller is not involved in the decision to process the personal data for additional compatible purposes, it will not be in a position to provide the Data Subject with a complete report on how the data was, or is being, processed, at least not until (or if) an audit is conducted. So let’s say there is a scenario where a Requestor has been granted disclosure/access to the personal data for a specific purpose, then discovers that there is(are) additional purpose(s) for which the personal data needs to be processed further. This could be for compatible purposes, or other unrelated ones (but still fulfilling the requirements of a legitimate interest of the Requestor and supported by a legal basis). It’d make sense to me, that in this kind of scenario, some follow-up to the original request for disclosure be available where the Requestor communicates the need for further processing in the SSAD, and that there is some need for the Controller to make a decision on wether to grant permission for this additional processing. Also, since this would be a follow-up to a previously approved disclosure request, it might make sense that the follow-up is flagged for a quicker response time of the request for additional processing of the personal data for additional purposes (compatible or unrelated). This could possibly be reflected in Building Blocks G and K? I know this adds an administrative layer, and slightly slows things down, but it provides more certainty in the process as a whole, doesn’t it? I believe it would be necessary in order to protect the rights of all parties involved, as well as provide the transparency in processing that you referred to in your proposed amendment to subsection C of Building Block D. If you agree with any of this, in principle, we can try some wordsmithing of the proposed amendment. If you have concerns, let’s try to address them first. Thanks again, Margie. Amr On Oct 8, 2019, at 6:53 PM, Margie Milam <margiemilam(a)fb.com<mailto:margiemilam@fb.com>> wrote: Hi Amr – Following up on today’s homework – here’s a link to information from the UK Information Office that can help guide the drafting of this section: https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-…<https://urldefense.proofpoint.com/v2/url?u=https-3A__ico.org.uk_for-2Dorgan…> Here’s what I suggest: The building block should use this language: “not incompatible with the original purpose, provided the new purpose is fair, lawful and transparent.” The policy recommendation would also need to include specific disclosures to the registrant, describing the common purposes for 3rd party access, so that the transparency requirement is met. Margie

2 1

"Abusive" use of SSAD
by James M. Bladel Oct. 9, 2019

Oct. 9, 2019

Colleagues – Following up with my homework from last Thursday, here is the non-exhaustive list of “abusive” SSAD behaviors. I’ve been in discussions with Mark SV, and note that he has some concerns. Expect his comments/edits in a separate message that will be a fast-follow to this post. Thanks— J. ------------- James Bladel GoDaddy “Abusive” use of SSAD may include (but is not limited to) the following behaviors/practices: 1. High volume submissions of malformed or incomplete requests. 2. Frequent duplicate requests that were previously fulfilled or denied. 3. Use of distributed or spoofed source addresses or platforms to circumvent quotas or rate limits. 4. Use of false or counterfeit credentials to access the system. 5. Storing/delaying and sending high volume requests with the intention of causing SSAD or other parties to fail SLA performance. 6. Attempts or efforts to mine or harvest the data protected by SSAD. As with other access policy violations, abusive behavior can result in suspension or termination of access to the SSAD.

3 7

**Reminder** Meeting Invitation / Observers / GNSO Temp Spec gTLD RD EPDP-P2 call / Thursday, 10 October 2019
by Julie Bisland Oct. 9, 2019

Oct. 9, 2019

As a result of various requests to facilitate observers to follow the EPDP Phase 2 deliberations in real time, audio cast will be made available for the EPDP plenary meetings. Staff will be monitoring audio cast attendance numbers so that the EPDP leadership can assess its usage. As a reminder, the zoom recording, mp3 recording, chat transcript and transcript of the EPDP plenary meetings will be publicly posted as soon as available on the EPDP wiki page and GNSO master calendar. Dear all, The next meeting of the GNSO Temp Spec gTLD RD EPDP – Phase 2 is scheduled on Thursday, 10 October 2019 at 14:00 UTC for 120 minutes. (calls will be scheduled for 120 minutes but aim to keep to 90 minutes) 07:00 PDT, 10:00 EDT, 16:00 Paris CEST, 19:00 Karachi PKT, 23:00 Tokyo JST, (Friday) 01:00 Melbourne AEDT For other times: https://tinyurl.com/yyuhrges [tinyurl.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__tinyurl.com_yyuhrges&d…> Agenda Wiki: https://community.icann.org/x/AYYCBw The recordings and transcriptions of the calls are posted on the GNSO Master Calendar page: https://gnso.icann.org/en/group-activities/calendar<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…> Meeting Audio Cast (for observers) To join the event, click on the link: Listen in browser: http://stream.icann.org:8000/stream01 [stream.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Listen in application such as iTunes: http://stream.icann.org:8000/stream01.m3u<https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Kind Regards, Terri If needed, an option to join via telephone has been added for this meeting. **New join information - Conference Bridge: Toll-free access number (US and Canada): 800 550 6865 and Toll 213 233 3193 Other telephone numbers found here: http://www.adigo.com/icann [adigo.com]<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.adigo.com_icann&d=D…> Enter passcode on telephone: 7349

1 0

For final review - building block a) criteria/content of requests
by Marika Konings Oct. 8, 2019

Oct. 8, 2019

Dear EPDP Team, Building block a) (criteria / content of requests) is ready for final review: https://docs.google.com/document/d/1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4…. Staff has created a log right below the building block language which highlights which updates were made following today’s meeting. Please flag by Wednesday 9 October at 22.00 UTC at the latest whether there are any remaining issues that require further consideration. Best regards, Caitlin, Berry and Marika Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>.

1 0

Proposed Agenda - EPDP Team Meeting #24 Thursday 10 October at 14.00 UTC
by Marika Konings Oct. 8, 2019

Oct. 8, 2019

Dear EPDP Team, Please find below the proposed agenda for the next EPDP Team meeting which is scheduled for Thursday 10 October at 14.00 UTC. Best regards, Caitlin, Berry and Marika EPDP Phase 2 - Meeting #24 Proposed Agenda Thursday, 10 October 2019 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Status of letter to ICANN Board b) Status of building blocks<https://community.icann.org/x/k5ICBw> 4. Accreditation<https://docs.google.com/document/d/1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4…> (building block f and j) – second reading continued (30 minutes) a) Overview of updates made b) Feedback from EPDP Team c) Confirm next steps 5. Receipt of acknowledgement<https://docs.google.com/document/d/1dSepSTKmaceu3oB1YLpp1wgdrJoERIQq7fg_8Ud…> (building block k) – second reading (15 minutes) a) Overview of updates made following first reading b) Feedback from EPDP Team c) Confirm next steps 6. Response requirements / expectations, including timeline/SLAs<https://docs.google.com/document/d/1KqfkWfbC6gBIrmE3OTTw7MYpThciaMc03Lu6M9s…> (building block g) – first reading (15 minutes) a) Review building block b) Feedback from EPDP Team c) Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): a) Thursday 18 October 2019 at 14.00 UTC b) Confirm action items c) Confirm questions for ICANN Org, if any Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>.

1 0

Notes and action items - EPDP Phase 2 Meeting #23 - 8 October 2019
by Caitlin Tubergen Oct. 8, 2019

Oct. 8, 2019

Dear EPDP Team, Below, please find the notes and action items from today’s EPDP meeting. As a reminder, the next meeting will be Thursday, 10 October at 1400 UTC. Best regards, Marika, Berry, and Caitlin -- EPDP Phase 2 - Meeting #23 Tuesday, 8 October 2019 at 14.00 UTC Action Items If any Team members disagree with the structure or overall approach of the accreditation building block proposal, please notify the list in advance of Thursday’s meeting. Based on today’s meeting, James Bladel to work with board liaisons and edit the last sentence of the Board questions letter. James to send updated letter to the Team for a 24-hour silent review period. Absent any objections, EPDP Support Staff to send the letter to the Board. Margie and Amr to work together to find a mutually acceptable solution to subsection C of Building Block D to share with the group by Friday, 11 October. Support Staff to reach out to Thomas regarding Building Block H, Subsection b. In absence of suggestion from Thomas, “or subset thereof” will be deleted. Margie to circulate the previously-suggested logging criteria from the BC accreditation model, and Support Staff to update the new auditing/logging building block accordingly. Support Staff to check the building blocks for consistency - specifically, review the text to ensure there is no reference to notifications to the data subject on a per-disclosure basis Support Staff to organize a conference call with interested members, including James, Chris and Amr to work together on compromise solution for Building Block H, Subpoint J re: confidentiality of LEA requests by Friday, 11 October. Support Staff to edit Subpoint C of Building Block A to address Volker’s concern regarding information provided by the requestor to be specific to the domain name for which disclosure is requested. Following receipt of edited text from Support Staff, EPDP Team will have 24 hours for silent review to express objections. Notes These high-level notes are designed to help the EPDP Team 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 at: https://community.icann.org/x/ZwPVBQ . 1. Roll Call & SOI Updates (5 minutes) · Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team. 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Welcome of new ICANN Org liaison – Eleeza Agopian b) Accreditation building block homework · Support Staff distributed the accreditation building block document, which incorporates input provided from the group’s submissions · Document separates policy principles and implementation-related guidance · A list of definitions from Alex Deacon’s proposal is also included · Team Members should review this document and come prepared to discuss during Thursday’s meeting · Question: should Team members wait until Thursday’s discussion to provide feedback? · EPDP Leadership is looking to see if the overall approach is acceptable to the group. The EPDP Team is welcome to provide feedback on the details of the accreditation building block in advance in the form of comments to the Google doc. · If any Team members disagree with the structure of the accreditation building block proposal, please provide this feedback in advance of Thursday’s meeting. c) Status of building blocks · The Team’s timeline is currently at risk. · Team members are encouraged to provide feedback to the building blocks in advance of meetings. Work conducted offline will help the Team in meeting the project timeline goals. 4. Finalization of questions to ICANN Org / ICANN Board a) Introduction of letter developed by CPH (see https://mm.icann.org/pipermail/gnso-epdp-team/2019-October/002580.html) · This letter is the culmination of a discussion that began during the F2F. · The letter puts a point on the question of ICANN org’s involvement in the operation and development of an SSAD system. The Team needs an answer to this question now. · The Team seems aligned that ICANN should have some sort of role in this, but the concern is what if the Board says it will not accept the model the EPDP Team agrees to. b) Feedback from EPDP Team · Perhaps the questions from Marc A’s document should be attached to these questions · Last sentence of the message - absent input from the Board, the Team may come up with recommendations that are not palatable to the Board. With a slight tweak in the language, this message could be more clear · The intention is to note that the risk is that the EPDP Team puts together a set of recommendations that is unacceptable to the Board, and the last year of the Team’s work becomes a sunk cost. The Team needs an answer to ICANN’s willingness to accept risk. Important to not allow the ambiguity to continue. · The clearer the questions are, the clearer the response from the Board will be · Based on today’s conversation, James to work with board liaisons and edit the last sentence of the letter. Once completed, the letter will be sent to the Team for 24 hours of review. Absent any objections, EPDP Support Staff to send the letter to the Board. c) Confirm next steps 5. Acceptable use policy (building block d & h) – Second reading (15 minutes) a) Overview of updates made following first reading b) Feedback from EPDP Team Building Block D Subpoint b · With respect to audits, the Team should be clear on what can be audited and how. No objections to the concept of auditing, but additional clarity may be helpful. · The BC accreditation model includes an example of what auditing could look like - there could be a cross-reference to that building block · After the striking of (no bulk access), the Team would include a reference to the auditing building block in terms of what items can be audited · The requestor should keep a record of its data processing Subpoint c · Similar to subpoint b, the references to auditing should be moved to the auditing building block so there is clarity with respect to auditing and what that includes · The reworded language captures the importance of only using the data for the purposes for which the data was requested · Uncomfortable with this language “consistent with” · Proposal from Brian - the requestor will only use the data for the purpose it was requested · There may be multiple purposes. If a phishing attack involves a trademark, would not want to prevent using the data for cybersecurity. · Proposal to use “not processed further in a manner that is incompatible with the specified purpose” · If an individual gets access to data, they are a controller, and the concept of secondary purposes is under their remit. In the code of conduct, there should be a limit to the purpose for which it was collected. · Disclosing party has to ensure that the new controller is processing the data in a compliant fashion · Put subsection C in square brackets - Margie and Amr to work together to find a mutually acceptable solution to share with the group by Friday, 11 October. Building Block H Subpoint B · Support Staff to reach out to Thomas regarding Subsection b. In absence of suggestion from Thomas, “or subset thereof” will be deleted. Subpoint D · This text should be included in the auditing/logging building block · The question marked in the document does need to be addressed - are there any volunteers to suggest ideas for the logging requirements · In the BC accreditation model, there were some suggestions for what needs to be included in the logs · Margie to circulate the previously-suggested from the accreditation model, and Support Staff to update the building block accordingly. Subpoint E · This should be removed · Why is the balancing test called out here, but no other tests (like the purpose test)? Subpoint C already covers this. · Disagree that this is redundant - it is up to the EPDP Team to provide as much implementation guidance as possible. · Important to qualify the balancing test for when it is required · Take off the square brackets and retain the proposed text Subpoint F · How would the data subject be able to object to the balancing test after it had been done? · This section is not supported under GDPR - if it does come from GDPR, this should be tracked in this section. · Should this be deleted? · This should not be deleted, but it is a fair question - the GDPR does not explicitly say that a data subject may challenge the outcome of a balancing test, but the GDPR does make allowances for data subjects to challenge the use of their data. · Delete this for now, and provisionally open a new building block for the rights of the data subject, and come up with something workable - how the data subject could interact with SSAD · The data subject’s rights under GDPR will depend on who the controller is - this may belong in another section like what information needs to be provided to registrants · https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-… right to object  - review this in conjunction with new building block Subpoint G · G and J are closely tied - there needs to be a carve-out for law enforcement where confidentiality is necessary · G and J should be part of the same subsection or next to each other · This is also closely tied to the objection to the processing of the data - · Is there a mandatory requirement under GDPR to notify a party when data is disclosed to a third party? · During the registration process, Rys and Rrs would disclose that the information may be disclosed to a third party and the circumstances under which that would be done. · May need to cross-check previous documents that there is no notification to the data subject on a per-disclosure basis Subpoint J · If there is an LEA request for non-public data and that request includes withholding notification to the data subject - this should come out of SSAD and be part of the due process on a jurisdiction by jurisdiction basis. LEA should use their respective local authority to get a warrant/court order. · LEA may need to use abilities to compel GoDaddy, an MLAT is necessary and that would take months. LEA would like the right to ask the company not to notify the data subject due to an ongoing investigation · This effort cannot be 100% focused on the ease and convenience on the access of the data - this seems like there needs to be a warrant or a court order - it’s not in the Team’s remit to create a bypass here · Within the SSAD, there should be an ability to designate things as confidential and urgent · Regarding logging - everything needs to be logged (including law enforcement) for the sake of auditing · If there is no law enforcement through the SSAD, where are we doing it? Another PDP? · Everything should go in through the SSAD, but not every decision needs to be made through the SSAD · This is not an attempt to fix MLATs - trying to produce a system where the system is logged, and certain logs have a higher bar to being released · Action: James and Chris to work together to work on Subpoint J to come up with a compromise by Friday, 11 October. Subpoint K · Need to call out unaccredited privacy/proxy data - privacy/proxy data has to be disclosed · Affiliated privacy/proxy data would not be redacted, so this may not be applicable here. · This is not appropriate here - this should say data that clearly does not contain data of a natural person · The focus should be on the data itself, not natural vs. legal persons · Concerned with the word “must” - there may be examples of legal persons that are protected (battered women’s shelters, for example) · Potential rewrite “…must not disclose non-public data of clearly identifiable as a data subject protected under applicable data protection regimes.” c) Confirm next steps 6. Criteria & content of requests (building block a) – Second reading (15 minutes) a) Overview of updates made following first reading b) Feedback from EPDP Team Subpoint A · Ensure this does not prevent reverse whois look-ups Subpoint B · Insert Brian’s addition, as there were no objections Subpoint C · The info provided should be specific to the domain name for which disclosure is requested Subpoint D · Ask for affirmation, and have additions in the AUP Regarding reverse WHOIS look-ups, since some Team members are wishing to take this issue up, can the Team agree to discuss the issue and include a specific question for public comment in the Initial Report? EPDP Feedback: · No. There was no issue scoping for this process. Since the community was not consulted in the scoping of this EPDP, this is not appropriate. · Potential compromise position: do not require it, do not prohibit it c) Confirm next steps 7. Receipt of acknowledgement (building block k) – second reading (if time allows) a) Overview of updates made following first reading b) Feedback from EPDP Team c) Confirm next steps 8. Wrap and confirm next EPDP Team meeting (5 minutes): a) Thursday 10 October 2019 at 14.00 UTC b) Confirm action items c) Confirm questions for ICANN Org, if any

1 0

Post Call | GNSO Temp Spec gTLD RD EPDP – Phase 2 | Tuesday, 08 October 2019 at 14:00 UTC
by Terri Agnew Oct. 8, 2019

Oct. 8, 2019

Dear all, All recordings for the GNSO Temp Spec gTLD RD EPDP – Phase 2 held on Tuesday, 08 October 2019 at 14:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/HZACBw> (attendance included) and the GNSO Master calendar <https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group…> . These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript As a reminder only members and alternates can join the call, observers can join via audio cast, listen to the recordings and read the transcript afterwards. For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-epdp-team/> and the main wiki page<https://community.icann.org/x/IYEpBQ>. Thank you. With kind regards, Terri

1 0