Dear all,
Please find below the notes and action items from today’s meeting on Thursday, 7 April 2022 at 13:30 UTC.
Kind regards,
Ariel, Steve, and Emily
Action Items:
Action Item 1: Leadership team to come back with ideas about how to break down the problem set.
Notes – IDNs EPDP Call – 7 April 2022
Welcome & Chair Updates (3 minutes)
* The time of next week’s call will conflict with the GNSO Council call. Usually when there is a conflict we move the call 24 hours later, but Friday next week is a holiday in some parts of the world. Suggestion is to move the meeting to Thursday 14 April at 11:30 UTC. Support expressed for this proposal.
* Work for Topic E will require the EPDP Team to make some assumptions about process because the SubPro IRT is not yet underway.
Introduction to Charter Question E3 and E1 (part 1) (new gTLD aspects only)
* Slide 4 – overview of charter questions E3 and E1 (Part 1). Reminder: The scope of discussion is limited to the future new gTLD aspect only, not to amend the structure or framework of processes established by SubPro.
* Slide 5 – Application process flow in 2012 round - provided to give context on the String Similarity Review step in the process.
* Slide 6 & 7 – Overview of the String Similarity Review in the 2012 round
* Slide 8 – Summary of Staff Paper proposal
* Comment: We have to do a matrix of the different inputs and outcomes. If we are just talking about new applications going forward, when an entity applies for a primary string, they should also indicate whether they are also interested in applying for variants at that time. They should only evaluate for strings that the applicant has indicated that they want. The review should look at if the primary string is similar to the items listed on slide 8. If the first, third or fourth bullet applies, the application is rejected. If the second, it goes into contention. If the primary string passes, the variants are evaluated. If the first, third, or fourth bullet applies, the applicant should have an opportunity to withdraw the request for the variant. If the variant would create a contention set, there should be an opportunity to withdraw or go forward with contention resolution. In the future, if the applicant would like to use a variant that it didn’t previously apply for, it needs to undergo a new string similarity analysis. If confusingly similar to other applied for TLDs, string contention should apply. Not every possible variant should be considered if the applicant doesn’t include every variant in the application. This would reduce associated costs.
* Comment: If it's a "Primary” the applicant might also be given the chance to "switch" to one of the applied for variants (if they are not blocked to string similarity)
* Slide 9 – Staff Paper proposal regarding contention sets
* Question for org: Why does the Staff Paper think that the evaluation should be all encompassing as opposed to constrained as proposed earlier in this discussion?
* Question for org: What is the probability of blocked label becoming unblocked?
* Response: It is not going to be frequent, but if a GP updates a proposal it can change a blocked label to allocatable.
* Comment: For allocatable variants, we should run it through. They are considered equivalent to the applied-for string. By not evaluating string similarity, you might have downstream issues for the users for that TLD. We also need to think about third or fourth rounds in the future. Does the entire set need to be evaluated against entire other full sets of variants, including then existing blocked variants?
* From Staff Paper: The analysis can be done at 3 levels: 1. Applied for strings (including selected variants) against other applied for and delegated strings and reserved strings 2. All applied for strings and allocatable variants get compared to other applied for strings and allocatable variants, delegated strings and reserved strings 3. Blocked variants are also compared.
* Staff paper proposes that whenever a string is applied for, it gets compared to all other strings, including allocatable and blocked variants. The intention was caution. At the time, there was very little knowledge of how variants will operate. This is an approach of maximal conservatism. If a label is blocked, the community doesn’t want it as a TLD. If a similar string is delegated, it is essentially a workaround.
* Comment: We discussed with the SSAC that when a registry wants to have a string allocated, it would need to demonstrate that it could handle that and would be evaluated on that. Applying the same logic, it doesn’t make sense to look at the full set in string similarity because the registry hasn’t requested those labels. If it later wants to apply for those allocatable variants, it could go through another string similarity review just as it would be evaluated to determine if it could handle managing those additional variants. Evaluating all possible variants is overly restrictive and conservative.
* Comment: The String Similarity evaluation should be done just before delegation. We don’t know when a blocked variant will become allocatable and then delegated.
* Comment: If we focus on reserved strings, we will still have to compare the full set because reserved string could become unreserved in the future, otherwise we would have disadvantaged someone who wanted a particular reserved string down the road.
* Comment: Understanding the conservative approach, let’s intersect that approach with discussions about fees associated with the application process. It is reasonable to think that applicants will limit themselves to a primary and perhaps one or two variants? If an allocatable and not applied-for variant is found to be in contention, what will we do with that information?
* Comment: If and when a registry wants an allocatable string to be delegated, it would need to apply for it. If by the time they decide that they want it delegated, circumstances have changed with respect to potential string contention, this will need to be taken into account in the evaluation process.
* Clarification: We have an applied for string X which is compared to an existing or another applied for string Y. X has its own allocatable and blocked variants and Y has its own allocatable and blocked variants. We are not comparing the full variant set of X and full variant set of Y. We are a just comparing X to Y and its variant set. If a variant of X is in contention it won’t block X.
* Comment: Just because someone has a TLD, it shouldn’t have a right of first refusal on every variant it has.
* Question: Most of the scripts have constraints in terms of variants, so the scope of the problem is relatively limited. Does this inform the discussion?
* Response: Each variant set for each label includes 1. The applied for string 2. Allocatable variants 3. Blocked variants. Allocatable variants could be 10s of labels. Blocked variants can be very large for not only Arabic but also scripts like Latin – thousands of labels.
* Comment: If we are speaking about two sets of strings X and Y, and one set X has strings that are variants of one another and in Y strings are variants of one another then the strings in the two sets are variants of one another.
* Comment: We are also talking about confusingly similar, which is somewhat different than being variants. Strings could be variants but not visually confusing.
* Next Steps: EPDP Team to review materials presented in this meeting and revisit this topic. Staff will consider if there is a way to organize the topic to support further discussion.
* Org comment: For the comparison, the Team needs to recommend which elements of each set are compared to which elements of the other set: [X] [Alloc-X] [Block-X] compared with [Y] [Alloc-Y] [Block-Y]
* Comment: If the community didn’t want the blocked string, shouldn’t it have also blocked the string that is confusingly similar to the blocked string. If they didn’t block it, maybe they are ok with it being delegated.
* Example: A Latin string is blocked, is it possible for someone to apply for a string that is exactly the same or similar in Cyrillic. If the string is similar to the Latin string should it be allowed through.
* Comment: If it’s confusing similar it should be blocked. If it’s a variant of something confusingly similar, but is not confusingly similar itself, it should be allowed.
* Comment: If the label is the same or almost the same as a blocked label it should have been considered a variant and have been blocked itself.
* Comment: A variant of a blocked string should only be prevented IF it is confusingly similar.
* Comment: Conservative approach could be costly, EPDP to think about how to add parameters around it to make the process easier and less costly.
Action Item 1: Leadership team to come back with ideas about how to break down the problem set.
Introduction to Charter Question E3a (new gTLD aspects only)
* Slide 11 – Overview of charter question E3a and context.
* Comment: The only thing that is rejected is the variant that is found to be confusingly similar. If the other variants are not found to be confusingly similar, they should not be rejected.
* Comment: We may treat every variant as separate and not as block for confusing similarity decision.
* Comment: We need to think through the idea of atomicity (the idea that a set is inseparable) of the variant set. If we treat an applicant set as an atomic whole, we should treat the evaluation that way. Once we try to split it up, we run into a potential issue about how we conceptualize these variants.
* Comment: Understanding where the previous comment come from, string similarity is a visual test. How can you justify rejecting a string if it’s not visually confusingly similar to another string? Where the applied for string is rejected, the other allocatable variants are still eligible unless they are also confusingly similar.
AOB
Reminders:
* Second reading is underway for A5 & A6 – please provide input on revisions by tomorrow (8 April).
* Leadership will review input and suggest next steps. We will not likely bring that back to a call for discussion.
* Provide input on proposal for outreach to CJK GPs – deadline: 8 April.
* Provide input on moving next week’s meeting Thursday 14 April at 11:30 UTC -- deadline: 8 April
