January 2022 - Gnso-epdp-idn-team

Reminder: Proposed Change to Sequencing of Charter Questions
by Ariel Liang Jan. 31, 2022

Jan. 31, 2022

Dear all, This is a friendly reminder to review the proposed change to sequencing of charter questions (details below). If you have any comment, please share on list by Wednesday, 2 February. Thank you, Ariel From: Ariel Liang <ariel.liang(a)icann.org> Date: Tuesday, January 25, 2022 at 8:31 PM To: "gnso-epdp-idn-team(a)icann.org" <gnso-epdp-idn-team(a)icann.org> Subject: Proposed Change to Sequencing of Charter Questions [Please see below the message sent on behalf of Donna] Dear EPDP Team, As you may have noticed from the proposed agenda for this week’s meeting, we will discuss possible changes to the sequencing of our charter questions. The goal is to ensure a logical order is being followed and provide efficiencies to our deliberations. In consultation with Dennis Tan Tanaka, who was the IDNs EPDP Charter Drafting Team Chair, the EPDP leadership team is proposing the following changes: https://docs.google.com/spreadsheets/d/1YfnJPAO7Ey6MRpVCR7N8uMPHmGWdnHcxioO… - gid=0<https://docs.google.com/spreadsheets/d/1YfnJPAO7Ey6MRpVCR7N8uMPHmGWdnHcxioO…> In summary: * Complete the first pass of Topic A questions related to RZ-LGR * Address questions with implications to IDNs at the top-level (application process, legal/operational framework): B1-B3, D1-D1b, B4-B4a, B5, E1-E7, D2-D3 * Followed by questions with implications to the second-level and beyond (lifecycle management, RPMs, etc.): C1-C6, D4-D8, E6, F1-F2 * And lastly, the IDN Implication Guidelines related questions: G1, G1a * The proposed sequencing takes into account the “explicit” dependencies, which are called out in the Charter, as well as the “implicit” dependencies identified by Dennis and the Leadership Team. The implicit dependencies column will be updated as the EPDP Team discovers additional ones along the way. We recognize that the revised sequencing won’t be perfect, particularly as we are learning the topics and working through the charter questions in an iterative manner. To that end, we will maintain the flexibility to adjust the sequencing if necessary in the future. I don’t want this exercise to become a distraction and take time away from out actual work. If agreement for the proposed sequencing becomes difficult and time consuming, we will default back to the original workplan and tackle the charter questions topic by topic. Thank you for your review in advance. We look forward to the discussion this Thursday. Best Regards, Donna

1 0

Notes and action items - IDNs EPDP Meeting #21 - 27 January 2022
by Emily Barabas Jan. 27, 2022

Jan. 27, 2022

Dear all, Please find below the notes from today’s meeting on Thursday, 27 January 2022 at 13:30 UTC. Kind regards, Ariel, Steve, and Emily Action Items: Action Item #1: Staff to send follow up message to the mailing list reminding members to provide any comments. Members to provide any input by 2 February 2022. Action Item #2: Leadership team to ensure that the recommendations in relation to A6 provide safeguards for the existing contracted parties. Be more explicit by what we mean by grandfathering. In recommendation 1.4, take out “to the extent feasible”, include that the RZ-LGR MUST be updated. Add implementation guidance explaining specific expectations regarding the limited circumstances for exceptions to backwards compatibility. Action Item #3: Leadership team to add a recommendation reaffirming the principle of backward compatibility. Action Item #4: Leadership team to update recommendation 1.6 to be more specific in the definition of grandfathering and the circumstances throughout the TLD lifecycle where this applies. Action Item #5: Leadership team to draft implementation guidance in relation to recommendation 1.5 focused on who should provide that information as part of the public comment. Notes – IDNs EPDP Call – 27 January 2022 Sequence of Charter Questions * Staff sent a message to the list earlier this week regarding sequence of charter questions. Comments are welcome regarding proposed reordering of the questions. * Leadership proposal is largely consistent with proposal from Dennis regarding order. * Some support expressed for reordering as proposed. Absent any comments in the coming week, this order will be adopted. There will be an opportunity to make additional changes to the ordering as we go through the questions where it makes sense to do so. Action Item #1: Staff to send follow up message to the mailing list reminding members to provide any comments. Members to provide any input by 2 February 2022. Charter question A6 – continued deliberations on open items (see open items under A6 in the Draft Outcome document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1Bt0LT45UaLyn…>) * Slide 3: Draft recommendations for this charter question. * Suggestion: We should have a recommendation that anyone responsible for updating the RZ-LGR must ensure backward compatibility and if they can’t, they should specify why. * Response: It is possible to make this explicit in our recommendations, but as discussed, this is already part of the RZ-LGR process. There might be rare exceptions. Backwards compatibility cannot be 100% guaranteed. * Question: If the LGR is unable to retain backward compatibility, some TLDs will be “illegal.” What are the mechanics of this? There may be legal issues. This TLD is not going to pass any assessment of the backend. * Response: In recommendation 1.6, the gTLD and delegated and allocated variants will be grandfathered. Therefore, there will no change to the Registry Agreement. Recommendation 1.5 calls out the exception, requires explaining why it is necessary, and provides balance of information through the public comment process. Perhaps we need to be more explicit. * Comment: If a registry is grandfathered and it needs to make a change, it may need to pass technical tests. This is the point where issues will arise. We need to add that these mechanics are not a reason for termination of a TLD. * Suggestion: Would the concern be addressed to add text to 1.6 that the TLD will continue to operate as it has been delegated? * Response: This will not provide assurance in cases where there needs to be a change to the TLD, because the change will have to go through processes for which it will fail. * Clarification regarding recommendation 1.4: Why do we use the text “to the extent feasible”? This seems to dilute the point that the circumstances are limited. * Response: This text was added because there is uncertainty about whether our recommendations could have an effect on a separate procedure. The RZ-LGR process is not under the GNSO. However, this text could be removed if the group supports it. * Some support expressed for removing “to the extent feasible.” * Question: For recommendation 1.5, is the expectation/intent that the RO, customers, and end users provide input to the public comment period or is it that the GP affirmatively seeks input in their rationale and this is included in their output? * Response: This speaks to one of our outstanding questions. This could be addressed as implementation guidance or rationale. We will get to this issue in the discussion. * Comment: If the RZ-LGR can’t maintain backwards compatibility, then maybe the registries don’t need to follow the LGR. We don’t need to be so passive. We can say that the LGR has a duty of backwards compatibility and registries have a duty to comply with the RZ-LGR. * Comment: We may need to identify the impact on contracts as something to consider further. * Comment: Agreement with the sentiment regarding obligations of different parties. At the same time, we need to understand that there are things outside of the control of GPs and IPs, such as a change in IDNA and Unicode. They are rare, but the policy needs to make clear that there are those external risks. The RZ-LGR update process already ensures backwards compatibility to the greatest extent possible. * ICANN org comment: Important to emphasize that this is a very rare, if ever, phenomenon. There are stability mechanisms built into three layers – Unicode has its own stability clauses that makes those cases extremely rare; stability clauses built into IDNA 2008 standard; in the RZ-LGR itself there is a stability clause. Even if the GP tries to change something, the IP would need to review and approve those changes. The IP is very conservative about changes that would impact an existing TLD. It’s an extremely high bar. * Comment: We need a safeguard, for example, absent a change to Unicode and IDNA, it should be prohibited to make a change that is contrary to backwards compatibility. * Response: There was a lot of thought and consideration that has gone into the development of the RZ-LGR. Decisions will be taken with due care. At the same time, we can make an effort to put in additional safeguards. * Comment: It doesn’t matter how rare the circumstance might be, we can make recommendations about what we expect the RZ-LGR to do. If they don’t meet their end of the bargain, we don’t have to follow the RZ-LGR. Action Item #2: Leadership team to ensure that the recommendations in relation to A6 provide safeguards for the existing contracted parties. Be more explicit by what we mean by grandfathering. In recommendation 1.4, take out “to the extent feasible”, include that the RZ-LGR MUST be updated. Add implementation guidance explaining specific expectations regarding the limited circumstances for exceptions to backwards compatibility. * Slide 4: Outstanding question #1 * Question: From the conversation it sounds like we do need to add something about the impact on existing RAs. Are there other existing policies and procedures to address? * Response: We should not leave this to an IRT. We should provide explicit guidance to the IRT. We should have a recommendation that the panel makes best effort for backwards compatibility. They are not beholden to this. There should be a backout clause for any cases where they don’t meet that expectation. * Comment: If there are principles in the contract, for example any exceptions to the process, this needs to be in the recommendations. Action Item #3: Leadership team to add a recommendation reaffirming the principle of backward compatibility. * The WG might need a small team to look at the contractual issues. * Comment: Outright rejecting the RZ-LGR where there is not backward compatibility might be too loose, we should put boundaries around that. * Concern: Grandfathering could mean that anything done is allowed, but anything new must follow the new process. * Donna Summary: With 1.5, we’ve tried to strike a balance, by bringing in the impact of an exception to backwards compatibility using the public comment period. It might be necessary to better explain what we mean by “grandfathering” – specifically, leadership sees it as no change to the operation of the gTLD. * Comment: this needs to be made explicit, so that the interpretation is shared by all parties. * Comment: The RZ-LGR is used in one moment in time in the TLD lifecycle, at the evaluation of the application. There are additional use cases in which the grandfathering would apply within the TLD lifecycle. We should focus on those use cases. * Comment: Maybe we can define grandfathering: In case RZ-LGR is updated, all existing TLDs will be subject to the version that applied when they were allocated. Action Item #4: Leadership team to update recommendation 1.6 to be more specific in the definition of grandfathering and the circumstances throughout the TLD lifecycle where this applies. * Slide 4 – Outstanding Question 3 * Question: Why are we calling out the GP, as opposed to the IP, in this clarification question? * Response: It is the GP that conducts the public comment. The GP proposes the update that may cause the incompatibility. They are best positioned to consider mitigatory action. * Clarification: The IP only has a review role, they provide feedback and demarcation, but the solution for the script is provided by the GP. The GP provides the solution, releases it for public comment. Based on public comment GP submits proposal to IP, IP evaluates, reviews and makes final determination about whether the proposal meets criteria (also taking into account public comments). * Clarification: 1.5 seeks to ensure the GP takes into account the impact of its actions. Who is best placed to do the analysis? * Response: The RO should have an opportunity to provide an assessment, Org should provide an assessment. If there is a disagreement, there should be a process to address any conflicts between the assessments. * Org comment: The scope of this particular study is beyond the scope of what the GP and IP are tasked to do, so they may not be well positioned to do the study. * Question: Is there anything in the process that allows the GP to consult with the RO that will be impacted? * Response: There is nothing requiring a consultation but it is also not forbidden. Action Item #5: Leadership team to draft implementation guidance in relation to recommendation 1.5 focused on who should provide that information as part of the public comment. * Slide 4 – Outstanding Question 4 * Comment: To the extent that ICANN can propose a solution, they should do so and the RO and comment on that. The contract already has mechanisms for disagreements. The answer is essentially the same as outstanding question 3. Charter questions A7 * Slide 6 – current status * Suggestion in response to the first question: For the policy recommendation, state that single character TLDs are allowed for scripts with ideographs/ideograms. The implementation is the specific languages listed on the slide. * For the second question, support expressed for outsourcing the question and providing a clear set of instructions. * Note: We will reaffirm SubPro rec in the text of the report. * Question regarding the second clarification question on the slide: if it not practical to outsource, we have discussed the possibility of a thorough review process. Are we suggesting that this review process takes place through something other than the DNS Stability Review? It does not seem that an additional review process is needed and could be done as part of the DNS Stability Review. * Support expressed for the idea that the evaluation process should be the same and maybe there is one more additional question to ask. * Summary: We’ve reaffirmed the SubPro policy that single character IDN TLDs are allowed and we need to talk about mechanisms for criteria. There does not appear to be support for a separate process as part of the application process. * Comment: SSAC has provided feedback that a single character without additional context may be more confusing. This is a string similarity problem. One possibility is that the new gTLD string similarity panel could take up an additional role with respect to evaluation of these applications.

