July 2022 - Gnso-epdp-idn-team

Potential Absences for August
by Ariel Liang 29 Jul '22

29 Jul '22

Dear All, Since August is a popular holiday month for the Northern Hemisphere, Leadership team and staff would like to check with the group regarding potential absences, so we could better plan the upcoming meetings. Thanks to those who already sent apologies in advance. If you have any planned time-off for the month of August, could you please be so kind to inform gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>? We appreciate the information. Best Regards, Ariel Ariel Xinyue Liang Policy Sr. Specialist Internet Corporation for Assigned Names and Numbers (ICANN)

1 0

Post Call | IDNs EPDP Team call | Thursday, 28 July 2022
by Devan Reed 28 Jul '22

28 Jul '22

Dear all, All recordings for the IDNs EPDP Team call held on Thursday, 28 July 2022 can be found on the agenda wiki page <https://community.icann.org/x/JgYVD> (attendance included) and the GNSO Master Calendar. <https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…> These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-epdp-idn-team/> and the main wiki page<https://community.icann.org/x/uAPpCQ>. Thank you! Kind Regards, Devan

1 0

Meeting Invitation | IDNs EPDP Team | Thursday, 04 August 2022 at 13:30 UTC
by Devan Reed 28 Jul '22

28 Jul '22

Dear all, The IDNs EPDP Team meeting is scheduled on Thursday, 04 August 2022 at 13:30 UTC for 90 minutes. Please click link to join the webinar: https://icann.zoom.us/j/94276275950?pwd=dG5hanFzMlpsYmh0NnFjTEQwOUV1dz09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/94276275950?pwd=dG5hanFz…> Passcode: !!0tV0Wh&K For Audio only: One tap mobile : US: +13017158592,,94276275950#,,,,*5259149775# or +13126266799,,94276275950#,,,,*5259149775# Webinar ID: 942 7627 5950 Passcode: 5259149775 International numbers available: https://icann.zoom.us/u/adP1jJ0gRH <https://urldefense.com/v3/__https:/icann.zoom.us/u/adP1jJ0gRH__;!!PtGJab4!v…> If this is your first time with Zoom, please take a look here: Welcome to Zoom <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> Members, participants, and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior <https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/KAYVD * Check your time zone: https://tinyurl.com/5n6hsd2d ONLY for Members and Participants * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Please select Everyone, when posting to the chat in order for everyone to see and to be captured afterwards. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Devan

1 0

Re: [Gnso-epdp-idn-team] Notes and action items - IDNs EPDP Meeting #45 - 28 July 2022
by Emily Barabas 28 Jul '22

28 Jul '22

