ABCDEFGHIJKLMNOPQRSTUVWX
1
Q No.Short DescriptionCharter Question Deliberation StatusRec No.Rec ContentOrg Input Received? Org Input ContentRequire EPDP Discussion?Org Input incorporated?
2
General Comment 11. ICANN org notes that all instances in the Initial Report where the EPDP Team refers to RZ-LGR-4 should be updated to RZ-LGR-5 or later developed versions when applicable.

● Including but not limited to the following instances: A4 Draft Answer to Charter Question		No
3
General Comment 22. ICANN org suggests that consistent terminology be used throughout the Initial Report, based on context, for example when referring to variant labels or variant gTLD labels in order to minimize confusion or misinterpretation. It is also recommended that the language mirrors terms used in the Subsequent Procedures Final Report as to avoid any confusion or contradictions.

● Including but not limited to the following instances: Recs. 1.12, 2.1, 3.2		No
4
General Comment 33. ICANN org is aware of the EPDP Team’s intention of providing a glossary along with the Initial Report. Where applicable, org input provides suggestions for instances when it may be helpful to add a term to said glossary.

● Including but not limited to the following instances: Rec. 1.1		No
5
General Comment 44. ICANN org notes that all instances in the Initial Report where the EPDP Team mentions “activating,” “activation,” or “seeks to activate” should be changed to a variation of “application process” such as “apply for” or “applying.” The use of “activate” applies to the step when the string is delegated after the successful application evaluation and contracting steps, therefore “application” and “activation” may not be considered synonymous.

● Including but not limited to the following instances: Recs. 1.4, 1.5, 2.5, 2.6, 3.1, Limited Public Interest Objection Recommendations, Legal Rights Objection Recommendations, Community Objection Recommendations		No
6
General Comment 55. ICANN org notes that in some instances the EPDP Team uses the term “IDN gTLD” whereas in others it uses “gTLD.” For consistency and to reduce the chance of any divergence in policy, the EPDP Team should change all instances in the Initial Report to the same term.

● Including but not limited to the following instances: Recs. 2.2, 2.3, 2.4, 2.5, 2.6, 2.7		No
7
General Comment 66. ICANN org notes that it would be helpful if the EPDP Team can explicitly state that the EPDP team’s recommendation is consistent with the recommendations of the New gTLD Subsequent Procedures PDP Final Report where appropriate.

● Including but not limited to the following instances: Recs. 1.11, 2.2, 2.3		No
8
General Comment 77. ICANN org notes that all instances in the Initial Report where the EPDP Team mentions "blocked variants "should be modified to be "blocked variant labels.”

● Including but not limited to the following instances: Rationale for Recommendation 3.2-3.3, and all String Similarity Small Group Recommendations.		No
9
A1sole authoritative sourceFor existing delegated gTLD labels, does the WG recommend using the RZ-LGR as the sole source to calculate the variant labels and disposition values?Draft Rec Stable Rec 1.1The RZ-LGR be the sole source to calculate the variant labels and disposition values for existing delegated gTLD labels. Yes1. ICANN org suggests that the IDN EPDP Team define what it means by “disposition values” and list them in this recommendation. It may also be useful if a definition is added in the glossary.No
10
A2standing of self-identified variantsIf some self-identified “variant” TLD labels by the former gTLD applicants are not found consistent with the calculation of the RZ-LGR, but have been used to certain extent (e.g., used to determine string contention sets), how should such labels be addressed in order to conform to the LGR Procedure and RZ-LGR calculations?No Rec NeededN/AN/ANo
(answer reviewed)
11
A3challenge processIf an applied-for TLD label, whose script is supported by the RZ-LGR, is determined to be “invalid”, is there a reason NOT to use the evaluation challenge processes recommended by SubPro? If so, rationale must be clearly stated. If SubPro’s recommendation on the evaluation challenge process should be used, what are the criteria for filing such a challenge? Should any additional specific implementation guidance be provided, especially pertaining to the challenge to the LGR calculation as it can have a profound, decimating impact on the use of RZ-LGR?Draft Rec Stable Rec 1.2

