September 2021 - Gnso-epdp-idn-team

Public comment proceeding for Latin script RZ-LGR proposal
by Steve Chan Sept. 28, 2021

Sept. 28, 2021

Dear EPDP Team, As this may be of particular interest to this group, calling your attention to ICANN org’s announcement for the Latin script RZ-LGR proposal public comment proceeding initiated last week. The announcement, that many of you may have already seen, is hyperlinked and the public comment proceeding page is here: https://www.icann.org/en/public-comment/proceeding/proposal-for-latin-scrip…. Best, Steve Steven Chan  Senior Director, GNSO Support Internet Corporation for Assigned Names and Numbers (ICANN) 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536  Email: steve.chan(a)icann.org Skype: steve.chan55 Mobile: +1.310.339.4410 Find out more about the GNSO by visiting: https://learn.icann.org/ Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar

1 0

Deadline Today - Comments on Draft Outreach Letter to SO/AC/SG/Cs
by Emily Barabas Sept. 28, 2021

Sept. 28, 2021

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 2

Notes and action items - IDNs EPDP Meeting #7 - 23 September 2021
by Emily Barabas Sept. 23, 2021

Sept. 23, 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.

1 0

Meeting Invitation | IDNs EPDP Team | Thursday, 30 September 2021 at 13:00 UTC
by Julie Bisland Sept. 23, 2021

Sept. 23, 2021

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 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

Post Call | IDNs EPDP Team call | Thursday, 23 September 2021 at 13:00 UTC
by Julie Bisland Sept. 23, 2021

Sept. 23, 2021

Dear all, All recordings for the IDNs EPDP Team call held on Thursday, 23 September 2021 can be found on the agenda wiki page <https://community.icann.org/x/qABmCg> (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, Julie

1 0

**Starting in 11 minutes** Meeting Invitation | IDNs EPDP Team | Thursday, 23 September 2021 at 13:00 UTC
by Julie Bisland Sept. 23, 2021

Sept. 23, 2021

**Starting in 11 minutes** Dear all, The IDNs EPDP Team meeting is scheduled on Thursday, 23 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/qABmCg * Check your time zone: https://tinyurl.com/b6hb3xnz [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/b6hb3xnz__;!!PtGJab4!qLvJ9Q2…> 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. Thank you. Kind regards, Terri

1 0

**REMINDER** Meeting Invitation | IDNs EPDP Team | Thursday, 23 September 2021 at 13:00 UTC
by Julie Bisland Sept. 22, 2021

Sept. 22, 2021

Dear all, The IDNs EPDP Team meeting is scheduled on Thursday, 23 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 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/qABmCg * Check your time zone: https://tinyurl.com/b6hb3xnz 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. Thank you. Kind regards, Terri

1 0

Proposed Agenda - IDN EPDP Meeting #7 - 23 September 2021
by Emily Barabas Sept. 21, 2021

Sept. 21, 2021

Dear all, Please find below the proposed agenda for our meeting on 23 September 2021 at 13:00 UTC. Kind regards, Steve, Marika, and Emily IDN EPDP Meeting #7 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 4. AOB * Next call: 30 September at 13:00 UTC

2 1

Post Call | IDNs EPDP Team call | Thursday, 16 September 2021 at 13:00 UTC
by Terri Agnew Sept. 16, 2021

Sept. 16, 2021

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

Notes and action items - IDNs EPDP Meeting #6 - 16 September 2021
by Emily Barabas Sept. 16, 2021

Sept. 16, 2021

