Dear all,

Please find below the notes and action items from today’s meeting on Thursday, 23 February 2023 at 13:00 UTC.

Kind regards,

Ariel, Steve, and Emily

Notes and Action Items - IDNs EPDP Call – 23 February 2023

Action Items

Action Item 1: EPDP Team members who missed today’s call to catch up with the recording.

Action Item 2: EPDP Team members to consider if there are areas of the Initial Report that their groups will have concerns about and share with the EPDP Team.

Action Item 3: EPDP Team members to provide input on whether ask that public comments are submitted via a form.

Action Item 4: ALAC reps to discuss among themselves input on IG 2.xx and consider if the new set of recommendations and IG sufficiently address the ALAC’s underlying concerns.

Action Item 5: WG members to provide input on alternatives in brackets for Rec 1.5 on slide 8: “Recommendation 1.5: A framework for developing best practice guidelines in the management of gTLDs and their variant labels by registries and registrars must be formulated with a view to encourage a [predictable] [optimal] [consistent] user experience.”

Action Item 6: Regarding new Recommendation 2.16, change “voluntary or involuntary” to “voluntarily or involuntarily.”

Action Item 7: Staff to adjust language in Rec 2.22 to make sure it is clear that an existing RO who later applies for variants will keep the existing RA and get a new one for the new variants (two RAs).

Action Item 8: For Recommendation 2.8, change geoTLDs to geographic name TLDs and include in the list of non-standard application types TLDs to which GAC Safeguards apply.

Action Item 9: Leadership Team to connect with CJK Chairs to understand what progress has been made and what the anticipated timeline will be for their inputs on single character TLDs.

Action Item 10: Leadership team to put together draft language to extend recommendation 2.7 text regarding fees.

Notes

Welcome and Chair Updates

• Noting low attendance on the call, those on the call discussed whether the meeting should proceed. Some support was expressed for continuing the call and encouraging those in attendance to catch up with the recording and provide input on the mailing list.

Action Item 1: EPDP Team members who missed today’s call to catch up with the recording.

• Last week’s webinar for the GAC was well received. During the webinar, the GAC did raise the question of potential dependencies between this group’s work and SubPro, in particular with respect to Phase 2. The EPDP hopes to deliver Phase 2 ahead of schedule.
• Edmon noted that there is a Board group having discussions about the EPDP’s work. The leadership team is hoping to meet with Edmon and Alan Barrett (the two Board Liaisons) in Cancun to better understand the conversations and concerns at the Board level. This will help the EPDP manage expectation going forward.
• Slide 3 – Remaining Work Leading Up to Publishing Phase 1 Initial Report
• Target: Publish Phase 1 Initial Report by Friday, 21 April 2023
  Time Remaining: 8 Weeks (including ICANN76)
  • Review Draft Text: E3 [In Progress]
  • Review Draft Text: A8, B4a, E1, E2, E3a, E4, E7/B5
  • Review Revised Draft Text: Incorporating ICANN org Input (Substantive & Editorial)
  • Review Draft Text: Revised or New Recommendations Due to Gaps Identified
  • Consolidate Phase 1 Preliminary Recommendations
  • Review Draft Phase 1 Initial Report: Selected Sections
  • Approve Full Draft Phase 1 Initial Report
  • Confirm Public Comment Approach (e.g., public comment input form)
• For further discussion: Approach to public comment (whether to use a form to receive responses or simply request standard narrative responses)
• The leadership team has begun to discuss if there are specific areas where the EPDP Team would like input from the community during the public comment period.

Action Item 2: EPDP Team members to consider if there are areas of the Initial Report that their groups will have concerns about and share with the EPDP Team.

Action Item 3: EPDP Team members to provide input on whether ask that public comments are submitted via a form.

Review of draft recommendations that received substantive ICANN org input 

• Slide 5 – Input for D1b – Rec 2.6
• Slide 6 – D1b – Proposed Revision to Draft Recommendations – based on discussion of org input on slide 5 during previous calls.
• Support expressed for the revisions. Breaking up the text makes it clearer. This text goes into the right level details without going into detail about what the test will be. We will be talking about the same entity principle at the second level and how the principle impacts behavior from an operational standpoint. 2.21 gives permission to create that new test in order to manage the capabilities of the registry operation to manage a sent with the same entity principle in place.
• Regarding “[ALAC Input] Implementation Guidance 2.xx: The submission process by applicants of supporting information must allow for a consistent and meaningful evaluation by evaluators with the requisite expertise.” From one perspective, this language appears to be redundant. The whole process should be consistent and meaningful, so it is not clear why this specific element needs to be called out here.