SubPro’s limited challenge mechanism for DNS Stability Review applies in cases where the applicant believes that the label is valid as per the RZ-LGR and that the DNS Stability Panel has incorrectly assessed the label as "invalid", thus resulting in the application having been incorrectly disqualified.No
(rec reviewed)
12
IG 1.3When the initial algorithmic check finds that the applied-for label does not conform to the RZ-LGR, the application submission system must issue a warning. However, the applicant should be allowed to submit the application if the label passes the mandatory string requirements and the IDNA 2008 requirements. This recognizes the unlikely, but possible situation, that the RZ-LGR was programmed or incorporated in the application submission system incorrectly.Yes1. ICANN org finds it important to note that while Implementation Guidance 1.3 expands on Rec.1.2, the possibility that the applicant can potentially override the RZ-LGR calculation in the application process to proceed may be helpful to incorporate into Recommendation 1.2 as well.No
13
2. ICANN org suggests that the EPDP Team clarify if an application should be stopped by the application submission system if the applied-for string does not conform to mandatory string requirements (eg: IDNA2008 requirements).No
14
A4script of application not supportedShould the SubPro recommendation be extended to existing TLDs that apply for a variant TLD label whose script is not yet supported by the applicable version of the RZ-LGR?No Rec NeededN/AN/AYes
(input for answer)		1. ICANN org suggests removing the phrase “soon to be” as this recommendation was drafted while RZ-LGR-4 was published. However, since the deliberations, RZ-LGR-5 has been published, thus this language should be updated accordingly.No
15
A5variant allocation ceiling valueShould there be a ceiling value or other mechanism to ensure that the number of delegated top-level variant labels remains small, understanding that variant labels in the second level may compound the situation? Should additional security and stability guidelines be developed to make variant domains manageable at the registry, registrar, and registrant levels?Draft Rec Stable Rec 1.4



No ceiling value is necessary as existing measures in the RZ-LGR to reduce the number of allocatable top-level variant labels, as well as economic, operational, and other factors that may impact the decision to seek to activate variant labels will keep the number of activated top-level variant labels conservative.Yes1. ICANN org suggests revising the text in Recommendation 1.4 that says “...decision to seek to activate variant labels…” to “...decision to apply for variant labels…”.No
16
2. ICANN org notes that all instances in the Initial Report where the EPDP Team mentions “activating,” “activation,” or “seeks to activate” should be changed to a variation of “application process” such as “apply for” or “applying.” The use of “activate” applies to the step when the string is delegated after the successful application evaluation and contracting steps, therefore “application” and “activation” may not be considered synonymous.No
17
Rec 1.5Best practice guidelines be developed for the management of a gTLD and its variant labels by registries and registrars with a view to ensuring a consistent user experience.Yes1. The Rationale for Recommendation 1.5 says “the EPDP Team agreed that the IRT would be responsible for developing the preliminary best practice guidelines.” ICANN org would like to remind the EPDP Team that an IRT is tasked with reviewing implementation plans, while ownership of the policy implementation process still resides with ICANN org.This recommendation seems to imply that ICANN is handing over responsibility to the IRT, which goes against IRT guidelines. ICANN org suggests noting in the rationale that the preliminary best practice guidelines would be developed during implementation.

