[Gnso-epdp-team] Notes and action items: EPDP Team Meeting #30 - 21 November 2019

[Caitlin Tubergen]

Dear EPDP Team:

 

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

 

As a reminder, the next meeting will be Tuesday, 26 November at 14:00 UTC.

 

Best regards,

 

Marika, Berry, and Caitlin

--

 

Action Items
Support Staff to assist in working with the volunteers for the new Authorization Provider Building Block. Volunteers are Sarah, Marc A., Margie, and Alex.
Janis to send chair-proposed questions to ICANN org regarding a cost-benefit analysis of the SSAD.
Support Staff to update the Financial Sustainability Building Block in light of the discussion during the meeting. (complete)
EPDP Team to review the updated Financial Sustainability Building Block before the next meeting on Tuesday, 26 November. 
 

EPDP Phase 2 - Meeting #30

Proposed Agenda

Thursday, 21 November 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)                      Update from the legal committee
The Legal Committee met on Tuesday
The LC has worked through the majority of Priority 1 questions, and is in the process of reviewing the updated guidance on territorial scope from the EDPB
The LC has begun reviewing the Priority 2 questions
The LC is almost finished with the summaries of the Phase 2 legal memos and these will be forwarded to the plenary team as soon as available 
b)                     Status of building blocks
While there are still a few blocks to work through, still hopeful to complete these by mid-December
Please continue working to complete all homework assignments in a timely manner
4.                            Responses received from ICANN Org and ICANN Board (20 minutes)

a)                      High level overview (ICANN org & ICANN Board liaisons)

ICANN org Response
ICANN org received the questions shortly before the Strawberry Paper was published
The paper goes into greater detail for those interested
The model in the paper is focused on two goals: centralize the decision-making power and promote a more consistent user experience
With respect to fielding requests for non-public data, this would be delegated to other parties. 
With respect to Question 4 and the responsibility for the decision, there are various decision points outlined in the paper. The gateway is a conduit among the different actors. 
Board Response
The Board has heard that having a predictable and reliable experience in terms of requesting and receiving responses for those with legitimate interests is critical. That means that decision making with respect to responding to requests needs to be centralized. 
The Strawberry Paper assumes the responsibility for the decision making would be made by the centralized model, rather than the contracted parties
The Board has not reached final conclusions on this but wants the community and the EPDP to understand that the Board would like the model to centralize the decision and inoculate CPs of liability as much as possible
b)                     Feedback from EPDP Team
With respect to the letter from ICANN org, there is an idea that the disclosure decision will be made by community-developed policy. The Team, thus far, is not clear who will make the disclosure decision. What part of the work the Team has done would determine the disclosure decision? There is no building block on this.
With respect to both letters, the feedback is interesting but is unlikely to move the ball forward. The Team really needs feedback for the EDPB – either the Team waits for answers, or the Team decides and agrees to a model with the information it has today, which may be flawed.
With respect to the proposed model, there is a reference to authorization providers as the entities that make the decision. If the EDPB says no one can make the decision except CPs, then the CPs are the authorization providers, but the model could still be centralized. The question comes down to can ICANN be the authorization provider for some decisions. It is implied that if ICANN can be the authorization provider, it is willing to assume the liability.
Disturbed at the extent at which the UAM is used as the touchstone for the decision. Many of the team members objected to the TSG and the potential for preempting policy decisions. Caution the Team against jumping to a conclusion that because ICANN is willing to be a centralized decider to make it the centralized decider. With respect to the EDPB advice, it’s like asking a court for a decision before a specific case is in front of it. 
Ask Janis to respond to Goran and the Board and thank them for their input. Based on these replies, there is a missing building block for authorization providers and answer who gets access to what data under what circumstances. 
Understand that this is not so much about shifting liability but recognizing that ICANN has liability as a likely controller it can assume liability from the CPs. There is unlikely to be a scenario where the CPs have no liability.
With respect to the suggestion that we are missing a building block on the authorization provider, could there be a rough outline for this or organize a call with interested members to discuss this with support staff
c)                      Confirm next steps
Sarah, Alex, Marc, and Margie to work together on a new building block for authorization providers.
5.                            Financial sustainability – second reading (20 minutes)