Action Item 4: ALAC reps to discuss among themselves input on IG 2.xx and consider if the new set of recommendations and IG sufficiently address the ALAC’s underlying concerns.

• Clarification on the Turkish example provided by org in comments on slide 6:  There are exceptions in the Latin LGR for two characters that have allocatable variants. The dotless i has an allocatable variant “i”. The German sharp s is also an exception. This is because when IDNA2008 deprecated IDNA2003, there were four examples of deviations that behave differently. Due to the co-existence of both protocols in the application layer, the variant relationship needed to be created minimize security concerns. The dotless i exception is about the local treatment in Unicode. It displays differently depending on local settings in the computer. Due to uncertainty about behavior at the application layer, the variant relationships were created to minimize security concerns.
• Regarding revision of 2.6 – D1b deals with existing ROs getting variants, as well as new applicant getting a new TLD and variants. Suggestion to change “to explain why it needs to activate one or more allocatable variant label(s)” to “to explain why it seeks one or more allocatable variant label(s)” to cover the different scenarios.
• Question: Does the current language sufficiently apply to scenarios involving both existing and new applicants? This may need further review by the group.
• Slide 7 – Input for A5 – Rec 1.5
• Slide 8 – A5 – Proposed Revisions to Draft Recommendations
• Regarding IG 1.6 – Should resellers be mentioned in the list of stakeholders involved in developing best practice guidelines?
• It was previously suggested that resellers should be involved, but this was removed because, as contracted parties, the registrars are the more appropriate stakeholders to weigh in.
• Regarding edit to IG 1.6: Using “an interest in IDNs” is too broad and may be appropriate to make more narrow, as suggestion in the revision. “Experience with IDN and variant labels” seems more appropriate. One way to think about this is to focus on registrants who have IDNs and variant labels.
• Feedback is welcome on the alternatives in brackets for Rec 1.5: “registries and registrars must be formulated with a view to encourage a [predictable] [optimal] [consistent] user experience.”

Action Item 5: WG members to provide input on alternatives in brackets for Rec 1.5 on slide 8: “Recommendation 1.5: A framework for developing best practice guidelines in the management of gTLDs and their variant labels by registries and registrars must be formulated with a view to encourage a [predictable] [optimal] [consistent] user experience.”

• Slide 9 -- Input for A9 – Rec 1.12
• Slide 10 – Proposed Revision to Draft Recommendation
• No additional comments about new IG 1.15, which is added to original Rec 1.12.
• Slide 11 -- Input for A10 -- Rec 1.13
• Slide 12 – D8 – Proposed Revision to Draft Recommendations
• Note that the term “un-delegated” as used in slide 12 might be revisited pending additional input from ICANN org.

Action Item 6: Regarding new Recommendation 2.16, change “voluntary or involuntary” to “voluntarily or involuntarily.”

• Question: Is the language under Charter Question D8, “labels under variant TLDs,” Is intended to be limited to the top-level, or is it also applicable to the second level?
• Response: This is a catchall question –it may be applicable to the top-level and second-level. When the charter question was developed, the language may not have been precise enough. It may be that there is a better place to put these recommendations than under Charter Question D8.

• Follow-up: It may not be a problem as long as the charter provides the necessary context for the Charter Question.
• In principle, agreement to move forward with recommendations with the possibility of changing the term “undelegation,” depending on further org input.
• Slide 13 – Input for B1 – Rec 2.1
• Slide 14 – D1a – Proposed Revisions to Draft Recommendations
  • Revisions to recommendations seek to distinguish between the case of the an existing and a future IDN gTLD and the impact on the RA(s).
• Leadership’s intent in recommendation 2.22 is that an existing RO who already has a contract with ICANN would then have a separate agreement for any newly added variants, but would keep their existing contract. This means that there would be two Registry Agreements.

Action Item 7: Staff to adjust language in Rec 2.22 to make sure it is clear that an existing RO who later applies for variants will keep the existing RA and get a new one for the new variants (two RAs).

