October 2019 - Gnso-epdp-team

Notes and action items - EPDP Phase 2 Meeting #24 - 10 October 2019
by Caitlin Tubergen Oct. 11, 2019

Oct. 11, 2019

Dear EPDP Team, Please find below the notes and action items from today’s EPDP meeting. The next EPDP meeting will be Thursday, 17 October at 1400 UTC. Best regards, Marika, Berry, and Caitlin -- EPDP Phase 2 - Meeting #24 Thursday, 10 October 2019 at 14.00 UTC Action Items Based on today’s meeting discussion, Support Staff to update the accreditation principles (Building Block F/J) via the Google Doc. EPDP Team to review and comment on updated principles by Wednesday, 16 October. 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) Status of letter to ICANN Board · The EPDP Team has been discussing the last sentence of the draft letter. · The circulated language was discussed by board liaisons · Is the consternation over the last sentence of the letter, or sending the letter more generally? · Issue with final sentence - it is not clear the EPDP Team needs to abandon the centralized model. If ICANN cannot answer the question, the EPDP Team will assume that ICANN is unwilling to do this, and the EPDP Team will draft policy recommendations accordingly. · The GAC has not objected to the letter, but strong language will help express the urgency of the situation. The Team should ask for a written response from ICANN. The language may be reworded so that it’s not a zero-sum situation. · In the second paragraph, the last sentence may need an update. · The original text was less definitive, and the proposed rewrite, in consultation with the board liaisons, made the question stronger. Perhaps revert to the original language. · Removing the last sentence entirely invalidates the point of sending the letter. · Time is of the essence, so the Team should not iterate indefinitely. · Action: EPDP Team members to send updated draft text to James immediately following the call. James to distribute updated version of the letter to the EPDP Team for 2 hours of silent procedure. b) Status of building blocks · Building Block A is closed and will be included in the Initial Report · Support Staff made updates to Building Block E - EPDP Team has 24 hours to flag additional issues · All other building blocks are under development 4. Accreditation [docs.google.com] (building block f and j) – second reading continued (30 minutes) a) Overview of updates made · As noted on the Team’s last call, Support Staff distributed the accreditation building block document, which incorporates input provided from the group’s submissions. The document separates policy principles and implementation-related guidance. · Nothing in the document has been agreed to; this is a Support Staff proposal based on the input received to date. · In certain areas, there may need to be further clarity on who is responsible for what. · The definitions that have been included were from Alex’s document, but the definitions have not been cross-checked with the draft text of the building block. b) Feedback from EPDP Team Principle a: · Concerned with why individuals cannot be accredited. · What is the reason for this? · Some team members argue that organizations can be more easily verified, while this is difficult to do with individuals. However, this can be removed if no agrees. · Could it be possible that only individuals or legal entities would have access to certain types of justifications for request? For example, a law enforcement officer may need to request on behalf of an LEA not on behalf of itself. There could be a distinction, not a prohibition. · Accredited entities can be both legal and natural persons. · The uniform baseline application for legal persons may be different than natural persons. · Why are non-accredited entities prohibited from sending in requests? · Oppose SSAD being limited to only certain types of users · Do not support limiting the system to accredited users only · Almost all individuals will be associated with a business · Accredited entities may be legal persons and individuals. Principle b: · Pointing out a trademark requirement is not appropriate here, or come up with a better example · Remove the example · Add the point that the baseline approach may be different for individuals vs. legal persons Principle c: · “Or automate” should be deleted b/c there is a logical issue in the statement · Adopt Brian K’s suggestion - “accreditation alone must not” · Review of the request could be automated, but not the disclosure of information · Accreditation is not purely for authentication of identity - it could be a wider verification than just knowing who the person is - an individual could submit to a code of conduct, for example · Is it worth starting out with the definition of terms authentication, accreditation, automation? · Staff to reword the “or automate” language Principle d: · Agree with this in principle, but more detail is needed from an operational perspective · System abuse could be an example of why de-accreditation occur, rather than having it as a definitive statement. As an example, there may be situations where trademark holder may lose a trademark - in that sense, if demonstrating that holding a valid trademark is a prerequisite to accreditation, losing the trademark could warrant de-accreditation. · Using “abuse” should not be the only reason for de-accreditation. For example, would violating the code of conduct be considered system abuse? · “in case of system abuse or in cases where pre-requisites for accreditation no longer exist” · In the BC proposal, there is a renewal procedure. The renewal process would require individuals and entities to confirm the accreditation criteria still exist. · Insert full stop after de-accreditation and insert examples of when de-accreditation may occur. Principle e: · Brian suggested changing clearinghouse to clearinghouses (no disagreement) Principle f: · No objections Principle g: · It’s not clear that this entity would be an accreditation authority or a sub-contractor. · Agree with this principle, but operationalizing this principle is subject to interpretation. More detail is needed here - for example, what information is subject to an audit, what information is not subject to an audit, etc. · With respect to auditing, the Team agreed to have a separate building block for auditing. The suggestions could be included in the new building block. Principle h: · G and H could be merged Principle i: · This should be considered in the financial considerations building block · This should be replaced completely with “the accreditation service may be part of a cost-recovery system” · Replace “must” with “likely” · Drop the second sentence, with the understanding that there are additional considerations with respect to the financial model · It is absolutely critical to have principles related to cost causation and cost recovery and the assignment of cost to specific parties; however, rates should not be determined at this stage · Individuals who are accredited and the entities who are accrediting must be self-sustaining · Elements of cost associated with accreditation need to be discussed in building block M Principle j: · Do not see the benefit of this bullet · Should be updated to entities and individuals · This does have merit b/c the Team wants to ensure that regular users are accredited to minimize the work. If there is a group such as IP attorneys or security researchers, this should be streamlined as much as possible. · What does the Team expect as the outcome of this statement? It’s unclear how to implement this. The statement should be dropped altogether. · Proposal to delete this point completely. Principle k: · The idea is that after accreditation that particular entity or individual is recognized as accredited. · Support Staff to reword to clarify. · “Confirm” is confusing everyone - change this word to make this clear · Support Staff to review Hadia’s input and Marc A’s input when updating this principle Principle l: · Wording needs to be tightened here · Accreditation should be renewed periodically should be added as an additional policy principle. c) Confirm next steps · Based on today’s meeting discussion, Support Staff to update the accreditation principles via the Google Doc. EPDP Team to review and comment on updated principles by Wednesday, 16 October. · EPDP Team to review Hadia’s message in advance of the next meeting. · The question regarding RDAP overlaps with principle k. 5. Receipt of acknowledgement [docs.google.com] (building block k) – second reading (15 minutes) a) Overview of updates made following first reading b) Feedback from EPDP Team · No objections to reworded text - this building block is now complete c) Confirm next steps 6. Response requirements / expectations, including timeline/SLAs [docs.google.com] (building block g) – first reading (15 minutes) a) Review building block · Does the group want to check back in on Phase 1 recommendations and Phase 1 implementation, or would the group prefer to take a clean-state approach? · Should sometime be added here about technical failures? · Would this be different if this is a centralized or decentralized model? · It may be helpful to read the questions below the building block to show what the building block is scheduled to address. 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

1 0

Re: [Gnso-epdp-team] [Board-Ops-Team] EPDP Phase 2 Team letter to ICANN Board Re. SSAD
by Wendy Profit Oct. 10, 2019

Oct. 10, 2019

Dear Marika, Thank you for forwarding the letter from the EPDP Phase 2 team to the Board. We are hereby acknowledging receipt on behalf of the Board and confirming the letter was forwarded to them. The letter was also forwarded internally for further processing. Thank you, Wendy Profit ICANN Board Operations Senior Manager 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094 From: Board-Ops-Team <board-ops-team-bounces(a)icann.org> on behalf of Marika Konings <marika.konings(a)icann.org> Date: Thursday, October 10, 2019 at 3:04 PM To: ICANN Board Ops <board-ops-team(a)icann.org> Cc: Goran Marby <goran.marby(a)icann.org>, "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org>, "council(a)gnso.icann.org" <council(a)gnso.icann.org> Subject: [Board-Ops-Team] EPDP Phase 2 Team letter to ICANN Board Re. SSAD Dear Board Ops Team, On behalf of the EPDP Phase 2 Team, please find attached correspondence to ICANN Board regarding the Standardized System for Access/Disclosure (SSAD). Best regards, 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

EPDP Phase 2 Team letter to ICANN Board Re. SSAD
by Marika Konings Oct. 10, 2019

Oct. 10, 2019

Dear Board Ops Team, On behalf of the EPDP Phase 2 Team, please find attached correspondence to ICANN Board regarding the Standardized System for Access/Disclosure (SSAD). Best regards, 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

EPDP Homework: Updated Draft of Board Letter
by James M. Bladel Oct. 10, 2019

Oct. 10, 2019

