The meeting of the GNSO Temp Spec gTLD RD EPDP – Phase 2 is scheduled on Tuesday, 14 January 2020 at 14:00 UTC for 2 hours.

For other times:


  1. Roll Call & SOI Updates (5 minutes)
  2. Confirmation of agenda (Chair)
  3. Welcome and housekeeping issues (Chair) (5 minutes)
  4. Discussion of models for inclusion / recommendation in Initial Report

          a) CPH Proposal

          b) EPDP Team reactions

          c) Possible alternative approaches

          d) Confirm next steps

     5. Preliminary Rec – Audit (see draft Initial Report)

        a) Review comments / suggestions provided by deadline

        b) Feedback from EPDP Team

         c) Confirm next steps

     6. Preliminary Rec - Financial sustainability (see updated document)

         a) Continue review of remaining sections

         b) Confirm next steps

    7. Commence review of input received on draft Initial Report (if time allows)

        a) See issues list –

        b) Confirm next steps

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

        a) Thursday 16 January 2020 at 14.00 UTC

        b) Confirm action items

       c) Confirm questions for ICANN Org, if any


Audits - Preliminary Recommendation - 8 Jan 2020

Financial Sustainability - 13 January 2020

Input received on draft Initial Report - 13 January 2020

Meeting Audio Cast (for observers)

To join the event, click on the link: 

Listen in browser:

Listen in application such as iTunes: 




Apologies:  none

Alternates: none

Notes/ Action Items

Notes & Action items

These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at:

EPDP Phase 2 - Meeting #39

Proposed Agenda

Tuesday, 14 January 2019 at 14.00 UTC

1. Roll Call & SOI Updates (5 minutes)

2. Confirmation of agenda (Chair)

  • It would be preferable to discuss this issue during the F2F meeting.
  • It would also be helpful to develop charts to go along with the proposal. (Thomas to create visual components to aid in the F2F discussion.)
  • The Team has been discussing the hybrid model discussed in the Initial Report for some time now. Disagree that this conversation should be postponed. Due to the timelines, it would be preferable to at least begin this discussion now.
  • This proposal was a significant effort and a sincere attempt at bridging the differences. If the concern that EPDP Team members have not had enough time to review the proposal, that is a fair criticism. If this is the case, a small team could flesh out the proposal in advance of the F2F. It would be helpful to highlight the differences b/w status quo and the proposed improvements.
  • Based on the comments, the conversation should be postponed – the question is, when should this discussion occur? Many groups urged the Team to be as swift as possible since the current situation is not sustainable. Proposal: postpone the discussion – reread the CPH proposal and study Marc Sv’s tables, and allow small team (Thomas, James, Marc A., Brian, Mark Sv., Hadia, Franck, Alan G. and Chris Lewis-Evans to work together to flesh out the differences in the Team. Some members of the Team believe the hybrid model is the only workable solution, while others believe the Team should continue with the centralized model. Support Staff to arrange a time tomorrow.)

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

4. Discussion of models for inclusion / recommendation in Initial Report – DISCUSSION POSTPONED

  1. CPH Proposal
  2. EPDP Team reactions
  3. Possible alternative approaches
  4. Confirm next steps

