[Gnso-epdp-idn-team] Notes and action items - IDNs EPDP Meeting #31 - 14 April 2022

[Emily Barabas]

Dear all,

Please find below the notes and action items from today’s meeting on Thursday, 14 April 2022 at 11:30 UTC.

Kind regards,

Ariel, Steve, and Emily



Action Items:

Action Item 1: Staff to proceed with next steps on distributing questions to ROs that have new gTLDs in Chinese and Arabic scripts.

Notes – IDNs EPDP Call – 14 April 2022

Welcome & Chair Updates

  *   Staff sent to the mailing list the draft questions for ROs that have new gTLDs in Chinese and Arabic scripts to understand interest in allocatable variant labels. Leadership teams seeks confirmation that staff can proceed with next steps, absent additional feedback or questions on this call.
  *   No additional comments. Support expressed for sending the questions.

Action Item 1: Staff to proceed with next steps on distributing questions to ROs that have new gTLDs in Chinese and Arabic scripts.

  *   The leadership team will let EPDP know when the survey is going out, the platform used, and who will be receiving the communication so that members can assist with encouraging ROs to respond.

Continued Discussion of Charter Question E1, E3, and E3a (new gTLD aspects only)

  *   Slide 4 – Review of charter questions E3, E1 (Part 1), and E3A
  *   Slide 5 – Comparison matrix – explanatory notes
  *   Slide 6 – Comparison matrix – Level 1
  *   Comment: The cons listed on slide 6 may not be cons, but rather factors to consider. An RO has no automatic rights to string. It only has rights to the string that is requested and delegated. It should be acceptable if an applicant doesn’t request an allocatable string and then they are later denied an application because the string they want is at that point in time confusingly similar to another string that has been delegated.
  *   Comment: An additional pro for Level 1 is that some variant labels will never be applied for. If a string that will never be applied for it shouldn’t be taken into account in the string similarity review and potentially found to be confusingly similar to another string.
  *   Comment: A potential con depends on how allocatable variants can be activated. If activation of variant is possible between rounds, a con would be that the string similarity review would have to be done at any point in time. If the RO says they want to activate an allocatable variant, and it can only be activated in the round, the string similarity review will already be part of the process so there is no con in that case.
  *   Question: Is distribution of TLDs purely first come first serve? It might not be so simple when there are multiple rounds if there is overlap in timing of evaluation processes. Are there specific rules that apply across rounds that govern how activation of variants by different ROs is prioritized? This needs to be considered.
  *   Slide 7 – Comparison matrix – Level 2
  *   Clarification of con regarding “7 scripts” on slide 7: Not all scripts in the RZ-LRG have allocatable variant labels. There are 7 that do. What is important in the string similarity review is visually confusability, not the language/script of the string. If we have 7 scripts with allocatable variants, the pool of strings to evaluate is bigger compared to Level 1.
  *   Comment: When someone applies for a string, they are applying for a license for that string and nothing else. When they get a TLD, they don’t have any rights to the variants of that string. To set a policy that gives a right of first refusal to an existing RO to any variants goes against the notion that the RO doesn’t have ownership rights of those strings. If we go down the path of Level 2 or 3, we might be going against the notion in the base agreement.
  *   Response: We are not suggesting giving IP rights to the applicant. In 2012 round the self-identified variants were incorporated in the string similarity review process. However, the applicant did not have any IP right over those strings.
  *   Comment: By reviewing the strings that have not been requested, you are essentially reserving the right for that RO for the string should they ever want it. You are essentially saying that RO has that right over anyone else who applies for a string that might be confusingly similar.
  *   Response: An applicant is not and RO bound to the registry agreement or the clause being referred to above: “Ownership Rights.  Nothing contained in this Agreement shall be construed as (a) establishing or granting to Registry Operator any property ownership rights or interests of Registry Operator  in the TLD or the letters, words, symbols or other characters making up the TLD string, or (b) affecting any existing intellectual property or ownership rights of Registry Operator.”
  *   Comment: Returning to the question of priority for strings if it is possible to request activation of variants at any time -- do edge cases warrant making the process more complex? This balance is more important than the pure concept of rights.
  *   Response: The previous comment makes an assumption that the policy will allow the RO to request activation of a variant between rounds. The EPDP Team has not agreed on that. If it’s the policy that you can only activate variants during rounds, SubPro addresses how prioritization of applications where there may be overlapping rounds.
  *   Slide 8 -- Comparison matrix – Level 3
  *   Question: Given that we have access to AI and other technology, would it be possible to automate some or all of this process?
  *   Response: This may be a question for implementation. What is the benefit of automation and what problem would it solve?
  *   Clarification: The maximally conservative approach is the safest but might be too much. If there is some automation, the time and expense could be reduced while still having a complete process.
  *   Response: There was a tool used previously, but it did not perform adequately. Similarity is considered at the perception layer and therefore is not easily done in an automated fashion.
  *   Comment: It may be hard to apply standard thinking about gTLD rights with an IDN TLD that has variants with different statuses. What is the most efficient and effective process to address the unique case of a IDN and its variants?
  *   Comment: When a string is formally requested there is a need to notify the community, provide an opportunity for objections, and complete related processes. SubPro did not favor requesting applications on a rolling basis because it is difficult to make this predictable. If you make this possible, you are going against the principle of predictability that SubPro spent a lot of time working on.
  *   Comment: It would be more predictable if we go with level 3, both for the previous round and subsequent rounds. At every activation point, you would have to depend on what is happening at that time, the predictability would be lower for applicants. It is more predictable to evaluate all variants upfront.
  *   Response: its predictable to give a right of first refusal on every variant to the existing registry operator, but that goes against many other principles.
  *   Question: For level 3, does the applicant have the choice of which variants it applies to activate?
  *   Response: It is not an obligation to apply for all of the variants in the set. It would be discretionary on the applicant.
  *   Question: What is the specific question we are trying to answer with respect to taking blocked strings into consideration?
  *   Response: The scenario we are taking into consideration is one where someone potentially gets a label that is similar to a blocked label.
  *   Comment: We would have to know why it’s blocked to figure out how to address it.
  *   Response: Reserved and blocked are two different items. IGO/INGO are reserved. Blocked means that they are labels that are blocked through the RZ-LGR against a label that is delegated, allocated, or reserved.
  *   Question: Why would the panel choose to block a particular string? Would that same rationale apply to a variant of a blocked string?
  *   Response: There are multiple motivations for blocking a string. The main motivation was that the RZ-LGR procedures suggested that allocatable variants should be minimized and blocked variants should be maximized. The panel may look at it from a usability perspective. If there are two characters that are nearly visually identical and there is no usability argument, then they would make it a blocked variant. If there is a usability argument, they would make it an allocatable variable.
  *   Question: Wouldn’t it depend on the exact reason it was blocked to determine rules regarding confusingly similarity?
  *   Comment: If there is not harm to moving forward except that a string is confusingly similar to a blocked string, it doesn’t make sense for there to be a general rule that they can never move forward.
  *   Slide 9 – Comparison Matrix – Consolidated View
  *   Diversity of views expressed about whether Level 1, Level 2, and Level 3 is most appropriate.
  *   Suggestion regarding activation of labels between rounds: What if there was a rule that if an applicant is applying for an IDN TLD, they know what the variant set looks like and they decide what they want to apply for? There is one opportunity to apply for the primary and the variant set you are interested in applying for. If they are still available in the future, there is still an opportunity. Does this simplify the question to answer?
  *   Discussion about whether Level 1 or Level 3 is more consistent with the SSAC conservative principle. From one perspective, Level 3 is a broader evaluation and therefore more conservative. From another perspective, Level 3 creates rights to a wider range of variants, and therefore Level 1 is more conservative because it treats the pool of variants in a more limited way.
  *   The leadership team will propose a path forward on this question. This may be an item where members need to go back to their groups for input.

AOB

  *   Reminder: Respond to poll about your participation in ICANN74. Poll is scheduled to close tomorrow (15 April).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20220414/76ac5394/attachment-0001.html>