FINAL VERSION SUBMITTED (IF RATIFIED)
The final version to be submitted, if the draft is ratified, will be placed here by upon completion of the vote.
FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC
The final draft version to be voted upon by the ALAC will be placed here before the vote is to begin.
DRAFT SUBMITTED FOR DISCUSSION
The first draft submitted will be placed here before the call for comments begins. The Draft should be preceded by the name of the person submitting the draft and the date/time. If, during the discussion, the draft is revised, the older version(S) should be left in place and the new version along with a header line identifying the drafter and date/time should be placed above the older version(s), separated by a Horizontal Rule (available + Insert More Content control).
Proposed by Justine Chew , 1 Feb 2024, 02:05 UTC
1. Commend to the ICANN Board, the revisions made by the IDNs-EPDP Team resulting from public comments received for the Phase 1 Initial Report, in particular, in aligning Rec 3.11 with the conservatism principle, by strengthening Rec 3.5 and IG 3.6 to help ensure that gTLD variant labels are introduced and managed in a safe and secure manner. The final Rec 3.5 and IG 3.6 read together with final Rec 3.7, IG 3.8 and IG 3.9, provides useful guidance towards efforts to mitigate the risks associated with variant management both before and after a string is delegated (if at all). The IDNs EPDP Team should be congratulated for taking into account the individual end user perspective, by taking steps to balance the risk of user confusion and potential for harm through exploitation of such user confusion against the utility for a language's need for and use of variant TLDs to facilitate a better end user experience.
- Note: Rec 3.11, Rec 3.5, IG .3.6, Rec 3.7, IG 3.8 and IG 3.9 collectively touch on an applicant's ability to seek one or more gTLD variant labels to their respective string or existing TLD. FN-1
2. With regards to a potential contradiction between the IDNs-EPDP Rec 3.22 and SubPro PDP IG 25.3 in respect of scripts not supported by the RZ-LGR, we opine that the IDNs-EPDP Rec 3.22 (which in effect disallows applications for strings in scripts not supported by the RZ-LGR), would be the more sensible way to proceed. It would be not be prudent for ICANN to accept such applications (which SubPro PDP IG 25.3 suggested be allowed) if they have little to no chance of passing initial evaluation due to non-conformance to the RZ-LGR since such scripts are not supported by the RZ-LGR. Potential applicants for strings in scripts not yet supported by the RZ-LGR should instead promptly engage with ICANN org to facilitate the relevant not-yet supported scripts to be integrated into the RZ-LGR, so as to not undermine the utility of the RZ-LGR. A Board-approved recommendation would displace any contradictory implementation guidance.
Rec & IG language for EASY REFERENCE ONLY and does not need to be included in statement
IDNs-EPDP
Final Recommendation 3.5: In addition to explaining the mission and purpose of the applied for primary gTLD string or existing gTLD, the applicant seeking one or more gTLD variant labels will describe the justification of such need. The justification given by the applicant shall at minimum provide the following information:
3.5.1 The meaning or intended meaning (for non-dictionary words) of each of the applied-for variant label(s), including sources;
3.5.2 Explanation of how the primary and variant labels are considered the same;
3.5.3 Explain the benefits and the user communities who will benefit from the introduction of the applied-for variant label(s); and
3.5.4 A description of the steps that the applicant will take to minimize the operational and management complexities of variant gTLDs and variant domain names that impact registrars, resellers and/or registrants.
Implementation Guidance 3.6: With respect to the evaluation of the information submitted per Final Recommendation 3.5:
3.6.1 The evaluation panel must include evaluators with relevant script expertise;
3.6.2 The evaluation panel should apply criteria based on a general standard of reasonableness and the criteria must be established during implementation;
3.6.3 Consistent with Recommendation 27.2 of the SubPro PDP Final Report, evaluation scores on the questions should be limited to a pass/fail scale (0-1 points only);
3.6.4 The applicant must pass each element to enable the applied-for variant label to proceed to the next stage of the application process; and
3.6.5 The evaluation outcome of any one applied-for variant label should not impact the evaluation outcome of any other applied-for variant label in the application (including the primary gTLD string).
Final Recommendation 3.7: A future applicant must be required to demonstrate its ability to manage the applied-for primary gTLD string and applied-for allocatable variant label(s) from both a technical and operational perspective. The same requirement applies to registry operators who wish to apply for allocatable variant label(s) of their existing gTLDs.
Implementation Guidance 3.8: The evaluation of capability to manage the variant label set should be closely tied to the overall technical capability evaluation. The evaluation should be based on measurable criteria including, but not limited to, the performance of Critical Functions with respect to second-level registrations under the primary gTLD string and the applied-for allocatable variant label(s).
Implementation Guidance 3.9: Within 15 months of the delegation of the first gTLD variant label and every 24 months thereafter, ICANN org should conduct research in order to identify whether any additional criteria or tests should be used, as part of the application process, to evaluate the technical and operational capability of an applicant to manage a variant label set at the registry level. ICANN org must offer the community an opportunity to provide input on the scope of the research to be undertaken, as well as any proposed outputs on additional criteria or tests, and such outputs should not be applied retroactively.
Final Recommendation 3.11: A future applicant applying for a primary gTLD string and up to four (4) of that string’s allocatable variant labels during an application round must incur the same base application fee as any other gTLD applicant who does not apply for variant labels in that round.
Final Recommendation 3.22: Only an applied-for gTLD string that conforms to the mandatory string requirements, including IDNA 2008 for IDN strings, as well as the RZ-LGR, can be submitted through the new gTLD application submission system. ..........
SubPro PDP
Implementation Guidance 25.3: If a script is not yet integrated into the RZ-LGR, applicants should be able to apply for a string in that script, and it should be processed up to but not including contracting. Applicants under such circumstances should be warned of the possibility that the applied-for string may never be delegated and they will be responsible for any additional evaluation costs.
Proposed by Hadia Elminiawi, 14 Feb. 2024 16:28
It is important to recognize that while implementation guideline 25.3 of the Subsequent Procedures PDP report pertains to all scripts, including but not limited to IDNs, recommendation 3.22 of the IDN EPDP for gTLDs specifically targets IDN TLDs and variants. Consequently, we can view 3.22 as a subset of 25.3 with more stringent criteria. Moreover the determination of variants and their disposition is exclusively done through the RZ-LGRs. Therefore, applying for a variant without its script being included in the RZ-LGRs would be impractical. (IDN EPDP for gTLDs Final Recommendation 1.1: The RZ-LGR must be the sole source to calculate the variant labels)
and disposition values for all existing gTLDs.)