Colleagues – Regarding the draft letter to the Board presented on Tuesday, some members were uncomfortable with the wording of the last sentence. Since that call, I’ve been working with our Board liaisons (Becky and Chris) to make some edits. The resulting Revised Draft copied below. To expedite your review, please note that only the final sentence has changed. Thanks— J. ------------- James Bladel GoDaddy Letter from EPDP 2 to ICANN Board on Standardized System for Access/Disclosure (SSAD) To: ICANN Board CC: Goran CC: GNSO Council Dear ICANN Board, We are writing to you at the suggestion of the EPDP 2 Board liaisons. The working group is at a critical junction which requires clear input from the Board in order to further our work to produce realistic, timely, implementable policy recommendations. Specifically, we seek to understand the Board’s position on the scope of operational responsibility and level of liability (related to decision-making on disclosure of non-public registration data) they are willing to accept on behalf of the ICANN organization along with any prerequisites that may need to be met in order to do so. Our goal is to avoid policy recommendations that cement the current situation, where requests for non-public registration data are handled on a case-by-case basis by the registry/registrar in a non-standardized and decentralized manner. We are considering several models for a Standardized System for Access and Disclosure (SSAD), including (but not limited to) the Unified Access Model (UAM) developed by the Technical Study Group. All of the proposed “centralized” SSAD models presume that ICANN will assume an operational role, and, depending upon the model, some degree of responsibility and liability for decisions to disclose non-public data to a third-party requester. In some models, ICANN (or its designee) would approve accrediting bodies, or function as an accrediting body themselves. Some proposed models establish ICANN (or its designee) as the entity that will conduct an initial validation of disclosure requests prior to relaying this request to the appropriate registry or registrar. Other proposed models would require ICANN to play a larger role, either endorsing the legitimacy of the request, or issuing a determination of whether or not the registrar or registry should or must disclose the non-public data to the third party requester. We recognize that our questions are clouded by the uncertainty associated with constructing a model that is compliant with the General Data Protection Regulation (GDPR) and other privacy laws. We are also aware of the work of ICANN org (via the “Strawberry Team”) to engage with data protection authorities to better understand the liability involved in decisions to disclose non-public registration data. As noted above, our goal is to produce realistic, timely, and implementable policy recommendations, and our work requires Board input on the level of involvement and amount of liability they are willing to assume for ICANN org, along with any prerequisites that may need to be met in order to do so. Absent that input, the EPDP work must abandon the centralized SSAD model, and shift its focus to policy recommendations aimed at improving the existing distributed model in which each registry and registrar independently evaluates, applies their own balancing test, and responds to queries on a case by case basis. Thank you, EPDP Phase 2 working group members

9 14

For final review - building block e) retention/destruction of data
by Caitlin Tubergen Oct. 10, 2019

Oct. 10, 2019

Dear EPDP Team, Building Block e (retention and destruction of data) is ready for your final review: https://docs.google.com/document/d/1WMhllLz5Zgm42C4Jfjiqinu32Jwiu_lhuBorzeu… The edit log notes the proposed changes made as a result of Marc A’s suggestions on the email list. Please flag any remaining issues that require further EPDP Team consideration (if any) by Friday 11 October at 22.00 UTC. Thank you. Best regards, Marika, Berry, and Caitlin

2 1

Zoom Security Update
by Nathalie Peregrine Oct. 10, 2019

Oct. 10, 2019

https://www.icann.org/news/blog/zoom-security-update · Author: Ashwin Rangan, SVP Engineering & Chief Information Officer · 10 Oct 2019 · · Zoom recently added new settings to increase security and ensure meeting privacy. These new settings will enforce a password on all new meetings scheduled, but will not affect meetings that have been scheduled prior to 29 September 2019. The only participants who will be required to enter a password are those who join a meeting via the Zoom app and manually type in the meeting ID. Participants who join a meeting via a link in a calendar or e-mail invitation will not be required to enter the password upon joining, as it is included in the URL by default. To learn more about the new settings, please visit the Zoom Help Center and read the FAQ here<https://support.zoom.us/hc/en-us/articles/360033331271>. At the recommendation of ICANN’s internal InfoSec team, these new settings will be enabled immediately. Because the vast majority of ICANN meeting participants join via invitation links, we expect the impact on community members and staff to be minimal. Please reply here or contact the Meetings Technical Services team directly at mts(a)icann.org<mailto:mts@icann.org> if you have any questions or concerns regarding this update. Nathalie Peregrine Manager, Operations Support (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) Email: nathalie.peregrine(a)icann.org <nathalie.peregrine(a)icann.org%20> Skype: nathalie.peregrine.icann Find out more about the GNSO by visiting: https://learn.icann.org/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…> See All SO and AC events on the ICANN Global calendar<https://features.icann.org/calendar> Nathalie Peregrine Manager, Operations Support (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) Email: nathalie.peregrine(a)icann.org <nathalie.peregrine(a)icann.org%20> Skype: nathalie.peregrine.icann Find out more about the GNSO by visiting: https://learn.icann.org/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…> See All SO and AC events on the ICANN Global calendar<https://features.icann.org/calendar>

1 0

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

Oct. 10, 2019

