At-Large Workspace: Expedited Policy Development Process (EPDP) on the Internationalized Domain Names (IDNs)

At-Large Representatives (ALAC Team)

ALAC Members: Satish Babu, Hadia Elminiawi (replaced Lianna Galstyan in Dec 2022), Abdulkarim Oloyede

ALAC Participants: Justine Chew

ALAC Observers: Lianna Galstyan

REPORTS/UPDATES TO & CONSULTATIONS WITH THE AT-LARGE CONSOLIDATED POLICY WORKING GROUP (CPWG)

11 Aug 2021 - ongoing

See GNSO Workspace: Expedited Policy Development Process (EPDP) on the Internationalized Domain Names (IDNs)

Preliminaries

At its meeting on 20 May 2021, the GNSO Council resolved to initiate an Expedited Policy Development Process (EPDP) on Internationalized Domain Names (IDNs) and adopted a charter for the EPDP Team to deliberate identified Policy Track issues and to provide policy recommendations on:

i) the definition of all TLD and the management of variant labels to facilitate delegation of variant gTLDs in the root zone while achieving the security and usability goal of variant labels in a stable manner; and

ii) how the IDN Implementation Guidelines, which Contracted Parties are required to comply with, should be updated in the future.

The charter questions in the charter were developed based on the following principles and framework:

Not to revisit Subsequent Procedures (SubPro) recommendations in context of future new gTLDs, but to consider whether such recommendations should be extended to existing gTLDs (where IDNs are concerned);
To consider the impact of recommendations out of the IDN Variant TLD Implementation Staff Paper ("Staff Paper") and Recommendations for the Technical Utilization of the Root Zone Label Generation Rules ("TSG recommendations") on both future and existing gTLDs where there is a lack of SubPro recommendation; and
To coordinate with the SubPro Implementation Review Team (SubPro IRT) on addressing implementation issues to achieve, to the extent possible, consistent solutions for new and existing gTLDs – to note that the SubPro IRT has not yet been convened at this point.

Remark on Project Plan of the EPDP

On 17 Nov 2022, GNSO Council approved the EPDP's Project Change Request (PCR). With this PCR, the EPDP seeks to facilitate the implementation planning of the New gTLD Subsequent Procedures by bifurcating its work into two phases, with Phase 1 covering topics related to top-level IDN gTLD definition and variant management, and Phase 2 covering issues pertaining to second-level IDN variant management, which also requires a timeline extension due to the diversity and complexity of IDN issues, additional data collection needs, review of ICANN org input for draft recommendations, and public comment-related processes. The timeline now contemplated is:

Publish Phase 1 Initial Report for Public Comment by April 2023
Submit Phase 1 Final Report to the GNSO Council by November 2023
Publish Phase 2 Initial Report for Public Comment by April 2025
Submit Phase 2 Final Report to the GNSO Council by November 2025

Policy Track Issues & Charter Questions (CQ)