ICANN org would also like to note that the EPDP Team should make clear whether “best practice guidelines” should be updated over time and how org is responsible for conducting periodic checks and managing the updates.		Yes
18
2. In regard to “consistent user experience,” ICANN org would also like more clarity on how the type of work created by this recommendation—whether a study or another type of report—would be scoped and who would be tasked with scoping such work?Yes
19
3. In addition, ICANN org seeks clarity on whether a potential study would have a larger scope, incorporating Universal Acceptance related work, or if it would be more narrow, focusing only on registries/registrars.Yes
20
4. ICANN org suggests changing Recommendation 1.5 to Implementation Guidance, as the phrasing of this recommendation seems to provide guidance rather than set a requirement.Yes
21
5. ICANN org notes that all instances in the Initial Report where the EPDP Team mentions “activating,” “activation,” or “seeks to activate” should be changed to a variation of “application process” such as “apply for” or “applying.” The use of “activate” applies to the step when the string is delegated after the successful application evaluation and contracting steps, therefore “application” and “activation” may not be considered synonymous.No
22
IG 1.6The development of best practice guidelines should involve relevant stakeholders, such as registries, registrars, and registrants who have experience or interest in IDNs in the scripts with allocatable variant labels.No
(rec reviewed)
23
A6future version of RZ-LGR vs existing delegationsDoes the WG agree with TSG’s suggested approach? If so, to what extent should the TLD policies and procedures be updated to allow an existing TLD and its variants (if any), which are not validated by a script LGR, to be grandfathered? If not, what is the recommended approach to address changes to the current version of the RZ-LGR that assign different disposition values to existing TLDs? Draft Rec Stable Rec 1.7Any existing gTLDs and their delegated and allocated variant labels (if any) not validated by a proposed RZ-LGR update must be grandfathered. In other words, the proposed update will apply to future new gTLDs and their variant labels and will not be retrospective; there will be no change to the contractual and delegation status of existing gTLDs and their delegated and allocated variant labels (if any), which predate the proposed RZ-LGR update and are subject to the version of RZ-LGR when those labels were delegated or allocated. Yes
(to confirm assumption in Rec 1.7 rationale) 		1. Is the EPDP Team in agreement with ICANN org’s assumption that “latest” refers to “upon finalization of the Applicant Guidebook (AGB)” rather than when a round closes, and that the RZ-LGR version in place at that point in time will be used even if the RZ-LGR is updated later?
No
24
Rec 1.8For all future versions of the RZ-LGR, Generation Panels (GPs) and the Integration Panel (IP) must make best efforts to retain full backward compatibility with existing 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. No
(rec reviewed)
25
Rec 1.9In the unexpected event where a proposed update of the RZ-LGR is unable to retain full backward compatibility for validating any existing 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 the following Implementation Guidance.No
(rec reviewed)
26
IG 1.10The GP analysis should identify security and stability risks (if any), as well as possible actions to mitigate the risks associated with allowing an existing 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. 		No
(rec reviewed)
27
A7single character IDNsWhat mechanism or criteria should be used to identify the scripts/languages appropriate for single-character TLDs?Draft Rec StableRec 1.11

Single character gTLDs may only be allowed for limited scripts and languages where a character is an ideograph. At the time of the EPDP Team's deliberation, the script that meets the criteria is the Han script, which is used in the Chinese, Japanese, and Korean languages. Yes1. ICANN org suggests referring to the language in Recommendation 25.4 of the Subsequent Procedures recommendations and supplementing it with the additional criteria as noted in the second sentence. This clarifies that the considerations noted in Recommendation 25.4 will continue to apply.

The EPDP may consider the alternative wording for enhanced clarity:

“In furtherance to Recommendation 25.4, at the time of the EPDP Team's deliberation, the script that meets the criteria is the Han script, which is used in the Chinese, Japanese, and Korean languages.”		No
28
2. ICANN org notes that it would be helpful if the EPDP Team can explicitly state that the EPDP team’s recommendation is consistent with the recommendations of the New gTLD Subsequent Procedures PDP Final Report where appropriate.No
29
Draft Rec Pending ReviewRec 1.14The EPDP Team affirmed the Recommendation 25.4 in the SubPro PDP Final Report that single character gTLDs may only be allowed for limited scripts and languages where a character is an ideograph. At the time of the EPDP Team’s deliberation, the script that meets the criteria is the Han script, which is used in the Chinese, Japanese and Korean languages. As such, applications for single character gTLDs that are ideographs will not be accepted until relevant guidelines from the Chinese, Japanese, and Korean Generation Panels are developed and implemented in the New gTLD Program.N/A
(no text sent)
30
A8additional consideration re: gTLD policies and proceduresWhat additional aspects of gTLD policies and procedures, which are not considered in the above charter questions, need to be updated to ensure that the validation of existing TLD labels and calculation of variant labels depend exclusively on the RZ-LGR in a consistent manner?Not Discussed N/A
(no text sent)
31
A9TLD label statuses (taxonomy)A given label in an Internationalized Domain Label (IDL) set may be in one of the following non-exhaustive status: delegated, withheld-same-entity, blocked, allocated, rejected. The WG and the SubPro IRT to coordinate and develop a consistent definition of variant label status in the IDL set.Draft Rec Stable Rec 1.12A given variant label may have one of the following label states: delegated, allocated, withheld-same-entity, blocked, or rejected. If the same terminology is used for certain label states and new gTLD application statuses, their respective definitions should be consistent. Yes
(to confirm assumption) 		1. Is the EPDP Team in agreement with ICANN org’s assumption that Recommendation 1.12 implies that ICANN org would maintain at least some of these variant label states mentioned (excluding those that are blocked)?

If that’s the case, then there needs to be a practical mechanism to record the variant label states over time.

