March 2022 - Gnso-epdp-idn-team

Notes and action items - IDNs EPDP Meeting #29 - 31 March 2022
by Emily Barabas 31 Mar '22

31 Mar '22

Dear all, Please find below the notes and action items from today’s meeting on Thursday, 31 March 2022 at 13:30 UTC. Kind regards, Ariel, Steve, and Emily Action Items: Action Item 1: RySG members on the EPDP Team to ask geoTLD colleagues if they have any concerns about the direction that the group is taking on charter question B5. Action Item 2: Leadership Team to draft response to charter question B5 and recommendation. Action Item 3: Leadership Team to send proposed approach to outreach to CJK GPs to the EPDP Team for review and response on the mailing list, to be wrapped up next week. The EPDP Team will try to raise and resolve questions on email. Action Item 4: Leadership Team to send follow-up email regarding proposed outcome for Charter question A10. Notes – IDNs EPDP Call – 24 March 2022 Welcome & Chair Updates * The call currently scheduled for the 14 April will need to be moved of cancelled. It conflicts with a GNSO Council call. Standard practice is to move the call back 24 hours if there is a conflict, but 15 April is Good Friday. Leadership will circle back with the EPDP with a suggestion about how to proceed. * The EPDP Team needs to begin thinking about ICANN74. Once it becomes clear what the format and requirements for the meeting will be, the EPDP Team can discuss the plan for the meeting. * Shout out to Satish for a panel that he chaired for the APAC DNS Forum. Donna was scheduled for present but was unable to attend due to power outage. Thanks to Pitinan from ICANN org for covering Donna’s presentation. * The session on the future of IDN variants had speakers from the policy side of the issue and speakers on the practical aspects of variant management. * There was a good response from the audience, especially in the questions raised. There were questions around how to treat variants as equivalent in practice. * Recording is available here: https://www.youtube.com/watch?v=KZ4jonmjam0 Continued discussion of Charter Question B4a * Slide 4 -- Overview of charter question and summary of discussion * The discussion left off with possible three scenarios: 1. Existing ROs – allocatable variant labels not being requested for activation; 2. Future applicants – allocatable variant labels not being applied for; 3. Future applicants – grounds for rejection removed for previously “rejected” labels * The intent of the charter question is to focus on the first two scenarios. Questions related to the third scenario will come up later in the charter questions. * Comment: There is not much of an issue if there is the rule that all strings from the variant set can only be applied for by the same entity. There would only be an issue if different entities could apply. * Two questions: The question “what role do they play. . .” alludes to whether the variant labels with status withheld-same-entity are used in any other process for example application evaluation (such as string similarity). The question of legal claims is separate. * Regarding the connection between how the variant labels can be used vs. the issue of legal claims -- in the charter drafting, the drafting team was thinking about how in the previous round, the declared variants were used to some extent in the application process for very specific reasons even though the applicant had no legal claims. The question was developed in the context of this experience. * It was noted that Topic E has questions about the role of withheld-same-entity labels in objection and string similarity review process, so this question is not about their role in those processes. * Comment: What really matters is what the applicant should do, for example should they mention the variants in the application. The WG should consider the question: “What are the reasons that the applicants should need to include variants in the application, for example because they want to activate the variant in the future?” This may be tied to other issues, for example the timing of when an applicant can activate a variant (during vs. outside the round). * This question specifically says that the variant label in question has not been requested for activation in the application process. There is a charter question of whether all variant labels in a set should go through string similarity process other than those that have been applied for, but we will get to this in addressing other charter questions. A suggestion was made to put aside this question until Topic E is discussed, and then the group can see if there is anything left that needs to be addressed that is relevant to this question. * Agreement: “Park” this question and revisit after addressing charter questions under Topic E. Introduction to Charter Question B5 * Slide 7 -- Overview of charter question and context * Slide 8 – Examples of Existing gTLDs with “Restrictions” * Preliminary recommendation that it would be one application submitted with variant labels and assumption that the gTLD and variant labels will be operated for a single user experience. * Comment: Yes, they should be bound by the same restrictions and treated the same way. It is a single application. If a primary string is applied for as a brand, the variants should also be brand TLDs, otherwise it would be a confusing user experience. * Comment: It is important to avoid a situation a geo TLD has a variant in another language that is a geo name for a different place. This result should be avoided. For geo TLDs, variants should have lower precedence. * Question: Does this intervention imply that for geo TLDs, the variant label should be less important? For example, if an applied for label has a variant that might be a different geo name in another language, is the suggestion that the variant label should not be available for the applicant, even though it would be a variant under the RZ-LGR? * Response: Correct. The application requires endorsement from the relevant jurisdiction. If a government can’t access a TLD because it a variant of a non-geo string, this is a serious problem. * Comment: This intervention implies that in special cases, the variant relationship should not be applied. This is not possible because the RZ-LGR is paramount and there is no way to have to two variants operated by two different operators, such as in the geo example. * This issue is to be resolved outside of this charter questions. B5 specifically asks if an applicant applies for a geo name and there are variants, that those variants also needed to be treated as geo names. * There are criteria/constraints that come from the application perspective, and another set that are about the use of the string. These might need to be examined separately. From a use perspective, the same rules might apply – for example if one string is used as a geo TLD, the variant should also be a geo TLD. For the brand case, the brand needs to submit proof that the applied for string is identical to a registered trademark of the RO. If there is a variant that is not visually identical, even if allocatable in the application process, will it be rejected because it will not meet the string criteria? At the use level, the main string and the variant will both be used as a brand, but do the same application criteria apply? * From the application perspective, if an application requires endorsement from a particular city in its language, the variant might be in a language that the city does not use. One question is whether the application criteria should be the same as the use criteria. * Comment: The one application principle should apply. All variants should be treated the same. There should be one application, with one set of criteria for the set, for example one endorsement for a set. In terms of the string itself, all variants will need to go through public comment, string similarity, and objections processes. If a party felt that an application infringed on their rights, that party would need to object at that time. Decoupling would cause a problem to the concept of variants. * If you have a trademark with different capitalization, you would still apply that to a TLD. The same would apply for simplified and traditional Chinese. Under trademark rules, they are considered to be conflicts, although the trademark itself could be applied for in one or the other. The safest route is to keep the one application principle – the endorsement is sought for the primary string, and the variants come as a package along with that. * Question: Is it possible that one applicant applies for a geo TLD and two variants together and a second applicant applies for one of those variants as its primary string? * Response: If A and B are variants of each other and C is a variant of B it is automatically a variant of A. There is no main label. They are all equally valid and important. * Comment: If applicant 1 applies for A and variant B and applicant 2 applies for B as a primary string, there will be a contention set and would need to be addressed through contention resolution. * Comment: There may be edge cases where there is contention for a brand or geo name. There need to be safeguards that can handle edge cases while applying the single application rule. * The specific questions related to variants and geo names may already be taken into account in the application and resolution processes, as well as the SubPro work. * Suggestion to ask geoTLDs for their opinions about obstacles for the last round. * Outcome: Some support expressed for the idea that the requirements that apply for a normal gTLD will also apply for a IDN gTLD and its variants. The same restrictions apply. Action Item 1: RySG members on the EPDP Team to ask geoTLD colleagues if they have any concerns about the direction that the group is taking on charter question B5. Action Item 2: Leadership Team to draft response to charter question B5 and recommendation. * Question: Are we limiting the scope of this response to the same application that covers a primary label and its variants? * Response: Yes. * Another example: Do we apply the same application evaluation criteria to all of the variants of a TLD in a special category? Or do the application criteria only apply to the primary string? Example: Straße and Strasse are variants in German. Will the same application criteria and processes apply to both? * This will be handled in a later charter questions. B5 is less about the application evaluation process and more about what needs to be included in the application. Charter Question A7 – approach to outreach to CJK GPs * Slide 10 -- Summary of discussion on part 2 of the question * Slide 11 – Proposal for consultation letter to GPs * Any initial reactions? Confirming that this is still an approach the group supports? * Comment: It is useful to consult with the GPs. * Regarding further points for setting expectations on Slide 11: The Chair’s perspective is that we should consider any feedback from the GPs as an input to EPDP Team deliberations. On the question “should the outcomes be encoded in the RZ-LGR, or should they be published as a document for reference,” it may be that we need to see the output before we can decide. Action Item 3: Leadership Team to send proposed approach to outreach to CJK GPs to the EPDP Team for review and response on the mailing list, to be wrapped up next week. The EPDP Team will try to raise and resolve questions on email. * Leadership team is revising A5/A6 language. This will be sent to the list soon. This will only be discussed further if additional concerns are raised. Charter question A10 * Slide A10 – Recap of discussion * Clarification may be needed regarding highlighted text on slide 14. Otherwise, the suggested path forward is to draft a response to the charter question in support of the recommendations in the staff paper. Action Item 4: Leadership Team to send follow-up email regarding proposed outcome for Charter question A10.