Policy Track Issues	Charter Questions	Charter Questions Discussed with CPWG #	EPDP Draft Recs / IG Status #
A. Consistent definition and technical utilization of RZ-LGR	a1: RZ-LGR as sole authoritative source a2: Any standing of self-identified variants a3: Any challenge process to RZ-LGR variant dispositions a4: Where script of application not supported by RZ-LGR a5: Any ceiling value for variant allocation a6: Impact of possible non-full backward compatibility of future version of RZ-LGR on existing delegations a7: Allowing single character IDNs a8: Catch-all a9: TLD label statuses (taxonomy) a10: TLD label statuses (changes)	a1, a2, a3 on 24 Nov 2021, 1 & 8 Dec 2021 a4, a5, a6, a7 on 2 Feb 2022 Revisited a5, a6 on 2 Mar 2022 a8 has been parked since it's a catch-all question a9, a10 on 18 May 2022 Revisited a7 part 1 and a10 (with 2nd reading) on 6 Jul 2022 Recap of a7 part 1 and conclusion to a7 part 2 => Phase 1 Initial Report	a1: PR 1.1: RZ-LGR as sole source to calculate variant labels, disposition values a2: No recommendation needed a3: PR 3.22: String must conform to mandatory string requirements and RZ-LGR to be submitted in application system If initial algorithmic check says string is “invalid” or “blocked” application can be accepted but applicant must be warned of potential disqualification If DSP confirms “invalid” or “blocked”, application is disqualified but applicant can invoke limited challenge mechanism Grounds of challenge limited to “incorrect assessment of technical implementation of RZ-LGR” IG 3.23: Application system should issue disqualification warning if initial algorithmic check says string is “invalid” or “blocked” PR 3.24: Disqualification remains unless and until string deemed valid and allocatable in future RZ-LGR a4: No recommendation needed a5: Ceiling value for variants PR 8.1: No ceiling value for delegated TL variant labels from a variant label set PR 8.2: Framework for developing guidelines for management of gTLD and variant labels at TL by registries and registrars must be created during implementation IG 8.3: The framework (per PR 8.2) should outline the scope and the steps involved in developing future guidelines, which at a minimum should involve relevant stakeholders, such as registries, registrars, and where feasible, registrants who have experience with IDNs and variant labels a6: Grandfathering for RZ-LGR PR 8.6: Any delegated gTLDs and their delegated and allocated variant labels (if any) not validated by a proposed RZ-LGR update must be grandfathered PR 8.7: For all future versions of the RZ-LGR, GPs and the IP must make best efforts to retain full backward compatibility with delegated gTLDs and their delegated and allocated variant labels (if any). The LGR Procedure must be updated to specify the exceptional circumstances, to the extent known to the GPs and IP, that could result in a proposed update to the RZ-LGR not being able to retain full backward compatibility. PR 8.8: In the unexpected event where a proposed update to the RZ-LGR is unable to retain full backward compatibility for validating any delegated gTLDs as well as their delegated and allocated variant labels (if any), the relevant GP must call out the exception during a Public Comment period and explain the reasons for such exception. The Public Comment period should also include the elements in IG 8.9 IG 8.9: The GP analysis should identify security and stability risks (if any), as well as possible actions to mitigate the risks associated with allowing a delegated gTLD and its delegated and allocated variant labels (if any) to be grandfathered. There should also be an assessment, conducted by ICANN org, of the potential impact of grandfathering on registries, registrars, registrants, and end-users, as well as proposed measures to reduce the negative impact. As part of the assessment, ICANN org should facilitate a timely dialogue between the registry operator of the grandfathered gTLD, relevant function(s) in ICANN org, the GP, other experts and affected parties. Notwithstanding the recommendation to grandfather affected gTLDs, in the event security and stability risks are identified, ICANN org and the affected registry operator should discuss possible measures to minimize the risks that would result in minimal disruption to registries, registrars, registrants, and end-users a7: PR 3.17:Only languages where character is an ideograph are eligible to have single-character gTLD i.e. only Han script for now, but not until relevant guidelines from CJK GPs are developed, implemented a8: No recommendation, more related to SL DN registrations a9: Label states PR 9.1: A given variant label must have one of the following label states at any one time: delegated, allocated, withheld-same-entity, blocked, or rejected. If the same terminology is used for certain label states and new gTLD application states, their respective definitions must be consistent IG 9.2: The label state for each variant label of an already delegated primary gTLD should be recorded and tracked by ICANN org so long as the primary gTLD remains delegated. Such records, including historical ones, should be maintained in a practical manner and made publicly accessible. a10: PR 9.3: Transition states of a variant label & IG 9.4: scenarios for variant label state transition
B. IDN Variant TLD Management: "Same entity" at the top-level	b1: Same entity top level b2: Same entity back end b3: Any additional requirements beyond b1 and b2 b4: Process to obtain variant labels b4a: Role of "withheld for same entity" b5: Extension of restrictions on community, brand to variant labels	b1, b2, b3, b4 + prefaced db1 on 16 Mar 2022 b4a (re: string similarity) Hybrid Model prefaced on 12 Oct 2022 - straw poll conducted b4 revisited on 2 Nov 2022 - straw poll conducted Recap of b5 pending	b1: PR 2.1: Allocatable variant label for existing IDN gTLD from 2012 round only allocatable or withheld for that registry operator b2: PR 7.7: The registry service provider for each one of the Critical Functions as defined in the Base RA for an existing IDN gTLD from the 2012 round must be the same as for its delegated variant labels.The Critical Functions are: DNS Service, DNSSEC proper resolution, EPP, RDDS, and Data Escrow. PR 7.8: If the registry operator of an IDN gTLD changes its back-end registry service provider, that IDN gTLD and any delegated variant label(s) associated with that IDN gTLD must simultaneously transition to the new back-end registry service provider. b3: No recommendation needed b4: PR 3.1: Allocatable variant label cannot precede primary PR 3.2: Future registry operator can only apply for allocatable variant label during application round PR 8.4: Same delegation timeframe for primary and allocatable variant labels that pass evaluation, same terms and conditions including ability for extension of time for delegation PR 8.5: Sequence of delegation of labels that pass evaluation is up to registry operator b4a: No recommendation b5: PR 3.16: Applied for allocatable variant label must be treated the same as its primary in terms of requirements - Community-based, Geoname, .Brand PR 7.15: Applied-for primary and allocatable variant labels must be bound by the same restrictions which will become contractual requirements in RA. Same with allocatable variant labels for existing IDN gTLDs. (Restrictions meaning for Community-based, Geonames, .Brand TLDs, TLDs subject to Cat 1 Safeguards)
C. IDN Variant TLD Management: "Same entity" at the second-level	c1: Same entity second level c2: Reconcile SubPro rec with existing RA c3: Mechanism to identify registrant - ROID c3a: If use ROID, anything else? c4: Harmonization of IDN tables; consider existing SLD c4a: Disposition of variant labels across TLD can differ c5: Methods to harmonize IDN tables c6: Use of RFC7940	c1, c2 pending	c1: Phase 2 c2: Phase 2 c3: Phase 2 c3a: Phase 2 c4: Phase 2 c4a: Phase 2 c5: Phase 2 c6: Phase 2
D. Adjustments in registry agreement, registry service, registry transition process, and other processes/procedures related to the domain name lifecycle	d1: Legal framework d1a: Registry Agreement d1b: 'Application' for future variant TLDs d2: Lifecycle management of variant TLDs d3: Same entity data escrow impact d4: Same entity lifecycle second level d5: Registration fees second level d6: Transfer second level, voluntary and involuntary d6a: UDRP impact on same entity principle d7: Suspension of 1 domain impact to variant set d7a: URS impact on same entity d8: Catch-all	d1a + d1b part 1 on 23 Mar 2022 - straw poll conducted d1b part 2 on 2 Nov 2022 - straw poll conducted d2, d3 are pending	d1: No recommendation needed d1a: Contractual Reuirements PR 7.1: Any future IDN gTLD along with its variant labels (if any) must be subject to one Registry Agreement IG 7.2: A new specification or an amendment to the base RA for any future IDN gTLD along with its variant label(s) may need to be developed to incorporate variant management provisions. PR 7.3: Any existing IDN gTLD registry operator from the 2012 round that applies for its variant labels in the future must be required to enter into a separate, new RRA for the newly approved variant label(s), while maintaining the existing RA for its existing IDN gTLD IG 7.4: It is expected that the separate, new RA for the newly approved variant labels will be linked in some way to the RA for the existing IDN gTLD from the 2012 round d1b: PR 3.3: Existing IDN gTLDs registry operators can only apply allocatable variant labels during application round PR 3.4: Future IDN gTLD primary and allocatable variants labels in one application PR 3.5: Both future IDN gTLD and existing registry operators who want allocatable variant labels must explain why they seek those variant label IG 3.6: Criteria for evaluating explanations (per PR 3.5) should be pre-identified and applied consistently by qualified PR 3.7: Both future IDN gTLD and existing registry operators who want allocatable variant labels must demonstrate ability to manage primary and variant labels from technical and operational perspective IG 3.8: Evaluation (per PR 3.7) should be closely tied to overall technical capability evaluation with criteria including Critical Functions with respect to SL registrations IG 3.9: ICANN org may do research to help identify additional standards or test for technical and operational capability evaluation (per PR 3.7) PR 3.10: Fee structure for all future applications must be consistent with principle of cost recovery PR 3.11: Future applicant for primary and up to 4 allocatable variant labels must incur base application fee PR 3.12: Any applicant applying for more than 4 allocatable variant labels may incur additional fees determined by ICANN org PR 3.13: Future registry operator applying only for allocatable variant labels must incur discounted base application fee PR 3.14: Existing registry operator applying for up to 4 allocatable variant labels of existing IDN gTLD in the immediate next round will have base application fee waived. If beyond immediate next round then must incur discounted base application fee. If apply for more than 4 existing IDN gTLD in the immediate next round then may incur additional fees. If beyond immediate next round then must incur discounted base application fee and may incur additional fees. PR 3.15: One-time exception in the immediate next application round, existing IDN gTLDs applications for allocatable variant labels to receive priority in processing order PR 7.5: The registry fixed fee for an IDN gTLD registry operator that operates the delegated gTLD label(s) from a variant label set must be the same as a gTLD registry operator of a single gTLD. PR 7.6: The calculation of the registry-level transaction fee must be based on the cumulative number of domain name registrations of the combined delegated gTLD label(s) from a variant label set d2: PR 7.9: In the event a Registry Transition or Change of Control process is initiated for an IDN gTLD, the process must encompass the IDN gTLD and all its allocated and delegated variant label(s), if any, at the same time. PR 7.10:After the Registry Transition Process or Change of Control process is completed for an IDN gTLD and its allocated and delegated variant label(s), only the successor registry operator can apply for the other non-delegated, allocatable variant label(s) of that IDN gTLD PR 7.11: Emergency transition of an IDN gTLD to an EBERO provider must include the allocated and delegated variant label(s) of that IDN gTLD, if any. All these labels must be transitioned to the same EBERO provider at the same time PR 7.12: In the event an IDN gTLD is reassigned as a result of a TMPDDRP determination, that reassignment must include all allocated and delegated variant label(s) of the IDN gTLD, if any, at the same time d3: PR 7.13: The same data escrow provider must be contracted for the IDN gTLD and its allocated and delegated variant label(s). IG 7.14: The escrow data associated with each gTLD variant label should be stored in separate files d4: Phase 2 d5: Phase 2 d6: Phase 2 d7: Phase 2 d7a: Phase 2 d8: Catch-all PR 8.10: A primary IDN gTLD that is removed from the root zone, either voluntarily or involuntarily, must also require the removal of its delegated variant label(s) from the RZ. PR 8.11: A delegated variant label that is voluntarily removed from the root zone will not require the removal of the associated primary IDN gTLD or its other delegated variant label(s). PR 8.12: In the event that a label is removed from the root zone as a consequence of its registry operator’s breach of the RA, its associated variant label set must also be removed from the RZ
E. Adjustments to objection process, string similarity review, string contention resolution, reserved strings, and other policies and procedures:	e1: Role of "withheld for the same entity" e2: Criteria for objection e3: String similarity (scope) e3a: String similarity (consequences) e4: String contention resolution e5: Reserved strings & strings ineligible for delegation e6: 2-character Latin IDN TLDs e7: Catch-all (same entity - top level)	e1, e3, e3a, e4 (re: string similarity) Hybrid Model prefaced on 12 Oct 2022 - straw poll conducted e2 part 1 & part 2, e5 part 1 & part 2 are pending	e1: Same as B4a, no recommendation e2: PR 5.1: All applied-for allocatable gTLD variant labels must be subject to the objection processes PR 5.2: A String Confusion Objection may be filed based on confusing similarity between combinations of applied-for primary gTLD strings and their variant labels established by Hybrid Model and SSPR exception - 8 scenarios included Only a blocked variant label of an applied primary claimed as confusingly similar to the blocked variant label of an existing gTLD/ccTLD or another applied-for primary string cannot be the basis of SC Objection. PR 5.3: Outcomes of String Confusion Objection consistent with 2012 AGB - 3 scenarios included PR 5.4: Permissible circumstances for Limited Public Interest Objection, Legal Rights Objection, and Community Objection - an objection may be filed against only the applied-for primary gTLD strings and/or the applied-for allocatable variant labels - 3 scenarios specified PR 5.5: Possible outcomes for Limited Public Interest Objection, Legal Rights Objection, and Community Objection: If an objection against an applied-for primary gTLD string prevails, then that application (in its entirety) is ineligible to proceed If an objection against only one or more applied-for allocatable variant label(s) prevails, then that application for the applied-for primary gTLD string and other unaffected applied-for allocatable variant label(s) may proceed without the applied-for allocatable variant label(s) which are rendered ineligible by the objection If the objection does not prevail, then that application (in its entirety) may proceed e3: String Similarity PR 4.1: Modify String Similarity Review to Hybrid Model PR 4.2 String Similarity Review Panel may decide whether and what blocked variant labels to omit in review but must be based on guidelines and/or criteria on basis of manifestly low level of confusability PR 4.3: Guidelines and/or criteria (per PR 4.2) must be developed during implementation e3a: PR 4.4: Integrity of set requires that all labels in a variant label set must share same outcome out of String Similarity Review: If an applied-for primary or any of its variant labels is confusingly similar to an existing gTLD or ccTLD or any of its variant labels, then the entire variant label set will be ineligible to proceed. If an applied-for primary or any of its variant labels is confusingly similar to another applied-for primary or any of its variant labels, then the entire variant label set will be placed in a contention set e4: String Contention PR 6.1: An applied-for primary gTLD string that is also a variant label of another applied-for primary gTLD string, as calculated by the RZ-LGR, must be placed in a contention set. PR 6.2: The entire variant label set of an applied-for primary gTLD string (no matter whether it is an ASCII string or an IDN string) must be processed in the contention set. e5 - Reserved Names: PR 3.18: Reserved Names list to not be expanded to include variant labels PR 3.19: Variant labels of Reserved Names not allowed e5 - Strings ineligible for delegation: PR 3.20: List of Strings Ineligible for Delegation to not be expanded to include variant labels PR 3.21: Only the protected orgs on list of Strings Ineligible for Delegation can apply variant labels of their protected strings; but only if they also apply for or have the primary e6: No recommendation e7: No recommendation
F. Adjustments to registration dispute resolution procedures and trademark protection mechanisms	f1: Same entity impact to TMCH top level f2: Same entity impact to RPMs, URS, UDRP, etc top level		f1: Phase 2 f2: Phase 2
G. Process to update the IDN Implementation Guidelines	g1: Process to update IDN Guidelines g1a: Differentiation for ccTLDs and gTLDs?		g1: Phase 2 g2: Phase 2

