September 2021 - Gnso-epdp-idn-team

RZ-LGR and DNS stability review
by Tan Tanaka, Dennis 06 Oct '21

06 Oct '21

Hello —during today’s meeting some of you referred to the DNS stability review process as the function to determine whether an applied-for string if deemed fit for the root zone. I also observed that we might want to focus on the very limited function of the RZ-LGR, and to deal with contention sets and other evaluation procedures later on. To that end, I looked at the old applicant guide book and searched for the DNS stability: string requirements (2.2.1.3.2). Basically, string requirements is broken down into three parts: Part I (technical requirements for all labels, Part II (requirements for IDNs), and Part III (policy requirements for gTLDs). The RZ-LGR, I believe, is meant to “replace” or “automate” Parts I and II of the string requirements review process (a copy of the text is down below for your reference). In addition to those functions, also helps with the calculation of variant labels, so that the applicants don’t have to come up with IDN variant rules of their own. The difference between the prior AGB and the RZ-LGR (if adopted), are 1. that the latter starts with a smaller universe of “valid” letters. Before RZ-LGR, virtually all protocol valid code points were available to be used in a TLD string (with exception of course of hyphen and digits). The RZ-LGR starts with a smaller repertoire than IDNA2008 (i.e. Maximal Starting Repertoire) which is further limited by each script generation panel. The result of each generation panel’s work is merged into the RZ-LGR. So, one applicant might challenge the RZ-LGR’s results because it did not accept one letter, or a combination or some script rule. This should be okay to challenge, but the process by which the applicant finds resolution would be through the established LGR procedure (i.e. make the case for inclusion of a new letter or rule) to maintain the stability of the RZ-LGR. 2. the RZ-LGR is designed to calculate the variant labels. The prior DNS stability review process did not do that; applicants were asked to provide these self-identified variant labels. I hope this helps the discussion. Best, Dennis Part I -- Technical Requirements for all Labels (Strings) – The technical requirements for top-level domain labels follow. 1. 1.1 The ASCII label (i.e., the label as transmitted on the wire) must be valid as specified in technical standards Domain Names: Implementation and Specification (RFC 1035), and Clarifications to the DNS Specification (RFC 2181) and any updates thereto. This includes the following: 1.1.1 The label must have no more than 63 characters. 1.1.2 Upper and lower case characters are treated as identical. 1. 1.2 The ASCII label must be a valid host name, as specified in the technical standards DOD Internet Host Table Specification (RFC 952), Requirements for Internet Hosts — Application and Support (RFC 1123), and Application Techniques for Checking and Transformation of Names (RFC 3696), Internationalized Domain Names in Applications (IDNA)(RFCs 5890-5894), and any updates thereto. This includes the following: 1.2.1 The ASCII label must consist entirely of letters (alphabetic characters a-z), or 1.2.2 The label must be a valid IDNA A-label (further restricted as described in Part II below). Part II -- Requirements for Internationalized Domain Names – These requirements apply only to prospective top-level domains that contain non-ASCII characters. Applicants for these internationalized top-level domain labels are expected to be familiar with the Internet Engineering Task Force (IETF) IDNA standards, Unicode standards, and the terminology associated with Internationalized Domain Names. 1. 2.1 The label must be an A-label as defined in IDNA, converted from (and convertible to) a U-label that is consistent with the definition in IDNA, and further restricted by the following, non-exhaustive, list of limitations: 2.1.1 Must be a valid A-label according to IDNA. 2.1.2 The derived property value of all codepoints used in the U-label, as defined by IDNA, must be PVALID or CONTEXT (accompanied 2.1.3 The general category of all codepoints, as defined by IDNA, must be one of (Ll, Lo, Lm, Mn, Mc). 2.1.4 The U-label must be fully compliant with Normalization Form C, as described in Unicode Standard Annex #15: Unicode Normalization Forms. See also examples in http://unicode.org/faq/normalization.html. 2.1.5 The U-label must consist entirely of characters with the same directional property, or fulfill the requirements of the Bidi rule per RFC 5893. 1. 2.2 The label must meet the relevant criteria of the ICANN Guidelines for the Implementation of Internationalised Domain Names. See http://www.icann.org/en/topics/idn/implementation-guidelines.htm. This includes the following, non- exhaustive, list of limitations: 2.2.1 All code points in a single label must be taken from the same script as determined by the Unicode Standard Annex #24: Unicode Script Property (See http://www.unicode.org/reports/tr24/). 2.2.2 Exceptions to 2.2.1 are permissible for languages with established orthographies and conventions that require the commingled use of multiple scripts. However, even with this exception, visually confusable characters from different scripts will not be allowed to co-exist in a single set of permissible code points unless a corresponding policy and character table are clearly defined.

4 5

Notes and action items - IDNs EPDP Meeting #8 - 30 September 2021
by Emily Barabas 30 Sep '21

30 Sep '21

Dear all, Please find below the notes from today’s meeting on Thursday 30 September 2021 at 13:00 UTC. Best regards, Steve, Marika, and Emily Action Items: None Notes – IDNs EPDP Call – 30 September 2021 Welcome & Chair Updates * Chair transition: Donna will transition to Chair in the next meeting. Edmon will remain on the calls to support Donna through the transition until the end of October when he joins the ICANN Board. * ALAC reps had requested an info session on the RZ-LGR. This is likely something that would benefit the whole group. This will be scheduled for next week’s regularly scheduled call. * Session should cover procedural elements that inform deliberations on the Topic A charter questions and help the group to understand whether a challenge mechanism makes sense at a practical level. * Request: include a demo of running a string through the RZ-LGR rules to determine if it’s valid or invalid; also go through an example with variants. Make sure that members understand how it works on a practical level. * ICANN org can prepare additional presentations if additional questions come up in the future. Continue deliberations on Topic A: Consistent definition and technical utilization of RZ-LGR – question a3 * Recap from last week’s discussion of a3: The WG is considering whether a challenge mechanism should be part of the New gTLD Program. Even if the challenge is triggered as part of the program, it might still need to go through the RZ-LGR process. * Review of the text of question a4 in the charter. * Comment: Important to separate a3 and a4 because the group may want to handle them differently. * Clarification: For a3: Suggestion that this should be treated like any other DNS stability challenge. If they apply for a string that is found to be invalid, it should be run through again. If still found to be invalid, it will be kicked out and they will have to work with the RZ-LGR and they will need to apply again in the next round. If there is no RZ-LGR for that script, they should still be able to work through the application process and then the application is put on hold. This is different from a situation where RZ-LGR exists but the string is found to be invalid, it can’t be resolved within that round. * Comment: Agree that if there is no RZ-LGR, it should be possible to put the application “on ice.” There should be text that says that the process should not be unnecessarily delayed. For cases where the RZ-LGR exists but the string is invalid, it should be possible to update the technical part of the application in the same round. * Comment: In cases where the applicant challenges the evaluations decision that a string is invalid, if it’s found that there was a mistake and the RZ-LGR needs to be updated, the string should also be “put on ice” until the issue is resolved and the application should be able to move forward as part of that same round. * Comment: At this point, we don’t know how frequent the rounds will come. When rounds occur regularly it will be relatively easy to punt an application to the next round. Until that time in cases where a review of RZ-LGR is triggered as the result of a challenge, they can wait until the results of that process with the possibility of proceeding. * Comment: If a string is found to be invalid, the applicant challenges the result, it’s re-run through the process and still found to be invalid, the applicant can go through the process with the RZ-LGR panel. This could be a long process. If that application is on its own (not in a contention set), then maybe it can go on hold for a long time. But if there are other applications in the contention set, they will also be on hold for a long time, too, which is bad for predictability. SubPro recommendations anticipate continuous rounds. If this is adopted by the Board, application opportunities will happen on a regular basis. We should let the other applications in the contention set move forward and the single applicant will need to reapply. * Comment: There should be a test tool for the script so potential applicants and others can test a string ahead of time to see if it might be found to be valid. * Response: There is a tool already at https://lgrtool.icann.org/b/. This tool was developed in a different context to support Generation Panels to develop their LGR proposals, but it can still be used to validate strings in the RZ-LGR. There is an additional tool in the planning phase that is expected to be more focused on the applicant and the application process. * Question: Where no script exists, how long would it take for a script to be put into the RZ-LGR (a4)? If a challenge needs to go through the RZ-LGR process, how long would that process take (a3)? * Response: As part of the data and metrics requested by the WG, org is working to provide metrics that can inform question a3 – information related to the feasibility of a challenge mechanism. The timeframe depends on the complexity of the work that needs to be done. It could potentially take as long as the quickest addition of a new script, around a year or more, but this will be discussed more on the next call. * Question a3 addresses applications for a string in a script that is already part of the RZ-LGR and the string is found to be invalid. Question a4 is the question about applications for strings in scripts that are not in the RZ-LGR. It may be helpful to think of these as two distinct issues. * Comment on a4: The big question is whether we should accept applications in strings that are not yet in the RZ-LGR. SubPro outputs state that we should but this group will also need to form a position. * Comment: For a4, SubPro considered this issue. They considered the paper the technical group. SubPro concluded that they should be able to apply and the application should be processed to the extent possible and go through contention sets. They should not be barred from applying. This WG would need a compelling reason to overturn that. * Comment: We should wait for Sarmad’s presentation before the group takes a position on whether challenges should be possible. * As the group becomes more familiar with the specifics of the process, members may feel more comfortable taking a position. * Introduction to a5: In the RZ-LGR, some languages have a situation where by permutation many allocatable variants could be possible from a technical and linguistic perspective. Many variants could potentially be put into the root. In reality, there are usually just a few variants that are the most useful. Should we set a ceiling in policy to increase predictability? * Question: Why is there an assumption that all of the variants have to go into the root, as well? * Technically and linguistically they are generated as allocatable. That doesn’t mean that they are delegated. It may be the case that most of them don’t need to be.

1 0

Re: [Gnso-epdp-idn-team] Proposed Agenda - IDN EPDP Meeting #8 - 30 September 2021
by Emily Barabas 30 Sep '21

30 Sep '21

Dear all, Please find below the proposed agenda for our meeting on 30 September 2021 at 13:00 UTC. Kind regards, Steve, Marika, and Emily IDN EPDP Meeting #8 Proposed Agenda 1. Roll Call & SOI Updates 2. Welcome & Chair Updates 3. Continue deliberations on Topic A: Consistent definition and technical utilization of RZ-LGR – question a3 4. AOB * Next call: 7 October at 13:00 UTC

4 4

Post Call | IDNs EPDP Team call | Thursday, 30 September 2021 at 13:00 UTC
by Terri Agnew 30 Sep '21

30 Sep '21

Dear all, All recordings for the IDNs EPDP Team call held on Thursday, 30 September 2021 can be found on the agenda wiki page <https://community.icann.org/x/qgBmCg> (attendance included) and the GNSO Master Calendar. [gnso.icann.org]<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, Terri

1 0

Meeting Invitation | IDNs EPDP Team | Thursday, 07 October 2021 at 13:00 UTC
by Terri Agnew 30 Sep '21

30 Sep '21

Dear all, The IDNs EPDP Team meeting is scheduled on Thursday, 07 October 2021 at 13:00 UTC for 60 minutes. Please click the link below to join the webinar: https://icann.zoom.us/j/94276275950?pwd=dG5hanFzMlpsYmh0NnFjTEQwOUV1dz09 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 [icann.zoom.us]<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 [gnso.icann.org]<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 [icann.org]<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/rABmCg * Check your time zone: https://tinyurl.com/tsne6sb7 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, Terri

1 0

IDNs EPDP Team meeting
by ICANN Policy Calendar 30 Sep '21

30 Sep '21

Meeting: IDNs EPDP Team meeting Date/time: Every Thursday at 13:00 UTC for 1 hour, beginning Thursday, 02 September 2021 through 21 October 2021 Please click the link to join the webinar: https://icann.zoom.us/j/94276275950?pwd=dG5hanFzMlpsYmh0NnFjTEQwOUV1dz09 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 If this is your first time with Zoom, please take a look here: Welcome to Zoom [gnso.icann.org]<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 [icann.org]<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the 02 Sept) Wiki agenda page (see left side for future dates): https://community.icann.org/x/lwBmCg * Check your time zone: https://tinyurl.com/4ex5bsh5 ONLY for Members and Participants * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Please select Panelists and Attendees, or 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.

1 0

**Starting in 15 minutes | Meeting Invitation | IDNs EPDP Team | Thursday, 30 September 2021 at 13:00 UTC
by Terri Agnew 30 Sep '21

30 Sep '21

**Starting in 15 minutes Dear all, The IDNs EPDP Team meeting is scheduled on Thursday, 30 September 2021 at 13:00 UTC for 60 minutes. Please click the link below to join the webinar: https://icann.zoom.us/j/94276275950?pwd=dG5hanFzMlpsYmh0NnFjTEQwOUV1dz09 [icann.zoom.us]<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 [icann.zoom.us]<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 [gnso.icann.org]<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 [icann.org]<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/qgBmCg * Check your time zone: https://tinyurl.com/3m67b53v [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/3m67b53v__;!!PtGJab4!vStlzSC…> 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, Julie

1 0

ICANN72 GNSO Sessions - How to Get Organized / Remote Participation Details
by Julie Bisland 29 Sep '21

29 Sep '21

Dear all, ICANN72 is right around the corner! This email provides some information to help you prepare and organize. Please note: You will need to register for ICANN72 to access the meeting schedule. Mandatory Registration for ICANN72 * Sign into your ICANN Account, or create an account here<https://account.icann.org/login>. * Register for ICANN72 by selecting Meeting Registration and click on the ICANN72 Registration link. Click here<https://gnso.icann.org/sites/default/files/policy/2021/presentation/instruc…> for detailed instructions. Note: the schedule will be published on 04 October 2021. Access the ICANN72 Schedule * ICANN72 schedule: https://72.schedule.icann.org/ For security purposes, participation links will be posted 24-hours prior to the session start times. * ICANN72 GNSO Sessions have been grouped on the ICANN72 GNSO wiki page<https://community.icann.org/x/CAFmCg>. Create your own schedule: * The ICANN Meeting website allows you to download all GNSO-related meetings to your inbox calendar in one go. For detailed instructions on how to create your personalized ICANN72 schedule and import your schedule to your calendar, click here<https://gnso.icann.org/sites/default/files/policy/2021/presentation/instruc…>. Review the Participation Tools and update Zoom * All sessions will use Zoom rooms. Access details are available 24hrs prior on the ICANN72 Meeting Schedule<https://72.schedule.icann.org/>. * Visit the Participation Tools page<https://72.schedule.icann.org/participation-tools> for links to download the latest version of Zoom for access to the ICANN72 sessions. * Please see the ICANN Meeting Virtual Participation How-To Guide<https://72.schedule.icann.org/attend#:~:text=virtual%20participation%20how-…> for more information on how to get the most out of the virtual meeting tools. Links to Bookmark ICANN72 Meeting Schedule<https://72.schedule.icann.org/> GNSO ICANN72 Wiki Page<https://community.icann.org/x/CAFmCg> GNSO Session agendas<https://community.icann.org/x/iIH8CQ> For all GNSO meeting-related queries (RP or others), please email us at: gnso-secs(a)icann.org and we will be more than happy to assist! Kind regards, GNSO SO/AC Support team -- Julie Bisland Policy Operations Sr. Coordinator (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) Skype ID: 79613b691cb8a6c1 Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…>

1 0

Sent: Draft Outreach Letter to SO/AC/SG/Cs
by Emily Barabas 29 Sep '21

29 Sep '21

Dear all, Seeing no comments or proposed edits, staff has sent out the outreach letters with a deadline for responses of 10 November 2021. You can find copies of the outreach letters here: https://community.icann.org/x/0gaHCg. As responses are received, they will also be posted to this page. Kind regards, Steve, Marika, and Emily From: Emily Barabas <emily.barabas(a)icann.org> Date: Tuesday, 28 September 2021 at 14:09 To: "gnso-epdp-idn-team(a)icann.org" <gnso-epdp-idn-team(a)icann.org> Subject: Deadline Today - Comments on Draft Outreach Letter to SO/AC/SG/Cs Dear all, As a reminder, today is the deadline to suggest edits to the draft outreach letter to SO/AC/SG/Cs requesting early written input on the charter topics. If you have any input please share it on the mailing list no later than 23:59 UTC. If no comments or concerns are received, the letter will be sent out to the community leaders tomorrow. Best regards, Steve, Marika, and Emily From: Emily Barabas <emily.barabas(a)icann.org> Date: Thursday, 23 September 2021 at 16:55 To: "gnso-epdp-idn-team(a)icann.org" <gnso-epdp-idn-team(a)icann.org> Subject: Notes and action items - IDNs EPDP Meeting #7 - 23 September 2021 Dear all, Please find below the notes and action items from today’s meeting on Thursday 23 September 2021 at 13:00 UTC. Attached, please find the draft outreach letter to SO/AC/SG/Cs requesting early written input on the charter topics. Please share any concerns/suggested edits on the mailing list no later than Tuesday 28 September at 23:59 UTC. Best regards, Steve, Marika, and Emily Action Item #1: Working Group members to review the draft outreach letter to SO/AC/SG/Cs and provide any concerns/suggested edits on the mailing list no later than Tuesday 28 September at 23:59 UTC. Action Item #2: WG to come up with questions to be covered in the upcoming prep session on RZ-LGR. Action item #3: For those that have not done so yet, please review all the introductory materials and sign off via the google sheet (see https://docs.google.com/forms/d/e/1FAIpQLSfbXhd2L4oAb_Cn22FnjkSoDSj0K-HNcij… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLSfbXhd2…>). Notes – IDNs EPDP Call – 23 September 2021 Welcome & Chair Updates * The group will put out a request for written early input to SO/AC/SG/Cs. Staff will send a draft of the letter to the WG for review after this call. WG members should respond on list if they have any concerns/suggested edits. Action Item #1: Working Group members to review the draft outreach letter to SO/AC/SG/Cs and provide any concerns/suggested edits on the mailing list no later than Tuesday 28 September at 23:59 UTC. * Policy support staff and the org IDN team met to discuss the data and metrics listed in the charter. Some additional clarifications are needed. An update will be provided soon on the timeline for delivering metrics. We will keep moving forward and can put items on hold if they are dependent on the delivery of these metrics. * Donna Austin will be confirmed by Council as the new Chair of the EPDP during today’s GNSO Council meeting – see consent agenda. * Edmon, Donna, and Farrell will be working with ICANN policy support on the logistics of the leadership transition for the EPDP. Continue deliberations on Topic A: Consistent definition and technical utilization of RZ-LGR * Charter question a3 focuses on a scenario where an applied for variant is found during evaluation to be invalid. If the applicant wants to challenge the process, how would this work? Should the SubPro-recommended challenge process apply for this use case? * Question: Is there any issue that has been raised by the challenge process to date? * Response: The SubPro challenge process has been recommended for the next round but it has not been used before. The process was created because in the last round any time there was a dispute in the evaluation process, there was no challenge mechanism to address the dispute. Instead, some parties opted to initiate reconsideration requests, which were not intended for this purpose. This process did not look at the merits, but only looked at whether staff violated the Bylaws. The SubPro WG felt that these types of issues should not go to the Board. If a party disagrees with the outcome of an evaluation, there should be a process to challenge the decision of the evaluator. SubPro recommended having this challenge for all evaluations, with the exception of IDNs, because SubPro felt that the IDN EPDP should address this particular use case. * Because this process is automated it might involve challenging RZ-LGR. How would this fit in? * We are not talking about applying the RZ-LGR in a vacuum. We are considering a use case in the context of the application process, where multiple applicants are applying in an application window. The RZ-LGR is an automated tool, but the process also involves ancillary processes that could determine that a string is invalid, because it doesn’t conform to the rules -- either code points are invalid, or other rules, for example where strings are put into a contention set. Those ancillary processes might be elements that parties want to challenge. The multiple connected evaluation elements may create additional complexity. * Are we talking about challenging about applications for IDNs? IDN variants? Or both? The evaluation of an IDN involves comparing an application to a pre-set checklist. If it doesn’t meet the criteria, it is not allowed to proceed. The evaluation entity is ICANN org. If we are talking about IDN variants being confusingly similar, then we are talking about the string similarity panel. In this case, a challenge might make sense, but data would be helpful about the frequency that a challenge could have arisen in the 2012 round. * Agree that there are two different scenarios: 1. the variant set is creating a conflict with another variant set and 2. it creates a confusing similarity issue with another TLD. These are related but separate issues. * If any of those challenges require an update to RZ-LGR, the update process is already defined by the RZ-LGR process which involves the relevant panel. It includes a public comment process. Creating a process outside of this could be detrimental to the RZ-LGR itself. * Suggestion: Take this question to a higher level. There is going to be an evaluation. If the result of the evaluation is something that the applicant believes is wrong, it should have a right to challenge. Regardless of whether this happened or not in the past, the applicant should have a right to challenge. The next question in the charter addresses the different scenarios and how they should be handled. The details should be handled in implementation. * We may face a situation where the IDN or variants can be challenged. In each case where the applicant prevails, they will need to freeze all applications within the same IDN or variants because there could be a change to the RZ-LGR or related-guidance and it could be applicable to all similar applications. It might also be relevant to applicants in the same round who already passed that stage of the application process. The changes resulting from any decisions related to challenges need to be implemented fast. * There are different categories of contention. In one, a TLD being applied for that confusingly similar to an existing TLD. With IDNs, it then needs to be determined if the applied-for string is similar to something that already exists in the context of the text itself and what it means in that specific language or script, and then also evaluated based on the variant rules: Is the makeup of the string potentially confusing with something that already exists. * Key question in a3: The RZ-LGR is only used for the technical validation of the string. Perhaps we should leave everything else, for example related to contention sets, to another process. We should focus on the case where the applicant disagrees with the determination related to technical validation. * Question: if two applicants apply for strings that are variants of one another, which one would be considered the variant? Who would get to move forward? * Response: They would be put into a content set. * Before a string exists, both strings are variants of one another. If one string already exists and another is applied for that cannot be considered unique to an existing TLD, that new application is considered a variant. * The only thing that we are considering as variants are generated by the RZ-LGR. * If there is an application that goes through the automated process, the process looks to see if the application is a variant of an existing string. If it is, it gets denied. If two applications are variants of one another, they go into a contention set. There is no main one and variant in these cases. * Staff produced a document to illustrate potential scenarios for a challenge: https://docs.google.com/spreadsheets/d/1m2OKyXsHa9pfyBz2u44UTTSYjAbuxe_FHCs… . Potential scenarios: 1. Applied-for gTLD is found to be invalid 2. Applied-for variant TLD is found to not be an allocatable variant. 3. A string is found to not be a blocked variant. * Purpose is to separate out this automated process from all of the other evaluation elements that might be impacted by variants. * Question: In the context of a next round, is the definition of variant the same? If an applicant applies for two strings that are variants, does that have to go through the RZ-LGR process before the applicant applies? * This is covered under charter question a4, but this can be discussed to some extent in combination with a3. It is possible for the applicant to run this through the RZ-LGR before applying, but there is also potentially the opportunity to raise a challenge. * Comment: The difference between valid and invalid strings is not clear. We need a clear and common understanding of the definition to use as a point of reference. It should be easily understood by a non-technical audience. * ALAC reps have some questions about the RZ-LGR process and would like to have an info session on this topic. * ICANN org is already organizing a session during prep week for ICANN72, and integration panels are coming in to explain how RZ-LGR and how it should be used. This is tentatively scheduled for 14 October. Org can organize any additional sessions on this topic if needed. Action Item #2: WG to come up with questions to be covered in the upcoming prep session on RZ-LGR.

2 1

**REMINDER** Meeting Invitation | IDNs EPDP Team | Thursday, 30 September 2021 at 13:00 UTC
by Julie Bisland 29 Sep '21

29 Sep '21

Dear all, The IDNs EPDP Team meeting is scheduled on Thursday, 30 September 2021 at 13:00 UTC for 60 minutes. Please click the link below to join the webinar: https://icann.zoom.us/j/94276275950?pwd=dG5hanFzMlpsYmh0NnFjTEQwOUV1dz09 [icann.zoom.us]<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 [icann.zoom.us]<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 [gnso.icann.org]<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 [icann.org]<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/qgBmCg * Check your time zone: https://tinyurl.com/3m67b53v [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/3m67b53v__;!!PtGJab4!vStlzSC…> 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, Julie

1 0