November 2019 - Gnso-epdp-team

Financial sustainability issues of the SSAD
by Janis Karklins 22 Jan '20

22 Jan '20

Goran, I am writing you in my capacity of the Chair of the EPDP Phase 2 Team to seek input on financial sustainability issues if the SSAD. The EPDP Phase 2 Team is considering the financial sustainability of the System for Standardized Access/Disclosure (SSAD) currently being deliberated. This will likely involve ICANN managing or operating a centralized system to facilitate requests for disclosure of non-public gTLD registration data. The Team is contemplating how considerable cost implications would be to develop, operationalize and run such a System. The EPDP currently considers principles on which such a system may be based. Work is still in progress, but the Team is discussing principles such as: 1. The SSAD should operate on a cost-neutral basis. No party should operate or seek to operate this service as a for-profit service, as this would invite abuse and manipulation of the SSAD functions. 2. Costs to operate the SSAD should be borne by the *direct* beneficiaries of the service. The costs of SSAD should not be transferred to Data Subjects (Registrants), either directly via fees from ICANN or indirectly via fees to Contracted Parties who provide the SSAD with data and bear the legal risks of disclosures. In the absence of responses from both the EPDP letter to the Board, and to the Strawberry Team’s query as presented to the European Data Protection Board, the EPDP team is not in a position to consider a single model for the potential SSAD. Accepting that financial sustainability is a vital consideration for the initial report, and as we have not yet determined the model for the SSAD, we must therefore present the financial sustainability of each of the general model types so far postulated: - Fully Centralized (e.g. with ICANN at the core) - Centralized Accreditation and request portal, distributed decision-making, with final response via Centralized portal (e.g. CZDS). - Central Gateway, with distributed review and disclosure The Team understands that a cost analysis is difficult to conduct while the exact details of the SSAD are still being determined. We hope that looking at existing systems such as TMCH or CZDS might provide useful baselines and identify dependent assumptions that impact cost models. CZDS, for example, is itself a centralized system for access to data (in this case zone file data), sharing many similarities with the SSAD being contemplated. Equally, financial sustainability analysis of the UAM could provide same useful indications for Team’s deliberations. In order to understand if it is possible for the SSAD to adhere to these crucial principles, we are requesting ICANN Org’s help in understanding all the likely costs associated with both the development and the ongoing operation of the SSAD. Once we understand the anticipated costs, we would expect to propose a credentialing and transaction fee structure which would pay for the System and allow us to better understand the cost/benefit balance of the SSAD as a whole. Your input on financial sustainability issues will be highly appreciated. Best regards JK

2 3

Draft Initial Report
by Caitlin Tubergen 10 Dec '19

10 Dec '19

Dear EPDP Team: Please find attached the draft Initial Report. As you review the draft, please be aware that the text highlighted in orange is still under review but has been included to give the Team a holistic idea of the Report’s status. Specifically, the orange text represents: Text not yet reviewed by the EPDP Team; Staff-proposed text to address comments provided on calls; or Placeholder text where further work is underway. As Janis noted during the Team’s last meeting, please review the draft and come prepared to Wednesday’s meeting ready to discuss the status of the draft Initial Report, with a specific focus on the readiness to publish for public comment. We have also attached the timeline slides Berry presented during ICANN66 to remind the Team of how the date we publish the Initial Report for public comment will affect the overall project timeline. To those celebrating: Happy Thanksgiving from the EPDP Leadership and Support Team! Best regards, Marika, Berry, and Caitlin

7 16

Re: [Gnso-epdp-team] For your review: purposes and user groups
by Margie Milam 27 Nov '19

27 Nov '19