2021 Deliberations

This EPDP Team has its first meeting on 11 Aug 2021 and have been meeting nearly every week, on Thursdays at 13:30 UTC.
The ALAC Team provided regular verbal updates to CPWG especially whenever there were some developments in the deliberations of this EPDP.
In particular, the ALAC Team, presented:

1. An update to CPWG on 1 Sep 2011 on the EPDP's third meeting of 25 Aug 2021, as an example
2. Some background to CPWG on 24 Nov 2021 and on EPDP Team deliberations for CQ a1-a3 as at 18 Nov 2021 (presentation)
3. A follow-up to CPWG on 1 Dec 2021 on recap to CQ a1-a3 (presentation)
4. An opportunity for discussion of questions at CPWG on 8 Dec 2021 out of the ALAC Team's presentations of 24 Nov 2021 and 1 Dec 2021

2022 Deliberations

The EPDP Team resumed meetings on 6 Jan 2022.
# At its 3 Feb 2022 call, it was determined that the EPDP Team would move forward with an updated sequence of charter questions.
The ALAC Team continued to provide regular verbal updates to CPWG especially whenever there were some developments in the deliberations of this EPDP.
In particular, the ALAC Team, presented:

5. And discussed with CPWG on 2 Feb 2022 positions and rationales for CQ a4 - a7 (presentation)
6. Some background to CPWG on 2 Mar 2022 and on EPDP Team deliberations for CQ a5 and a6 (presentation)
7. Some background to CPWG on 16 Mar 2022 and on EPDP Team deliberations for CQ b1 - b4, d1b (presentation)
8. And discussed with CPWG on 23 Mar 2022 to seek indicative positions for CQ d1b (presentation) by way of 5 straw poll questions:

