Dear all, Please find below the notes and action items from today’s meeting on Thursday, 30 June 2022 at 13:30 UTC. Kind regards, Ariel, Steve, and Emily Action Items: Action Item 1: Staff to develop graphics to demonstrate scenarios for C1. Notes – IDNs EPDP Call – 30 June 2022 Welcome & Chair Updates * Survey was sent out to Chinese and Arabic TLD ROs to get a sense of their interest in activating variants. For Chinese TLDs, 23 responses were received. For Arabic TLDs, 2 responses were received. * It was noted that there might have been some confusion among ROs about the purpose of the survey because it was sent by GDS. * Leadership team will process survey results and bring back to the group for consideration. * Reminder to read draft responses to charter questions and recommendations out for review: Deadline 8 July. Review Charter Questions a7 and a10 * The Team will do a second reading of revised language for a7 and a10 and tidy up the language where needed: https://docs.google.com/document/d/1Bt0LT45UaLynFNverh1nJhyvq6q6NxgSFAOnOp2LG44/edit<Welcome%20&%20Chair%20Updates%20%20%20•Communication%20was%20sent%20out%20to%20Chinese%20and%20Arabic%20TLD%20ROs%20to%20get%20a%20sense%20of%20their%20interest%20in%20activating%20variants.%20For%20Chinese%20TLDs,%2023%20responses%20were%20received.%20For%20Arabic%20TLDs,%202%20responses%20were%20received.%20%20%20•It%20was%20noted%20that%20there%20might%20have%20been%20some%20confusion%20among%20ROs%20about%20the%20survey%20because%20it%20was%20sent%20by%20GDS.%20%20%20•Leadership%20team%20will%20process%20survey%20results%20and%20bring%20back%20to%20the%20group%20for%20consideration.%20%20•Reminder%20to%20read%20draft%20text%20out%20for%20review:%20Deadline%208%20July.%20%20%20%20Review%20Charter%20Questions%20a7%20and%20a10%20%20•The%20Team%20will%20do%20a%20second%20reading%20of%20revised%20language%20for%20a7%20and%20a10%20and%20tidy%20up%20the%20language%20where%20needed:%20https:/docs.google.com/document/d/1Bt0LT45UaLynFNverh1nJhyvq6q6NxgSFAOnOp2LG44/edit%20%20•Agreement%20that%20the%20first%20sentence%20of%20Recommendation%201.11%20should%20read:%20“Single%20character%20gTLDs%20may%20only%20be%20allowed%20for%20limited%20scripts%20and%20languages%20where%20a%20character%20is%20an%20ideograph.”%20(“script”%20and%20“language”%20are%20pluralized)%20%20•Additional%20transitions%20added%20to%201.13%20that%20were%20missing%20in%20the%20original%20text%20to%20improve%20accuracy%20of%20the%20language%20–%20transition#2%20from%20“withheld-same-entity”%20to%20“blocked”%20covers%20cases%20where%20the%20RZ-LGR%20is%20not%20fully%20backwards%20compatible;%20transition> * Agreement that the first sentence of Recommendation 1.11 should read: “Single character gTLDs may only be allowed for limited scripts and languages where a character is an ideograph.” (“script” and “language” are to be pluralized) * Additional transitions added to 1.13 that were missing in the original text to improve accuracy of the language – transition #2 from “withheld-same-entity” to “blocked” covers cases where the RZ-LGR is not fully backwards compatible; transition #5 from “allocated” to “withheld-same-entity”covers intentional retirement or removal of TLD from the root zone. If a gTLD is terminated the same RO can re-apply. If it’s a brand, the RO has to wait two years to re-apply. * Text from the graphic originating in the staff paper has been moved to rationale. Rationale also now includes description of the two newly added transitions. * Text added to the rationale explaining why the EPDP Team disagrees with the explanatory remarks in the Staff Paper that the transition from “rejected” to “withheld-same-entity” is automatic. * Support expressed for the revised language. Charter Question C1 * Dennis Tan has suggested that questions C1 and C2 are considered in tandem. Explanation: The charter drafting team wanted to acknowledge the structure of the Staff Paper. The intention was to look at this in a vacuum and break the conversation down piecemeal – first, look at what the same entity principle means, then define what the same entity is. Second level variants exist today and the same entity principle is applied to those as a concept. C1 speaks to just the definition of the concept, C2 goes into what that means in practice, including for existing gTLD operators. It would be beneficial to look at the same entity principle means as a registrant (C2), holistically with C1, because there are real-world implications. In the existing Registry Agreement the same entity is the sponsoring registrar as opposed to the registrant. * Summary: C2 assumes that the registrant is the “same entity”, but in C1, there is no definition of same entity. The current situation at the second level is that the same entity is not the registrant. * Review of charter question C2 – Slide 10 * Context: Definition of “Same Entity” at Second-Level – Slide 11 * Clarification of staff paper recommendation 3: “. . . or else withheld for possible allocation only to that entity.” The concept in the staff paper was that the registrant is the same entity. * Charter question C1 – Slide 4 * Comment: definition of “same entity” should be defined further. * Context for Scenario 1 & Discussion – Slide 5 * Discussion question: should a future second-level label under any allocatable variant label of an existing TLD (i.e., Chinese or Arabic gTLD) be only allocated to the same entity, or else withheld for possible allocation only to that same entity? * Example: sld.variantTLD1 and sld.variantTLD2 are two distinct DNS records, each one in its respective zones. Should they have the same registrant? * Question: What is the downside of it not being the same entity? * Response: Variant labels are by definition considered the same by the users from various points of view, for example they may be visually identical (but different code points). If they are registered to different registrants, a user may think they are going to one website but they are going to a different website (misconnection). If the same entity principle is followed, you don’t have the risk of misconnection, so the security concern is addressed. * Question: Can we define same entity as the same registrant and same registry, but the registrar can be different? * Response: This becomes tricky in the implementation if there is not a connection that requires the same registrar. * Comment: We need to be mindful of relationships. The registry has a relationship with the registrar. The registrar has a relationship with the registrant or the registrar may have a relationship with the reseller who has a relationship with the registrant. The way the data flows upstream currently needs to be taken into account. If/when information flows from the registrant to the registry, this is limited. It is difficult to picture how a registry would manage this situation without having the registrar in the middle. * Additional comment: During the course of a domain registration, the registrant can change its registrar. The registrar is changeable. The registry and the registrant are the key players. * Comment: In response to question about whether a registry could check that it is same registrant. Technically this is possible because it is possible to have shared contact/registrant handle between registrars. But allowing different registrars would likely be complex to manage. * Comment: While technically feasible, it is very impractical to operate and scale. * Comment: If the registrant changes the registrar, it can do so for the variant labels, as well. * Comment: Once you have a variant set “package”, the set must move together. If this principle is followed, there is not a way to separate into different registrars. * Comment: When the variant TLD is activated, the registrant should activate the variant at the same registrar as the primary. * Summary: Support for the same entity being the registrant. Question: How do we put this into policy? Can we put a requirement on the registrant that if they register a name at the second level that they use the same registrar when they want more than one label in a “package”? * Comment: We need to keep in mind why we are doing this PDP. We want more IDNs. As we issue recommendations about how the relationships need to be implemented, what will be required of registries and registrars, and how it will be enforced, we need to think about the technical complexity and make it implementable for the contracted parties. * Comment: Currently there is no technical standard solutions for making two TLDs operate in the same way. At the end of the day, if no contracted parties are willing to do the work, there will be no supply. If there is no supply, there will be no demand. Action Item 1: Staff to develop graphics to demonstrate scenarios for C1.