1 0

Post Call | IDNs EPDP Team call | Thursday, 31 March 2022 at 13:30 UTC
by Devan Reed 31 Mar '22

31 Mar '22

Dear all, All recordings for the IDNs EPDP Team call held on Thursday, 31 March 2022 can be found on the agenda wiki page <https://community.icann.org/x/ZwB1Cw> (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, 07 April 2022 at 13:30 UTC
by Devan Reed 31 Mar '22

31 Mar '22

Dear all, The IDNs EPDP Team meeting is scheduled on Thursday, 07 April 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/aQB1Cw * Check your time zone: https://tinyurl.com/48vbnvxs 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

15 MINUTES **REMINDER** Meeting Invitation | IDNs EPDP Team | Thursday, 31 March 2022 at 13:30 UTC
by Devan Reed 31 Mar '22

31 Mar '22

Dear all, The IDNs EPDP Team meeting is scheduled on Thursday, 31 March 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/ZwB1Cw * Check your time zone: https://tinyurl.com/bdz2emrr [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/bdz2emrr__;!!PtGJab4!sZ23lql…> 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, 31 March 2022 at 13:30 UTC
by Julie Bisland 30 Mar '22

30 Mar '22

Dear all, The IDNs EPDP Team meeting is scheduled on Thursday, 31 March 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/ZwB1Cw * Check your time zone: https://tinyurl.com/bdz2emrr [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/bdz2emrr__;!!PtGJab4!sZ23lql…> 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