Dear all, Please find below the notes and action items from today’s meeting on Thursday 16 September 2021 at 13:00 UTC. Best regards, Steve, Marika, and Emily Action Item #1: Leadership team to send out a “last call” for any comments/concerns about the draft project plan. Absent comments by Monday, the project plan will be submitted to Council. Action Item #2: Keep calls at 60 minutes for now. Revisit length of meetings after the working group has deliberated on charter questions in Topic A. Action Item #3: Staff to take back items discussed last week regarding data and metrics and see if additional nuance should be added to the bullets in the charter. Action Item #4: Members/participants to prepare to discuss charter question a3 - a10 on upcoming calls. Action item #5: 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 – 16 September 2021 Welcome & Chair Updates * This is a full agenda. The goal is to get through at least agenda item 5. Draft Project Plan * Current PDPs and EPDPs all have formal, standardized project plans like the draft displayed on screen. These are an outcome of PDP 3.0, a GNSO Council initiative to increase the efficiency and effectiveness of policy development efforts. They are more detailed than some of the work plans we have used in the past. * The initial items on the project plan are administrative. Working group members should focus on section 2. The project plan is built around the topics in the charter, with a repeatable process that will be followed for each topic: understand the topic and questions, conduct deliberations, first reading, second reading, and confirm the draft is stable. * Once there are stable drafts for all topics, these will feed into the Initial Report. Following the steps in section 3 related to the Initial Report, the steps related the Final Report in section 4 will be completed. * This project plan should be realistic and achievable. It will be delivered to the GNSO Council and will be used by the Council to hold the WG accountable. It is not expected that there is absolute precision in the estimates. If additional time is needed to complete the EPDP, the working group can submit a Project Change Request to Council explaining the need for an extension to the timeline. * The polls conducted in the working group during early calls helped to inform the timeframes for deliberations included in the work plan. * The project plan estimates delivery of the Initial Report in early 2023 and Final Report in April 2023. * Status will be reviewed each month and a “project package” will be delivered to the GNSO Council with updates about the EPDP’s progress. * Absent objections, this work plan will be sent to the GNSO Council and will go on the October Council agenda for formal acknowledgment. Action Item #1: Leadership team to send out a “last call” for any comments/concerns about the draft project plan. Absent comments by Monday, the project plan will be submitted to Council. * Question: There may be additional work associated with IDN implementation guidelines and interactions with the IRT for SubPro. Is this included in the project plan. * Answer: Noting that the IRT may be some time away, continue to move forward with the timeline as proposed. If additional items come into play, we may need to adjust. Length of meetings * The working group currently meets weekly for 60 minutes. The last few meetings we were rushing through the agenda. Would it make sense to extend weekly calls to 90 minutes so there is more time for deliberations? * Leadership suggestion: start calls at 12:30 UTC and run to 14:00 UTC. * Comment: Once we start getting deeper into the substance of the discussion, less time will be needed for process is administrative matters. 60 minutes may be sufficient. * Suggestion: Work through charter questions in Topic A with 60-minute calls. Revisit length of calls after that work is complete to determine if 90-minute calls are needed. Action Item #2: Keep calls at 60 minutes for now. Revisit length of meetings after the working group has deliberated on charter questions in Topic A. Review of proposed data & metrics requests from the charter * The working group will likely need staff to assist with data collection. * The charter identifies six suggested data elements to support the work, beginning on page 19. Does it make sense for the working group to instruct staff to go ahead and begin collecting/organizing these metrics? * Using the latest version of the RZ-LGR determine the variant labels of the 2012 New gTLD Round and determine whether the list of calculated variants match those that were identified by the applicant (a2) * Time needed to create an LGR script proposal and frequency a RZ-LGR is updated (a4, a6) * Methods used to establish the same entity at the second-level by the same Registrar and across different Registrars (c3, c3a) * Number of registries that use the machine readable LGR format specified in RFC 7940 for second-level IDN tables (c6) * Using the latest version of the RZ-LGR determine the variant labels, if any, of i) all delegated gTLDs, and ii) all ICANN reserved TLD labels. Determine whether the calculation is consistent with reality or whether any exceptions need to be considered (e5) * Breakdown of the scripts/languages represented in a validated and active trademark in the TMCH (f1) * Suggestion: Request the data from staff now and then allow members to add to this along the way. * Question: Staff noted some questions on last week’s call. Do they coincide with the list in the charter or add to it? Action Item #3: Staff to take back items discussed last week regarding data and metrics and see if additional nuance should be added to the bullets in the charter. Continue deliberations on Topic A: Consistent definition and technical utilization of RZ-LGR * We left off last week at charter question a3. * Staff-provided background on the challenge/appeal mechanism included in the SubPro recommendations – The Final Report provides a table in Annex F which lays out all of the evaluation elements and objections processes that could potentially be challenged or appealed in the New gTLD Program. The table explores what the appeal could look like in practice. This group could use the table as a model and try to fill in the values to help think through a possible challenge process for resolving disagreements with the RZ-LGR calculation for an applied-for TLD label where the label is found to be “invalid.” * Next week, we will try to fill in a row to the table to help inform whether the approach would make sense. * Note that whatever this group produces does not need to follow the model of what SubPro produced, but SubPro’s work can be used as a starting point. * Potential data point to collect: Frequency that a RZ-LGR is updated. If updated frequently, there might not be a need for a challenge mechanism. * Response: There is not an active review. It is an on and off issue. Action Item #4: Members/participants to prepare to discuss charter question a3 - a10 on upcoming calls.

1 0