The call for the IDNs EPDP team will take place on Thursday, 13 October 2022 at 13:30 UTC for 90 minutes.

For other places see:


  1. Roll Call and SOI Updates (2 mins)
  2. Welcome and Chair Updates (5 min) 
  3. Review of Revised Project Plan (15 mins)
  4. Review language for recommendation 2.6 (20 mins)
  5. Approach to string similarity (Charter Questions B4a, E3a, and E4) (45 mins)
  6. Charter Question D1b (time permitting)
  7. AOB (3 mins)





Apologies: Anil Kumar Jain


Audio Recording

Zoom Recording (including audio, visual, rough transcript and chat)

GNSO transcripts are located on the GNSO Calendar

Notes/ Action Items

Action Items

Action Item 1: EPDP Team members to respond on list about whether to do one Final Report or two Final Reports.

Action Item 2: ALAC representatives to take into account RySG feedback on the proposed IG and provide additional feedback.


SOI updates

  • Maxim is no longer a GNSO Councilor.

Welcome and Chair Updates

  • Today’s discussion focuses on several topics we have discussed previously.

Review of Revised Project Plan

  • Framing: the leadership team had further discussion after the EPDP Team call last week. Leadership team would like input from the Team on doing 2 Final Reports, one for phase 1 and a second for phase 2, rather than doing one combined Final Report. By doing two Final Reports, the timeline discussed last week will expand again. While the optics may not be favorable, it may be better from a pragmatic perspective.
  • As Chair, Donna supports two Final Reports, which will allow the EPDP to deliver top-level recommendations to the Council and then the Board while the phase 2 work progresses.
  • Leadership understands that some in Council will have questions about the length of the extended timeline. The original estimates were rough estimates and they were optimistic. The new estimates build on what we now know. They are conservative, so that the Team does not need to continue to submit additional PCRs every time there is slippage on a milestone.
  • The goal is to deliver the work ahead of the revised schedule.
  • The EPDP Team might want to consider if there are times when it might be helpful to have two meetings a week, for example to support conversations that are more complicated and require introduction before deliberations.
  • To consider: How can we do our work a little differently to help us speed up the work?
  • Slide 4 – Option 1: One Phased Approach (Updated)
    • Initial Report Part 1 Public Comment: 21 April 2023 
    • Initial Report Part 2 Public Comment: 3 January 2025 
    • Final Report submission to Council: 29 August 2025
  • Slide 5 – Option 2: Two Phase Approach
    • Phase 1  Initial Report Public Comment: 21 April 2023 
    • Phase 1 Final Report submission to Council: 3 November 2023
    • Phase 2  Initial Report Public Comment: 25 April 2025
    • Phase 2 Final Report submission to Council: 7 November 2025
  • Because this group is representative across the community and we are taking time to get input from org along the way, when we put the Initial Report out it will be in relatively good shape. We shouldn’t get a lot of public comments that require substantive work. Therefore, the Final Report should be submitted to Council well before November next year.
  • With phase 2, if TechOps can do considerable work to help support that work, that puts the group in a position to do substantive work through 2024.
  • EPDP Team leadership met with Karen Lentz’s team (ICANN org GDS). Recognizing that the ODA should be provided to the Board in Dec this year, the next steps are still being determined.
  • Leadership team is aware of the dependency of this work on the next round and will keep in contact with Karen’s team as they develop timelines for next rounds. There are still some unknowns on the next rounds timeline and we will do our best to make sure that the EPDP is not getting in the way of that work.
  • Comment: It would be helpful for Edmon to go back to the Board and get feedback on the dependency between this work and next rounds. The EPDP should try to beat this timeline. We should try to be more aggressive, especially in phase 2. If we set conservative timelines, we will meet and not beat them. The first phase work without the second phase work may not be sufficient for subsequent rounds planning.
  • Edmon will take this issue back to the Board and seek to provide feedback.
  • Comment: If there is an opportunity for F2F time, we should explore that.
  • Comment: Agreement that the timeline is conservative and we can aim to beat it, but it is useful to lay out for the community that there are difficult issues that need to be hashed out. IDNs could possibly go ahead in subsequent rounds without variants.
  • Question: Is there anything in Phase 2 that would impact next round?
  • Response: In conversations with Karen’s team and at the leadership level, even though the second level topics wouldn’t kick in until after delegation, the details of some elements may need to be incorporated into the AGB and the application process itself. The implementation of SubPro is a considerable amount of work. There are many moving parts.
  • Looking at the two approaches, the one phase approach only saves two months of time.
  • Outstanding question – we don’t know how long it will take TechOps to do its work prior to phase 2. There will be conversations about this in the CP Summit the first week of November. Hopefully we can get a better sense of this following the Summit and that input can feed into thinking about Phase 2 timeline. We might be able to have a small group working on Phase 2 charter questions at the same time as we are finalizing the phase 1 report.
  • Informal “temperature of the room”—13 responded in favor of two Final Reports and none in favor of one Final Report.

