Dear all, With apologies for the delay, please find below the notes from today’s meeting on Thursday, 13 January 2022 at 13:30 UTC. Kind regards, Ariel, Steve, and Emily Action Items: Action Item #1: EPDP Team members to provide input on draft text in response to charter question A6 and open items. Notes – IDNs EPDP Call – 13 January 2022 Welcome & Chair Updates * Staff shared draft text for a response to charter question a6. The leadership team has identified a number of questions for the EPDP team in the document. EPDP Team members are encouraged to review and provide feedback. These items will be discussed further on the 20 January call. * If there are any questions in the interim, please share them on the mailing list. Action Item #1: EPDP Team members to provide input on draft text in response to charter question A6 and open items. Engagement session with SSAC members to discuss SSAC's early input and additional Q&A General comments from SSAC members: * There is nothing technically in the DNS protocol or other technical protocols (e.g. SMTP for mail, X509 used in TLS) that indicates relationships between two strings that are called variants. Once in use, there is no difference between a variant and another domain name. They are two domain names. It is important to think about the implications of this and how it may be abused. * There might be cases where two strings are confusable. For confusability reasons, they can’t be given to two different registries. But there may be a business arrangement where they might be delegated to the same registry. * Clarification on the use of the term “confusable”: It might be the case that there are different rules if applications for two strings come from the same applicant or two different applicants. The term variant is one that is used between applicants and those that evaluate applications. Once delegated, there are only domain names. * Question: Have you had discussions about whether there needs to be a central index of strings that are variants in IANA? * Response: There have not been discussion of this issue. Each registry that handles variants keeps its own records. * This group needs to talk about how IDN variants are delegated first and then will talk about how this is tracked, for example in IANA. Question regarding responses to A1 & A4: * When looking at different characters and code points that can be allowed, we need to separate code points that are allowed in a zone as a whole vs. code points that are allowed in a label together. Sub domains to the domain may also have specific rules. * The SSAC recommends that the root zone must use one and only one set of rules for the Root LGR procedure for validation of TLD labels and their variants. * Clarification of the question: The comment on A4 seemed to imply that if the string was IDNA valid, it should be allowed. * Clarification: The RZ-LGR should be an absolute quantifier or rule set for what should be allowed in the root zone. If an existing TLD applies for a variant TLD label whose script is not yet supported by the applicable version of the RZ-LGR, then the best way is to put the application on hold, the community to work together to produce a LGR for that script and integrate into the LGR. Question regarding responses to A2: * SSAC members point to ccTLDs specifically because there may be a mix of policies with ccTLDs and gTLDs, so it is important to look at synchronized TLDs to ensure continuity of policies. Yes, the word variant in ccTLDs is wrong, the right term is “synchronized TLDs” * If such a situation mentioned in A2 did happen, the applicant can request a review on the LGR to see if LGR needs to be updated. It is important not to make ad hoc exceptions that could potentially undermine the LGR. * The existence of LGR not only set a boundary on the strings an applicant can apply for, it also creates a predictive environment for the users of domain names, in services, applications, user interfaces and ultimately the users that use these applications and services. ALAC question 1 regarding responses to A5 & C2: * Don’t blanket delegate all variants because you can. Look at the bundled experience you want users to have and only delegate the ones you need. The larger the set, the harder it is to keep everything synchronized. * Question: If the Registry is interested in applying for many variants, is there any reason that they should be prevented from doing so from the perspective of technical risks? * Response: This is too hypothetical to answer from the SSAC perspective. There is no ability to separate between two variants and two domain names from a technical perspective. The SSAC approaches the issue from this perspective. * Response: In a particular language community, the concept of variants is important. The SSAC is saying that it is hard to make that work, because there is no technical way to set this up. If you are going to make it work the way that a language community expects, there needs to be a lot of work done to make it work. If you are going to make it work, it is a lot easier to limit the number of variants in a bundle. From a security and stability standpoint, you can have as many as you want, as long as you keep them synchronized and do the work to do that. * As an example, if you have a language community with two very important variants, SSAC doesn’t see a problem for the community having a policy for allowing the applicant to have two labels for the price of one. But after the business transaction, the entity has two domain names. There is no technical solution to keep those variants together. * We already have examples in ccTLDs where they implement policies where variants don’t point to the same website. SSAC doesn’t have a problem with that from a technical point of view. This concerns business and policy. ALAC question 2 regarding responses to A5 & C2: * This follows from the suggestion to only instantiate variants that your language community needs. The SSAC recommends that the language communities are in a better position than SSAC to make decisions about criteria for limits. In making that decision, the people involved should keep in mind that every time they add to the bundle, they add to the challenge of managing the bundle. * Question: No one really speaks for a language community authoritatively, so how can this be implemented? Possible alternative – criteria for a registry to demonstrate in the application process that it is in a position to effectively manage the variants it is requesting. * Response: There may be different elements of this evaluation depending on what is being proposed in terms of variants. * Question: Was some of this thinking done with ccTLDs in mind? The ccTLD Fast Track process was relatively fast moving compared to the gTLD process. Was there any thinking in the SSAC discussion about the differences? * Response: I don’t believe the differences were discussed. * From an application evaluation standpoint, how can one determine whether an applicant is capable of making a set of variants work? There are not technical tools to make that work. This is a problem for the EPDP to solve. * Question: Could the SSAC help in thinking about the things that need to be synchronized to make variants work? This would help formulate a list of things for an evaluator to consider? * Answer: It’s not possible to make a complete list because we don’t know how the domains will be used. * Answer: It’s possible to provide illustrative examples, but would be concerning if those examples were converted into definitive criteria. Jeff’s questions regarding A5: * Apply a very tight limit at the start to ensure that you have a conservative start. As operators gain experience, you may decide to make the rules more permissive. · Start with the question: Is one label sufficient? If not, are two sufficient? If not, which candidate variants are uniquely differentiated from the primary label, widely used in the community? · For example, the Chinese community allows for three variant labels, one which has been applied-for, one which is the Simplified Chinese version and one which is the Traditional Chinese version. A similar limit may be imposed in the beginning to ensure conservatism, and which may be relaxed over time, as the community gains experience with IDN variant TLD delegation and associated usability and manageability challenges. * There could be cases where more variants than are necessary may be applied for because of economic value, but there is concern that hundred or tens of variants for a label may create technical and management challenges for the parties involved. * Question: How do you apply the proposed questions above in practice? An applicant for variants will always argue that they are necessary. How can you evaluate what is or is not necessary? * Response: The SSAC advises a conservative approach initially rather than a self-regulatory system. The SSAC is not assuming that actors or good or bad. The SSAC is interested in reducing the risk of a combinatory explosion. * It is for policy work to define synchronization and determine how synchronization can be achieved. * This combinatorial explosion creates a stability issue at both registrars and registries, and will likely complicate account management and user experience for registrants. Questions regarding B3 and C4a: * We call them variants, but in fact they are different domain names. Whatever you do to make them the same in practice is entirely up to the registrant. Any policy you make is going to be something you cannot do mechanically. You can make rules, but they need to be phrased in a way that is not technical. * In practice the implementation of variants has been poor. If we are going to make a good user experience better, we need to make sure that that measures are in place to implement them more effectively. Example: .cat d-names. * Issues can come up anywhere you have to compare two versions of a name. It’s not just an issue of DNS lookups. Additional questions: * Question: Most registries now just activate one name and block the variants? * Response: Correct, most follow this model. * Question: Is there a technical barrier to having a policy that allows a registrant to switch which is the primary and which is the variant at the second level. * Response: The cause for concern is if the variant is going to a different registrant, but there is otherwise not a technical concern.