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/1Bt0LT45UaLynF...> * 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/1Bt0LT45UaLynF...> * 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.