March 2023 - Gnso-epdp-idn-team

Documents for Review / Input before Monday Meeting
by Ariel Liang April 3, 2023

April 3, 2023

Dear All, In preparation for the Monday, 3 April meeting, please find below the documents for your review and input, especially the ones under 1b, 2a, and 2b. 1. Draft Sections of the Phase 1 Initial Report: https://docs.google.com/document/d/1nD-a82Bx_JIYzWcZwBQcD61Aqn_yBPQMVr1l3Ep… * You can find all draft sections of the Initial Report from the table of contents here i. Section 4, Annex C, and Annex E will be completed right before circulation of the full report to the EPDP Team ii. Staff plan to provide an overview of all these draft sections during the Monday meeting * Please specifically focus on the review of the following sections, as EPDP Team’s input are expected be discussed on Monday: i. Section 3 Glossary ii. Section 4 Introduction section to the Preliminary Recommendations iii. Section 5 Differences Between EPDP-IDNs and ccPDP4 Preliminary Recommendations * Leadership team may provide more substantive edits before the call 1. Redline and highlighted draft text that needs to be closed off: * A3 (pp.3-6): https://docs.google.com/document/d/1Bt0LT45UaLynFNverh1nJhyvq6q6NxgSFAOnOp2… * D1b (pp.4-10): https://docs.google.com/document/d/1C6xKX87w2LtN4Is0mehuRgc1GqjKmbbhT14KbvU… i. Please focus on the review of the revised Rec 2.25 and 2.29, and the rationale for Rec 2.7, 2.24-2.27, and 2.29 * B4 (Rec 2.13, p.4): https://docs.google.com/document/d/15YGISgNQYL_VfcVVZ6E97qbo42GPziP6x089bR3… i. We missed to address the leadership comment during yesterday’s call * D8 (Rec 2.18, pp.17-18): https://docs.google.com/document/d/1C6xKX87w2LtN4Is0mehuRgc1GqjKmbbhT14KbvU… i. We missed to address the updated text during yesterday’s call * A9 (Rec 1.12, p.17): https://docs.google.com/document/d/1Bt0LT45UaLynFNverh1nJhyvq6q6NxgSFAOnOp2… i. The definition of the label states may need to be incorporated in the recommendation language based on agreement on the glossary In addition, on 16 March 2023, the ICANN Board adopted a substantial portion of the SubPro PDP Outputs. The Outputs adopted by the ICANN Board include all the IDN recommendations in Topic 25 of the SubPro PDP Final Report. See details here: https://www.icann.org/en/board-activities-and-meetings/materials/approved-r…. This should have minimum impact on the EPDP preliminary recommendations, as our recommendations are consistent or align with the SubPro recommendations. Thank you all for your efforts for the final push. Have a nice weekend! Best Regards, Ariel

4 4

Proposed Agenda - IDN EPDP Meeting #76 - Monday 3 April 2023 at 13:00 UTC for 2 hours
by Ariel Liang March 31, 2023

March 31, 2023

Dear all, Please find below the proposed agenda for our meeting on Monday, 3 April 2023 at 13:00 UTC (2 hour call). Kind regards, Ariel, Steve, and Emily IDN EPDP Meeting #76 Proposed Agenda 1. Roll Call and SOI Updates (2 mins) 2. Welcome and Chair Updates (5 mins) 3. Close off any remaining charter question discussions, e.g., A3 and D1b (40 mins) 4. Discuss Section 3 and Section 5 of Initial Report (40 mins) 5. Overview of Initial Report sections (30 mins) 6. AOB (3 mins)

2 1

Post Call | IDNs EPDP Team call | Thursday, 30 March 2023
by Devan Reed March 31, 2023

March 31, 2023

Dear all, All documents for the IDNs EPDP Team call held on Thursday, 30 March 2023 can be found on the agenda wiki page <https://community.icann.org/x/qgP5DQ> (attendance included) and the GNSO Master Calendar<https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…>. These include: * Attendance (please let me know if your name has been left off the attendance list) * There is no recording for this call. Please reference Notes/Action items. For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-epdp-idn-team/> and the main wiki page<https://community.icann.org/x/uAPpCQ>. Thank you! Kind Regards, Devan

