Dear all, 

Please find below the notes and action items from Saturday’s meetings on 11 March 2023. Apologies for the delayed distribution.

Best,

Ariel, Emily, and Steve

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

Action Items

Action Item 1: Add Implementation Guidance or rationale to reflect that: some additional fees specific to IDN variants may be needed, beyond the application fee.

Action Item 2: Draft language to capture outcome of single fee for both registry-level and transaction fees.

Action item 3: Clarify language to specify between challenge to RZ-LGR versus the SubPro challenge mechanism. Specify three scenarios.

Action item 4: Draft the latter part of Rec 1.2 more like a recommendation (or consider moving to rationale).

Action item 5: Include the primary and disposition values as challengeable via the SubPro challenge mechanism.

Action item 6: Investigate what a “reasonable” number of variant strings is for various scripts, based on learnings from the GPs.

Roll Call and SOI Updates 

• None

Welcome and Chair Updates 

• Background on this EPDP
• Review of timeline to Phase 1 Initial Report. Noting need for drafting of glossary and review of text.

Close Loop  - D1b - flat application fee & registry level fee (fixed fee & transaction fee) 

• Slide 5 - Context of question
• Slide 6 - New draft recommendation as a result of the previous call, related only to the application fee.
• Language probably needs additional work, but the principle is that the primary string, plus any number of variants, should be subject to a single base application fee.
• As a result of the hybrid model, the number of permutations will be quite high. Unclear if those costs would be borne by all applicants or just by the affected applicants.
  • May want to note that some additional fees specific to IDN variants may be needed, beyond the application fee.

Action Item: Add Implementation Guidance or rationale to reflect that: some additional fees specific to IDN variants may be needed, beyond the application fee.

• Reminder that we’re only talking about the application fee, and as well, that we need to consider existing gTLDs and how they apply for their variants.
• Noted that this model is helpful in promoting the adoption of IDNs.
• Reminder that variants are determined by the RZ-LGR.
• As a principle, the primary string and all variants should be treated the same.
• Noted that reviewing additional strings (variants), there is likely to be extra cost. The result of this recommendation is that those additional costs are borne by all applicants. 
  • There are other examples of all applications that have different evaluation elements being subject to the same fee. ASCII and IDN applications, which have IDN tables, would have the same fee in 2012. Geo names are also part of the base application fee.
  • ASCII domains will have variants as well, so this is not just specific to IDNs.
• Slide 7 - Reviewing RA language about registry-level fees, which is about the fixed fee and the transaction fee.
• Slide 8 - Recommendations are in line with the integrity of the set. Because the primary gTLD and variant labels are recommended to be subject to a single agreement, should the registry-level fixed fee only be levied once or per delegated gTLDs?
• There is also a technical level to consider. There are more zones set up and entries in the zone. Managing the set at a technical level, there is no fixed implementation that all registries will follow.
• There might be a preference to just worry about the administrative level.
• Clarification that for the technical level, this is more about the EPP side and the domain create, renewal, transfer. So, based on transactions. The DNS side is up to the RO to manage.
• Support for single fee, based at least in part because of the principle of the set. The registry-level fee is already substantial and adding additional annual fees may further dampen interest. 
• Registry-level transaction fees should also be subject to a single fee.

Action Item: Draft language to capture outcome of single fee for both registry-level and transaction fees.

• Question about fees for names registered in each variant. This sounds like a second-level question?
• Clarification question about what constitutes 50,000. Does each registration count, including variants, as a transaction? Some belief that the transactions would be based on the set. By way of example, 25,000 transactions under the primary gTLD and 25,000 transactions under variant 1, would total 50,000 transactions.
• Not clear if there will be a new EPP command to create a set.

Second Reading of Draft Text Circulated Prior to ICANN76

E3 (added variant labels to Reserved Names): https://docs.google.com/document/d/115eSNnxBsCbUszEGU7i4xbzLwu1u8_UdaGEJD9CVvVc/edit

• Reviewing text in Google doc. Approach is to ask the commenters to explain and seek to resolve comments.
• Question about the consistency of language and the model, in respect of blocked labels. There seems to be a gap/inconsistency for just Reserved Names. This was addressed in drafting the language.
• Concern about the limitation of two-character strings. This limitation comes from the 2012 AGB and is affirmed by SubPro. It seems out of scope for this team to modify. However, is it not possible that a 1-char or 3-char string would be similar to a 2-char ASCII (which are reserved for potential ccTLDs)? This language therefore seems limiting.
• Could use additional clarity around what “manifestly low level of visual confusability”
• Is there also an exception for mixed script? Answer is no. Glossary will note that only valid labels will be included in the blocked variants list, except where there might be some exceptions. Implementation guidance may be useful.
• Intent is to give discretion to the expert panelists.
• Noted that allocatable variant labels for reserved names would be included in the string similarity review.
• Table added to help provide a visual representation of the comparable combinations. If we want to include it, need to update it for accuracy.