ICANN org also notes that Recommendation 1.13 below is an extension of this recommendation and that this assumption also applies to it.		Yes
32
2. ICANN org suggests that consistent terminology be used throughout the Initial Report, based on context, for example when referring to variant labels or variant gTLD labels in order to minimize confusion or misinterpretation. It is also recommended that the language mirrors terms used in the Subsequent Procedures Final Report as to avoid any confusion or contradictions.No
33
A10TLD label statuses (changes)What is the procedure to change the label status for individual variant labels?Draft Rec Stable Rec 1.13A variant label may go through the following transitions:
1. from “blocked” to “withheld-same-entity”;
2. from “withheld-same-entity” to “blocked”;
3. from “rejected” to “withheld-same-entity”.
4. from “withheld-same-entity” to “allocated”;
5. from “allocated” to “withheld-same-entity”;
6. from “allocated” to “delegated”; and
7. from “delegated” to “allocated”		Yes1. ICANN org notes that Recommendation 1.13 is an extension of Recommendation 1.12 and that the same assumption stated in the input above applies for both.Yes
34
2. For every change to the lifecycle of a primary label does anything need to happen specifically for variants?

Recommendation 1.13 discusses changes in variant label states; However if the primary gTLD is revoked, will the variants still need to be tracked and/or status maintained or will they be removed along with the primary label? Can the EPDP Team provide additional guidance?

For example: If we’re trying to track a primary label and all of its variant labels (the variant set), and if there is no primary label contracted or in the root zone, it seems that there is no set or label set to maintain because there is no longer a TLD.		Yes
35
3. ICANN org notes that the Rationale for Recommendation 1.13 provides more clarity and guidance on this recommendation and encourages the EPDP Team to pull out the relevant content and recategorize it as Implementation Guidance as to make it more
actionable.		No
36
B1same entitiy top levelShould this recommendation be extended to existing TLDs?Draft Rec Stable Rec 2.1Any allocatable variant label of an existing gTLD, as calculated by the RZ-LGR, can only be allocated to the registry operator of the existing gTLD or withheld for possible allocation only to that registry operator.Yes
(same comment applies to recs 2.1, 2.2, 2.3) 		1. ICANN org assumes that Recommendations 2.1, 2.2, and 2.3 would require implementation steps that include changes to the registry agreement and some elements that are incorporated by reference such as the registry transition process incorporated in Section 7.5.

The WG may want to consider the operational impacts of Recommendations 2.1-2.3. Updating the agreement for existing registry operators on the base agreement is a process subject to the global amendment process defined within Section 7.6 and 7.7. The process is limited in frequency and must be accepted by the registry operators on the base agreement per the applicable thresholds. Currently, there are no existing rules, processes, or procedures for allowing individual Registry Operators (ROs) to move between base versions of the Registry Agreements, as the scenario has never occurred. ICANN org also notes that not all existing registries are on the same registry agreement, which the EPDP Team may want to consider when drafting the outputs. An updated base registry agreement for future rounds will be developed during implementation of the outputs from the Final Report on the new gTLD Subsequent Procedures Policy Development Process.