1 0

REMINDER | Meeting Invitation | IDNs EPDP Team | Monday, 03 April 2023 at 13:00 UTC
by Devan Reed March 31, 2023

March 31, 2023

Dear all, The IDNs EPDP Team meeting is scheduled on Monday, 03 April 2023 at 13:00 UTC for 2 hours. Please click link to join the webinar: https://icann.zoom.us/j/94276275950?pwd=dG5hanFzMlpsYmh0NnFjTEQwOUV1dz09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/94276275950?pwd=dG5hanFz…> Passcode: !!0tV0Wh&K For Audio only: One tap mobile : US: +13017158592,,94276275950#,,,,*5259149775# or +13126266799,,94276275950#,,,,*5259149775# Webinar ID: 942 7627 5950 Passcode: 5259149775 International numbers available: https://icann.zoom.us/u/adP1jJ0gRH <https://urldefense.com/v3/__https:/icann.zoom.us/u/adP1jJ0gRH__;!!PtGJab4!v…> If this is your first time with Zoom, please take a look here: Welcome to Zoom <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> Members, participants, and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior <https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/rQP5DQ * Check your time zone: https://tinyurl.com/42urhjbt [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/42urhjbt__;!!PtGJab4!6N2h_Ng…> ONLY for Members and Participants * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Please select Everyone, when posting to the chat in order for everyone to see and to be captured afterwards. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Devan

1 0

Notes and action items - IDNs EPDP Meeting #75 - 30 March 2023
by Emily Barabas March 30, 2023

March 30, 2023

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/1Bt0LT45UaLynFNverh1nJhyvq6q6NxgSFAOnOp2… * 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_VfcVVZ6E97qbo42GPziP6x089bR3… * 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/1C6xKX87w2LtN4Is0mehuRgc1GqjKmbbhT14KbvU… * 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_UdaGEJD9C… * See new Table 3 submitted by Dennis. Review of Glossary * Glossary: https://docs.google.com/document/d/115eSNnxBsCbUszEGU7i4xbzLwu1u8_UdaGEJD9C… * 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

1 0

Meeting Invitation | IDNs EPDP Team | Monday, 03 April 2023 at 13:00 UTC
by Devan Reed March 30, 2023

March 30, 2023

Dear all, The IDNs EPDP Team meeting is scheduled on Monday, 03 April 2023 at 13:00 UTC for 2 hours. Please click link to join the webinar: https://icann.zoom.us/j/94276275950?pwd=dG5hanFzMlpsYmh0NnFjTEQwOUV1dz09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/94276275950?pwd=dG5hanFz…> Passcode: !!0tV0Wh&K For Audio only: One tap mobile : US: +13017158592,,94276275950#,,,,*5259149775# or +13126266799,,94276275950#,,,,*5259149775# Webinar ID: 942 7627 5950 Passcode: 5259149775 International numbers available: https://icann.zoom.us/u/adP1jJ0gRH <https://urldefense.com/v3/__https:/icann.zoom.us/u/adP1jJ0gRH__;!!PtGJab4!v…> If this is your first time with Zoom, please take a look here: Welcome to Zoom <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> Members, participants, and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior <https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/rQP5DQ * Check your time zone: https://tinyurl.com/42urhjbt ONLY for Members and Participants * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Please select Everyone, when posting to the chat in order for everyone to see and to be captured afterwards. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Devan

1 0

15 MINUTES REMINDER | Meeting Invitation | IDNs EPDP Team | Thursday, 30 March 2023 at 13:00 UTC
by Devan Reed March 30, 2023

March 30, 2023

