2023-03-02 IDNs EPDP - Meeting #72

Notes/ Action Items

Notes and Action Items - IDNs EPDP Call – 02 March 2023

Action Items

Action Item 1: Include definition for Reserved Names in glossary.

Action Item 2: Request input on questions in slides 10 and 11.

Action Item 3: Nevertheless, prepare draft recommendation language to help understanding.

Action Item 4: Members to provide opinions on options for close date on list.

Welcome and Chair Updates

• Last call before ICANN76. Please take note that this group’s sessions are first up on Saturday, and there are two of them.
• Hopeful there is good turnout for the sessions, particularly in person (Michael, Satish, Dennis note they will be in person; Maxim, Zuan, Jerry will be remote). Planning to take a team photo if possible.
• Slide 3: Reminder about text circulated for team review:
  • Items 1-3 are currently out for review. Input needed to develop Initial Report.
  • Editorial edits stemming from ICANN org input in progress.
• Expectation is that substantive input stemming from member review of draft text will be form basis for ICANN76 session. Review of text is therefore imperative.

Discuss Draft Recommendations with Potential Gaps

• Slide 5: Discussing remaining fee elements which includes both the application fee and annual registration fees. Current rec 2.7 says that applications for variant label(s) should be subject to cost recovery.
• Suggestion from leadership to include a new rec that relies on a single flat application fee, no matter how many variants. The rationale is that IDNs and variants are a priority for ICANN and the community. Could otherwise be a barrier to variants.
• And the RO would only be subject to a single registry-level fee, same as a single gTLD RO.
• This group is not intending to set the fees specifically but rather, the principles that a gTLD operator and its two variants for example, should not be charged the registry-level fees three times.
• Re: the cost recovery principle, it was for the overall New gTLD Program collectively, not specific to each application. An ASCII gTLD application and an IDN gTLD application, or one that provided hundreds of IDN tables, would be subject to the same application fee. The RySG will consider this topic soon.
  • A clarification that this concept would seem to only apply when the primary gTLD and variants are applied for in a single round. Assumption that there would be a fee if an existing RO applies for just a variant.
• Concerns that setting pricing would be against anti-monopoly laws in many countries.
• Concern that suggested Rec 2.24 would create an unfair advantage for the RO with variants (in respect of the annual fees).
• Noted that there is a draft recommendation that there is no ceiling for applying for variants. That recommendation is in part reliant on there being financial hurdles for additional variants, which would cause a RO to think carefully before applying for more variants than they might need.
• Does the RO’s business model matter? If the registrant automatically get the variants, should each variant domain count against transaction fees? It may help to remember that variants are considered the “same”.
• In new gTLD process in 2012, each application was for a single gTLD. Some support for draft Rec 2.24. For transaction fees, registrars may have to pay for variant second-level domains. Preference to have transaction fees based one a single domain name, with no additional fees for variants for registries or registrars.
  • This sort of pricing structure would be consistent with the concept of a set.
• Concern raised in draft Rec 2.24 about the reference to a single RA. Belief that this is not decided yet by group.
• Noted that Rec 2.24 makes sense in the context of “tight bundling” of sets, where the domains behave the same. The SubPro recommendation (25.8) notes that domains do not need to act or behave the same b/c each domain is an independent registration (technically). This implies that the bundling is “loose” as there is a good deal of flexibility available to contracted parties.
  • Suggestion that the EPDP might see this differently from SubPro, at least in respect of the fees aspect.
  • The context of SubPro’s rec is to allow flexibility for the registrant. The “tight bunding” concept is required at the CP level however.
  • For annual fees, suggestion that transactions are triggered by domain create.
• Appears that there is agreement on the concept that the set should drive application fees (i.e., a single application fee). However, not agreement yet on the registry-level fees.
• Suggestion to charge a delegation fee for variants.
• Noted that nearly all ROs are subject to a uniform agreement. Concern that the concept of a single agreement may be problematic for existing ROs requesting a variant. A specification would make things easier.
• Will need to revisit this topic before the Initial Report is completed.
• Slide 7: Org question whether a gTLD can be applied for that is visually similar to a Reserved Name.
• Input from Dennis that the rationale argues against the hybrid model. This would seem inconsistent.
  • Suggestion that the same rules should apply for consistency.
  • Noted that this rationale was developed before the hybrid model was agreed to, which is why we might need to revisit this language for consistency.
  • Currently, the hybrid model only compares against the Reserved Names list, not the variants. If changing the approach for Reserved Names, might need to adjust hybrid model.
  • Could potentially only include test and example, since there would be IDNs here.
• Suggestion that there is a difference between ICANN-imposed reserved names versus the RO’s reserved names. However, we are talking about the top-level here. Need to be clear which list we are talking about.
  • We will need to come back to this question.

Action Item: Include definition for Reserved Names in glossary.

• Slide 8: Proposed new recommendations.
  • Proposal is to rely on “remove from the root zone” rather than revoked or un-delegated. Request that org evaluate whether this terminology is acceptable and addressed concerns.
  • May need implementation guidance to note that breach of RA doesn’t always result in removal from the root zone, it could be that EBERO is invoked.
• Slide 9: Org input on “Revoked”. Revoked is a more precise term. Un-delegated could include a gTLD that is never delegated.
• Slide 10: The question is about an ongoing RZ-LGR review. It was noted that this potential outcome could be dependent upon a4.
  • A4 notes that for existing gTLDs, all scripts are already integrated into RZ-LGR.
  • Not clear there is a dependency between a4 conclusion and this open item.
  • Clarifying question about what is being challenged: the outcome or the RZ-LGR? It is limited to challenging the algorithmic check.
  • It seems that the preliminary outputs may be sufficient.

Action Item: Request input on questions in slides 10 and 11.

Action Item: Nevertheless, prepare draft recommendation language to help understanding.

Phase 1 Initial Report: Proposed Structure

• Slide 13: Reviewing format of the Initial Report, which looks like the standard format for most other reports.
  • Section 3: Glossary is not always a standard inclusion.
  • Annex A for the hybrid model is also not a standard inclusion.
• Clarification that the background section should be summary level and brief.
• Section 4 will be the core of the report.

Public Comment Timeline

• Slide 15: Reviewing remaining time to get to Initial Report.
• At ICANN76 will hold second reading and full view of all draft recs.
• May cancel 23 March meeting based on travel back home. Aim is to complete P1 Initial Report draft on 24 March.
  • Support for keeping 23 March.
  • Discuss report on 30 March meeting (other than the draft recommendations, which have been subject to discussion for the past meetings).
• Target date for public comment is 17 April with publish date on 24 April.
• Therefore, aiming for agreement from EPDP Team for Initial Report on 7 April.
• If a guided submission form is needed, 4 business days required to build.
  • The guided submission form helps with facilitating the public comment collection and review.
  • General support for guided submission form.
• The closing date is important in respect of ICANN77. Option 1, a 5 June close date would occur just before ICANN77 (12-15 June). If after ICANN77, it could be Option 2, 26 June.
• Could focus on Phase 2 questions instead during ICANN77. However, preference again is that the public comment input be reviewed.
• Chair preference is Option 1. Because recommendations have been developed iteratively, they should not be a surprise to participating community groups. Hopefully this allows for the 42 calendar day period.
• May need to extend time or schedule another meeting to gain agreement for publishing Initial Report.

Action Item: Members to provide opinions on options for close date on list.

AOB

• None