Depending on the final recommendations from this EPDP, it is foreseeable in some circumstances that the current base agreement from 2017 may be insufficient in form and substance to address variant handling at the top level and may necessitate that the registry operator adopt a more current version. Accordingly, a process would need to be developed as only one base agreement currently exists.		Yes
37
2. ICANN org suggests that consistent terminology be used throughout the Initial Report, based on context, for example when referring to variant labels or variant gTLD labels in order to minimize confusion or misinterpretation. It is also recommended that the language mirrors terms used in the Subsequent Procedures Final Report as to avoid any confusion or contradictions.No
38
B2same entity back endShould this recommendation be extended to existing TLDs and their variant TLD labels?Draft Rec Stable Rec 2.2
The registry operator of an existing IDN gTLD must use the same back-end registry service provider, the organization providing one or more registry services (e.g., DNS, DNSSEC, RDDS, EPP), for operating any additional delegated variant labels of that gTLD. Yes1. See input 1. for Rec 2.1 (row 36)Yes
39
2. ICANN org notes that this recommendation is similar to Recommendation 25.5 from the SubPro Final Report. In order to avoid confusion and multiple interpretations, the same wording should be used for this recommendation to the extent possible. Also see General Comment above.No
40
3. In addition, ICANN org suggests using the language, “all Critical Functions as defined by the base registry agreement for the TLD and its variant labels must be provided by the same service providers.”Yes
41
4. ICANN org notes that in some instances the EPDP Team uses the term “IDN gTLD” whereas in others it uses “gTLD.” For consistency and to reduce the chance of any divergence in policy, the EPDP Team should change all instances in the Initial Report to the same term.No
42
Rec 2.3If the registry operator of an IDN gTLD changes its back-end registry service provider, that IDN gTLD and any additional delegated variant label(s) associated with that gTLD must simultaneously transition to the new back-end registry service provider.Yes1. See input 1. for Rec 2.1 (row 36) Yes
43
2. ICANN org notes that in some instances the EPDP Team uses the term “IDN gTLD” whereas in others it uses “gTLD.” For consistency and to reduce the chance of any divergence in policy, the EPDP Team should change all instances in the Initial Report to the same term.No
44
3. ICANN org notes that it would be helpful if the EPDP Team can explicitly state that the EPDP team’s recommendation is consistent with the recommendations of the New gTLD Subsequent Procedures PDP Final Report where appropriate.No
45
B3additional requirements beyond B1 and B2Is there a need for additional constraints for the same entity requirement for the top-level ?No Rec NeededN/AN/ANo
(answer reviewed)
46
D1aregistry agreementShould each TLD label be the subject of a separate Registry Agreement with ICANN? If not, should each TLD label along with its variant labels be subject to one Registry Agreement with the same entity?Draft Rec Stable Rec 2.4Any existing or future IDN gTLD along with its variant labels (if any) will be subject to one Registry Agreement. Yes1. See above input for Recommendations 2.1-2.3. However, ICANN org notes that there are different types of gTLDs such as .Brand TLDs, Geographic Names, etc. Does the EPDP Team envision different rules for each type of TLD?

For example: Looking at .Brand TLDs, an applicant may only receive Specification 13 and the associated brand designation if, among other elements, the string matches a trademark. While the SubPro recommendations widened that limit slightly, variants were not mentioned. Would a brand only be allowed to obtain variants for which they have trademarks? Or would the brand designation only apply to the primary string and variants would be operated differently? Or would the evaluation only be upon the primary string and variants would be allowed per the expression of need mentioned previously and the RO would have the obligation to operate variants under the same rules as the
primary? Similar questions may be applicable to other gTLD types.		Yes

(input already discuss)
47
2. ICANN org notes that in some instances the EPDP Team uses the term “IDN gTLD” whereas in others it uses “gTLD.” For consistency and to reduce the chance of any divergence in policy, the EPDP Team should change all instances in the Initial Report to the same term.No
48
D1bapplication of future variant tldsWhat should be the process by which an existing registry operator could apply for, or be allocated, a variant for its existing gTLD? What should be the process by which an applicant applying for a new IDN gTLD could seek and obtain any allocatable variant(s)? What should be the associated fee(s), including the application fees and annual registration fees for variant TLDs? Should any specific implementation guidance be provided?Draft Rec Stable Rec 2.5

Future IDN gTLD applicants will be required to submit one application covering the primary IDN gTLD and corresponding allocatable variant label(s) the applicant seeks to activate.Yes1. ICANN org notes that all instances in the Initial Report where the EPDP Team mentions “activating,” “activation,” or “seeks to activate” should be changed to a variation of “application process” such as “apply for” or “applying.” The use of “activate” applies to the step when the string is delegated after the successful application evaluation and contracting steps, therefore “application” and “activation” may not be considered synonymous.No
49
2. ICANN org notes that in some instances the EPDP Team uses the term “IDN gTLD” whereas in others it uses “gTLD.” For consistency and to reduce the chance of any divergence in policy, the EPDP Team should change all instances in the Initial Report to the same term.No
50
Discussion TabledRec 2.6The applicant will be required, as part of the application process, to explain the reason(s) why it needs to activate the applied-for variant label(s). In addition, the applicant will be required to demonstrate their ability to manage the primary IDN gTLD and the applied-for variant label(s) as a set from both a technical and operational perspective.Yes1. ICANN org suggests that the EPDP Team divide Recommendation 2.6 into two parts. The first part can focus on the “need” while the second part can focus on “demonstrating the ability.”

