Dear EPDP Team:

Please find below the notes and action items from today’s meeting.

The next meeting will be Tuesday, 2 June at 14:00 UTC, and the meeting will be three hours.

Best regards,

Marika, Berry, and Caitlin

--

Action Items

1. EPDP Team Members to review the remaining questions on the Rec. 15 Financial Sustainability Discussion Items List and provide feedback over the list in advance of the next meeting on Tuesday, 2 June.
2. Beginning Saturday, 30 May, EPDP Team Members to begin reviewing the final draft recommendations and adding “cannot live with” items into the tables within the recommendations. EPDP Team Members to review the PCRTs and Discussion Tables for Priority 2 topics. All feedback on recommendations will be due Friday, 5 June.

EPDP Phase 2 - Meeting #61

Proposed Agenda

Thursday 28 May 2020 at 14.00 UTC

1. Roll Call & SOI Updates (5 minutes)

2. Confirmation of agenda (Chair)

3. Welcome and housekeeping issues (Chair) (5 minutes)

• Confirm assignments and expectations for homework week (10 min)

1. Review of updated recommendations (see https://community.icann.org/x/K4LsBw)
2. Confirm timing and next steps

• We are approaching “homework week,” which will officially begin on Saturday
• https://community.icann.org/display/EOTSFGRD/g.+Draft+Final+Report+-+Phase+2

• Groups should carve out time next week to review the updated recommendations as well as the discussion tables for the Priority 2 items
• By way of example, if you click on Rec. 3 – there are three recs combined in this doc (3, 5, 8) for consistency and to avoid duplication. At the top of the document, the familiar tables have been inserted where groups are asked to focus on “cannot live with” items. If you flag an issue, please provide a concrete proposal with respect to how your group could live with the text.
• Similar to previous reviews, you may also provide minor edits and editorial changes in the minor edits table.
• For ease of reading, the clean version of the recommendation appears first. If you scroll further down, you will see the marked-up version. Green language is identical to the Initial Report. Yellow highlighted text represents changes made in response to the public comment period. Blue highlighted text represents grammatical changes or reorganization changes.
• Some of the later recommendations also include a tracking table, where we document where the changes were derived from – either from the discussion tables or from the specific meeting date during which it was discussed.
• Feedback on recommendations is due by Friday, 5 June at the latest.
• The versions will be final by Friday COB.
• Following 5 June, Leadership will devise a schedule based on the feedback received.
• This may result in additional meetings the week of 15 June.  Just to be on the safe side, we will send placeholder invites to the group. Meeting times will be dependent on how many “cannot live with” items we receive.

4. Recommendation #18 Audits (10 min)

1. Review remaining discussion items gleaned from input provided on audits discussion table

• Question 4: Should this recommendation only include requirements that are not already included in the RA/RAA?
• Are there any obligations listed here that are already required and do not need to be called out?
• Recall focusing on auditing requirements for the SSAD system and not include requirements already called out in the RA/RAA, so we should only include new requirements not in the RA/RAA. Unless someone can point to a specific instance where this was not done, the group can move on.
• For auditing obligations that don’t exist under relevant data protection laws, the team focused on what we thought the minimum requirements should be for the SSAD system.
• Outcome: keep text as is.
• Question 5: In cases of repeated non-compliance or audit failure, matters should be referred back to the accreditation authority. Should CPs be allowed to use past abuse as a reason to deny future requests?
• The Accreditation Authority should deny access to the system; this is not the CP’s job.
• Each request should be evaluated and approved or denied on its merits. Abusive requests should not be allowed, and that should be captured by the CGM, not the CP.
• As long we CPs can report this kind of abuse to the system, and the system is able to prevent this going forward, this will be OK.
• This may be an implementation detail.
• Question 6: Is there a need to revisit this recommendation since it may have been written before the group agreed on the model? For example, does the EPDP Team envision that additional audits are necessary based on the model the Team has chosen?
• ICANN org in the model is the accreditation authority. If the authority decides to hire a third party, the audit requirements of the third party should exist.
• Question 7: does the team want to revisit the use of “SHALL” in this recommendation? Perhaps Staff could review this recommendation for consistency.
• Don’t shall and must have the same meaning? The language should be consistent throughout the document
• Question 8 from ICANN org: everything after the first sentence should be placed in implementation guidance instead of having it as a policy recommendation?
• Do not agree with this. There are parts of the recommendation that should be part of the actual recommendation.
• Agreement to keep as is.

2. Confirm next steps

5. Implementation guidance I (10 min)

1. Review discussion items gleaned from input provided on implementation guidance i discussion table

• Multiple requests can be submitted together, but they have to be submitted for the same reason.
• The requirement to consider each request on its merits still applies.
• Would it make sense to integrate this into Rec. 12 (query policy) as an implementation note?
• Yes, this is OK to move to query policy.
• On assumptions and takeaways, what does it mean that priority designation needs to be respected?
• The way the implementation guidance reads is that it should be possible for the requestor to enter more than one name into a request, but our understanding is that the same priority designation applies for all names in the request.
• Regarding the first bullet – agree that request should state clearly which trademark is being infringed. However, the first part of the bullet is problematic. Would not want to preclude the requestor to submit multiple requests – some are counterfeiting, and some are trademark infringement. For those reasons, everything after the semicolon is OK, but not the text before the semicolon.
• Instead of identical, could we use comparable or related – this may be too stringent a requirement.
• Do not understand what a “bulk request” is. If we have a trademark, and there are 400 names that infringe the mark – what if they are at different registrars? Either you are making a request for each domain name, or you make bulk requests.
• Seems like this is an implementation issue. Do not want to the concept to be lurking when we get into implementation. For convenience sake, a requestor could manually enter – here is a domain name, here is mark four separate times, or I could enter this once and the SSAD could sort it out. Each request would still be considered on its merits. Need to remove the word “bulk”. Perhaps use the word “batch.”
• Staff to move implementation guidance to Rec. 12.

2. Confirm next steps

6. Recommendation #15 Financial Sustainability (20 min)

1. Review discussion items gleaned from input provided on Financial Sustainability discussion table

• Question 1: Should MAY change to MUST
• Troubled by the use of MUST b/c there may be a class of entity that should not be charged.
• Pushed for MAY here b/c governmental agencies may have issues paying for access
• Retain the word MUST. For the SSAD, the cost associated with vetting and accrediting an applicant do not go away depending on who is using it. However, in favor of a subsidy program either by SSAD or by ICANN. But in the scope of this recommendation, the costs should be tracked accurately and completely.
• Keep MUST, but put a footnote that certain SSAD users may be either subsidized or charged no fee, which would put everyone in the same position. In the MfE, one of the topics that the MfE would review is the financial sustainability, including fee structure and fee volume.
• Accreditation Applicants may be charged, but the costs can be met by the Accreditation Authority.
• Applicants must be charged…unless the Accreditation Agency itself bears the cost.
• Question 2: Would it be acceptable to retain the reference to data subjects not bearing the cost of having their data disclosed. Similarly, data subjects should not be subjected to explicit additional charges.
• Proposal to remove the word “their” and have it read “of having data disclosed”
• What does explicit additional charges mean? Do not agree to this addition as unclear what the intent is.
• Registrars cannot add on a new fee to cover the costs of SSAD. Have a problem with removing “their” since Registrants are the source of money.
• From the Rr side, it was a concern that ICANN might pay for this by adding money to the ICANN fee. This is a concern b/c registrants would then be indirectly paying for this. Thinking this could be like the UDRP – ultimately requestors filing cases are pay fees for the processing of the cases.
• Do not want to strike “their” in the first sentence. In the second sentence, CPs must not charge registrants for charges associated with disclosure decisions.
• If ICANN cannot fund this, we need to say that, but there is not agreement on this.
• This sentence was discussed extensively in Los Angeles.
• We are not precluding ICANN from funding this.
• All in all, data subjects should have to pay more just b/c we have an SSAD.
• ICANN may spend money to set this up, but accreditation fees should help recover this. The idea of ICANN subsidizing users is not permissible under this.
• Question 3: Further consideration will be given in the implementation phase for which types of governmental entities fees may need to be waived
• This was previously discussed
• Change the last sentence to "The EPDP Team also recognizes that governments may be subject to certain payment restrictions which should be taken into account in implementation.
• Question 4: creation of a legal risk fund – can the group provide specifics or note why this is necessary?
• Do not think this should be stricken
• This is not the CP risk, but also the risk of ICANN getting sued based if they are deemed as a data controller. Legal risk should be managed for all parties.
• The legal risk fund will be developed further in implementation.
• Support Staff to capture Alan Woods’ comment in a footnote.
• “Given the potential for legal uncertainty and the heightened legal and operational risk on all parties included in the provision of the SSAD, creation of a legal risk fund refers to the creation of a suitable legal contingency plan, including but not limited to appropriate insurance cover, and any other appropriate measures that may be deemed sufficient to cover potential regulatory fines or related legal costs.“

• Question 5: is further reference needed with respect to historic costs?
• Do historic costs refer to set-up costs of the system?
• First sentence references costs for developing, deploying, and operationalized the system.
• Part of the historic costs are also what CPs are incurring for providing disclosure outside of the SSAD (the existing processes)
• The SSAD will remove some of the historic costs – for example, the requests for names registrars do not manage
• Can the reference to historic costs be removed?
• Historic costs are not part of the calculation
• Historic costs – costs being borne by contracted parties in the absence of an SSAD
• We should be clearer about how this will be calculated or how it would work in effect.
• Support staff’s understanding that developing and deploying the system may be considered in the cost-recovery basis.
• Could the team just keep the first line of the paragraph and delete the rest.
• Ask Support Staff to finetune the notion of historic costs and start the next call with this conversation.
• EPDP Team members are encouraged to review the questions ahead of time and provide feedback on the list.
• Tuesday’s call will be 3 hours

2. Confirm next steps

7. Recommendation #19 Evolution Mechanism (20 min)

1. Review input received on updated draft recommendation
2. Confirm next steps

8. Review of public comments received on the addendum (15 min)

1. High level overview (see discussion tables)
2. Confirm next steps

9. Wrap and confirm next EPDP Team meeting (5 minutes):

1. Tuesday 2 June at 14.00 UTC (tentative). Topic to be addressed: any topics not completed during today’s meeting.
2. Confirm action items

1. Confirm questions for ICANN Org, if any