Dear all, All recordings for the GNSO Temp Spec gTLD RD EPDP – Phase 2 held on Thursday, 10 October 2019 at 14:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/AYYCBw> (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

Meeting Invitation / Observers / GNSO Temp Spec gTLD RD EPDP-P2 call / Thursday, 17 October 2019
by Terri Agnew Oct. 10, 2019

Oct. 10, 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, 17 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/y3gx4fla Agenda Wiki: https://community.icann.org/x/A4YCBw 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 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 Enter passcode on telephone: 7349

1 0

Re: [Gnso-epdp-team] Proposed Agenda - EPDP Team Meeting #24 Thursday 10 October at 14.00 UTC
by Marika Konings Oct. 10, 2019

Oct. 10, 2019

Please note that the hyperlink for item 4 was incorrect. This should have been fixed now. Best regards, Caitlin, Berry and Marika From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of Marika Konings <marika.konings(a)icann.org> Date: Tuesday, October 8, 2019 at 14:04 To: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Gnso-epdp-team] Proposed Agenda - EPDP Team Meeting #24 Thursday 10 October at 14.00 UTC 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/1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk…> (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…>.

3 3

Re: [Gnso-epdp-team] EPDP Homework: Updated Draft of Board Letter
by Matt Serlin Oct. 10, 2019

Oct. 10, 2019

I believe including that final sentence gets at the heart of the issue with the guidance we are seeking and removing it makes the letter less impactful IMO. Yes, we think the Board and Org do know these things but I think being as explicit as possible with our words will help ensure we get the most clear answer from the Board as possible. Regards, Matt From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of "Mark Svancarek (CELA) via Gnso-epdp-team" <gnso-epdp-team(a)icann.org> Reply-To: "Mark Svancarek (CELA)" <marksv(a)microsoft.com> Date: Wednesday, October 9, 2019 at 3:35 PM To: "James M. Bladel" <jbladel(a)godaddy.com>, "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: Re: [Gnso-epdp-team] EPDP Homework: Updated Draft of Board Letter I still think it’s better not to close the letter with a threat or even a prediction. The Board and Org know the critical importance of giving us a decision answering this letter. We suggest removing the final sentence. The rest of the letter is great. /marksv From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> On Behalf Of James M. Bladel Sent: Wednesday, October 9, 2019 1:07 PM To: gnso-epdp-team(a)icann.org Subject: [Gnso-epdp-team] EPDP Homework: Updated Draft of Board Letter Colleagues – Regarding the draft letter to the Board presented on Tuesday, some members were uncomfortable with the wording of the last sentence. Since that call, I’ve been working with our Board liaisons (Becky and Chris) to make some edits. The resulting Revised Draft copied below. To expedite your review, please note that only the final sentence has changed. Thanks— J. ------------- James Bladel GoDaddy Letter from EPDP 2 to ICANN Board on Standardized System for Access/Disclosure (SSAD) To: ICANN Board CC: Goran CC: GNSO Council Dear ICANN Board, We are writing to you at the suggestion of the EPDP 2 Board liaisons. The working group is at a critical junction which requires clear input from the Board in order to further our work to produce realistic, timely, implementable policy recommendations. Specifically, we seek to understand the Board’s position on the scope of operational responsibility and level of liability (related to decision-making on disclosure of non-public registration data) they are willing to accept on behalf of the ICANN organization along with any prerequisites that may need to be met in order to do so. Our goal is to avoid policy recommendations that cement the current situation, where requests for non-public registration data are handled on a case-by-case basis by the registry/registrar in a non-standardized and decentralized manner. We are considering several models for a Standardized System for Access and Disclosure (SSAD), including (but not limited to) the Unified Access Model (UAM) developed by the Technical Study Group. All of the proposed “centralized” SSAD models presume that ICANN will assume an operational role, and, depending upon the model, some degree of responsibility and liability for decisions to disclose non-public data to a third-party requester. In some models, ICANN (or its designee) would approve accrediting bodies, or function as an accrediting body themselves. Some proposed models establish ICANN (or its designee) as the entity that will conduct an initial validation of disclosure requests prior to relaying this request to the appropriate registry or registrar. Other proposed models would require ICANN to play a larger role, either endorsing the legitimacy of the request, or issuing a determination of whether or not the registrar or registry should or must disclose the non-public data to the third party requester. We recognize that our questions are clouded by the uncertainty associated with constructing a model that is compliant with the General Data Protection Regulation (GDPR) and other privacy laws. We are also aware of the work of ICANN org (via the “Strawberry Team”) to engage with data protection authorities to better understand the liability involved in decisions to disclose non-public registration data. As noted above, our goal is to produce realistic, timely, and implementable policy recommendations, and our work requires Board input on the level of involvement and amount of liability they are willing to assume for ICANN org, along with any prerequisites that may need to be met in order to do so. Absent that input, the EPDP work must abandon the centralized SSAD model, and shift its focus to policy recommendations aimed at improving the existing distributed model in which each registry and registrar independently evaluates, applies their own balancing test, and responds to queries on a case by case basis. Thank you, EPDP Phase 2 working group members

7 9