Proposed Agenda - IDN EPDP Meeting #29 - Thursday 31 March 2022 at 13:30 UTC for 90 minutes
by Emily Barabas 29 Mar '22

29 Mar '22

Dear all, Please find below the proposed agenda for our meeting on Thursday 31 March 2022 at 13:30 UTC. As a reminder, working documents for Topics A and B are available here<https://community.icann.org/pages/viewpage.action?pageId=176622687>. Kind regards, Ariel, Steve, and Emily IDN EPDP Meeting #29 Proposed Agenda 1. Roll Call & SOI Updates (2 min) 2. Welcome & Chair Updates (5 min) 3. Continued discussion of Charter Question B4a (20 min) 4. Introduction to Charter Question B5 (25 min) 5. Charter Question A7 – approach to outreach to CJK GPs (25 min) 6. Charter Question A10 – status/general agreement of Team (10 min) 7. AOB (3 min)

1 0

Updated due to GNSO Council meeting conflict | Meeting Invitation | IDNs EPDP Team | Friday, 15 April 2022 at 13:30 UTC
by Devan Reed 28 Mar '22

28 Mar '22

Sending this in advance to get the right date on everyone’s calendars. **Please note, the 14 April call has been rescheduled to Friday, 15 April. Please remove the 14 April .ics from your calendars and replace with the attached .ics file for Friday, 15 April at 13:30 UTC for 90 minutes. Dear all, The IDNs EPDP Team meeting is scheduled on Friday, 15 April 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/awB1Cw * Check your time zone: https://tinyurl.com/2p9xs662 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

IDNs EPDP Team meeting
by ICANN Policy Calendar 28 Mar '22

28 Mar '22

Meeting: IDNs EPDP Team meeting Date/time: FRIDAY 15 April 2022 at 13:30 UTC for 90 minutes Please click the link to join the webinar: https://icann.zoom.us/j/94276275950?pwd=dG5hanFzMlpsYmh0NnFjTEQwOUV1dz09 Passcode: !!0tV0Wh&K For Audio only: One tap mobile : US: +13017158592,,94276275950#,,,,*5259149775# or +13126266799,,94276275950#,,,,*5259149775# Webinar ID: 942 7627 5950 Passcode: 5259149775 International numbers available: https://icann.zoom.us/u/adP1jJ0gRH If this is your first time with Zoom, please take a look here: Welcome to Zoom <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 agenda wiki page: https://community.icann.org/x/awB1Cw * For other places see: https://tinyurl.com/2p9xs662 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.

1 0

Post Call | IDNs EPDP Team call | Thursday, 24 March 2022 at 13:30 UTC
by Devan Reed 24 Mar '22

24 Mar '22

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

Notes and action items - IDNs EPDP Meeting #28 - 24 March 2022
by Emily Barabas 24 Mar '22

24 Mar '22