Action Item 1: EPDP Team members to respond on list about whether to do one Final Report or two Final Reports.

  • Suggestion from one member to have a face-to-face retreat for a 2-3 day period. Leadership can look into whether this is feasible and whether that would be productive.

Review language for recommendation 2.6

  • ALAC proposed language in second to last sentence of the rationale of recommendation 2.6: “Therefore, the applicant will be required to respond to additional application questions to address why they seek to activate those variant label(s) in addition to the primary new gTLD (i.e., necessity and expected usage of the variant labels), as well as how it plans to manage the set operationally to achieve the security and usability goals for their set in a stable manner. This would contribute to ensuring a good user experience.”
  • ALAC proposed IG (new): “Implementation Guidance 2.xx: Submission by applicants of supporting information must allow for a consistent and meaningful evaluation by evaluators with the requisite expertise.”
  • ALAC rationale: Regarding revised rationale, suggested elements are already included in the Charter, so they are appropriate to include here. Additional IG speaks to previous comments from RySG.
  • Comment: from RySG perspective, we are coming closer to middle ground. We are moving away from expectations that registries manage consistent user experience, which is good. Regarding usability goals and user experience, it’s true that the charter calls these out without defining them. It’s important to look at how those terms are used in the charter in context. Regarding usability goals, the biggest usability goal is to have a management framework to allow those labels into the root zone. In terms of good user experience, the context in the charter is focused on how IDN tables are set up and provide consistency in terms of the results they produce. However, they do not need to behave the same with respect to the disposition values. If refer back to the context of how those terms are being used, the language may be acceptable.
  • On the proposed IG, comment from the RySG perspective: It should be the process and requirements that should set up for a consistent and predictable process, not the submission by the applicant. Every step of the evaluation process needs to be meaningful and we would expect that the necessary expertise is being leveraged. Why would we need to emphasize those aspects of the evaluation process? We expect them to happen regardless.
  • ALAC response: This is the first time we are doing this evaluation element, so we think it should be called out. ALAC will provide a more detailed response with possible proposed revision.
  • Perhaps what is more important is that evaluation of IDN applications should be consistent. There isn’t a way to ensure that what the applicants provide is consistent unless there is a technical format that needs to be followed. That is not something that is possible. From one perspective the proposed IG needs re-consideration.

Action Item 2: ALAC representatives to take into account RySG feedback on the proposed IG and provide additional feedback.

Approach to string similarity (Charter Questions B4a, E3a, and E4)

  • While there seems to be some support for the hybrid model, there are some items from the feedback to discuss.
  • Slides 8 – 12 – summary of feedback and positions submitted on the mailing list.
  • ALAC, GAC, and NCSG supported the hybrid model.
  • RySG raised additional considerations: string similarity process should not rely solely on the RZ-LGR for visually confusable labels, but may be used as an input; careful consideration should be given to implementation to achieve consistency and predictability of outcomes; procedure should identify and remove mix-script labels from further consideration to avoid unnecessary work.
  • IPC -- hybrid model needs to have an exception process. For example, if there is a Brand that has a name which happens to be a non-allocatable variant of another string that has been delegated, then we believe that new Brand should be able to overcome any potential string similarity review of string confusion objection.
  • Elaboration from IPC – without an exception process there is not support for the hybrid model.
  • Comment: the hybrid model doesn’t create the situation in the case of objections. It’s the implementation of the RZ-LGR that makes this the case. We’d have to change the RZ-LGR to make this exception possible.
  • Response: Disagree, it is the hybrid model that would be a limiting factor.
  • When we talked about the hybrid model, we talked about the ability to appeal (object), which may allow for this exception process. Objection by a brand owner could then allow them to use their string in the next round.
  • Response: Brand owners will not be monitoring applications on an ongoing basis and file objections preventatively.
  • We need to ensure if trademark owner can object, that we take into account how long the trademark has been around to prevent gaming.
  • Appeal had a specific meaning in SubPro. This is something different. The term rebuttable presumption or similar should be used because the standard is different.
  • Next step: Throughout the discussion about the hybrid model and the different alternatives, the ability to implement has been on our minds. Now that we see that there is some support for the hybrid model with conditions, the Team will see what feedback ICANN org comes back with from an implementation perspective and then pick up on this conversation again.
  • No labels