a)                      Review draft question developed by Marc and James
The idea of this letter came out of the financial building block, where a financial sustainability analysis is requested to be performed by ICANN org. If the Team is recommending this study, it is too late since recommendations are being made in the meantime. It is critically important that the Team understands what the financial model for this system will look like and is critical to get these questions to ICANN org as soon as possible.
Is there any objection to sending the questions as written to ICANN org?
The letter contains certain assumptions the group has not agreed to, namely, who bears the burden of the costs of the system. The Team has not agreed that the entire burden of the system falls to the users of the system.
The beneficiaries of the system are those who want data disclosed to them. It is distortive to make requests free. If the Team can agree that people who make requests should have to pay for the requests, no matter how small, that would be acceptable. Domain name registrants should not have to pay for their own surveillance.
Those who request disclosure are not the only beneficiaries – everyone benefits from a consistent and accountable system.
Proposal to strike from the letter the sentences/paragraphs that currently are numbered as one and two, but keep the rest, could this letter be sent? 
Request for more time to read and digest the letter and respond with concrete updates and suggestions.
Do not support removing the questions of the letter.
Proposals for such a system include operating under these principles – the team is ultimately looking for protection of the registrant. While CPs are making these decisions every day, the additional system that is to be created is an additional cost.
How much will ICANN be able to assess the cost of the system? Could the CPs provide some estimates?
Either the team is building a system or it’s not – would recommend removing text accordingly
Uncomfortable with principle 2 since there is no consensus on that
Janis could take full responsibility to ICANN org to make a cost estimate and create a small team to hash out the letter
Question to Team: Janis to take responsibility to send the question out
Action: Janis to send questions on his own behalf by tomorrow
b)                     Review building block
Paragraph 1
No objections
Paragraph 2
Do not understand the equal savings concept here. Savings is not a feature of the system, so object to this language.
Concern with this language is that it is saying that cost must result in equal savings for each contracted party – this seems to indicate that depending on the size, the policy compliance may differ by CP.
It is not possible to know all sizes and different business models – even putting up a website to receive requests would be a different cost for different sized registrars.
The basic idea behind the language is correct, but the wording is bad. Equality assumption is unrealistic here – there will never be equality b/w comparing Verisign and a tiny registrar. The key concept here is the cost-benefit ratio – the cost reductions are meant that manual response to requests would be more expensive than responding through the system. May want to throw in a protective clause that any system that imposes unreasonable burdens on smaller operators would be avoided.
Support idea of projection of expected number of requests and then compare an SSAD model to responding directly.
Based on this discussion, Support Staff to propose language re: proportionality and cost-benefit analysis should be taken into account. 
Paragraph 3
Someone who has proposed to change language that makes sense with language that does not make sense – do not understand what cost allocation means. Cost allocation is, by definition, arbitrary. 
Both accreditation system and the subsequent running of SSAD should recover costs incurred.
Agree to revert back to original language
Paragraph 4
Questioning the value of this addition.
Whatever cost structure is imposed must take into account that public authorities have limited resources, and their role and resources need to be taken into account
Based on the costs they generate instead of infrequent users – delete the second part after the semi-colon.
With respect to the first sentence, could rephrase for the recognition that costs with respect to the use of the system may differ from user to user
Paragraph 5
This is far too long and too prescriptive
Hoping this paragraph will be overcome with the events of the letter sent. Suggest deleting this paragraph at this point and put in a placeholder for further consideration once ICANN responds to Janis’ letter
Important to provide for an oversight and appeal mechanism based on fundamental fairness. Also propose adding sentence that registrants should not bear the cost of third parties having access to their data
Paragraph 6 (Accreditation)
The subscription model is an interesting concept – that would allow flexibility in terms of costs
Concerned with sub-bullet c and the last point
Could we say the fee structure should be reviewed as the operationalization of the fees evolve
The fees should follow the principles of the policy
c)                      Feedback from EPDP Team

d)                     Confirm next steps

 

6.                            Response requirements (building block g) – second reading continued (20 minutes)

e)                     Review building block

f)                       Feedback from EPDP Team

g)                      Confirm next steps

 

7.                            Terms of use – second reading (20 minutes)

h)                     Review building block

i)                       Feedback from EPDP Team

j)                       Confirm next steps

 

8.                            Automation – second reading (20 minutes)

k)                      Review building block

l)                       Feedback from EPDP Team

m)                   Confirm next steps

 

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

 
Initial proposal from Leadership is to have meetings on 26 Nov and 28 Nov, and some team members requested to cancel the meeting on Thanksgiving. 
Proposal to move meeting on 28 to move to Wednesday, 4 Dec. Last meeting of the team will be 19 December and resume either on 9 January or 16 January.
a)                      Tuesday 26 November at 14.00 UTC

b)                     Confirm action items

c)                      Confirm questions for ICANN Org, if any

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20191121/a172f759/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4620 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20191121/a172f759/smime-0001.p7s>