[Gnso-epdp-idn-team] Sent: Draft Outreach Letter to SO/AC/SG/Cs
Nigel Hickson
nigel.hickson at dcms.gov.uk
Wed Sep 29 13:23:53 UTC 2021
Emily
Good afternoon, I did make some edits on the Google Document yesterday;
best
Nigel
On Wed, 29 Sept 2021 at 14:04, Emily Barabas <emily.barabas at icann.org>
wrote:
> 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 at icann.org>
> *Date: *Tuesday, 28 September 2021 at 14:09
> *To: *"gnso-epdp-idn-team at icann.org" <gnso-epdp-idn-team at 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 at icann.org>
> *Date: *Thursday, 23 September 2021 at 16:55
> *To: *"gnso-epdp-idn-team at icann.org" <gnso-epdp-idn-team at 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]
> <https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLSfbXhd2L4oAb_Cn22FnjkSoDSj0K-HNcijDZDW_zpvseqXH8A/viewform__;!!PtGJab4!q5jSiym6ABR-Yt9L0-wMEdzB_QGY4Er_C8v9qUet_0gDUe9SNMlbjhwwHJ10QwIR71PL5G9bdg$>).
>
>
>
>
>
>
>
>
> *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_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.
>
>
> _______________________________________________
> Gnso-epdp-idn-team mailing list
> Gnso-epdp-idn-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-idn-team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20210929/b3bec942/attachment-0001.html>
More information about the Gnso-epdp-idn-team
mailing list