• Clarification that the RO would have a choice of having two RAs or could optionally move to the new RA for the gTLD they already have a contract for.
• Slide 15 – Input for B2 – Rec 2.2 & 2.3
• Slide 16 – Proposed Revision to Draft Recommendations
  • Revision adds reference to Critical Functions and defines the Critical Functions.
• No concerns raised about this revision.
• Slide 17 – Input for B5 – Rec 2.8
• Slide 18 – B5 – Proposed Revision to Draft Recommendations
  • Footnote will be added to explain that Community-based TLDs, Brand TLDs, and GeoTLDs are referenced in this recommendation because they are the only non-standard types of TLDs.
• Comment: Spell out geoTLDs to geographic name TLDs. Earlier version of this text mentioned applicability of GAC Safeguard. May still be applicable here. A deeper look may need to be given to how these are reflected in the contract.
• GAC Safeguards were incorporated into PICS.
• If this is the case, TLDs for which GAC Safeguards are included need to be reference.

Action Item 8: For Recommendation 2.8, change geoTLDs to geographic name TLDs and include in the list of non-standard application types TLDs to which GAC Safeguards apply.

Second reading of draft recommendations that received EPDP Team input and draft recommendations with potential gaps 

• Slide 20 – A7 – Rec 1.14: [ALAC Question] While we understand that the task of developing the guidelines is to be undertaken by the CJK GPs and we support this as the EPDP Team's recommended approach, we wonder if it might be prudent to ask for the CJK GPs to have the guidelines ready for public comment by set time such that their implementation can be included in time for the next round.

• Question: If the EPDP Team set a timeline, how would it be enforced?
• Comment: We want them to collaborate with us, but any deadline or task is unenforceable. Worst case scenario is that we don’t get the input. Is the only path in that case that single character TLDs are not permitted? If that is the case, are we comfortable with that possible outcome? The panels are not required to do this work. They are volunteers. The work may take time. If we are not comfortable with that outcome and we want single character TLDs to be ready to be applied for, what is our plan b?
• We know the Board is having conversations on dependencies. If we don’t have an answer, what is the impact on SubPro?
• EPDP Team leadership can have another conversation with CJK Chairs to see if they’ve made any progress and how much longer they think they will need to complete the task. If it falls outside of the timeline for producing the Phase 1 report, how will this be addressed in the Final Report? If there is no recommendation from the EPDP Team and the EPDP Team dissolves when it completes its work, who confirms the recommendation from the CJK group?

Action Item 9: Leadership Team to connect with CJK Chairs to understand what progress has been made and what the anticipated timeline will be for their inputs on single character TLDs.

• Slide 21 – D1b – Rec 2.7 [EPDP Leadership Question] Could or should we entertain some discount in application fees for variants which are applied for together with the primary string, for example?
• Question: Here we are talking about the application fees. Does this charter question also cover ongoing fees for the RO?
• Answer: Yes, this charter question also addresses ongoing fees. The registration fee depends on factors related to the SubPro implementation. It appears that this may be the reason that we don’t currently have a recommendation on the ongoing fees.
• IDNs are a priority for the ICANN Board. It will increase the reach of the Internet. The absence of variants is problematic, as we have heard from some existing ROs. We have recommendations for a single application and a single Registry Agreement. We don’t know whether including variants is going to have a significant impact on the evaluation process. The string similarity review is going to be more complex because of variants. Should we consider recommending that we support the notion that it is one application and therefore it should be considered a single application fee? In the context of IDNs being globally beneficial, could we recommend that the annual fee is the same flat fee for an RO? If the combination of IDN and variants reaches the 50,000 registration threshold then the additional fee would kick in.
• There is an opportunity to put recommendations in the Initial Report to get more feedback before making a final decision.
• There are two competing objectives: One is to introduce TLDs in a stable, secure, predictable manner and the other is to encourage adoption of IDNs and variants. Was there any difference in 2012 if the applicant was applying for a TLD that was doing IDNs versus one that wasn’t? Was there any change in the application fee?
• The cost recovery principle seems to be a high-level guideline that everyone pays the same even if there are some differences in the process. For example, if the fee was the same for applicants even if there were different numbers of IDN tables, maybe we can apply that principle here as well. If a set is managed under a single agreement, what effect does that have on both application fees and variable fees that an RO is obligated to pay to ICANN?
• Could there be a flat fee for the application, regardless of how many are being applied for the set?

Action Item 10: Leadership team to put together draft language to extend recommendation 2.7 text regarding fees.