1 0

Post Call | IDNs EPDP Team call | Thursday, 27 January 2022 at 13:30 UTC
by Devan Reed Jan. 27, 2022

Jan. 27, 2022

Dear all, All recordings for the IDNs EPDP Team call held on Thursday, 27 January 2022 can be found on the agenda wiki page <https://community.icann.org/x/nYH3Cg> (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) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript 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

Meeting Invitation | IDNs EPDP Team | Thursday, 03 February 2022 at 13:30 UTC
by Devan Reed Jan. 27, 2022

Jan. 27, 2022

Dear all, The IDNs EPDP Team meeting is scheduled on Thursday, 03 February 2022 at 13:30 UTC for 90 minutes. 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/n4H3Cg * Check your time zone: https://tinyurl.com/59kez55p 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, 27 January 2022 at 13:30 UTC
by Devan Reed Jan. 27, 2022

Jan. 27, 2022

Dear all, The IDNs EPDP Team meeting is scheduled on Thursday, 27 January 2022 at 13:30 UTC for 90 minutes. 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/nYH3Cg * Check your time zone: https://tinyurl.com/m8c7umcx [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/m8c7umcx__;!!PtGJab4!sM6ZXLg…> 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

Proposed Agenda - IDN EPDP Meeting #21 - 27 January 2022 at 13:30 UTC for 90 minutes
by Emily Barabas Jan. 27, 2022