Dear all, The IDNs EPDP Team meeting is scheduled on Thursday, 30 March 2023 at 13:00 UTC for 2 hours. Please click link to join the webinar: https://icann.zoom.us/j/94276275950?pwd=dG5hanFzMlpsYmh0NnFjTEQwOUV1dz09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/94276275950?pwd=dG5hanFz…> Passcode: !!0tV0Wh&K For Audio only: One tap mobile : US: +13017158592,,94276275950#,,,,*5259149775# or +13126266799,,94276275950#,,,,*5259149775# Webinar ID: 942 7627 5950 Passcode: 5259149775 International numbers available: https://icann.zoom.us/u/adP1jJ0gRH <https://urldefense.com/v3/__https:/icann.zoom.us/u/adP1jJ0gRH__;!!PtGJab4!v…> If this is your first time with Zoom, please take a look here: Welcome to Zoom <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> Members, participants, and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior <https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/qgP5DQ * Check your time zone: https://tinyurl.com/yckbznhw <https://urldefense.com/v3/__https:/tinyurl.com/yckbznhw__;!!PtGJab4!60Gp8xO…> ONLY for Members and Participants * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Please select Everyone, when posting to the chat in order for everyone to see and to be captured afterwards. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Devan

1 0

REMINDER | Meeting Invitation | IDNs EPDP Team | Thursday, 30 March 2023 at 13:00 UTC
by Devan Reed March 29, 2023

March 29, 2023

Dear all, The IDNs EPDP Team meeting is scheduled on Thursday, 30 March 2023 at 13:00 UTC for 2 hours. Please click link to join the webinar: https://icann.zoom.us/j/94276275950?pwd=dG5hanFzMlpsYmh0NnFjTEQwOUV1dz09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/94276275950?pwd=dG5hanFz…> Passcode: !!0tV0Wh&K For Audio only: One tap mobile : US: +13017158592,,94276275950#,,,,*5259149775# or +13126266799,,94276275950#,,,,*5259149775# Webinar ID: 942 7627 5950 Passcode: 5259149775 International numbers available: https://icann.zoom.us/u/adP1jJ0gRH <https://urldefense.com/v3/__https:/icann.zoom.us/u/adP1jJ0gRH__;!!PtGJab4!v…> If this is your first time with Zoom, please take a look here: Welcome to Zoom <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> Members, participants, and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior <https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/qgP5DQ * Check your time zone: https://tinyurl.com/yckbznhw [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/yckbznhw__;!!PtGJab4!60Gp8xO…> ONLY for Members and Participants * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Please select Everyone, when posting to the chat in order for everyone to see and to be captured afterwards. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Devan

1 0

Notes and action items - IDNs EPDP Meeting #74 - 27 March 2023
by Emily Barabas March 29, 2023

March 29, 2023