Dear all, Please find below the notes and action items from today’s meeting on Thursday, 28 July 2022 at 13:30 UTC. Kind regards, Ariel, Steve, and Emily Action Items Action Item 1: Leadership team will send proposed revisions to to Recommendation 2.3 under Charter Question B2 [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/15YGISgNQYL_V…>, and Recommendations 2.5 and 2.6 under Charter Question D1b (part 2) [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1C6xKX87w2LtN…> to the mailing list to give those not on the call an opportunity to review the revised text. Action Item 2: Staff to consider if rationale for recommendation 2.5 can be further clarified, perhaps by adding “Where the primary label is sought with one or more variant labels at the same time.” Notes – IDNs EPDP Call – 28 July 2022 Welcome and Chair Updates * A number of EPDP Team members are absent today. We will go over several edits, but also give absent members an opportunity to review following the call. * The EPDP Team had a good conversation with the ccPDP4 Team on Tuesday. The leadership team may look into adopting the “stress test” methodology that the ccPDP4 Team described on Tuesday’s call. Recommendation 2.3 under Charter Question B2 Proposed revision: Recommendation 2.3: If the registry operator of an IDN operating a variant gTLD label changes its back-end registry service provider, that IDN gTLD and any additional delegated variant label(s) associated with that gTLD all the variant gTLD label(s) in the set must also simultaneously transition to the same new back-end registry service provider. B2 Draft Rationale for Recommendations and Implementation Guidance: Rationale for Recommendation 2.2 and Recommendation 2.3: For feasible and consistent implementation of the “same entity” requirement at the top-level, the EPDP Team affirms to extend the SubPro PDP and the Staff Paper recommendations to existing gTLDs and their variant labels. The EPDP Team further recommends that the same back-end registry service provider must operate all delegated variant gTLD label(s) in the set at any given time. If the registry operator operating a variant gTLD label changes its back-end registry service provider, all variant gTLD label(s) in the set must also transition to the same new back-end registry service providerTo that end, the transition to a new back-end registry service provider must apply to the primary gTLD and all of its delegated variant labels at the same time. * New edits try to capture that the primary the gTLD and variant labels are included in the recommendation. * The rationale seeks to provide further clarification that the transition applies to both. * Leadership team notes the email on the mailing list pointing out the potential consequences of the way the working group has been using the term “primary TLD”. Leadership team notes that we will need to clean up terminology to ensure it is consistent and correct and also develop a glossary. Action Item 1: Leadership team will send proposed revisions to to Recommendation 2.3 under Charter Question B2 [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/15YGISgNQYL_V…>, and Recommendations 2.5 and 2.6 under Charter Question D1b (part 2) [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1C6xKX87w2LtN…> to the mailing list to give those not on the call an opportunity to review the revised text. Recommendation 2.5 under Charter Question D1b (part 2) Proposed revision: Keep recommendation language for 2.5 as it is and revise rationale. Rationale for Recommendation 2.5: The EPDP Team noted SubPro PDP’s recommendation that future applications of new gTLDs “must be assessed in rounds”. The EPDP Team agreed that for the next application round and each subsequent round, an applicant who applies for a primary new IDN gTLD and some or all of its allocatable variant label(s) in the same set will only be required to submit one application for the set. This would allow for an efficient and streamlined process. * Provides context about the SubPro recommendation regarding the use of rounds for subsequent procedures. * Intent of this recommendation is that instead of submitting multiple applications at the same time, the applicant can submit one application for the label and the allocatable variants they want to activate. * It is not clear from the text of recommendation that the original application may need a supplemental application if the applicant wants to activate additional variants at a later date. * Suggestion: Add to rationale that the EPDP Team has not yet addressed when and how a gTLD RO can apply for additional variants. * The recommendation also seems to imply that every time subsequent applications are submitted the primary also needs to be part of that application, which may not be the intent. * The discussion of the process for activating subsequent variants for strings that had previously been requested and allocated will be addressed in future discussions of D1b (part 1). Action Item 2: Staff to consider if rationale for recommendation 2.5 can be further clarified, perhaps by adding “Where the primary label is sought with one or more variant labels at the same time.” Recommendation 2.6 under Charter Question D1b (part 2) Proposed Revision: Rationale for Recommendation 2.6: As IDN gTLDs and variant labels that are considered a set are yet to be delegated and operated at the root zone level, there is uncertainty about how the set will be managed and operated by the registry operator from a technical and user perspective. Therefore, it will be important that applicants are able to explain their need for a set of IDN variant label(s) as well as demonstrate their technical capability to operate and manage the set. Therefore, the applicant will be required to respond to additional application questions to address why they seek to activate those variant label(s) in addition to the primary new gTLD (i.e., necessity and expected usage of the variant labels), as well as how it plans to manage the set operationally to achieve the security, stability, and usability goals for IDN variants as well as how it plans to manage the set operationally, with a view to ensuring a secure, stable, and consistent user experience. The applicant’s response to these questions is expected to be a critical component in the evaluation process. Evaluators with requisite expertise are expected to assess these responses. * Attempts to address RySG concern that registry should not and can not be responsible for ensuring a “consistent user experience” as well as ALAC’s feedback that the user experience is an important element of implementing IDNs. * The proposed text attempts to provide a compromise that accommodates the concerns expressed by both groups. * Noting that some RySG and ALAC members are not in attendance, EPDP will wait for additional feedback on the mailing list.

1 0

15 MINUTES **REMINDER - Meeting Invitation | IDNs EPDP Team | Thursday, 28 July 2022 at 13:30 UTC
by Devan Reed 28 Jul '22

28 Jul '22

Dear all, The IDNs EPDP Team meeting is scheduled on Thursday, 28 July 2022 at 13:30 UTC for 90 minutes. Please click link to join the webinar: https://icann.zoom.us/j/94276275950?pwd=dG5hanFzMlpsYmh0NnFjTEQwOUV1dz09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/94276275950?pwd=dG5hanFz…> Passcode: !!0tV0Wh&K For Audio only: One tap mobile : US: +13017158592,,94276275950#,,,,*5259149775# or +13126266799,,94276275950#,,,,*5259149775# Webinar ID: 942 7627 5950 Passcode: 5259149775 International numbers available: https://icann.zoom.us/u/adP1jJ0gRH <https://urldefense.com/v3/__https:/icann.zoom.us/u/adP1jJ0gRH__;!!PtGJab4!v…> If this is your first time with Zoom, please take a look here: Welcome to Zoom <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> Members, participants, and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior <https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/JgYVD * Check your time zone: https://tinyurl.com/2tcjap4b<https://urldefense.com/v3/__https:/tinyurl.com/2tcjap4b__;!!PtGJab4!-rL2JDn…> ONLY for Members and Participants * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Please select Everyone, when posting to the chat in order for everyone to see and to be captured afterwards. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Devan

1 0

REMINDER - Meeting Invitation | IDNs EPDP Team | Thursday, 28 July 2022 at 13:30 UTC
by Julie Bisland 27 Jul '22

27 Jul '22

Dear all, The IDNs EPDP Team meeting is scheduled on Thursday, 28 July 2022 at 13:30 UTC for 90 minutes. Please click link to join the webinar: https://icann.zoom.us/j/94276275950?pwd=dG5hanFzMlpsYmh0NnFjTEQwOUV1dz09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/94276275950?pwd=dG5hanFz…> Passcode: !!0tV0Wh&K For Audio only: One tap mobile : US: +13017158592,,94276275950#,,,,*5259149775# or +13126266799,,94276275950#,,,,*5259149775# Webinar ID: 942 7627 5950 Passcode: 5259149775 International numbers available: https://icann.zoom.us/u/adP1jJ0gRH <https://urldefense.com/v3/__https:/icann.zoom.us/u/adP1jJ0gRH__;!!PtGJab4!v…> If this is your first time with Zoom, please take a look here: Welcome to Zoom <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> Members, participants, and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior <https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/JgYVD * Check your time zone: https://tinyurl.com/2tcjap4b [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/2tcjap4b__;!!PtGJab4!-rL2JDn…> ONLY for Members and Participants * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Please select Everyone, when posting to the chat in order for everyone to see and to be captured afterwards. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Devan

1 0

Re: [Gnso-epdp-idn-team] primary labels and consequences of retiring them
by Tan Tanaka, Dennis 26 Jul '22

26 Jul '22

Donna, Thank you. I like the approach. Best, Dennis From: "Donna(a)registry.godaddy" <Donna(a)registry.godaddy> Date: Tuesday, July 26, 2022 at 3:17 PM To: Dennis Tan Tanaka <dtantanaka(a)verisign.com>, Maxim Alzoba <m.alzoba(a)gmail.com>, "Michael.Bauland(a)knipp.de" <Michael.Bauland(a)knipp.de> Cc: "gnso-epdp-idn-team(a)icann.org" <gnso-epdp-idn-team(a)icann.org> Subject: [EXTERNAL] RE: [Gnso-epdp-idn-team] primary labels and consequences of retiring them Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Dennis, all Thank you for raising the question about what we mean when we use the term ‘primary’ and the potential consequences associated with such a designation. Michael has also provided some useful input on this point. As our discussions have evolved we have referred to the ‘primary’ to make a distinction between the IDN gTLD being applied for and the associated variant labels that are either allocatable or blocked that comprise an IDN variant ‘set’. However, our discussions can be complicated, particularly as we all have different levels of understanding of IDNs, and we use words that some might consider technically incorrect, but I believe have become commonly understood terms or phrases within our group, to help distinguish a point that someone/we’re trying to address or make. I agree that the Team does need to discuss what is the most accurate terminology that we should use to describe what we intend with our recommendations. The leadership team is aware that this is a concern and have discussed developing a glossary, which I think will be helpful. In addition, we also recognize that the draft text that we have circulated to date is not consistent in the use of terms or phrases and this is something we are also looking to address. So, I want to acknowledge your concerns, but for now I would like to park these for later discussion/consideration by the Team to give the Leadership Team some time to look into how best to address the issue. Thanks Donna From: Gnso-epdp-idn-team <gnso-epdp-idn-team-bounces(a)icann.org> On Behalf Of Tan Tanaka, Dennis via Gnso-epdp-idn-team Sent: Tuesday, July 26, 2022 8:34 AM To: m.alzoba(a)gmail.com; Michael.Bauland(a)knipp.de Cc: gnso-epdp-idn-team(a)icann.org Subject: Re: [Gnso-epdp-idn-team] primary labels and consequences of retiring them Caution: This email is from an external sender. Please do not click links or open attachments unless you recognize the sender and know the content is safe. Forward suspicious emails to isitbad@. And this is the question I post to this group. Do we need to always have a label designated as “primary”, and if so, what function will it serve? My current thinking is that the primary label serves its purpose to determine the set of ALL variant labels — allocatable and blocked. Beyond this point the set is established (disposition values are captured), and so, I would argue, a “primary” label no longer have utility (other than a data point to indicate how the set was formed, and/or potential re-calculation due to rz-lgr changes). Each applied-for/delegated label should have equal standing in the set, IMO. But perhaps I am missing something. Dennis From: Gnso-epdp-idn-team <gnso-epdp-idn-team-bounces(a)icann.org<mailto:gnso-epdp-idn-team-bounces@icann.org>> on behalf of Maxim Alzoba <m.alzoba(a)gmail.com<mailto:m.alzoba@gmail.com>> Date: Tuesday, July 26, 2022 at 3:54 AM To: Michael Bauland <Michael.Bauland(a)knipp.de<mailto:Michael.Bauland@knipp.de>> Cc: "gnso-epdp-idn-team(a)icann.org<mailto:gnso-epdp-idn-team@icann.org>" <gnso-epdp-idn-team(a)icann.org<mailto:gnso-epdp-idn-team@icann.org>> Subject: [EXTERNAL] Re: [Gnso-epdp-idn-team] primary labels and consequences of retiring them Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. I think the procedure of the retirement needs to have a check for the existence of the primary and if not - election of the new one. Maxim Alzoba On Jul 26, 2022, at 09:42, Michael Bauland <michael.bauland(a)knipp.de<mailto:michael.bauland@knipp.de>> wrote: Hi Dennis, On 25.07.2022 21:46, Tan Tanaka, Dennis via Gnso-epdp-idn-team wrote: A few additional comments on 2.3 re: use of “primary label” * Some questions I reckon we will face throughout: what is the “primary” label? what function does it serve? should we use such nomenclature? … some background notes: * When we talk about variants in a set, it is important to note which of all labels is the source for variant label calculation, or as we have adopted: the primary label. As a way of context, first, the variant relationship between two code points must satisfy the symmetrical property (there are other properties, but not relevant to this topic). This means, if ‘A’ is a variant of ‘B’, then ‘B’ is a variant of ‘A’. Second, any variant relationship is also assigned a disposition value: allocatable or blocked. The disposition value is unidirectional. Which means, a variant relationship could yield an ‘allocatable’ variant in one direction (e.g., AàB: allocatable), but a ‘blocked’ variant in the other direction (e.g., BàA: blocked). These rules are encoded in the LGR. * As we progress in our deliberations about the lifecycle of gTLDs it is important to understand (and remember) how the various variant labels and disposition values came to be (to discern which ones are allocatable/withheld or blocked). However, I believe we need to remain open (or at least give thoughtful consideration) to cases where one TLD label in the set needs to be handled separately e.g., retirement, and the implications of this one change applies to the rest of the labels in the set. For instance, what if the registry operator wants to retire the “primary” label and continue to operate the rest of variants. In this case, it would be unwise, perhaps, to re-assign the attribute of “primary” to another label in the set, because that might change the profile of the set as a whole (of course, this would depend what “primary” means and how it is used). This is a very good point. Especially with asymmetric disposition we have a real problem if a primary label is retired and the other variants are kept. There might arise a situation in which none of the remaining variants can be made primary, because it would entail one of the other existing variants to become blocked instead of allocatable. The question would then be * Do we allow a variant set to exist without a primary label? * Will retiring a primary label require the registry to select another primary label and thereby possibly force them to retire other variants together with the former primary label? Take the following quite simple example. Applied for primary label: bıß Allocatable Variants: biß, bıss, biss So, someone might have all four labels in the Root zone at some point. If they now retire the primary label bıß, the other three labels could not exist at the time (without bıß also existing). Case 1: biß is made new primary Consequence: bıss becomes a blocked variant. Case 2: bıss is made new primary Consequence: biß becomes a blocked variant. Case 3: biss is made a new primary Consequence: both bıss and biß become blocked variants. Even though the example is not very likely, it's certainly possible and in other scripts might be similar examples that are more likely. So, to summarise my points: * Initially, we need a primary label to determine the disposition value of all variants. * Retiring a primary label may cause problems and we need to decide how to deal with these problems. Best regards, Michael

1 0

Re: [Gnso-epdp-idn-team] Proposed Agenda - IDN EPDP Meeting #44 - Thursday 28 July 2022 at 13:30 UTC
by Tan Tanaka, Dennis 26 Jul '22

26 Jul '22

A few additional comments on 2.3 re: use of “primary label” * Some questions I reckon we will face throughout: what is the “primary” label? what function does it serve? should we use such nomenclature? … some background notes: * When we talk about variants in a set, it is important to note which of all labels is the source for variant label calculation, or as we have adopted: the primary label. As a way of context, first, the variant relationship between two code points must satisfy the symmetrical property (there are other properties, but not relevant to this topic). This means, if ‘A’ is a variant of ‘B’, then ‘B’ is a variant of ‘A’. Second, any variant relationship is also assigned a disposition value: allocatable or blocked. The disposition value is unidirectional. Which means, a variant relationship could yield an ‘allocatable’ variant in one direction (e.g., A-->B: allocatable), but a ‘blocked’ variant in the other direction (e.g., B-->A: blocked). These rules are encoded in the LGR. * As we progress in our deliberations about the lifecycle of gTLDs it is important to understand (and remember) how the various variant labels and disposition values came to be (to discern which ones are allocatable/withheld or blocked). However, I believe we need to remain open (or at least give thoughtful consideration) to cases where one TLD label in the set needs to be handled separately e.g., retirement, and the implications of this one change applies to the rest of the labels in the set. For instance, what if the registry operator wants to retire the “primary” label and continue to operate the rest of variants. In this case, it would be unwise, perhaps, to re-assign the attribute of “primary” to another label in the set, because that might change the profile of the set as a whole (of course, this would depend what “primary” means and how it is used). * All I am saying is let’s be careful where and how we use the term “primary”. Perhaps this is a good test case for stress testing a la ccPDP4. Best, Dennis From: Gnso-epdp-idn-team <gnso-epdp-idn-team-bounces(a)icann.org> on behalf of Ariel Liang <ariel.liang(a)icann.org> Date: Monday, July 25, 2022 at 1:48 PM To: Emily Barabas <emily.barabas(a)icann.org>, "gnso-epdp-idn-team(a)icann.org" <gnso-epdp-idn-team(a)icann.org> Subject: [EXTERNAL] Re: [Gnso-epdp-idn-team] Proposed Agenda - IDN EPDP Meeting #44 - Thursday 28 July 2022 at 13:30 UTC Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Dear All, First, as a reminder – the joint ccPDP4 and IDN-EPDP meeting will take place tomorrow (Tue, 26 July at 14:00-15:30 UTC). We look forward to your participation! Second, as a refresher of last week’s meeting and a preview of the upcoming IDN-EPDP meeting on Thursday (see agenda below), leadership team and staff are proposing the following changes to the draft recommendations 2.3, 2.5, and 2.6, incorporating input received: Rec 2.3 (see p.2: https://docs.google.com/document/d/15YGISgNQYL_VfcVVZ6E97qbo42GPziP6x089bR3…): · Summary of discussion – some members raised the concern that the “primary” label was not specified · Recommendation language: revised as “If the registry operator of an IDN gTLD changes its back-end registry service provider, that IDN gTLD and any additional delegated variant label(s) associated with that gTLD must also simultaneously transition to the new back-end registry service provider.” o This revision seeks to clarify the gTLD labels that are impacted by the transition of back-end registry service provider without the need to use the term “primary label” and “set”. · Rationale – replaced the last sentence with the following: “To that end, the transition to a new back-end registry service provider must apply to the primary gTLD and all of its delegated variant labels at the same time.” o This sentence seeks to explain, in general terms, the transition of back-end RSP simultaneously apply to the primary gTLD and all of its delegated variants. Rec 2.5 (see p.3: https://docs.google.com/document/d/1C6xKX87w2LtN4Is0mehuRgc1GqjKmbbhT14KbvU…): · Summary of discussion – some members were unsure about adding the phrase “during the same round” at the end of the recommendation language, as the discussion about the process and timing of variant activation is still ongoing. · Recommendation language – no change to the original recommendation language (i.e., not adding “during the same round”) · Rationale part – add the following sentence at the beginning: “The EPDP Team noted SubPro PDP’s recommendation that future applications of new gTLDs ‘must be assessed in rounds’.” o This seeks to provide context that future new gTLD applications are expected to happen in rounds. Rec 2.6 (see p.3: https://docs.google.com/document/d/1C6xKX87w2LtN4Is0mehuRgc1GqjKmbbhT14KbvU…): · Summary of discussion – divergence of opinion from RySG and ALAC regarding “ensuring a secure, stable, and consistent user experience” in the rationale · Recommendation language – no change · Rationale – replace the phrase “…with a view to ensuring a secure, stable, and consistent user experience” with “…to achieve the security, stability, and usability goals for IDN variants”. o This is the general goal of variant management as incorporated in the IDN-EPDP charter Best Regards, Ariel From: Gnso-epdp-idn-team <gnso-epdp-idn-team-bounces(a)icann.org> on behalf of Emily Barabas <emily.barabas(a)icann.org> Date: Monday, July 25, 2022 at 1:06 PM To: "gnso-epdp-idn-team(a)icann.org" <gnso-epdp-idn-team(a)icann.org> Subject: [Gnso-epdp-idn-team] Proposed Agenda - IDN EPDP Meeting #44 - Thursday 28 July 2022 at 13:30 UTC Dear all, Please find below the proposed agenda for our meeting on Thursday 28 July 2022 at 13:30 UTC. Kind regards, Ariel, Steve, and Emily IDN EPDP Meeting #44 Proposed Agenda 1. Roll Call & SOI (2 minutes) 2. Welcome & Chair Updates (5 mins) 3. Review Proposed Revisions to Recommendation 2.3 under Charter Question B2 [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/15YGISgNQYL_V…>, and Recommendations 2.5 and 2.6 under Charter Question D1b (part 2) [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1C6xKX87w2LtN…> (80 mins) 4. AOB (3 mins)

4 4

Post Call | IDNs EPDP Team with ccPDP4 meeting | Tuesday, 26 July 2022
by Devan Reed 26 Jul '22

26 Jul '22

Dear all, All recordings for the IDNs EPDP Team with ccPDP4 meeting held on Tuesday, 26 July 2022 can be found on the agenda wiki page <https://community.icann.org/x/woFJD> (attendance included) 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) For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-epdp-idn-team/> and the main wiki page<https://community.icann.org/x/uAPpCQ>. Thank you! Kind Regards, Devan

1 0

Notes and Action Items - IDNs EPDP Team with ccPDP4 meeting - Tuesday, 26 July 2022 at 14:00 UTC
by Emily Barabas 26 Jul '22

26 Jul '22

Dear all, Please find below the notes and action items from today’s meeting on Thursday, 26 July 2022 at 14:00 UTC. Kind regards, Ariel, Steve, and Emily IDNs EPDP Team with ccPDP4 meeting Tuesday, 26 July 2022 at 14:00 UTC Action Items Action Item: Edmon and Sarmad will seek further input from the Board UA/IDN WG: To what extent are the divergences between the gNSO and ccNSO draft recommendations a concern? If there is a divergence, but not a conflict, is this an issue? Is the expectation that the groups resolve differences or just highlight them? High-Level Notes * Slide 3 – Overview: Goal and focus of this session. * Discuss draft recommendations developed by both groups to understand the similarities and differences. * Slide 4 – General Comparison of the ccPDP4 and IDN EPDP, including topics in scope, procedure, scope of policy, and implementation. * Overview: There are differences between the way that the two WGs and the Supporting Organizations do their business, but there are overlaps in the subject matter being addressed through the respective E/PDPs. * Question for further discussion: How did the ccPDP4 conduct its stress testing? * Response: Scenarios are developed and consideration is given about the ability to handle that scenario. There may be similarities with what the ODP is doing in the GNSO. * Response: ccNSO started doing stress testing with the retirement policy. The policy itself is 4-5 pages long. It’s helpful to understand how various outliers play out under the policy. The working group develops scenarios. The WG discusses how the scenarios would play out under the proposed policy. Could the WG live the with outcome or does there need to be an adjustment to the policy before the recommendations go out for consensus call? The stress test is included in the WG outputs. The stress test allows you to respond to any questions that later come up in public comment or through other channels. * Slide 5 – RZ-LGR Utilization: Consistent recommendations between the two groups. * Overview: The level of detail may be different between the recommendations from the two groups, but the general principle remains consistent. * Slide 6 – RZ-LGR Utilization: Potential Difference * Overview: Two areas where there may be divergence are on limiting the number of delegated variants and on “grandfathering” existing TLDs after an RZ-LGR update with which the TLD is not validated. * Question: What does “meaningful representation” mean and how does it play into the ccPDP work? * Response: This is a basic policy requirement for eligibility for ccTLD strings. The concept was shared with the cc community for validation. In the GNSO case, there may be different considerations, for example brand representation, but for the cc community, the focus is specific. * Response: The requirement for a meaningful representation of the territory is analogous to gTLD requirements for special purpose TLDs e.g., brand TLDs or geo TLDs. * Response: Only one string is delegated per language and must be supported by people who represent the territory and the language. The string should be from a recognized script, usually defined by the government. * Response: The WG did a case study on what it would mean to have Pakistan with Arabic script and various variants. This was based on the staff study. There are about 1200 variants, including blocked variants. Only 6 or 7 are allocatable, most of which are not a meaningful representation. This tightly defined concept helps to limit the number of variants that will be in use. * Question: To what extent are the recommendations on the limits at odds? It is not clear that they necessarily are. Is this something the Board would consider a divergence of concern? Is the expectation that we resolve difference or just highlight them? * Response: The Board has not taken up discussion on this since Edmon joined the Board. The idea is that the policies from the ccNSO and GNSO do not contradict one another. There is likely understanding that they will not be identical. If contradictory, there might be an impact on the consistent user experience. Some level of consistency is desired. * Response: In the case that the ccNSO and GNSO might not have identical recommendations, but we don’t want to be in a situation where they are contradictory. Action Item: Edmon and Sarmad will seek further input from the Board UA/IDN WG: To what extent are the divergences between the gNSO and ccNSO draft recommendations a concern? If there is a divergence, but not a conflict, is this an issue? Is the expectation that the groups resolve differences or just highlight them? * Slide 7 – RZ-LGR Utilization: Additional Recommendations * Overview: Recommendations that cover additional topics that do not overlap between the two groups. * Slide 8 – Same Entity at Top-Level: Consistent Recommendations * Overview: Consistency in recommendations on allocation of variant TLD to same entity and registry operators and back-end registry service providers for variant TLDs. * Slide 9 – Same Entity at Top-Level: Additional Recommendations * Overview: Recommendations that cover additional topics. * Both groups have sub-groups working on issues related to confusing similarity. On the issue of whether the two sub-groups should coordinate, it was noted that the IDN EPDP small group will need to bring its outputs to the full EPDP for its consideration before outputs are considered stable. * Question: EPDP is considering best practice guidelines on the management on variants at the top level. There have been IDN ccTLDs and variants in operation for some time. Is this left to the individual ccTLD or are there some consistent practice that can be shared on this issue? * Response: There are IDN ccTLDs in traditional and simplified Chinese. They have been allocated to the same IDN ccTLD manager. IDN ccTLD managers participate in the WG, and the WG asks them questions. Records of the deliberations reflect this input. The Fast Track experience has evolved over time and this evolution takes into account the experience of those who have gone through the process. * Slide 10 – Same Entity at Second-Level * Sub-Group of ccPDP4 is considering this topic. ccPDP4 will discuss whether allocation of variant SLD to same entity and registration of variant SLD under variant TLD to same entity is within or outside scope. These may not be policy recommendations, but technical considerations or advice. * IDN EPDP has had initial discussions and realized that defining the same entity as the registrant is difficult to implement in practice. The EPDP Team is exploring separating out the second level discussion from the top level to provide time for additional data collection and for the contracted parties to explore this topic further and provide input to the EPDP Team. * Slide 11 – IDN-EPDP Upcoming Work * Timeline is somewhat in flux, because the EPDP is considering restructuring its work. Regular communication will be maintained between the support staff for the GNSO and ccNSO. If the timeline is adjusted for the IDN EPDP, when the EPDP Team notifies the GNSO Council, it will also provide this information to the ccPDP4. * Upcoming work for ccPDP4: The Variant Management Sub-Group and Confusing Similarity Sub-Group are wrapping up their work. Stress Test will be conducted, followed by a public comment period, before submitting recommendations. The final recommendations will likely be submitted in the next 4-6 months. * Suggestions for further coordination: * Additional coordination on the topic of confusing similarity once the respective groups have reviewed sub-team/small group outputs. * Additional opportunity to work together on stress testing. Emily Barabas Policy Development Support Senior Manager Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org<http://www.icann.org/>

1 0