Dear all, Please find below the notes and action items from today’s meeting on Thursday, 21 July 2022 at 13:30 UTC. Kind regards, Ariel, Steve, and Emily Action Items Action Item 1: Leadership Team to consider how to make clear in recommendation 2.3 that the set includes the primary label and the variants. Action Item 2: Leadership Team to consider how to more clearly reflect the intent of Recommendation 2.5. Action Item 3: Leadership Team to further consider resolving concerns with Recommendation 2.6. EPDP Team will return to this item. Action Item 4: GNSO Policy Staff to work with Bart to see if it is possible to weave additional suggested topics into the deck. Notes – IDNs EPDP Call – 21 July 2022 Welcome & Chair Updates (5 mins) * Thanks to ALAC and RrSG for meeting with the leadership team during “office hours”. It was helpful to receive feedback on the progress of the EPDP, working methods and also to get to know members better. * Leadership team would like to meet with representatives from other groups if this is possible. * ICANN75: Sessions for the EPDP Team are tentatively scheduled as the first two sessions on Saturday 17 September: Session 1 - 09:00-10:00 (local time), and Session 2 - 10:30-12:00 (local time). The EPDP Team will use this time for substantive discussion on some of the more difficult topics. Details will follow. * Update from Dennis Tan on CPH work on questions regarding IDNs at the second level. * Dennis recently briefed the CPH TechOps group about EPDP Team work and requested input on managing the same entity principle at the second level over the lifecycle of a domain. * TechOps might be a group to advise on managing IDN variants at the second level throughout their lifecycle. * Today IDN variants at the second level may be activated by request of the sponsoring registrar of the canonical name. This is like the same entity principle, but the same entity is the registrar. There are no registrar obligations. SubPro recommended in 25.6-25.8 that IDN second level domains need to be registered by the same entity, which is the registrant. How do you confirm that the same entity (registrant)? One possible solution is using the contact object to glue names. But reusing the contact object is not currently widespread. You can look at matching text fields, but this is difficult to implement. Any solution needs to be implemented in a way that is interoperable. * The expectation that two domains act consistently is out of the hands of registries and registrars. * TechOps group is interested to contributing to this work. * Leadership comment: It is helpful to get those with technical expertise to weigh in, although this may take time. * The group might want to consider delivering its work in two packages. The first will focus on the top level. The second can focus on the second level. The timing of the second package can depend how quickly TechOps can provide input. Second reading: Review proposed amendments/concerns with draft text: B1, B2, B3, B5, D1a, D1b (part 2) (35 mins) (https://community.icann.org/pages/viewpage.action?pageId=176622687) * Topic B: https://docs.google.com/document/d/15YGISgNQYL_VfcVVZ6E97qbo42GPziP6x089bR3w... * Redlines without comments reflect minor edits. Those with comments in the document are more substantive feedback. * Recommendation 2.1: Any All allocatable variant labels of an existing gTLD, as calculated by the RZ-LGR, can only be allocated to the registry operator of the existing gTLD or withheld for possible allocation only to that registry operator. * “All” may imply that there may be many allocatable variants. “Any” indicates that there may be a limited number. This edit is accepted by the group. * In the rationale for Recommendation 2.1, suggestion to add text in bold: The EPDP Team agreed that abiding by the “same entity” principle and having the same registry operator for all allocatable variant labels of an existing gTLD will help minimize, but not eliminate, the security risk associated with the “failure modes” – including denial of service and misconnection – when dealing with variant labels. * Rationale: The same entity principle helps to manage risks but does not take them away completely. Group accepts redline. * Suggested edit to Recommendation 2.2: The registry operator of an existing IDN gTLD must use the same back-end registry service provider, the organization providing one or more registry services (e.g., DNS, DNSSEC, RDDS, EPP), for operating any additional all delegated variant labels of that gTLD. * Suggestion is to improve precision of the language. Could account for a situation where we can apply for variant labels between rounds. Accepted by EPDP Team. * Suggested edits to Recommendation 2.3: If the registry operator operating a variant gTLD label changes its back-end registry service provider, all the variant gTLD label(s) in the set must also simultaneously transition switch to the same new back-end registry service provider. * In addition, the suggested edit includes updating “switch” to “edit” in the rationale for Recommendation 2.3. * “Simultaneously” emphasizes that the transition needs to happen at the same time. * “Transition” is the official term and is consistent with other materials. * No objections raised to these updates. * Question: The language only mentions that the variants are transitioning but it doesn’t mention the primary. Suggestion to add reference to the primary and the variants. Possible options: * "....all the variant gTLD label(s) in the set and the primary gTLD must also ...."? * "all the gTLD label(s), including the primary and its variants in the set" Action Item 1: Leadership Team to consider how to make clear in recommendation 2.3 that the set includes the primary label and the variants. * The Working Group might need to include in the recommendations the definition of “primary TLD.” * Feedback from RySG on Recommendation 2.8. Dennis is seeking input from Brand TLD Group and GeoTLD Group. * Topic D: https://docs.google.com/document/d/1C6xKX87w2LtN4Is0mehuRgc1GqjKmbbhT14KbvUH... * Suggested edit to Recommendation 2.4: Any eExisting orand future IDN gTLDs along with itsand their variant labels (if any) will be subject to one Registry Agreement with the same registry operator. * Edits are primarily editorial in nature and suggested for clarity. No objections. * Recommendation 2.5: Future IDN gTLD applicants will be required to submit one application covering the primary IDN gTLD and corresponding allocatable variant label(s) the applicant seeks to activate during the same round. * Corresponding edit also suggested for the rationale for 2.5. * Edit intends to make the text more precise. * Comment: The deliberations are still pending about whether there will be variant activation between rounds, so this text may not be accurate based on the state of deliberations. * Alternatives: “application process” or “at the same time.” * Does “at the same time” indicate that we are disallowing allocation of variants at a later time? * The text does refer to primary label and IDN variants. The point is that if they want the variants at the same time as the primary, it will be in one application. Action Item 2: Leadership Team to consider how to more clearly reflect the intent of Recommendation 2.5. * 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, 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. * Per RySG, the text RySG proposes to delete seems to be a requirement to do something the applicant is not in a position to do. * Concern raised about how the plan for the use of the TLD might be incorporated into the contract as a commitment. * Registry can’t police or monitor use of domains and content to ensure a “consistent user experience”. * ALAC response. “1. The EPDP team had identified as an important consideration the ability of registries and registrars to be able to successfully handle the complexities of IDN variants (ie., "manageability"), in order to ensure the security, stability and consistency of the use of IDN variant labels. The ALAC team therefore considers the struck out text as necessary to convey this message. 2. As such, the Recommendation 2.6 for D1b (Part 2) has no Implementation Guidance, and therefore there is little possibility of misconstruing the text as Implementation Guidance. 3. Further, the text in question is part of the Rationale rather than in the Recommendation and is meant to provide context to the Recommendation. On account of these points, the ALAC Team is in favour of retaining the text.” * ALAC is open to further discussing “consistent user experience” and the potential for guardrails. Action Item 3: Leadership Team to further consider resolving concerns with Recommendation 2.6. EPDP Team will return to this item. Prep for joint meeting with ccPDP4 (45 mins) * Tuesday, 26 July 2022 from 14:00-15:30 UTC * Goal: Fulfill board request that the two groups keep each other informed about progress so that the solutions will be consistent. * Variant SubGroup is wrapping up their work to present to the full ccPDP4. It is helpful for them to understand any inconsistencies with EPDP Team draft outputs. * Suggestion: Is it possible to list areas which are similar to one another and focus the discussion around those areas? * Speakers from EPDP: Donna and Justine. Proposed speakers for ccPDP4: Anil and Dennis. * Slide 6 – General Comparison – ccPDP4 and IDN-EPDP * Slide 7 – RZ-LGR Utilization: Consistent Recommendations * Slide 8 – RZ-LGR Utilization: Potential Difference * Slide 9 – RZ-LGR Utilization: Additional Recommendations * Slide 10 – Same Entity at the Top-Level: Consistent Recommendations * Slide 11 – Same Entity at the Top-Level: Potential Difference * Slide 12 – Same Entity at the Top-Level: Additional Recommendations * Main focus of the conversation is areas where we appear to have inconsistencies between the two groups. * Suggestion: additional possible topics for discussion: EBERO, process for the situation in which applicant is denied a variant. Action Item 4: GNSO Policy Staff to work with Bart to see if it is possible to weave additional suggested topics into the deck.