Dear all, Please find below the notes and action items from today’s meeting on Monday, 27 March 2023 at 13:00 UTC. Kind regards, Ariel, Steve, and Emily Notes and Action Items - IDNs EPDP Call – 27 March 2023 Action Items Action Item 1: EPDP Team members to review draft text for the Initial Report explaining areas of divergence between EPDP and ccPDP4 draft recommendations. Action Item 2: Leadership team will try to work through the Phase 2a questions, estimate the amount of time needed to work through those questions, and any data collection needs and will circle back with the EPDP Team. Notes Welcome and Chair Updates * Today’s meeting is primarily administrative in nature. There is limited attendance, but there will not be substantive deliberations on charter questions on this call. Items of divergence with ccNSO * The Board is in the process of identifying the difference between the EPDP’s recommendations and ccPDP4’s recommendations. The Board would like to have a section in the Initial Report explaining for each identified area of divergence: the nature of the divergence from the perspective of the EPDP, the rationale behind the EPDP recommendation, and the expected impact of the area of divergence. * Verbal summary provided by staff of the draft text for the Initial Report for this section related to divergence. The EPDP team will have an opportunity to review the full text: https://docs.google.com/document/d/1bGc-Us2AYWPh8ZSnIumJtQnb-W7xUBwKDlvx4RZ… Action Item 1: EPDP Team members to review draft text for the Initial Report explaining areas of divergence between EPDP and ccPDP4 draft recommendations. * Focus is 7 topics that were identified by staff supporting the Board’s consideration of this issue: * Main items: 1. Variant label disposition values; 2. Limiting number of delegated variant labels; 3. Impact on delegated TLDs due to RZ-LGR update; 4. String Similarity Review * Additional items that this group may or may not need to analyze: * 5. Applying for strings in scripts not supported by RZ-LGR: SubPro addressed this topic, so the EPDP team did not. * 6. Single character TLDs: The EPDP Team recommended that these may be possible for Han script, but no application can be accepted until relevant guidelines implemented. ccNSO did not address this topic. This may be for the ccNSO to explain. * 7. Delegation of successfully evaluated TLD and its variants TLDs: EPDP Team recommended maintaining the timeframe for delegation that existing in the 2012 round. It is unclear how the variant ccTLD will be delegated if the primary TLD has not been delegated yet. This may be for the ccNSO to explain. Discussion points: * It is expected that the 7 points are the ones that the Board will relay to the EPDP and ccPDP teams, although this has not yet come through officially. * The expectation is that Edmon will provide communication from the Board. * Additional potential point of divergence/difference: second level considerations. It might be good to highlight that this EPDP will produce recommendations relevant to second level labels. The ccPDP discussed some items about the second level. Because of the remit of the ccNSO, these will not result in recommendations, but there may be considerations captured in the Final Report. * This might be a similar type of issue as #6 above. * This Initial Report will focus on the top level. We could potentially flag this item, noting that there won’t be any recommendations on the second level yet from the EPDP. * Reminder: It’s not necessarily a problem that recommendations differ between the two groups. gTLDs and ccTLDs operate under different frameworks and the scope of policy development is different in the two communities. We just need to be able to explain the differences. It is helpful if the EPDP and ccPDP have similar explanations of the inconsistencies in their respective reports. * Confirmation from the Board Liaison that the communication from the Board is likely to be very similar to what is being reviewed today. The Board would like an explanation of inconsistencies, but it is not necessarily a problem that there are differences. * Reminder: In the draft text, the “Rationale and Impact” for each item attempts to address why the difference is not a problem. Review potential 2a questions (as suggested by the EPDP leadership team) * Reminder, the Board passed a resolution during ICANN76 (https://www.icann.org/en/board-activities-and-meetings/materials/approved-r…) – “Resolved (2023.03.16.08), the Board directs the ICANN Interim President and CEO, or her designee(s), to deliver the Implementation Plan to the Board no later than 1 August 2023. The timely delivery of the Implementation Plan requires the satisfactory completion of the following four deliverables by the last day of the ICANN77 Public Meeting (15 June 2023): . . . A project plan from the GNSO Internationalized Domain Names (IDNs) Expedited Policy Development Process (EPDP) Working Group (WG) identifying all charter questions that will impact the next Applicant Guidebook, along with considerations to ensure a consistent solution on IDN Variant TLDs with the ccPDP4 on IDN ccTLDs (in accordance with prior Board Resolution 2019.03.14.09<https://www.icann.org/en/board-activities-and-meetings/materials/approved-r…>), and a timeline by when the IDNs EPDP WG will deliver relevant recommendations to the GNSO Council.” * The Board would like to understand the timeline for the EPDP Team’s work on “phase 2a” questions. These are phase 2 questions that have a dependency with finalizing the AGB. The leadership team has done some initial analysis and wants to work through that with the group. * As the group goes through the potential phase 2a charter questions, EPDP Team members should keep in mind the timeframe for working through deliberations on this group of CQs. * Consider whether it might be possible to have a Final Report that combines recommendations from Phase 1 and Phase 2a. * List of potential phase 2a questions: https://docs.google.com/spreadsheets/d/1YfnJPAO7Ey6MRpVCR7N8uMPHmGWdnHcxioO… * The Board is considering a similar analysis that is included in the spreadsheet linked above. * Question: Is it correct that Column B is indicating that if any of the following is implicated, there is a dependency: AGB, application question, contract for future ROs, operational impact? * Response: The Board resolution specifically addresses impact on the AGB, so this group may want to refine its analysis to specify if it is a dependency with the AGB or other elements of the New gTLD Program, noting that it’s not completely clear what will be contained in the AGB itself. Best guess is that the scope of the AGB will be similar to 2012. * Some items will be referenced in the AGB but will live outside the AGB. * We may need to think about these charter questions from the very narrow perspective of impact on the AGB as opposed to impacting contracts etc. We may need further guidance from Council or org about what needs to be in scope for that analysis. Discussion points * C1: Clarification – because this CQ focuses on extending SubPro requirement to existing second level labels, it shouldn’t touch on the AGB or contracts for new applicants. It appears that C1 will not be necessary for the AGB. * Comments regarding the substance of the CQ: * It could be the case that there are second level variants that are currently not activated but blocked. There are also scenarios where two second level strings are already registered as separate strings, but they could be identified as variants. * Concerns raised about the legal implications of panelists who do not have legal obligations and policies whose decisions result in termination of contracts. * Reminder that we are not yet discussing substance. * C2: This item focuses on already activated IDN variant labels at the second-level, and therefore does not have an impact on the next round. * C3: This question refers to both existing and future gTLDs, so could have dependencies for the next round, but the question regarding mechanism could be an implementation issue that could be handled by the SubPro IRT. * Comment on substance of the CQ: ROID should be unique identifiers, so it should not be the same for two registrations of the same entity. ROID is not a good idea. * Comment that this is a charter question that informs the content of the AGB (potentially technical questions in the application). * Note that, for now, this should be marked as “yes.” * The mechanism to ensure the same entity principle at the second level may be referred to in the AGB or other implementation materials, but the level of detail that needs to be in the AGB is not yet clear to this group. * Will the AGB be developed by the IRT or separately? * IRT itself is comprised of community members. GDS (ICANN org staff) will draft the AGB. The IRT will validate the implementation (the AGB) is true to intent. * C3a: Focuses on whether additional mechanisms need to be developed to ensure that the same entity principle is observed at the second level. Conditional on the decision of the group to use ROID as the mechanism. This was initially marked as “no” because it goes into the details of implementation. * C3 will touch on managing the same entity principle. We need to be clear as to how we triage these questions. One might argue that any additional mechanism will need to be contractual agreement, which would make it a “yes,” but you might not need it per se for the AGB, in which case it may be a “no.” * C3a changed to a “maybe” because of the connection to C3. * C4: Initial analysis is that this is a “yes” because it impacts future registries when they apply. Harmonization will impact the IDN tables submitted by the applicants. * C4a: Focuses on second level domains under a single TLD that doesn’t have a variant at the top level and whether behavior needs to be the same. This was marked as “no” because it not about the top-level. SubPro already addressed this by saying that they don’t need to behave the same. * C5: Regarding mechanism for harmonizing IDN tables – initially categorized as a “no” because this is an implementation question. This might not even be an implementation issue but something that registries need to figure out themselves if harmonization is required. * C6: Focuses on IDN table format. IDN tables must be included with applications. Therefore, initial assessment is that this is a “yes.” No objection to keeping C6 as a “yes.” * D4: Addresses whether second level domain names should behave as a unit at different points in their lifecycle. This group needs to discuss the impact on the transfer phase. This question is also asking whether other statuses need to synchronized beyond transfers. This was initially sorted as “yes.” If there are labels that are registered by the same registrant, they could be renewed together or separately. If this group makes a recommendation about this, it would need to be in the AGB and/or other elements of the application process, so that applicants know they need to adhere to the requirements. No objections to keep as “yes.” * D5: Focuses on fees paid by contracted parties per registration. Links back to discussion on fees in phase 1 (under D1b). * If applicant needs to include financial model in the application, it is important for the applicant to have information about fees in advance. * 2012 AGB includes the draft RA at the time, draft RA may also be in the next version of the AGB. * D5 may need to be part of the AGB – change this item to “yes” * D6: Initially marked as “yes” -- due to a potential application question about registration life cycle and potential impact on AGB and contract. Note that this charter question anticipates coordination with RPMs work that has not yet been initiated. * D6a: Initially marked as “yes” as it is related to transfer, and references RPMs, so may have an impact on the AGB. * D7: Marked as “no” -- If one domain is suspended and the other exists, it won’t impact the same entity requirement. It won’t break the set. * If one variant is suspended, will it impact suspension of other variants in the set? This was initially marked as “no”. Changed to “maybe” because new language may be needed in the AGB if it is determined that the suspension of one variant impacts suspension of another. * Comment: If there is a consensus policy on IDNs, it shouldn’t be included in the RA. * D7a: same entity requirement for suspensions ordered by URS or other dispute resolution mechanisms. This was changed from “no” to “maybe” consistent with D7. * D8: Reminder of parking lot question from Edmon linked to this CQ: "What should be included in (or the behaviour of) WHOIS/RDAP for IDN variants, both the IANA whois and the Registry WHOIS?" D8 is preliminarily a “maybe.” * F1: Focuses on TMCH. Preliminarily categorized as “yes” because it is related to SAC060, which needs to be addressed before the next round and has a potential impact on the AGB. The group left it as a “yes.” * F2: Same as above. * G1 and G1a: Marked as “no” because it is not AGB-related. Action Item 2: Leadership team will try to work through the Phase 2a questions, estimate the amount of time needed to work through those questions, and any data collection needs and will circle back with the EPDP Team.

