Dear all, Please find below the notes and action items from today’s meeting on Thursday, 30 March 2023 at 13:00 UTC. Kind regards, Ariel, Steve, and Emily Notes and Action Items - IDNs EPDP Call – 30 March 2023 Action Items Action Item 1: In public comment input form, change open-ended question “Are there any recommendations the EPDP Team has not considered?” to “Are there any issues pertaining to top-level variant gTLDs the EPDP Team has not considered?” Action Item 2: In header for Section 9 – Change “Variant Label State” to “Variant Label States” Action Item 3: Add additional question for each recommendation asking for any input on the rationale. Action Item 4: Revise Recommendation 1.5 to read: “In order to encourage a positive and predictable registrant experience, a framework for developing guidelines for the management of gTLDs and their variant labels at the top level by registries and registrars must be created during implementation.” In addition, change “best practice guidelines” to “guidelines” in Implementation Guidance 1.6. Action Item 5: Move suggested IG under Recommendation 2.2 to rationale for Recommendation 2.2. Action Item 6: Update Recommendation 2.24 with: “A future gTLD applicant applying for an IDN gTLD and up to [x] variant labels will incur the same base application fee as any other gTLD applicant who does not apply for variant labels in that round.” Action Item 7: Update Recommendation 2.25 to read: “An applicant or an existing registry operator from the 2012 round that exceeds [x] variant labels in their application may incur additional fees that ICANN org considers to be proportionate with any additional costs associated with evaluating the application and consistent with the cost recovery principle.” Add language also including the concept “or if the variant label(s) are applied for in more than one application round.” Action Item 8: Update Recommendation 2.29 to read: “As a one time exception for the immediate next new gTLD application round, the base application fee for allocatable variant labels by existing IDN gTLD registry operators from the 2012 round will be waived.” Action Item 9: Add an item to the glossary for label states. Action Item 10: EPDP Team members to suggest additional text to explain glossary item “same entity.” Action Item 11: Update definition of “string” to read: “A combination of characters / letters that form the top-level domain name.” Notes Welcome and Chair Updates * Today’s call will focus on reviewing text for the Initial Report. * We will try to get through remaining text today and Monday. If this is possible, we will cancel the call next Thursday, 6 April. Public comment input form * Overview of Public Comment Input Form (see attachment). * Form seeks to provide structure and direction for commenters, makes clear their level of support for recommendations, and collects specific input on recommendations. This approach makes review of comments more efficient. * The form follows a template provided by ICANN org. The first section of text is standard. * Section 1: Information about submission * Sections 2-9 list specific recommendations and implementation guidance from the Initial Report. For each recommendation, the form asks the commenter to respond with level of support for the recommendation, asks the commenter to provide revised wording and rationale for revised wording where applicable, and asks for the rationale for non-support if applicable. * Section 10 includes open ended questions that give an opportunity for broader input. Focus: any additional recommendations that the EPDP Team has not considered; feedback on the glossary; any other issues. Discussion points on public comment input form: * General support for the format. Question about how the review of public comments will be organized, noting that triage is important when the volume of comments is high. * Staff typically consolidates comments and arranges them in a logical manner to support review by the EPDP Team. On a future call, leadership will present on the proposed approach for reviewing comments for the initial report. * For open-ended question, “Are there any recommendations the EPDP Team has not considered?” suggestion to edit the question to: “Are there any issues pertaining to top-level variant gTLDs the EPDP Team has not considered?” Support expressed for this suggestion. Action Item 1: In public comment input form, change open-ended question “Are there any recommendations the EPDP Team has not considered?” to “Are there any issues pertaining to top-level variant gTLDs the EPDP Team has not considered?” * Introduction needs to make clear that this is a phase 1 report and that phase 2 work will follow. Action Item 2: In header for Section 9 – Change “Variant Label State” to “Variant Label States” Action Item 3: Add additional question for each recommendation asking for any input on the rationale. * Discussion of whether it is helpful to include line numbers in the report for commenters to reference in the comments. Agreement to leave them out for now as it may make the page look cluttered. Third reading of draft text * Leadership suggestion to streamline the text included in the main body of the report by moving responses to charter questions to an annex. Charter questions themselves will stay in the main body of the report. The charter question responses provide important context, but the focus is the recommendation text and the rationale. * Support expressed for this approach. Topic A: https://docs.google.com/document/d/1Bt0LT45UaLynFNverh1nJhyvq6q6NxgSFAOnOp2L... * Revisions to response to charter question A3 and associated recommendations: * Suggestion to remove: “In the event that an applied-for gTLD string, whose script is supported by the RZ-LGR, is deemed “invalid” or “blocked” (where the string is a variant label) by the RZ-LGR, such an application is ineligible to proceed in the application process.” Replace with text of Recommendation 1.17: “An applied-for gTLD string that has been accepted through the submission system and correctly assessed by the DNS Stability Review Panel as “invalid” or “blocked” (where the string is a variant label) is disqualified unless and until such a string is deemed valid and allocatable in a future version of the RZ-LGR, if any.” Some support expressed for this approach. * The text “(where the string is a variant label)” has been added throughout the section. * Second bullet in response to charter question A3 may need additional clarification based on feedback from Dennis. * First sentence of Recommendation 1.2, added text in brackets – “Only an applied-for gTLD string that conforms to the mandatory string requirements, including IDNA 2008 for IDN strings [and the RZ-LGR].” * Rationale for Recommendation 2.1 updated to for consistency with the principle of the integrity of the set. * Revisions to response to charter question A5 and associated recommendations: * Current text of Recommendation 1.5 reads “A framework for developing best practice guidelines in the management of gTLDs and their variant labels by registries and registrars must be formulated with a view to encourage a positive registrant experience.” * Suggested alternative: “In order to encourage a positive and predictable registrant experience, a framework for developing best practice guidelines for the management of gTLDs and their variants by registries and registrars must be created during implementation.” * Suggestion to use “acceptable practice” instead of “best practice.” * As a reminder, these will not be binding. * Best practices suggests a single right way to do things. There will be different views about how to manage variants operationally at the second level. Acceptable practices can guide good registrant experience without implying that there is one best approach. * IG 1.6: Suggestion to clarify that the practices are targeting registries and registrars. Action Item 4: Revise Recommendation 1.5 to read: “In order to encourage a positive and predictable registrant experience, a framework for developing guidelines for the management of gTLDs and their variant labels at the top level by registries and registrars must be created during implementation.” In addition, change “best practice guidelines” to “guidelines” in Implementation Guidance 1.6. * New sentence added to Rationale for Recommendation 1.5 and Implementation Guidance 1.6 (in brackets): The EPDP Team agreed that it would be valuable to develop best practice guidelines for the management of variant domains at the registry and registrar levels. [This is to address any unintended consequences of Recommendation 1.4, . . ] Topic B: https://docs.google.com/document/d/15YGISgNQYL_VfcVVZ6E97qbo42GPziP6x089bR3w... * Revision to Recommendation 2.2: “Recommendation 2.2: The registry service provider for each one of the Critical Functions as defined in the base Registry Agreement 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.” * Suggested Implementation Guidance to go with Recommendation 2.2: “Registry operators may use different third party service providers for the provision of their Critical Functions. In the event that an existing IDN gTLD registry operator from the 2012 round applies for variant labels of their IDN gTLD in a future round, they will be required to use the same service provider for the provision of their respective critical functions, for example their Data Escrow provider must be the same for the existing IDN gTLD and the delegated variant labels and their DNS service provider must also be the same for their existing IDN gTLD and the delegated variant labels.” Action Item 5: Move suggested IG under Recommendation 2.2 to rationale for Recommendation 2.2. * New sentence added to Rationale for Recommendation 2.2: “The EPDP Team affirms that whichever registry service provider is used for a Critical Function for an existing IDN gTLD from the 2012 round, the same registry service provider must be used for providing such a Critical Function for its delegated variant label(s).” Topic D: https://docs.google.com/document/d/1C6xKX87w2LtN4Is0mehuRgc1GqjKmbbhT14KbvUH... * Addition of bracketed text to Implementation Guidance 2.28: “Criteria for evaluating the explanations submitted by applicants on [the need for variant label(s)] should be pre-identified and applied consistently by evaluators with the requisite expertise.” * Current text for Recommendation 2.24: “A future IDN gTLD applicant must be allowed to apply for up to [x] allocatable variant label(s) in the same application by paying the same base application fee. The base application fee for each such application must be the same base application fee as any other application.” Suggested alternative formulation of the recommendation: “Recommendation 2.24: A future gTLD applicant applying for an IDN gTLD and up to [x] variant labels will incur the same base application fee as any other gTLD applicant who does not apply for variant labels in that round.” Reason for the proposed alternative: Some might interpret this as inconsistent with the recommendation stating that there is no ceiling value. Action Item 6: Update Recommendation 2.24 with: “A future gTLD applicant applying for an IDN gTLD and up to [x] variant labels will incur the same base application fee as any other gTLD applicant who does not apply for variant labels in that round.” * Current text for Recommendation 2.25: “ICANN org should assess and charge additional application fees based on the “cost recovery” principle if the applied-for allocatable variant labels of a primary IDN gTLD string exceeds the threshold number of [x], or if the variant label(s) are applied for in more than one application round.” Suggested alternative language: “An applicant that exceeds [x] variant labels in their application may incur additional fees that ICANN org considers to be proportionate with any additional costs associated with evaluating the application and consistent with the cost recovery principle.” * Proposed alternative intends to make the recommendation language simpler. Text suggests that ICANN has the discretion about whether an application fees apply. Action Item 7: Update Recommendation 2.25 to read: “An applicant or an existing registry operator from the 2012 round that exceeds [x] variant labels in their application may incur additional fees that ICANN org considers to be proportionate with any additional costs associated with evaluating the application and consistent with the cost recovery principle.” Add language also including the concept “or if the variant label(s) are applied for in more than one application round.” * Current text of Recommendation 2.29: “As a one time exception for the immediate next application round, an existing IDN gTLD registry from the 2012 round must be allowed to apply for up to [x] allocatable variant label(s) of its existing IDN gTLD without paying the base application fee.” Alternative language proposed: “As a one time exception for the immediate next new gTLD application round, the application fee for existing IDN gTLD registry operators from the 2012 round will be waived.” * Suggestion that alternative needs to specify “up to [x] allocatable variant label(s)” * If we do include “up to [x] allocatable variant label(s)”, we need to include language about the proportionate fee. * Because there is still money left over from 2012, perhaps the cost of fees for existing ROs should be covered (no additional fee if there are more than x variants). * Existing IDN gTLD registry operators have been at a disadvantage. Do we want to carry the x value over to existing gTLD registry operators? * We should clarify in the language of this text that we are referring to variant labels, so that the recommendation can stand alone. * Should we change “application fee” to “base application fee” for clarity? * We say in 2.25 that ICANN can determine additional fees for additional costs, so the alternative language in 2.29 does not need to include language about additional fees. * For clarity, if we have a specific intention with respect to the application fee, it should be called out in the text. * Does 2.25 also apply to existing RO from 2012 who applies for x number of variants, or do we waive the fee? * Support for the idea that the only waiver the existing ROs should enjoy is a waiver on the base application fee. If they apply for more variants later, additional fee should apply. Action Item 8: Update Recommendation 2.29 to read: “As a one time exception for the immediate next new gTLD application round, the base application fee for allocatable variant labels by existing IDN gTLD registry operators from the 2012 round will be waived.” * New Recommendation 2.26: “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.” * New Recommendation 2.27: “The calculation of the registry-level transaction fee must be based on the cumulative number of domain name registrations of the combined under all of the delegated gTLD label(s) from a variant label set.” * Associated rationales are also newly added. Topic E: https://docs.google.com/document/d/115eSNnxBsCbUszEGU7i4xbzLwu1u8_UdaGEJD9CV... * See new Table 3 submitted by Dennis. Review of Glossary * Glossary: https://docs.google.com/document/d/115eSNnxBsCbUszEGU7i4xbzLwu1u8_UdaGEJD9CV... * There are a handful of acronyms that are used regularly in the report that are repeated in the glossary. * Glossary term “allocatable” – note that these variants may be also be generated from IDN tables at the second level. * Response: we may not want to introduce the second level in this report as it is focused on the top level. We need to be clear in the intro the context of the list. It is focused on the specific work of phase 1 and the way we use terms in the report. For phase 2, we can always adjust the text. * Comment that “Conservatism” may not be able to strike a balance between user needs and security and might lean towards security. * “Delegated” – suggestion that the first sentence may not be needed: “The subsequent status of a label after it has been Allocated to the entity that has applied for the label.” * Discussion of defining label states – there is a table included in the response to CQ A10 * Suggestion to expand on definition of Same Entity. * “String” – should this focus on the top level, because the Phase 1 report focuses on the top level? In the context of this report, we use it in this context. Action Item 9: Add an item to the glossary for label states. Action Item 10: EPDP Team members to suggest additional text to explain glossary item “same entity.” Action Item 11: Update definition of “string” to read: “A combination of characters / letters that form the top-level domain name.” * Suggestion to update “Variant Label Set” definition