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

1. EPDP Team to review the updated CPH-proposed language on Financial Sustainability by Tuesday, 3 December.
2. Support Staff to update the Response Requirements building block based on the EPDP Team’s discussion by Wednesday, 27 November.
3. 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