A8, B4a, E1, E2, E3a, E4, E7/B5: https://docs.google.com/document/d/1iXaAy3uDyoVlZ4L9jYiY_8bzqpZR7I1xa9qUWenB5XU/edit

• General agreement for text to be included in the Initial Report.

A3 (added recs & rationale), A5, A7, A9, B4, B5, D1a, D1b, D8 (added rationale), E5 (revised rationale)

Topic A: https://docs.google.com/document/d/1Bt0LT45UaLynFNverh1nJhyvq6q6NxgSFAOnOp2LG44/edit

• There is a suggestion that the outcome of the challenge process would determine next steps. This bullet is specific to the RZ-LGR review process (outside of the SubPro challenge mechanism).
• These sets of recommendations include both elements (applying even lacking RZ-LGR and when the RZ-LGR itself is being challenged).
• There may be a third instance where the tool itself is improperly implemented.
• Clarified that SubPro already has a recommendation about applying for a gTLD in a script that is not already a part of the RZ-LGR.
• It seems that only the instance where an applicant is challenging the implementation of the RZ-LGR is relevant to this EPDP. However, can include the language about the challenge outside of the SubPro process (e.g., via the GPs).

Action item: Clarify language to specify between challenge to RZ-LGR versus the SubPro challenge mechanism. Specify three scenarios.

• Suggestion that the language in Rec 1.2 looks like rationale. Since this is the recommendation, there is opportunity to draft it more like a recommendation.

Action item: Draft the latter part of Rec 1.2 more like a recommendation (or consider moving to rationale).

• Rationale for Rec 1.17 has a question about validity of strings. There is a further question about the ability to challenge whether a variant string is blocked when they think it should be allocatable. Currently, the recommendation seems to only apply to the primary string.

Action item: Include the primary and disposition values as challengeable via the SubPro challenge mechanism.

• Rec 1.4 - agreement on clarifying language. Concern about this creating the perception that there is a ceiling value for variants.
• Rationale for Rec 1.5 - Concern about user experience versus what may be more appropriate, the registrant experience.
• Could specify that the user experience is outside of the control of registries and registrars. And thus, could specify that the framework is limited to best practices for registries and registrars deploying variants.
• Clarification that for SSAC, the concern was about the registry managing too many variants, which would impact the registry, registrar, and registrant.
• Re: Rec 1.5, understanding is that it was drafted in response to not impose a ceiling value for variants. This set of recommendations was drafted prior to the agreement by the WG to set a single base fee for the primary gTLD and all variants. Does this warrant revisiting Rec 1.4? Noted that applicants must explain need for variants.
• The other significant factor is that only 7 scripts allow for allocatable variants and only Arabic has a high number of permutations. Chinese may also have a higher number of allocatable variants.
• Suggestion that Rec 1.5 does not seem to connect to Rec 1.4. Would this mean that the framework is needed prior to the launch of the next round? Presumably the framework that is needed is to help potential applicants understand what is needed to manage variants.
• Could make sense to separate between registry/registrar level considerations and then a more holistic set of guidance for variants (for registry, registrar, registrants).
• Should highlight the elements that might limit uncontrolled applications for variants, considering the switch to a single application fee.
• Could there be limitations on the single fee provision? Challenge is of course in determining what that arbitrary number might be.
• The “arbitrary” number can be informed by the limits that the GPs imposed, so it will not be quite so arbitrary.

Action item: Investigate what a “reasonable” number of variant strings is for various scripts, based on learnings from the GPs.

Topic B: https://docs.google.com/document/d/15YGISgNQYL_VfcVVZ6E97qbo42GPziP6x089bR3wgZw/edit

• N/A

Topic D: https://docs.google.com/document/d/1C6xKX87w2LtN4Is0mehuRgc1GqjKmbbhT14KbvUH5Sw/edit

• N/A

Topic E: https://docs.google.com/document/d/1RLvsyQvliafNEA9Ja1RCObywpAWfp1kTmte0WZlyqqs/edit

• N/A

Consolidated View of All Draft Phase 1 Recommendations: [Draft] Consolidated View of Draft Phase 1 Recommendations.pdf

• N/A

AOB

• N/A 

Steven Chan


Senior Director, Policy Development Support & GNSO Relations

Internet Corporation for Assigned Names and Numbers (ICANN) 

12025 Waterfront Drive, Suite 300

Los Angeles, CA 90094-2536


Email: steve.chan@icann.org

Skype: steve.chan55

Mobile: +1.310.339.4410

Find out more about the GNSO by visiting: https://learn.icann.org/

Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO

Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar