Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

The call for the IDNs EPDP team will take place on Thursday, 12 January 2023 at 13:00 UTC for 120 minutes.

For other places see: https://tinyurl.com/42bk5fek

Info

PROPOSED AGENDA


  1. Roll Call and SOI Updates (2 mins)
  2. Welcome and Chair Updates (5 min)
  3. Deliberate on Charter Question E4 (40 mins)
  4. Deliberate on Charter Question E3a  (40 mins)
  5. AOB (3 mins)

BACKGROUND DOCUMENTS


SLIDES


Tip
titlePARTICIPATION

Attendance

Apologies: none


Info
titleRECORDINGS

Audio Recording

Zoom Recording (including audio, visual, rough transcript and chat)

GNSO transcripts are located on the GNSO Calendar



Note

Notes/ Action Items


Notes and Action Items - IDNs EPDP Call – 12 January 2023


Action Items


Action Item 1: Leadership team to develop draft language and recommendations in response to Charter Questions E3a and E4 based on EPDP Team discussion on today’s call.


Notes


Notes – IDN EPDP – 12 January 2023


Welcome and Chair Updates

  • The expectation is that we will run to two hours today as noted in the agenda. We also expect to use the full two hours for meetings going forward.
  • Extended calls will help to keep the EPDP on track for upcoming milestones.
  • Today we will test the consequences of the hybrid model.

 

Deliberate on Charter Question E4

  • Slide 4 – Charter Question E4 and Background
    • e4) The WG and the SubPro IRT to coordinate to ensure consistency in the implementation of the string contention resolution mechanism for variant label applications of existing and future new gTLDs.
  • Slide 5 – String Contention Flow Diagram
  • Slide 6 – Questions for Consideration
    • Q1: Should a recommendation be developed to explicitly specify that two applied-for strings that are each other’s variant according to the RZ-LGR must be placed in a contention set? (e.g., applicant A applies for 滙豐, and applicant B applies for 汇丰)
    • Q2: In the contention set, if one of the labels is already allocated, should the contention be resolved in favor of the entity that possesses the already-allocated label?
    • Q3: Should the entire variant label set (including all allocatable and blocked variants) be processed in the contention set, as opposed to the only applied-for strings?
  • Comment: If a string is outright a variant of another, it has to be considered a contention set based on the RZ-LGR.
  • Comment: Agreement regarding Q1 that two or more entities can’t have “rights” over the same variant set.
  • Clarification: Q1 is included for completeness -- should the AGB explicitly state that two applied-for strings that are each other’s variant according to the RZ-LGR must be placed in a contention set? It seems that the answer is yes to ensure that there is clarity in the implementation phase.
  • Clarification regarding question 2: We may see existing IDN gTLD operators applying for their variants. Do they have existing gTLD status that we can apply to the variants as well?
  • Comment: Due to the same entity principle it can’t be allocated to the other entity.
  • Comment: If those labels are on “withheld to same entity” status they are ineligible for allocation to another entity.
  • Question: Strings can go into contention because they are variants of each other or because they are similar to each other. In a contention set, if one of the strings is a variant of an already delegated TLD, what is the source of the contention in Q2?
  • Clarification: When the hybrid model was proposed, the assumption was that the entire variant set is used, including some variants that may not be applied for. If applicant A applies for string A, and existing RO B applies for variant of B called B variant, and A and B variant are confusingly similar, should we assume that A is rejected?
  • These questions identifies places where there could be some confusion in the process. When we are developing recommendations, we want to make sure we are clear about the implications of the recommendations to ensure consistency in implementation.
  • Comment: Q2 and Q3 appear to be related. If we say that the answer to Q2 is yes, then it makes sense that the answer to Q3 is also yes, so that in the future, there is predictability.
  • Summary: Some agreement expressed that a label that is confusingly similar to an existing gTLD or any of the existing gTLD’s variant labels cannot be delegated.


Deliberate on Charter Question E3a

  • Slide 8 – Charter Question E3a and Context
    • e3a)After a requested variant string is rejected as a result of a string similarity review, should the other variant strings in the same variant set remain allocatable? Should individual labels be allowed to have different outcomes/actions (e.g., some labels be blocked and some be allowed to continue with an application process)?
  • Slide 9 -- When the Variant Set is Considered in String Similarity Review. . . If one label in the variant set is found confusingly similar, what should be the consequence for that label and the other labels in the variant set? (Variant Set = Primary String + All Allocatable Variants + All Blocked Variants
    • Thought 1: The variant set should be treated as one unit and all labels in the set should face the same consequence of String Similarity Review 
    • Thought 2: The labels in the variant set should be treated as individual labels and could face different consequences
  • Comment: Variants are individual, independent labels only in the technical sense. For language communities, they are identical.
  • Clarification: We don’t know how the string similarity review will be conducted, but we do know that the work will be conducted manually by a panel. If the string similarity review is done on a string by string basis, there may be an outcome that a blocked variant of one string is confusingly similar to the allocatable variant of another string. Does that warrant putting the two applications into a contention set? Should this be different compared to a situation where the primary string(s) are the ones that are confusingly similar? Should there be an opportunity to assess the level of risk associated with the two strings that are confusingly similar?
  • Comment: In the processing of the string similarity review, we should err to the conservative side in the policy, which is Thought 1. If there is an appeal, Thought 2 would be tested in the appeals process. These are corner cases. In corner cases, the appeals process could kick in and offer a more nuanced review. The objections process can have a similar role of providing a more nuanced second look. It is not for the policy to select between Thought 1 and Thought 2.
  • Comment: If there is a possibility of an appeal, this could be something the EPDP Team could provide implementation guidance on.
  • Comment: It would be helpful for the panel to be able to make determinations on a case by case basis based on risk.
  • Slide 10 – Example Strings
  • Slide 11 -- If Thought 1 is supported…Consequence of Scenario 1
    • An applied-for string or its variant label is found confusingly similar to an existing TLD or its variant label  the entire set of the applied-for string cannot proceed in the application process.
  • Comment: This model may go too far. There should be a mechanism, perhaps an appeal mechanism, in case there actually isn’t confusing similarity.
  • Response: The same entity principle creates a right for existing TLD operators, and this diagram tries to show the consequences. Thought 1 is the default but that it is possible to reverse this if they are successful in the challenge.
  • Comment: Perhaps the applicant can still apply for these strings but use the challenge/appeal mechanism if they feel that a review of the decision is appropriate. 
  • Comment: We are talking about the different mechanisms that can determine whether two strings are similar. It might be productive to isolate the conversation to focus on the consequences if two strings are found to be similar.  
  • Summary: The default consequence is that the set is eligible to proceed (Thought 1), but that there are opportunities to challenge, which could be acknowledged in the rationale.
  • Slide 16 -- If Thought 1 is supported…Consequence of Scenario 2
    • Scenario 2: An applied-for string or its variant label is found confusingly similar to another applied-for string or its variant label The entire sets of the applied-for strings end up in a contention set. The prevailing applicant can proceed to the next stage of the application process and the non-prevailing applicant is ineligible to proceed. This means that the entire set of the non-prevailing applicant is ineligible to proceed.
  • Comment: Before the contention resolution, there should be a challenge/objection allowed.
  • Comment: In this scenario, at least one set (1 or 3) should be delegated. We should define a clear set of rules for contention so that there is no further litigation from the party that loses contention.
  • Summary: The group appears to be converging on thought 1 for these scenarios, as default. Challenge/appeals mechanisms can be noted, but recommendations are already included in SubPro.
  • Comment: We may need to develop implementation guidance on the appeal as it applies to variants.
  • Comment: The text on thought 2 could potentially be leveraged for implementation guidance on the review panel. The panel may take a legal or technical position based on the approach, which may be beyond what this group should provide guidance on.


Return to Charter Question E4

  • Q3: Should the entire variant label set (including all allocatable and blocked variants) be processed in the contention set, as opposed to the only applied-for strings?
  • Based on the above discussion, it appears that the answer is yes.
  • Q2: In the contention set, if one of the labels is already allocated, should the contention be resolved in favor of the entity that possesses the already-allocated label?
  • Based on the discussion, it appears that the answer is yes here, as well.


Action Item 1: Leadership team to develop draft language and recommendations in response to Charter Questions E3a and E4 based on EPDP Team discussion on today’s call.


Additional Question for Discussion

  • Question: If the same applicant applies for two different labels and they are considered similar to each other, would the two labels from the same applicant go into a contention set? If yes, how would the contention be resolved?
  • Comment: In the 2012 round, an applicant applied for two strings that they knew would possibility be considered similar. The applicant, based on the outcome of the evaluation process, decided to drop one and keep the other.
  • Comment: The AGB should explain what the consequence should be, but if the applicant makes that decision that is their choice.
  • Response: There is a possibility where the applicant actually wants to use both strings.
  • Comment: The applicant could object to the decision creating the contention set or make a choice themselves with which string they want to proceed.
  • Comment: If there is a technical issue, both strings should not be allowed. If it’s a legal issue, there should be an opportunity to challenge. This is a concept not specific to IDNs.
  • Summary: If the question is not specific to IDNs, it may not be subject to recommendations from this group.