Here’s the BC response to Caitlin’s questions: * The concept of user groups is useful because it helps explain the likely types of requestors that are expected to use the SSAD, and will make it easier to identify those that can validate their identity to help with accreditation. * We believe that a predetermined list of purposes is necessary. In Phase 1, the BC dissented from the Final Report because Purpose 2 did not specify the important third party purposes such as cybersecurity, IP infringement and consumer protection. We continue to believe that this is required under GDPR to provide transparency to the registrant regarding how their personal data may be processed. As a result, we do not support replacing this specificity with a list of user groups. Instead, the policy recommendation needs to: * List specific third party purposes in an updated Recommendation 1, Purpose 2 * Identify the legal basis to support the purpose cited by the requestor * We propose that the following language be added to the Purposes Building Block. Please note that the list in our proposed Purpose 2.2 (i)-(v) is based on the categories of user cases from the Wiki<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protec…>. All the best, Margie & Mark, On behalf of the BC _______________________________________________________ Proposed text for the Purposes Building Block: With respect to the ICANN purpose for this disclosure, the EPDP Team recommends that the requestors may select from the following purposes: * Purposes 1, 3-7 as listed in the EPDP Phase 1 Final Report * Purpose 2 from the EPDP Phase 1 Final Report is replaced with the following: Purpose 2.1: The EPDP recognizes that ICANN has a responsibility to foster the openness, interoperability, resilience, security and/or stability of the DNS in accordance with its stated mission (Bylaws Section 1.1). It has a purpose to require actors in the ecosystem to respond to data disclosure requests that are related to the security, stability and resilience of the system. Purpose 2.2: The EPDP recognizes that third parties may submit data disclosure requests for the following specific purposes: (i) criminal law enforcement, national or public security, (ii) non law enforcement investigations and civil claims, including, intellectual property infringement and UDRP and URS claims, (iii) contacting registrants, (iv) consumer protection, abuse prevention, digital service provider (DSP) and network security, or (v) Registered name holder consent or contract. From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of Caitlin Tubergen <caitlin.tubergen(a)icann.org> Date: Thursday, November 21, 2019 at 3:02 PM To: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Gnso-epdp-team] For your review: purposes and user groups Dear EPDP Team: Under the Team’s current review schedule, no time has been set aside to further discuss purposes and user groups. To that end, we wanted to test a proposed approach to these building blocks as outlined in the list of issues that was shared prior to ICANN66. User groups: * Consider whether or not a set of user groups needs to be developed – is this already addressed through the accreditation recommendations? * If this is considered addressed as a result of the accreditation recommendations, consider the following text: “The EPDP Team expects that the question of user groups will be addressed through the accreditation policy; specifically, all requestors will need to be accredited, and accreditation will include identity verification, which may include user category/categories.” Purposes: * Consider purpose 2 and the previous agreement: “The EPDP Team agreed to consider at a later stage in the process whether an ICANN purpose for disclosure is necessary and/or desirable”. Has a later stage arrived, or is further time needed? Is this a question to be raised as part of the public comment period on the Initial Report? * Consider also whether a set of pre-determined purposes needs to be developed that third-party requestors can provide. If this is not deemed necessary at this stage, consider the following text: “As identified in building block a) criteria and content of requests, each request must include information about the legal rights of the requestor specific to the request and/or specific rationale and/or justification for the request, e.g. What is the basis or reason for the request; Why is it necessary for the requestor to ask for this data? The EPDP Team expects that over time, the entity responsible for receiving requests will be able to identify certain patterns that could result in the development of a preset list of rationales and/or justifications that a requestor can select from, while always maintaining the option for the requestor to provide this information in free form”. Based on your feedback, the leadership team will determine when to discuss this further or whether the proposed approach has sufficient support to be incorporated in the draft Initial Report. Please provide feedback by Thursday, 28 November. Best regards, Marika, Berry, and Caitlin

1 0

REMINDER: For your review: purposes and user groups
by Caitlin Tubergen 27 Nov '19

27 Nov '19