Jan. 27, 2022

Dear all, Please find below the proposed agenda for our meeting on 27 January 2022 at 13:30 UTC. Kind regards, Ariel, Steve, and Emily IDN EPDP Meeting #21 Proposed Agenda 1. Roll Call & SOI Updates 2. Welcome & Chair Updates 3. Sequence of Charter Questions 4. Continued Deliberations on Topic A: Consistent Definition and Technical Utilization of RZ-LGR (Topic A working document: live version [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1I9dSd7alSvz9…> in Google Docs, archived versions in MS Word on wiki<https://community.icann.org/display/epdpidn/Working+Documents>) * Charter question A6 – continued deliberations on open items (see open items under A6 in the Draft Outcome document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1Bt0LT45UaLyn…>) * Time permitting, return to charter questions A7, A9, and A10 5. AOB

2 1

**REMINDER** Meeting Invitation | IDNs EPDP Team | Thursday, 27 January 2022 at 13:30 UTC
by Julie Bisland Jan. 26, 2022

Jan. 26, 2022

Dear all, The IDNs EPDP Team meeting is scheduled on Thursday, 27 January 2022 at 13:30 UTC for 90 minutes. 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/nYH3Cg * Check your time zone: https://tinyurl.com/m8c7umcx [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/m8c7umcx__;!!PtGJab4!sM6ZXLg…> 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

Proposed Change to Sequencing of Charter Questions
by Ariel Liang Jan. 26, 2022

Jan. 26, 2022

[Please see below the message sent on behalf of Donna] Dear EPDP Team, As you may have noticed from the proposed agenda for this week’s meeting, we will discuss possible changes to the sequencing of our charter questions. The goal is to ensure a logical order is being followed and provide efficiencies to our deliberations. In consultation with Dennis Tan Tanaka, who was the IDNs EPDP Charter Drafting Team Chair, the EPDP leadership team is proposing the following changes: https://docs.google.com/spreadsheets/d/1YfnJPAO7Ey6MRpVCR7N8uMPHmGWdnHcxioO… - gid=0<https://docs.google.com/spreadsheets/d/1YfnJPAO7Ey6MRpVCR7N8uMPHmGWdnHcxioO…> In summary: * Complete the first pass of Topic A questions related to RZ-LGR * Address questions with implications to IDNs at the top-level (application process, legal/operational framework): B1-B3, D1-D1b, B4-B4a, B5, E1-E7, D2-D3 * Followed by questions with implications to the second-level and beyond (lifecycle management, RPMs, etc.): C1-C6, D4-D8, E6, F1-F2 * And lastly, the IDN Implication Guidelines related questions: G1, G1a * The proposed sequencing takes into account the “explicit” dependencies, which are called out in the Charter, as well as the “implicit” dependencies identified by Dennis and the Leadership Team. The implicit dependencies column will be updated as the EPDP Team discovers additional ones along the way. We recognize that the revised sequencing won’t be perfect, particularly as we are learning the topics and working through the charter questions in an iterative manner. To that end, we will maintain the flexibility to adjust the sequencing if necessary in the future. I don’t want this exercise to become a distraction and take time away from out actual work. If agreement for the proposed sequencing becomes difficult and time consuming, we will default back to the original workplan and tackle the charter questions topic by topic. Thank you for your review in advance. We look forward to the discussion this Thursday. Best Regards, Donna

1 0

15 MINUTES **REMINDER** Meeting Invitation | IDNs EPDP Team | Thursday, 20 January 2022 at 13:30 UTC
by Devan Reed Jan. 20, 2022

Jan. 20, 2022

