Dear EPDP Team,

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

The next meeting will be tomorrow, 2 July at 14:00 UTC and will run for 4.5 hours (if needed).

Best regards,

Marika, Berry, and Caitlin

--

Action Items

1. In advance of tomorrow’s meeting, EPDP Team members to please review the updated Rec. 16/7 and provide “cannot live with” items with both an accompanying rationale for why this is a “cannot live with” item and specific suggestions for how the concern can be addressed.
2. For the remaining yellow items, EPDP Team members to please provide additional clarification in advance of tomorrow’s meeting.

EPDP Phase 2 - Meeting #70

Proposed Agenda

Wednesday 1 July 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)

• Rec. 6 issue – paragraph 5 – no objection to including the language, “nor can refusal to disclose be solely based on the fact that the request is founded on alleged intellectual property infringement”
• Can the Team live with this change?
• EPDP Support Staff to apply change

4. Consider outstanding items / questions in relation to recommendation #19 – Mechanism [docs.google.com]

a. Review outstanding items / questions

• Can the EPDP Team provide additional guidance on how the difference between policy and implementation can be further delineated? For example, the following items were included in a previous iteration. Which of the below (if any) can be considered changes to implementation?

i. SLAs (recommendation #9)

ii. Automated use cases (recommendation #16/7) – review and assess possible updates to implementation of types of disclosure requests that can be automated;

iii. Third-party purposes / justifications (recommendation #4) – review and assess possible updates to third-party purposes / justifications;

iv. Financial sustainability (recommendation #15) – review and assess possible updates to implementation guidance in relation to financial sustainability.  

v. Operational and system enhancements - only for those items where ICANN org is looking for guidance from the GNSO Standing Committee.

• Items that stay within the SSAD could be an implementation change. Items that flow through to contracted parties as obligations by ICANN Compliance would be new policy work, not implementation. As a starting point, ii would be policy, not implementation.
• For third party purposes as a policy change, when we drew this list, it was about populating the drop box with a standardized formulation of purposes.
• The scope is broad, and the standing committee can look at all of the issues of SSAD. It may be that the Standing Committee identifies it is a policy issue and refers it to the GNSO as a policy issue.
• One of the most pleasing parts of this mechanism is that it has a broad scope of that the standing committee can consider – not in favor of earlier suggestion. Want to ensure that Advisory Committees are consulted vis-à-vis the charter
• This mechanism does not go far enough with what the evolutionary mechanism is meant to address – the policy, for example, the policy would be automatically updated for a new legal purpose. Section 4.2 of the Temp Spec said that if there is legal clarity given from the EDPB that clarifies legal purposes, that would update the requirements.
• It is not an issue of whether the group can discuss it or not, it’s an issue of how this can be resolved. If it is deemed policy, and therefore a PDP would need be created, that is not what we agreed to. That is the crux of this. CPs would have to agree with recommendations of the Standing Committee, but for use cases that will not create liability, they need to be automated without a PDP.
• The Team should not create a mechanism that would bypass the bylaws and the PDP process. For automation use cases, for example, the policy recommendation suggests that use cases are automated when it is legally permissible, it needs to be automated
• Cannot make a mechanism that bypasses the policy development process – this seems to be what other members are saying. This committee can make recommendations to the Council, but it can’t just change what is legally permissible. What does it mean to say things that are automatically adjusted – based on what? This is not acceptable.
• There are two ways to get binding policy obligations into a contract – a GNSO PDP or direct negotiations b/w contracted parties and ICANN org. We cannot create a mechanism that creates a third way to create binding policy obligations.
• If there is a policy consideration, the Council could then launch a PDP
• What if we get legal guidance and, on the fly, adjust the contractual obligations of contracted parties – this is not something that CPs can agree to as part of this PDP. That is a fundamental change to the bylaws. Saying that CPs have a veto still does not make this OK. This circumvents the GNSO policy development process. Do not understand the use case others have raised – we have established that CPs can automate. If others are trying to force automation, do not see how this could be interpreted as anything other than policy.
• For Mark Sv’s list of use cases – the Team said it could be handled in evolution. If a decision is made to implement the ARS, the info would need to be released to ICANN – it would not impact privacy, and there would be no liability to the contracted party, that would be something that could be automated without changing the policy. That is the point that a number of others agree to – if there is agreement from CPs that it does not increase liability, it is not a change in policy, it is an implementation of policy.
• Understood that the mechanism would be the place where future legal clarity would be considered. This would not be a policy change if the law evolves to a place where another legal basis is added or another purpose where it is permissible to access data. This would not go outside the bylaws, it’s just implementation of a broad policy recommendation that has been vetted by this group.
• The conversation that we’re having here that cases where it is commercially feasible, is a statement of policy. What if six months from now after this policy is implemented, the EDPB said – the UAM presented by ICANN org to the EDPB is absolutely compliant with GDPR and the only controller with respect to transfer of data to the third party is the CGM. That suggests that use cases could be automated, but does that go all the way to adopting the UAM? You could say theoretically it is just implementation of policy, but that turns on other policy changes being adopted – moving from SSAD to a UAM would clearly be a major policy change
• There is more to data protection law than disclosing data to third parties – CPs are still responsible for handing data over.
• What may constitute policy and what may constitute implementation of existing policy. Does it give CPs any comfort to know that there would not be any automatic adjustment of automated use cases, but if there is new legal advice, this would be a subject for the standing committee to grapple with. The standing committee would still need to ensure it is dealing with implementation and not policy.
• There are two levels of safeguards – one is within the standing committee itself, and one is within the Council
• What we’re looking for is not policy development. The UAM has some key differences from what is developed here. We’re looking for types of automation and centralization that is allowable with further legal guidance. Section 4.2 of the Temp Spec – as soon as there is legal guidance from a competent body, CPs need to provide data within 90 days of guidance being published. Adding new automation use cases is not a policy change. What is legally, commercially and technically viable will change over time, and we need to get this updated without having a PDP.
• The Team discussed centralization but decided not to take that path. Automation may replace centralization in the future.
• Do not agree that Rec. 19 could change or evolve into a totally different model like a UAM. This is not possible through Rec. 19. Ask CPs to pinpoint what items could not be addressed because of contractual obligations.
• Limiting the language to automation is OK for CPs, but decision making could be done at the CGM that is not fully automated
• If the Team wants to achieve consensus, evolutionary mechanism needs to be a part of it. It appears that every group is a bit uncomfortable with this recommendation, which means there is balance.
• Is there anything under paragraph b that groups cannot live with?
• The text on the screen is not the problem. It is the unspoken part that is not OK. If the CPs agree that there are some use cases which could be implemented b/c they have been demonstrated to be legal and there is not a liability increase for CPs. If these, instead, would have to go to a PDP – ALAC cannot agree to this. This hinges on what is unsaid.
• It seems that ALAC is saying that this committee, after doing its due diligence determines that something is legally permissible, the output of this committee would be a requirement for CPs to automate. NCSG would not agree that there are use cases that may be identified later that meet these criteria that would require them to automate. This is something that contracted parties need to determine themselves during a PDP.
• Thought the Team had crafted the Rec. 16 carefully enough that automation is a MUST if legally permissible, technically and commercially feasible
• The default voting threshold for GNSO Council motions that are not explicitly called out in the Bylaws have a simple majority threshold.
• The GNSO has clearly established procedures for voting thresholds, and it takes into account the bicameral nature of the GNSO. Changing GNSO operating procedures and voting thresholds is not in the scope of this group. It needs to be clearer here that consensus requires for support from Contracted Parties.
• The preceding sentence should be majority consensus, not full consensus.
• If we were to go for unanimity, this may not be operational b/c one group could block consensus.
• ALAC introduced having ICANN org liaisons to the committee – understand where that may be helpful – need to be clear on what the role would be. Since this is under the consensus section, it seems that ICANN org would be part of the consensus – this seems incorrect.
• Consensus should consider equally the views of all.
• B/c of potential liability and fines, CPs are specifically called out.
• Some degree of consent for CPs is required – no one submits to ICANN’s authority except voluntarily
• SSAD operator should have a veto and should be a party to any new recommendation

• Does the scope for the GNSO Standing Committee require further limitation? Note: there is a proposal from the RrSG to include the following sentence, but GAC has expressed disagreement: “The Charter must not be restrictive in allowing the Committee to address any operational issues involving the SSAD, but should be clear that issues already addressed (meaning discussed, if not necessarily resolved) within Phase 1 or 2, including Phase 2 Priority 2 issues, are not part of this team’s purview.”

• How will the GNSO deal with recommendations from the GNSO Standing Committee, i.e., what is the voting threshold to approve, and upon approval, do the recommendations go to ICANN Org for implementation or require a GNSO Policy Process?
• Does the consensus process require additional updates? Some members have noted full consensus is difficult to achieve, and others have noted full CP consensus should not be required for every update (but may be required for updates to SLAs, for example). Can the Team provide further guidance on when full consensus or full consensus of the CPs is required?
• RrSG proposes to remove the following items from the bulleted list in paragraph 1, noting these should only be b/w the CP and the SSAD operator. Does the EPDP Team agree to this removal?

• Number of disclosure requests automated by the Central Gateway;
• Number of disclosure requests automated by the Contracted Parties;
• Number of requests processed manually

• This bulleted list was included in the previous proposals – it was just to reflect that data points could feed into this.
• Do not understand why these bullets are proposed to be removed
• Consider changing to number of decision requests automated
• Note – this is a minimum list of requirements
• The data we’re talking about here will be produced by the CGM and will not require CPs to manually prepare data
• Issue with changing “no later” to “no earlier” – not comfortable leaving it completely open ended – propose a cap – no earlier than 3 months, no later than 9 months
• Instead of specifying a status report, it may be possible to implement these statistics on a rolling basis
• Consensus = consensus plus (with CPs), NOT full consensus
• Concerned that full consensus was taken out – this consensus puts the NCSG at a disadvantage against the commercial stakeholders group
• If the Team is going to insist on representation for EPDP, that would be 25 people – that cannot work. If full consensus is required, ALAC or GAC could veto.
• Suggest to add two additional hours to tomorrow’s call

b. EPDP Team Feedback

c. Confirm next steps

5. Continue run through of yellow items [docs.google.com] (items identified for further discussion / clarification)

a. Consider yellow items identified for recommendations (continuing with rec #15 and moving down the list)

b. EPDP Team feedback

c. Confirm next steps

6. Consider outstanding items / questions in relation to recommendation 7/16 (automation) [docs.google.com]

a. Review outstanding items / questions

b. EPDP Team Feedback

c. Confirm next steps

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

a. Thursday 2 July at 14.00 UTC. Topics to be addressed: Any remaining items.

b. Confirm action items

c. Confirm questions for ICANN Org, if any