Thank you, Sarah and all CPH Members for the timely response. If any other EPDP Members have any feedback on the below proposals regarding purposes and user groups, please respond by Thursday, 28 November. Thank you. Best regards, Marika, Berry, and Caitlin From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of Sarah Wyld <swyld(a)tucows.com> Organization: Tucows Date: Tuesday, November 26, 2019 at 8:42 AM To: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: Re: [Gnso-epdp-team] For your review: purposes and user groups Sent on behalf of the CPH team: Hello Team, Thanks for laying out these suggested options for how to approach the Purposes and User Groups. We note that this would not generally be our preferred approach for addressing open issues, but because we did significant work on these topics already in plenary, we think that we can agree with the proposal for how to conclude these questions. For User Groups, the building block in combination with the Accreditation building block should be sufficient to identify users and group them appropriately; we can therefore support the suggested text in the second bullet point. For Purposes, we agree that no further work is required, and again support the second bullet point in that section. Yours Truly, The CPH Team -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 On 11/21/2019 6:02 PM, Caitlin Tubergen wrote: Dear EPDP Team: Under the Team’s current review schedule, no time has been set aside to further discuss purposes and user groups. To that end, we wanted to test a proposed approach to these building blocks as outlined in the list of issues that was shared prior to ICANN66. User groups: Consider whether or not a set of user groups needs to be developed – is this already addressed through the accreditation recommendations? If this is considered addressed as a result of the accreditation recommendations, consider the following text: “The EPDP Team expects that the question of user groups will be addressed through the accreditation policy; specifically, all requestors will need to be accredited, and accreditation will include identity verification, which may include user category/categories.” Purposes: Consider purpose 2 and the previous agreement: “The EPDP Team agreed to consider at a later stage in the process whether an ICANN purpose for disclosure is necessary and/or desirable”. Has a later stage arrived, or is further time needed? Is this a question to be raised as part of the public comment period on the Initial Report? Consider also whether a set of pre-determined purposes needs to be developed that third-party requestors can provide. If this is not deemed necessary at this stage, consider the following text: “As identified in building block a) criteria and content of requests, each request must include information about the legal rights of the requestor specific to the request and/or specific rationale and/or justification for the request, e.g. What is the basis or reason for the request; Why is it necessary for the requestor to ask for this data? The EPDP Team expects that over time, the entity responsible for receiving requests will be able to identify certain patterns that could result in the development of a preset list of rationales and/or justifications that a requestor can select from, while always maintaining the option for the requestor to provide this information in free form”. Based on your feedback, the leadership team will determine when to discuss this further or whether the proposed approach has sufficient support to be incorporated in the draft Initial Report. Please provide feedback by Thursday, 28 November. Best regards, Marika, Berry, and Caitlin _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

2 1

Draft authorization provider building block
by Caitlin Tubergen 27 Nov '19

27 Nov '19

Dear EPDP Team: Following the EPDP Meeting on Thursday, 21 November, Support Staff worked with a few volunteers to develop an Authorization Provider Building Block. As a standard disclaimer, the text within this Authorization Provider Building Block is for discussion purposes within the EPDP Team and, accordingly, is NOT final. As you can see, the small team of volunteers did not agree to all of the text within the building block but would like to share the current proposal as a basis for further team discussion. Thank you again to the volunteers, Margie, Alex, Marc. A., Sarah, and Alan W., who attended additional meetings during an already busy week. Best regards, Marika, Berry, and Caitlin

1 0

Notes and action items - EPDP Meeting #31 - 26 Nov 2019
by Caitlin Tubergen 27 Nov '19

27 Nov '19