It would also be helpful if the EPDP Team can provide Implementation Guidance on both parts of this recommendation as it would be useful to provide more clarity on how ICANN org should evaluate applicants with regard to demonstrating “need” and what standards or tests should be used to allow applicants to demonstrate their ability to manage variants. This additional layer will assist org in implementing this recommendation more effectively.		Yes
51
2. One example that may be helpful in the instance of a gTLD that has a relevant community follows. We can look at “ıssız” and “issiz” as an example. The applicant for ıssız can be required to provide supporting documentation of the Turkish community demonstrating that not activating "issiz" would prevent a global customer (using a keyboard with only a regular i) from typing the TLD.Yes
52
3. ICANN org acknowledges the wide breadth of knowledge within the EPDP Team that has helped inform the Outputs in the Initial Report. If the EPDP Team feels that the group lacks sufficient expertise and/or time to develop questions and the criteria by which they would be evaluated, there are several options.

The EPDP Team may consider requesting additional research be conducted to help supplement part two of the recommendation on “demonstrating the ability”. This could be in the form of a recommendation as permitted by the Policy Development Process Manual, which states that PDP Teams may make recommendations to the GNSO Council regarding “Research or Surveys to be Conducted.”		Yes
53
4. ICANN org notes that all instances in the Initial Report where the EPDP Team mentions “activating,” “activation,” or “seeks to activate” should be changed to a variation of “application process” such as “apply for” or “applying.” The use of “activate” applies to the step when the string is delegated after the successful application evaluation and contracting steps, therefore “application” and “activation” may not be considered synonymous.No
54
5. ICANN org notes that in some instances the EPDP Team uses the term “IDN gTLD” whereas in others it uses “gTLD.” For consistency and to reduce the chance of any divergence in policy, the EPDP Team should change all instances in the Initial Report to the same term.No
55
Discussion TabledRec 2.xxThe submission process by applicants of supporting information must allow for a consistent and meaningful evaluation by evaluators with the requisite expertise.N/A
(no text sent)
56
Draft Rec Stable Rec 2.7The fee structure associated with future IDN gTLD applications that include variant label(s), as well as activation requests from existing registry operators for allocatable variant label(s) of their respective IDN gTLDs, must be consistent with the principle of cost recovery reflected in the 2012 Applicant Guidebook and affirmed by the New gTLD Subsequent Procedures PDP.No
(rec reviewed)
57
Draft Rec Pending ReviewRec 2.9Applications for allocatable variant labels of existing IDN gTLDs from the 2012 round can be submitted during the next round of the New gTLD Program and any subsequent rounds. N/A
(no text sent)
58
Rec 2.10As a one-time exception, applications for allocatable variant labels of existing IDN gTLDs from the 2012 round must receive priority in processing order ahead of all other new gTLD applicants, including the IDN applicants that elect to participate in the prioritization draw during the next round. N/A
(no text sent)
59
B4process to apply to variant labelsWhat should an application process look like in terms of timing and sequence for an existing and future Registry Operator with respect to applying or activating their allocatable variant TLD labels?Draft Rec Pending Review

Rec 2.11An application for an allocatable variant label cannot precede an application for that variant label’s primary IDN gTLD.N/A
(no text sent)
60
Rec 2.12A registry operator who wishes to apply for an allocatable variant label of its delegated IDN gTLD must submit an application during an application round.N/A
(no text sent)
61
Rec 2.13Applicants for a primary IDN gTLD and requested allocatable variant label(s) that pass evaluation will be subject to the terms and conditions of the 2012 round in respect of the timeframe for delegation, including the ability to apply for an extension of time for delegation.N/A
(no text sent)
62
Rec 2.14The sequence for delegating the applied-for primary IDN gTLD and the requested allocatable variant label(s) that pass evaluation can be determined by the registry operator.N/A
(no text sent)
63
B4arole of "withheld for the same entity"For the variant labels with status “withheld for the same entity” (i.e. not requested for allocation in the application process), what role do they play?Draft Text Being DevelopedN/A
(no text sent)
64
B5extension of restrictions of community, brand to variant labelsDo restrictions that apply to a TLD (e.g., community TLDs, dot brand TLDs) also apply to its variants? Are these labels equally treated as different versions of the same string, orcompletely independent strings not bound by the same restrictions?Draft Rec Stable Rec 2.8

In future new gTLD application processes, the primary applied-for gTLD and its allocatable variant labels requested by the applicant are to be treated as different versions of the same string and will be bound by the same restrictions. Yes1. In Recommendation 2.8, the EPDP Team says: “labels requested by the applicant…will be bound by the same restrictions.” ICANN org would like to note that the New gTLD program binds applicants, whereas the Registry Agreement (RA) binds Registry Operators (ROs). It would be helpful to note in the recommendation that the restriction mentioned is valid if reflected in the Registry Agreement.Yes
65
2. ICANN org suggests changing the recommendation language by removing the phrase “are to be treated as different versions of the same string…” as it may be difficult to interpret this text but only seems to be an explanatory note.