2 1

Proposed Agenda - IDN EPDP Meeting #75 - Thursday 30 March 2023 at 13:00 UTC
by Emily Barabas March 29, 2023

March 29, 2023

Dear all, Please find below the proposed agenda for our meeting on Thursday 30 March 2023 at 13:00 UTC (2 hour call). Kind regards, Ariel, Steve, and Emily IDN EPDP Meeting #75 Proposed Agenda 1. Roll Call and SOI Updates (2 mins) 2. Welcome and Chair Updates (5 mins) 3. Public comment input form (10 mins) 4. Third reading of draft text (60 mins) 5. Review of Glossary and other selected sections of the draft initial report (40 mins) 6. AOB (3 mins) For item 4: Topic A: https://docs.google.com/document/d/1Bt0LT45UaLynFNverh1nJhyvq6q6NxgSFAOnOp2… A3 & A5: pp.3-5, 7-9 Topic B: https://docs.google.com/document/d/15YGISgNQYL_VfcVVZ6E97qbo42GPziP6x089bR3… B2: p.2 Topic D: https://docs.google.com/document/d/1C6xKX87w2LtN4Is0mehuRgc1GqjKmbbhT14KbvU… D1b, D8: pp.4-9, 16-17 Topic E3: https://docs.google.com/document/d/115eSNnxBsCbUszEGU7i4xbzLwu1u8_UdaGEJD9C… pp.5-9 (table 3 created based on Dennis’s input) For item 5: Section 2 Working Group Approach: https://docs.google.com/document/d/1TkYLu5Dztk3-L6i5C7QvG4zWI3kCnsrV7bEWrDa… Section 3 Glossary (cleaned up): https://docs.google.com/document/d/1pVFaL0f9vJkPEuJ6UhA4Ix5X2fCY12nsP3GRcuB… Section 5 Divergence with ccPDP4 Draft Recommendations: https://docs.google.com/document/d/1bGc-Us2AYWPh8ZSnIumJtQnb-W7xUBwKDlvx4RZ… Annex C Background: https://docs.google.com/document/d/1PEiMbC21Yv1LgimcL-m7NBmTQCLRUvSeG7yrizo… Emily Barabas Policy Development Support Senior Manager Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org<http://www.icann.org/>

1 0