Dear EPDP Team: Please find below the notes and action items from EPDP Meeting #31. The next EPDP Team meeting will be Wednesday, 4 December at 14:00 UTC. Best regards, Marika, Berry, and Caitlin -- EPDP Phase 2 - Meeting #31 Proposed Agenda Tuesday, 26 November 2019 at 14.00 UTC Action Items EPDP Team to review the updated CPH-proposed language on Financial Sustainability by Tuesday, 3 December. Support Staff to update the Response Requirements building block based on the EPDP Team’s discussion by Wednesday, 27 November. Support Staff to distribute the draft Initial Report by Thursday, 28 November. 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Status of building blocks 4 of the yellow building blocks will be discussed during today’s meeting 4. Financial sustainability – second reading continued (20 minutes) a) Review updated building block As agreed during the last call, Janis sent an email to Goran asking ICANN org to provide cost estimates of the centralized model Support Staff has updated the financial sustainability building block to incorporate the proposed feedback from the last call The cost estimate for the SSAD should be built upon more than a guesstimate The team should be mindful of its scope. Guessing the costs is out of scope and back of the envelope guesses are not helpful. The email to Goran was not what SSAC expected, and it will be discussing the email in its next meeting. b) Feedback from EPDP Team With respect to the cost differences – there are costs associated with (1) development of the SSAD overall (the platform), (2) the integration of each CP into the system, and (3) the ongoing system (or the long-term service) Edit that development means incorporation of Rys and Rrs into the system Can someone please provide an estimation of what level of magnitude of costs are we talking about here Team needs to also consider the users of the system and the costs there. If there is a trademark accreditor like WIPO, the Team needs to consider how WIPO would integrate with the system and how users would integrate with WIPO Could the team consider the development, deployment, and operationalization of the system Part of the problem is that the team is still not answering the important question – there are many building blocks but no picture on the box of what the building blocks are supposed to build Discussed the integration into the CP but not into the users of the system. The team is trying to cost out something that is unknown at this point. Either the team adopts a wild guess number or the Team needs to say the building block will not be completed until the system starts running. Suggest getting away from talking about a specific number at this time. Need to discuss components of the system. This is akin to putting out an amorphous RFP and asking someone to fashion a guess based on to be determined details. The Team has agreed to a central gateway, but the Team has not yet agreed to where the disclosure decision will be made. It may not be practical for ICANN to be the authorization provider Proposal to park this conversation for the next meeting so Team can review the CP-proposed language c) Confirm next steps EPDP to review the updated CPH-proposed language by Tuesday, 3 December. 5. Response requirements (building block g) – second reading continued (20 minutes) d) Review building block e) Feedback from EPDP Team Subpoint a Perhaps the Team may not want to bake a MUST in the ability to amend requests – it may be easier to submit a new request? If the requestor made an inadvertent omission, it must have the opportunity to amend the request. It doesn’t make sense to charge the requestor again. Propose changing “amend” to “update and resubmit” Practically speaking, this will likely be a web interface Should specify that there is no cost for a malformed request There is a cost for submitting malformed requests Disagreement regarding the amendment of requests creating additional costs Action: staff to put in brackets the costing issue so that it can be resubmitted The question about having an incomplete entry – the rec in Phase 1 – it is not a qualified entry unless the required information is complete – the requestor has to submit a complete entry or it is not a reasonable request The current formulation of a is in contradiction of Rec. 18 Implementation guidance: most likely the application will be sent through an interface, and the system should reject the request until all required fields are filled out The ambiguity comes when all requested fields are filled in, but the system/recipient wants more information, and the parties end up in a dialogue May need to include a definition of incomplete Subpoint b Subpoint c Concerned with the added timeframes – these are in contradiction with Rec. 18 When discussing Rec. 18, the Team agreed the timelines would be different under Rec. 18 The timeline is in reference to requests that cannot be responded to automatically When requests come in bulk, smaller registrars will have a hard time meeting the proposed timeline, so the timeline needs to include some leeway. Without knowing how the system will operate, it is hard to agree to the proposed timeframes. Concern with including recommendations with “if this, then that” Propose deleting this language completely – “without undue delay” is sufficient Ambiguity like this is not helpful to the implementation team Could urgent requests be limited to public safety organizations? Tough timelines make for sloppy decisions Consider changing “must” to “should” – the target is identified, but no obligation is created European law is filled with unspecific timeframes – “without undue delay” is very common in German law The disclosure response must be returned in a time TBD – asterisk or footnote capturing the divergence in time frames Subpoint d Friendly amendment – footnote should make its way into the text as a clarifying point. ICANN org may want to do more analysis than reasonableness. Proposal to delete d Subpoint e The Team has not decided who the data controller is. There should not be a second bite of the apple baked into this – should not contemplate stating that the requestor should go to the controller Subpoint f Is this redundant of c? Consider putting for accredited public safety authorities Could add – a separate accelerated timeline will be recommended for urgent requests Maybe f can become the footnote for c – in c “unless exceptional circumstances” as well as “urgent” Action: Support Staff to edit point b based on today’s conversation Start next call with continuation of reading f) Confirm next steps Action: Support Staff to edit point b based on today’s conversation Action: Support Staff will distribute the draft Initial Report on Thursday for the Team’s 6. Terms of use – second reading (20 minutes) g) Review building block h) Feedback from EPDP Team i) Confirm next steps 7. Automation – second reading (20 minutes) j) Review building block k) Feedback from EPDP Team l) Confirm next steps 8. Wrap and confirm next EPDP Team meeting (5 minutes): a) Wednesday 4 December 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, 26 November 2019 at 14:00 UTC
by Terri Agnew 26 Nov '19

