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@icann.org>
Date: Tuesday, 28 September 2021 at 14:09
To: "gnso-epdp-idn-team@icann.org" <gnso-epdp-idn-team@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@icann.org>
Date: Thursday, 23 September 2021 at 16:55
To: "gnso-epdp-idn-team@icann.org" <gnso-epdp-idn-team@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-HNcijDZDW_zpvseqXH8A/viewform [docs.google.com]).

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.

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_FHCsK9LUKPVI/edit#gid=0 . 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.