The EPDP may consider the alternative wording for enhanced clarity:

“In future new gTLD application processes, the primary applied-for gTLD and its allocatable variant labels requested by the applicant will be bound by the same restrictions.”		Yes
66
3. While the EPDP Team lists the “restrictions” to which Recommendation 2.8 is referring in Charter Question b5, ICANN org suggests they also be listed in this recommendation in order to be more explicit and to reduce ambiguity.Yes
67
E1role of "withheld for the same entity"What role, if any, do TLD labels “withheld for possible allocation” or “withheld for the same entity” play vis-a-vis: objection process; and string similarity review process?Draft Text Being DevelopedN/A
(no text sent)
68
E2criteria for objectionThe WG and the SubPro IRT to coordinate to ensure consistency in the implementation of the objection process for the variant label applications of existing and future TLDs.Part 1 - Draft Rec Stable Rec 3.1

In future new gTLD application processes, all allocatable variant gTLD labels that applicants request to activate must be subject to the objection process. Yes1. ICANN org notes that all instances in the Initial Report where the EPDP Team mentions “activating,” “activation,” or “seeks to activate” should be changed to a variation of “application process” such as “apply for” or “applying.” The use of “activate” applies to the step when the string is delegated after the successful application evaluation and contracting steps, therefore “application” and “activation” may not be considered synonymous.No
69
70
Draft Text Being DevelopedString Confusion Yes
(input for small team rec)		1. ICANN org suggests that the EPDP Team revise the String Similarity Objections recommendations to align more closely with the structure of the String Similarity Review recommendations noted in the previous section once finalized.No
71
Limited Public InterestYes
(input for small team rec)		1. ICANN org suggests that the EPDP Team be intentional and precise when using terms such as “should” or “must” while providing its output, as the language used have different implications during policy implementation.No
72
Legal RightsYes
(input for two options)		1. ICANN org’s assumption is that the EPDP Team does not intend to recommend a new standard for review and that this output only refers to the allowable strings that can be objected against. Can the Working Group confirm that the assumption is correct?Yes

(input already discussed)
73
2. As noted above in the string similarity review recommendations, there are two types of blocked variant labels. The first type is a blocked variant label within the same script, and the second type is a blocked variant label created by mixing various scripts. When the EPDP Team is drafting recommendations on objections, ICANN org suggests being explicit on whether they apply to only single or mixed-script blocked variant labels.

Regarding the second type of blocked variant labels, ICANN org seeks confirmation on whether a holder of such a trademark is allowed to file an objection. If that’s the case, then mixed script blocked variant labels will also need to be maintained.

For clarity, marks can be in mixed-scripts, and if mixed-script blocked variant labels are not included in possible objection terms, then any mark holder that has a mixed script trademark would not be able to object against the mixed-script blocked variant labels.		Yes

(input already discussed)
74
3. In order to reduce the complexity of the String Similarity-related recommendations, ICANN org would like to point out that blocked variant labels mentioned in these recommendations are only a subset which is within the same script and excludes the mixed-script blocked variant labels (except in cases allowable in the RZ-LGR).Yes

(input already discussed)
75
4. ICANN org would also like to know if there is an expectation that the tool we provide would list all of the blocked variant labels? If that’s the case, having to consider all mixed scripts as well would lead to millions of permutations creating a high level of complexity and issues. Would it be sufficient to enumerate allocatable variant labels but only respond against a specific input label if it is a blocked variant label of a primary one, without enumerating the blocked variant labels?Yes

(input already discussed)
76
Community Yes
(to confirm assumption)		1. ICANN org’s assumption is that if an objection can be raised against a blocked variant label that can never be allocated, and the objector prevails, then the application will not move forward (the primary label and all applied for variant labels are not allowed to proceed). Can the Working Group confirm that the assumption is correct?Yes

(input already discussed)
77
E3string similarityThe WG and the SubPro IRT to coordinate to ensure consistency in the implementation of the string similarity review procedure for variant label applications of existing and future gTLDs.Draft Text Being DevelopedRec 3.12Yes
(operational input for implementing the hybrid model)		See details on pp.12, 15-16: https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20221116/c1e0a14b/IDNEPDPICANNOrgInput-16Nov22-0001.pdf#page=12 Yes