Dear all, Please find below the notes and action items from today’s meeting on Thursday, 24 March 2022 at 13:30 UTC. Kind regards, Ariel, Steve, and Emily Action Items: Action Item 1: Update Recommendation 1.4 to be more specific as it applies to registry operators and the factors impacting their decision to apply for variants (currently the text refers to “market forces”). Action Item 2: Add implementation guidance for Recommendation 1.5 indicating that the IRT will determine who will develop best practices. Action Item 3: Leadership team to propose edits to Recommendation 1.7 taking into account the discussion. Action Item 4: Leadership team to consider comments on Implementation 1.9 and 1.10 and suggest a path forward. Action Item 5: Update text of Implementation Guidance 1.10 to refer to: “registry, registrar, registrants and end-users”. Action Item 6: Leadership team to post revisions to the list based on today’s discussion for additional review by the EPDP Team. Notes – IDNs EPDP Call – 24 March 2022 SOI Updates * Jeff Neuman is updating his SOI to reflect that he has an interest in the new .hiphop registry operator. Welcome & Chair Updates * Reminder from the Chair to EPDP members that they signed a Statement of Participation, which includes the following point: “I will treat all Members/Participants of the Working Group with civility both face-to-face and online, and I will be respectful of their time and commitment to this effort. I will act in a reasonable, objective, and informed manner during my participation in this Working Group and will not disrupt the work of the Working Group in bad faith.” * Opinions are welcomed and valued, but all perspectives need to be brought in and taken into account. The goal is to work towards consensus. * EPDP members are encouraged to focus chat contributions on the topic at hand in the discussion and not distract from verbal discussion. * If you miss a call, please review the recording to understand the context of the discussion in order to ensure that the deliberations can progress effectively. * Reminder about EPDP Team process: The Team has one or two conversations on the topic. When there is pretty good agreement, the leadership team drafts text for the WG to review, and then the EPDP considers any additional input member on that text. Review of EPDP Team member input on Charter Questions A5 [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1Bt0LT45UaLyn…> * Clarification: not all comments that have been submitted are included in the Google Doc. Items are added to the Google Doc if they need further consideration or input from the WG. Statements of support for draft text are not included. * ALAC comment on Recommendation 1.4 regarding the term “market forces”: Per ALAC members, it appears that the text implies that market forces are determinant. ALAC supports defining this term or using an alternate term. * Comment: The intent of this text is that registries would not apply for more variant labels than they could manage. Considerations for registries include financial factors as well as other factors. * Staff response: The intent of the term “market forces” is defined in the rationale. * Comment: Market forces mean economic factors. It doesn’t mean that the registry will seek to activate more than it can handle. Action Item 1: Update Recommendation 1.4 to be more specific as it applies to registry operators and the factors impacting their decision to apply for variants (currently the text refers to “market forces”). * ALAC comment on Recommendation 1.5: Suggestion to have binding policies instead of best practices to ensure consistency. * Comment: There should be consistent applicant criteria for registries when the apply for variants, but we don’t want to be too rigid since we don’t fully understand capabilities with respect to variants and what the user experience should be. We don’t want to hamper innovation. * Comment: Variant is a policy concept and not a technical one. There is not a technical solution for operationalizing variants. We should be careful about what we mean by consistency and make sure we consider the issue in the broader context. There is a role for registries, but also for registrars and registrants in the implementation of variants. * Comment: The right approach for the evaluation is to have a set of minimum requirements that must be met to pass evaluation but not to have rigid requirements more broadly with respect to variants. * Question: Who would develop and manage the best practices? * Response: Best practices have traditionally been organic and been developed as need arises. From a policy perspective, this would go to the IRT to decide how to implement the recommendations. * Comment: If a set of best practices exists as a live document, this might be unstable. * Comment: Implementation of variant labels hasn’t been done before. There needs to be faith in the ROs and RSPs that they will be able to implement effectively and that best practices will be developed over time. * Reminder: SubPro made a recommendation that second-level variant labels “are not required to act, behave, or be perceived as identical.” That recommendation took into account input from the staff paper on IDNs and the SSAC. Note: The SubPro recommendation will be considered further later in the charter when we discuss behavior of variants. * Outcome: No change to the recommendation. Add implementation guidance to address the question of who will develop best practices. Action Item 2: Add implementation guidance for Recommendation 1.5 indicating that the IRT will determine who will develop best practices. * Staff notes a revision to footnote 15 in response to comment from Michael Bauland. Review of EPDP Team member input on Charter Questions A6 [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1Bt0LT45UaLyn…> * ALAC comment on Recommendation 1.6: Suggestion to provide a definition of grandfathering. * Staff sought to provide a definition of grandfathering in the second sentence of the recommendation with additional clarification in the rationale. * Outcome: No additional clarification is needed. * ALAC comment of Recommendation 1.7: ALAC expressed uncertainty as to whether a script community can anticipate “exceptional circumstances” that might break backwards compatibility. * Suggestion: Add “To the extent possible” before “The LGR Procedures must be updated to specify the exceptional circumstances. . .” * From another perspective, this language should not be softened. Label Generation Panels should be bound by certain principles. The impact of a change that is not backwards compatible is significant. Therefore, the language should include a strong “must.” * Comment: The LGR procedure is not currently explicit enough. What one person considers “exceptional circumstances” another person may not. Therefore, it should be explicit. * Question: Is it ok to say “must” given that the LGR process already abides by the principle of conservatism? * Staff Comment: There is a stability principle which is part of the LGR procedure itself. Staff previously spoke with the integration panel and the panel agreed that there is hardly any chance that the LGR for a script could be changed to make an existing TLD invalid. There are safeguards built into the LGR procedures and from the IP as well. * Suggestion to strike out “be updated to. . .” so that it is clear that the principles are aligned rather than dictating what the procedures must do. * Comment: Panels operate without many legal restrictions. Registries should not be blindly bound to what the panels do. There needs to a balance to ensure predictability for contracted parties. * Reminder: the two exceptional circumstances previously identified are changes to IDNA2008, Unicode standards. * Comment: Perhaps the LGR can enumerate the known exceptional circumstances acknowledging that it may not be possible to identify all potential exceptional circumstances in the future. * Question: How difficult is it to change the LGR procedure? If set of exceptional circumstances can be updated in the LGR, then why is this an issue? * Response: A team of experts from different script communities developed and reviewed the LGR procedure, which was approved by the Board. This was the mechanism taken up in the first part. Something similar would need to happen each time to LGR is updated. * Clarification on ALAC comment: Support in principle the recommendation but how practically implementable is the recommendation? * Should the tense of the sentence beginning “The LGR procedure must. . .” be updated to reflect that we are talking about the past and not the future? * Comment: The burden on the registry/registrar/registrant/end users of breaking backwards compatibility is greater than the burden on the panels of making this more predictable. * Comment: At a minimum, the LGR procedure could be updated to include the two exceptional circumstances identified. To the extent that additional circumstances are identified in the future, perhaps they could be added. Action Item 3: Leadership team to propose edits to Recommendation 1.7 taking into account the discussion. * ALAC Comment on Implementation Guidance 1.9: ALAC appears to support removing “if known and understood by the GP” and suggested additional text “the GPs, together with other technical entities such as RSSAC, SSAC or ICANN Org, should identify the security and stability risks…” o Comment: We may be implicitly expanding the expertise of the panel, specifically with respect to mitigation. o Clarification: Specific competency can vary from GP to GP. GPs include linguistic expertise, the community perspective, DNS and IDNs. The GP is expected to include expertise on the security and stability of IDNs. Some may have less experience in registry operations than another. Integration panels are consulted in the GP work and their expertise are brought into that work. You cannot say for sure that a GP will have expertise in registry operations. Perhaps there should be some collaboration between the GP and someone who understands registry operations. o Additional clarification: When a GP is considering in the context of security and stability they may need to balance the impact on the business. This may be an area where they need additional input. o Comment: IG 1.9 does not appear to say that it should only the GP – it leaves open that GPs can consult. o Suggestion to consider combining 1.9 and 1.10, which may help to address ALAC’s concerns. Action Item 4: Leadership team to consider comments on Implementation 1.9 and 1.10 and suggest a path forward. * Implementation Guidance 1.10 – the word “timely” is suggested in response to GAC comment on this item. * ALAC comment on Implementation Guidance 1.10: “We are not sure if the phrase “the gTLD registry operator, their customers, and end users” (used twice in the text) has any special context to it, and if it is as inclusive in comparison with “registry, registrar, registrants and end-users”. Action Item 5: Update text of Implementation Guidance 1.10 to refer to: “registry, registrar, registrants and end-users”. · Staff notes redlines in rationale for recommendations 1.6-1.8 in response to inputs received from GAC and Michael Bauland. Action Item 6: Leadership team to post revisions to the list based on today’s discussion for additional review by the EPDP Team. · Suggestion regarding Charter Question A5: A ceiling value is needed. There is going to some level of confusion for end users. · GAC comment: The work of this group is important. It is hard to get the essence across to “laymen” and explain why it enhances multilingualism on the internet. Suggestion for WG leadership or representatives to meet with the GAC at ICANN74 to discuss the EPDP’s work. · If the GAC has specific questions that they would like to discuss/cover, it is helpful to understand this in advance. Continued discussion of Charter Question B4a * Slide 4 – context, summary of discussion to date. * Covers two, and possibly 3, scenarios: 1. Existing ROs might have withheld same entity strings; 2. In a future round, an applicant applies for primary and allocatable variants, but the applicant has not requested to activate the variants; 3. Applicant requested a label, it’s allocatable, but it was rejected. If grounds for rejection are removed it becomes withheld-same-entity.

1 0