The ALAC team resumed sharing updates on the EPDP Team's work:

9. With CPWG on 18 May 2022, in particular, the EPDP Team draft outcomes for CQs a9 and a10 (presentation)

Post-ICANN74, the ALAC team presented:

10. An update to CPWG on 6 Jul 2022 on the overall progress of EPDP Team's work and revisited the draft recommendation text for CQs a7 part 1 and a10 (post 2nd reading) (presentation)

11. An update to CPWG on 20 Jul 2022 regarding a 'Virtual Office Hour' chat between some members of the ALAC Team and the EPDP Leadership/Staff Team regarding the workings and progress of the EPDP (no presentation).

Post-ICANN75, the ALAC team presented:

12. And discussed with CPWG on 12 Oct 2022 the role of variants in string similarity review which impinges on many charter questions (eg. b4a, e1, e3, e3a, e4) (presentation); introducing and ascertaining support for the proposed Hybrid Model.

13. To CPWG on 2 Nov 2022 on the contemplated Project Change Request (PCR) which would affect the timeline and issuance of the EPDP's Initial and Final Reports, and how those reports would be split into 2 phases. The team also discussed CQ B4 and CQ D1(b) which deals with establishing the processes by which (i) new applications could apply for a new IDN gTLD and allocatable variants, and (ii) existing ROs could apply for allocatable variants of their existing IDN gTLDs (presentation). The team conducted several polls in relation to these to CQs, the results of which are:

2023 Deliberations

The EPDP Team resumed meetings on 5 Jan 2023.
The ALAC Team presented:

14. And discussed with CPWG on 1 Feb 2023 the draft recommendation and rationale text for CQs A7, B4, D1b, E5 and E6 (presentation)

Phase 1 Initial Report

The ALAC Team presented to and consulted with CPWG (Phase 1 Initial Report):

15. On 3 May 2023 - overview, structure, underlying principles, sec 4.1, sec 4.2 and sec 4.3 (presentation)

16. On 10 May 2023 - role of variants in Limited Public Interest Objection and Community Objection, possible outcomes (presentation)

17. On 17 May 2023 - modifications to String Similarity Review (Hybrid Model) & exceptions, outcomes for contention resolution (presentation)

18. On 24 May 2023 - call for inputs to PR 3.6 & IG 3.6 on factors related to absence of ceiling value for variants (presentation)

On 31 May 2023, the ALAC Team discussed the draft ALAC Statement to the Initial Report

Update for 01 September CPWG:

Discussions at the third meeting of the EPDP on IDNs (25 Aug 2021)

The meeting started with Roll Call & SoI Updates (Edmon reported an update of his SoI on account of his induction into the ICANN Board). All members were asked to read the background documents that Edmon had shared in his welcome mail and confirm through the form.
The background presentation by Sarmad, which started in the previous meeting, was completed.
The next item was an initial review of the charter questions, and the basic strategy was presented in a document. The steps involved:
- Consider whether the order of topics A-G as presented in the Charter is the appropriate order to work (Agreed by the group).
- For each topic, there will be discussions in order to gain a deeper understanding of the issues and positions involved, and also consider if AC/SOs needed to be consulted. As an initial step, a poll was conducted (involving all members + participants) for two items A and B to rate the complexity of the topic ("High"-10+ hours, "Medium"-5-10 hours, and "Low"-Less than 10 hours). The poll reported both items to be 'Medium complexity'. It was decided to discuss this methodology further in the next meeting.
Given the clash of the EPDP Meeting Time with ALAC CPWG, the group decided to run a Doodle poll to choose between Tuesday and Thursday at the same time (13:00 UTC).

Action Items
AI #1: Members to read background documents included in Edmon’s welcome email and confirm when they have done so here. The welcome email is available at: https://mm.icann.org/pipermail/gnso-epdp-idn-team/2021-July/000002.html

AI #2: Staff to circulate and members/participants to fill out Doodle poll to schedule next week’s meeting and future meetings.

Full minutes available at: https://community.icann.org/display/epdpidn/2021-08-25+IDNs+EPDP

Content

Space Tools