(input already discuss)
78
Rec 3.13
79
IG 3.14
80
E3astring similarity consequencesAfter a requested variant string is rejected as a result of a string similarity review, should the other variant strings in the same variant set remain allocatable? Should individual labels be allowed to have different outcomes/actions (e.g., some labels be blocked and some be allowed to continue with an application process)?Draft Text Being DevelopedN/A
(no text sent)
81
E4string contention resolutionThe WG and the SubPro IRT to coordinate to ensure consistency in the implementation of the string contention resolution mechanism for variant label applications of existing and future new gTLDs.Draft Text Being DevelopedN/A
(no text sent)
82
E5reserved stringsShould the reserved strings ineligible for delegation for existing and future gTLDs be updated to include any possible variant labels?Draft Rec Stable & Sent to ICANN org for Input
Rec 3.2

The Reserved Names list should not be expanded to include variants. Yes1. ICANN org suggests that consistent terminology be used throughout the Initial Report, based on context, for example when referring to variant labels or variant gTLD labels in order to minimize confusion or misinterpretation. It is also recommended that the language mirrors terms used in the Subsequent Procedures Final Report as to avoid any confusion or contradictions.No
83
2. ICANN org notes that all instances in the Initial Report where the EPDP Team mentions "blocked variants "should be modified to be "blocked variant labels.”No
84
Rec 3.3No application for a variant of a Reserved Name is allowed. Yes1. ICANN org notes that all instances in the Initial Report where the EPDP Team mentions "blocked variants "should be modified to be "blocked variant labels.”No
85
Draft Rec Pending ReviewRec 3.10The list of Strings Ineligible for Delegation should not be expanded to include variants. N/A
(no text sent)
86
Rec 3.11Only the protected organizations on the list of Strings Ineligible for Delegation are allowed to apply for the allocatable variant(s) of their protected string(s) at the top-level. Consistent with Recommendation 2.11, an application for an allocatable variant label of a protected string cannot precede an application for the protected string, which serves as the primary or source string for generating the variant label.N/A
(no text sent)
87
E6two char Latin IDN TLDsIs there any reason to permit the registration of gTLDs consisting of decorated two-character Latin labels which are not variant labels of any two-letter ASCII labels?No Rec NeededN/AN/AN/A
(no text sent)
88
E7catch all same entity top levelWhat other ICANN policies and procedures should be updated to enforce the “same entity” rule and the use of RZ-LGR as the sole source to calculate the variant Labels and disposition values?Draft Text Being Developed- Evaluation Criteria for Variants of TLDs with Restrictions

- Singular / Plural Form 		N/A
(no text sent)
89
D2lifecycle management of variant tldsIn order to ensure that the same entity principle is maintained for a gTLD and its allocated variant TLD labels, what are the operational and legal impacts to the: Registry Transition Process or Change of Control in the Registry Agreement; Emergency Back-End Registry Operator (EBERO) provisions; and reassignment of the TLD as a result of the Trademark Post-Delegation Dispute Resolution Procedure (TM-PDDRP)?Draft Rec StableRec 3.4In 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 gTLD label(s), if any, at the same time. N/A
(no text sent)
90
Rec 3.5After the Registry Transition Process or Change of Control process is completed for an IDN gTLD and its allocated and delegated variant gTLD label(s), only the successor registry operator can apply to activate the other non-delegated, allocatable variant label(s) of that IDN gTLD. N/A
(no text sent)
91
Rec 3.6Emergency transition of an IDN gTLD to an EBERO provider must include the allocated and delegated variant gTLD label(s) of that IDN gTLD, if any. All these labels must be transitioned to the same EBERO provider at the same time.N/A
(no text sent)
92
Rec 3.7In the event an IDN gTLD is reassigned as a result of a TM-PDDRP determination, that reassignment must include all allocated and delegated variant gTLD label(s) of the IDN gTLD, if any, at the same time.N/A
(no text sent)
93
D3same entity data escrow impactsIn order to ensure that the same entity principle is maintained, what are the operational and legal impacts to the data escrow policies, if any.Draft Rec StableRec 3.8

The same data escrow provider must be contracted for the IDN gTLD and its allocated and delegated variant label(s). N/A
(no text sent)
94
IG 3.9The escrow data associated with each variant gTLD label should be stored in separate files.N/A
(no text sent)
95
96
97
98
99
100