5. Preliminary Rec – Audit (see draft Initial Report)

  1. Review comments / suggestions provided by deadline
  • Audit of accrediting authority – if the accrediting authority is ICANN, ICANN can do this function, but ICANN could also outsource the accrediting function to a contractor. What happens to accredited entities if ICANN has an irreparable breach.
  • IPC comment within the Initial Report – breach is too broad here – is this any type of breach, or a data breach? The second issue – what requirements of CPs would be lifted – is it all requirements – this is too broad. The term other entities is used, but “other entities” should be defined.
  • If the accreditation authority is breached, the accredited entities’ credentials could still be valid; alternatively, the credentials could be suspended until the breach is cured.
  • The word breach is confusing this this context since breach is both a contractual term as well as a data privacy term. The Team is not in a position to say – all accreditations are revoked. ICANN will have to take measures to remedy the breaches quickly since there is not a higher authority to remedy the issue on behalf of ICANN.
  • The point of this paragraph was to call upon existing accountability mechanisms for ICANN. What could help here is to clarify the term breach means “breach of the accreditation policy” and then delete the rest.
  • Would it be helpful to clarify that this is about breaches of accreditation policy?
  • Agree that “breach of the accreditation policy” remedies the issue. Following that, there may be further work on contractual language needed. IPC proposed language to get the Team started on this discussion.
  • The policy should be restrictive to breaches of policy.
  • If such a breach happens, refer to already-existing accountability mechanisms
  • There is probably an opportunity to leave some of these things to implementation. Where the Team expects things to be worked out by the IRT, this should be clearly spelled out in the policy recommendations. There is an opportunity to take this to a small team.
  • The Team needs to determine how the accreditation model will work before finalizing the details of auditing.
  • Proposal: If ICANN serves as the accreditation authority, existing accountability mechanisms are expected to address any breaches of the accreditation policy, noting that in such extreme case, the credentials issued during the time of the breach will be reviewed. Modalities of this review should be established in the implementation phase.
  • Breaches by the accreditation body apply irrespective of if ICANN is the accreditation body.
  • From ICANN org’s point of view – one challenge is who is doing what. For example, who is determining the breaches, who is disclosing the data, etc.
  • The four questions added at the bottom – propose adding a fifth one – who was affected by this improper data disclosure?
  • ICANN org issue – if there is an accreditation authority and an identity provider, is there a role for the identify provider?
  • “referred back to the accreditation authority or identify provider (if applicable) for action.
  • The Team needs to develop a chapter on those disclosing data – as soon as the agreement on who will make the disclosure decision, this can be fleshed out.
    1. Feedback from EPDP Team
    2. Confirm next steps

6. Preliminary Rec - Financial sustainability (see updated document)

  1. Continue review of remaining sections
  • Updated paragraph re: disproportionately high burden on smaller operators is acceptable.
  • Unreasonable would be easier to implement but can live with the disproportionately high.
  • Cost causation – proposal to strike “based on cost causation” or replace with “a number of factors”
  • Is there equivalent language that notes that some users will drive higher costs and should bear a proportionate responsibility for the cost
  • Consider as asterisk and footnote, describing what is meant – the volume, frequency, etc.
  • Action: Brian to consider footnote for cost causation
  • Under no circumstances paragraph – “foot the bill” change to “pay”
  • “bear the cost burden” instead of “foot the bill”
  • Propose to work with Amr to find common ground. Coming from – prohibition on ICANN funding any of this does not seem reasonable.
  • This is not a blanket prohibition – instead, ICANN is footing the bill for the development of SSAD, but operational and maintenance costs should also be borne by users of the system
  • Action: Brian, Amr, Stephanie, and Franck to identify a compromise solution for presentation to the group for the group to review by next Thursday.
  • “should not be profit-making for ICANN nor contracted parties” for anyone – if the work is subcontracted, the subcontractor may make profits
  • Neither should costs – should be deleted since same concept is mentioned in the previous paragraph, and that will be rephrased by smaller group.
  • Proposal to unbracket the first paragraph “the fee structure” and label as implementation guidance.
  • The EPDP will further consider – move down and put the heading “placeholders”.
  • The EPDP team also recognizes that the SSAD fee structure
  • Revisit during next Thursday’s call
    1. Confirm next steps

7. Commence review of input received on draft Initial Report (if time allows)

  • ISPCP asked about the use cases could be annexed to the Initial Report
  • Use cases should be further fleshed out – Belgian DPA is asking for exactly what is being done – what the Team has done. This could help with a response from the EDPB or Belgian DPA.
  1. See issues list –
  2. Confirm next steps

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

  1. Thursday 16 January 2020 at 14.00 UTC
  2. Confirm action items
  3. Confirm questions for ICANN Org, if any

  • No labels