Dear all, The IDNs EPDP Team meeting is scheduled on Thursday, 20 January 2022 at 13:30 UTC for 90 minutes. 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/m4H3Cg * Check your time zone: https://tinyurl.com/4mr2byj5 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/4mr2byj5__;!!PtGJab4!pYQ0pkq…> 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

3 2

Notes and action items - IDNs EPDP Meeting #20 - 20 January 2022
by Emily Barabas Jan. 20, 2022

Jan. 20, 2022

Dear all, Please find below the notes from today’s meeting on Thursday, 20 January 2022 at 13:30 UTC. Kind regards, Ariel, Steve, and Emily Action Items: Action Item #1: Leadership team will update the recommendations based on today’s discussion and share with the EPDP Team for review. Notes – IDNs EPDP Call – 20 January 2022 Welcome & Chair Updates * The leadership team continues to look into reordering charter questions and will provide feedback in a week or two. They will only suggest changes to the order if they think there is substantive benefit. The EPDP Team will work through the rest of Topic A before any changes are made to the order. * Update on GNSO Council Approach to IDN Implementation Guidelines v.4.0: The Council has agreed with the Board’s suggestion to continue to defer items that overlap with the EPDP. The Council drafted a letter identifying items in the Guidelines that overlap with the EDPD charter. This is a discussion item on today’s Council call and the letter is expected to be sent by the end of the week. As liaisons, Dennis and Anil will relay relevant updates to the ccNSO and ccPDP4. Charter question A5 * Last week, the EPDP Team discussed with SSAC members whether there should be a ceiling mechanism for variants. This week, the EPDP Team will reflect on the SSAC’s input. * Follow up on data collection exercise for this charter question: Org checked all scripts in the RZ-LGR and those that will be incorporated in next version to see if there are mechanisms in place to reduce the number of allocatable variants. * Presentation of results: slide 4 lists scripts with no variant labels, scripts with no allocatable variant labels, and scripts that have allocatable variant labels. * Scripts with allocatable variant labels: Arabic, Bengali, Chinese, Greek, Latin, Myanmar, Tamil. * Question: Does this list only cover gTLDs and ccTLDs? * Answer: The same would apply to both gTLDs and ccTLDs. It includes all scripts in the RZ-LGR. * Question: What do we have these three categories listed on slide 4? Is the categorization a technical decision or a policy issue? * Two distinctions: First is the question of variants versus no allocatable variants (column 1 versus column 2). This depends on the judgment of the script community and the way they define variants for the script. For those scripts that have variants, there is the question of whether they are allocatable (column 2 versus column 3). The question about whether they are allocatable is primarily an issue of usability. Once you define something as a variant and determine that it will be treated as such, the security aspect is contained, but the usability aspect is not. Allocation may be appropriate for usability reasons. * Clarification: The security challenges are the same for column 2 and 3, arising from the fact that there could be code points that are the same within a script or between scripts. By declaring such code points as variant code points, the security issues are addressed in both column 2 and 3. We may want to have them as allocatable because of usability requirements. * Question: Is there a reason to think that security issues might change as we add more scripts and that security panels will need to reassess allocatable variants? * Clarification: When saying that the security issues are addressed by considering the labels variants, this is referring to security issues as defined in a limited context – those with respect to “same” code points. It does not address all possible security issues, for example those related to string similarity. * Comment: Evaluation at the root level is to address similar looking TLDs. Providing an example of the difference between allocatable and non-allocatable, in Chinese U+39DF = U+64D3 are considered equivalent. If you apply for the TLD to the left, the one to the right can’t be applied for independently. The question is whether the two can be allocated to the same entity. The question is whether the label stands on its own and is unique. If it is not, an application for the TLD should fail. * Org data collection: Looking at scripts in column 3 on slide 4, org went through existing list of TLDs which are delegated and ran them through the RZ-LGR to see how many variants are created. See slides 5-6. Most scripts have been able to put a reasonable ceiling on the number of variants. There are at least two scripts – Arabic and Chinese that might create an unanticipated number of variant labels. * Question: Is the analysis in slide 4 an official analysis? * Answer: ICANN org staff collated information from the RZ-LGR proposals for use by this group. * Question: For the Latin script proposal, does the analysis take into account public comments that have been received. * Response: Yes, the public comments have been taken into account and they don’t impact definitions of allocatable variants. * Comment: The SSAC members seemed to agree that we shouldn’t come up with an arbitrary limit/ceiling value but focus on evaluation criteria in order to understand that the registry can manage any issues that arise with variants. * Question: Do the Registries and Registrars have insight into the challenges that arise with the bundling exercise? * Comment: When you apply for the TLD, you shouldn’t automatically be granted variants. You should be protected against other applicants obtaining variants. If ICANN wants to offer variants, from a Registry perspective and a DNS perspective, that’s a separate zone and there is maintenance of two zone files involved. It’s two separate TLDs that the Registry needs to facilitate and operate. * Comment: In general, the concept of IDN variants is not “look alike.” In Chinese, up to 5% of users will type the variant. It’s not just an issue of protection, it’s also an issue of usability, at least in the Chinese case. * Comment: Agree that we shouldn’t automatically give applicants variants, but the question is whether there should be a limit. * Org comment: When we are generating allocatable variants through the RZ-LGR process, even though panels work to manage the number of allocatable variants, the process still over-generates as a byproduct of making some of the solutions work. When people use variants, they do it from a language perspective. Since the RZ-LGR is script based, variants are generated with code points across languages in the script. Therefore, not all allocatable variants are equally usable. * Questions: Should further guidelines be developed and if so, should the working group provide recommendations and/or implementation guidance for those guidelines? * Summary: This is a limited issue impacting a limited number of scripts. We are not recommending a ceiling value. There is some support for idea that this is something for the market to provide for. We may come back to put some ideas in place for the guidelines with input from the Registries and Registrars. Charter question A6 * Org question: The are a set of variants labels that are blocked. There will be a smaller set, allocatable to the same applicant. There will be an even smaller set that will be delegated variant labels. If a variant label or string is delegated, it has a high stability bar. It should remain delegated unless there is an extreme circumstance. Allocatable variants are not yet in the root, so changes there may be less critical. Since for blocked strings are not able to be used, changes there are even less critical. For recommendations 1.4 and 1.5, we talk about variants – do we want to differentiate between these three groups? * Question: What are the implications of the different buckets referenced above as they apply to recommendations 1.4 and 1.5? * Clarification: If a variant TLD was delegated and in the root and there is a change in the RZ-LGR saying that that variant should be blocked, or that it is no longer a variant, it should be grandfathered. But if the variant is blocked and then it becomes allocatable, that doesn’t create as significant and issue compared to changing something that is in the root zone and delegated. The categories speak to how much of a stability impact that change can have on the root zone. * Comment: Suggest restricting these recommendations to delegated and allocated variants and not address blocked variants. There is no harm done if the blocked variant is taken away due to a change. * Support expressed for limiting the recommendations to delegated and allocated variants. * Suggestion to use “variant labels” instead of “variants.” * Question from org regarding recommendation 1.6: RZ-LGR has a built-in stability clause. Would you still want to go back and update RZ-LGR procedures? Additional comment: It may not be possible to anticipate all applicable circumstances that would result in an update to the RZ-LGR. * Comment: We did think some elaboration of the circumstances would be helpful for predictability. * Question regarding 1.5: what are we trying to say by “extremely strong”? Are we trying to say that there are circumstances where the presumption could be rebutted? * Question: After the public comment process, will it be the panel that makes the decision about grandfathering? * Clarification: Determining whether a specific label should be delegated in the root zone is outside the purview of the Generation Panels, as their responsibility is currently defined. * Comment: This group can set a policy that if there is a change, an existing TLD is grandfathered. The question is if there is a presumption, what if anything can result in an exception. * Comment: The Generation Panel does not have the power to change Registry contracts as currently set up. Contracted parties have little reason to agree to change this. * Suggestion: Grandfathering should be absolute in recommendation 1.5. * Suggestion: in recommendation 1.5: "except as set forth in 1.6, all existing gtLDs…….will be grandfathered." * Question: Can we seek public opinion before granting grandfather status? * Response: This may be covered in recommendation 1.4. * Comment: This will be implemented in contracts. We shouldn’t give a panel power over contracts they are not a party to. It’s ok for the panel to make a recommendation, subject to a process between ICANN and the Registry. But the panel is not a party to the contract. * Comment: Further discussion may be needed about what that process would be following the recommendation from the panel. * Summary: Recommendation 1.5 to be updated to say that the TLD will be grandfathered, except as set forth in 1.6. Additional edits may be appropriate for 1.6.

1 0