26 Nov '19

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

For your review: purposes and user groups
by Caitlin Tubergen 26 Nov '19

26 Nov '19

Dear EPDP Team: Under the Team’s current review schedule, no time has been set aside to further discuss purposes and user groups. To that end, we wanted to test a proposed approach to these building blocks as outlined in the list of issues that was shared prior to ICANN66. User groups: Consider whether or not a set of user groups needs to be developed – is this already addressed through the accreditation recommendations? If this is considered addressed as a result of the accreditation recommendations, consider the following text: “The EPDP Team expects that the question of user groups will be addressed through the accreditation policy; specifically, all requestors will need to be accredited, and accreditation will include identity verification, which may include user category/categories.” Purposes: Consider purpose 2 and the previous agreement: “The EPDP Team agreed to consider at a later stage in the process whether an ICANN purpose for disclosure is necessary and/or desirable”. Has a later stage arrived, or is further time needed? Is this a question to be raised as part of the public comment period on the Initial Report? Consider also whether a set of pre-determined purposes needs to be developed that third-party requestors can provide. If this is not deemed necessary at this stage, consider the following text: “As identified in building block a) criteria and content of requests, each request must include information about the legal rights of the requestor specific to the request and/or specific rationale and/or justification for the request, e.g. What is the basis or reason for the request; Why is it necessary for the requestor to ask for this data? The EPDP Team expects that over time, the entity responsible for receiving requests will be able to identify certain patterns that could result in the development of a preset list of rationales and/or justifications that a requestor can select from, while always maintaining the option for the requestor to provide this information in free form”. Based on your feedback, the leadership team will determine when to discuss this further or whether the proposed approach has sufficient support to be incorporated in the draft Initial Report. Please provide feedback by Thursday, 28 November. Best regards, Marika, Berry, and Caitlin

2 1

Meeting Invitation / Observers / GNSO Temp Spec gTLD RD EPDP-P2 call / Wednesday, 04 December 2019
by Terri Agnew 26 Nov '19

26 Nov '19

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 Wednesday, 04 December 2019 at 14:00 UTC for 120 minutes. (calls will be scheduled for 120 minutes but aim to keep to 90 minutes) For other times: https://tinyurl.com/vzz8of4 Agenda Wiki: https://community.icann.org/x/UYEzBw 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 [adigo.com]<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.adigo.com_icann&d=D…> Enter passcode on telephone: 7349

1 0

**Reminder** Meeting Invitation / Observers / GNSO Temp Spec gTLD RD EPDP-P2 call / Tuesday, 26 November 2019
by Julie Bisland 25 Nov '19

25 Nov '19

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 Tuesday, 26 November 2019 at 14:00 UTC for 120 minutes. (calls will be scheduled for 120 minutes but aim to keep to 90 minutes) For other times: https://tinyurl.com/y6j7gw2j [tinyurl.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__tinyurl.com_y6j7gw2j&d…> Agenda Wiki: https://community.icann.org/x/Q4EzBw 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