[Gnso-epdp-idn-team] Notes and action items - IDNs EPDP Meeting #46 - 4 August 2022

[Emily Barabas]

Dear all,

Please find below the notes and action items from today’s meeting on Thursday, 4 August 2022 at 13:30 UTC.

Kind regards,

Ariel, Steve, and Emily



Notes and Action Items - IDNs EPDP Call – 4 August 2022

Action Item

Action Item 1: EPDP Team members to review slides 15-18 of today’s deck. The Team will return to the topic of strings ineligible for delegation on the next call.
Notes


Welcome & Chair Updates

  *   GDS Team will be working to actively help the EPDP think about implementation considerations for the EPDP Team’s draft recommendations.
  *   Michael Karakash from GDS has been joining the EPDP Team calls since the beginning of our work and will facilitate this process.
  *   The goal is to create a formal, transparent process to help ensure that there aren’t unnecessary delays in implementation. GDS and other parts of org will conduct an analysis regarding potential implementation elements while the EPDP work is being completed.
  *   Michael will coordinate with other org teams to get early feedback on recommendations once the EPDP Team considers them to be stable.
  *   Leadership team considers this a positive step. Early org engagement can enhance Board’s consideration and reduce the challenges associated with IRT work.
  *   GDS is also conducting the ODP on SubPro and may have relevant insights to share as the EPDP Team continues its work.
  *   Edmon, speaking from the Board perspective, is glad to see this work and coordination taking place.



Glossary Items

  *   An issue was raised on the mailing list about the language we are using, and specifically the EPDP Team’s use of the term “primary” label. If we keep that terminology or related terminology in our work and our recommendations, we need to be clear about the implications and be consistent.
  *   Leadership team believes that it would be helpful for the team to have a glossary.
  *   Initially the leadership team suggests focusing on the terms “primary” and “set”. Are we using the term “set” different in different contexts?
  *   Slide 4 – Purpose of Glossary List
  *   Slide 5 – Existing Sources for Glossary List
  *   Slide 6 – Relevant Glossary from Integrated Issues Report
  *   Slide 7 – Relevant Glossary from IDN Implementation Guidelines v4.0
  *   Slide 8 – Relevant Glossary from Staff Paper
  *   Slide 9-10 – Relevant Glossary in ccPDP4 – focus is on label states
  *   Slide 11 – Overlapping Terms
  *   Slide 12 – Non-Overlapping Terms
  *   Slide 13 – Issue for Discussion
     *   Focus: definitions of Primary, Primary IDN gTLD, Set, Variant Set, Variant Label Set
     *   Question: what does it mean when we talk about a primary IDN gTLD when someone submits an application? Are members comfortable with using that term in our discussions and in our draft language?
     *   Comment: At the technical level, all strings are independent. The origin of “primary” is linguistic and proposed by linguistic communities. It is not technical. From the language community perspective, the term serves a purpose. If variants are not allowed, the string that is being applied for is the primary. If variants are allowed, it is somewhat more complex.
     *   Comment: When a string is applied for, the language community would determine, which strings will be considered variants by way of the RZ-LGR. Primary label is largely the choice of the applicant based on their business model. Given a primary string, the RZ-LGR (as developed through the language community) determines which other strings need to be tied up with the string in a variant relationship as well as the disposition values.
     *   Comment: In some cases, some of definitions may depend on other definitions. For example, you need to define “label” before you can define “primary” and “variant” labels. It may help to start with the most foundational definitions first.
     *   Question: Is primary label the same as primary IDN gTLD?
     *   Response: Yes, in the context of gTLDs.
     *   Comment: In the discussion of IDN implementation guidelines, there was a suggestion not to use the term variant in isolation, because there can be variants at the code point level or at the label level. Therefore, the term by itself can be ambiguous.
     *   Question: From the technical perspective, there is no primary label. All labels in a set are variants of one another. What is the benefit of calling something primary?
     *   Response: We have come to understand the primary as the source label. For the application process, you need to have a source label. The question is whether we carry that through in our recommendations. If so, we need to explain why we use it.
     *   Response: The reason for identifying a primary is about how the variant is defined. If a person applies for a label A, and label B is an allocatable variant, B can be obtained later. It is possible that if B is applied for first, the applicant may not be allowed to get A. The dispositions are not symmetrical, which impacts the value of variant labels.
     *   Comment: If one label is a variant of another, they should be considered equal. It doesn’t matter which one is applied for. You shouldn’t give one more value to another. Suggestion to use “applied-for label.” After the application phase, there is no difference between the delegated strings.
     *   Comment: Whether we use primary or applied for, the results are similar. However, there is a difference between the string that is applied for and the others in the set. The applied for string is used to calculate the disposition values of the variants using the RZ-LGR.
     *   Comment: Some designation is necessary for the initially applied for label.
     *   Comment: There are no ties between what is included in the application and what is included in the RA. In IANA, all TLDs are equal and independent.
     *   Comment: The EPDP is primarily focused on the application process. From the application perspective, it makes sense to refer to a primary, source, or initially applied for label. Once the evaluation process is complete, the RA is signed, and the TLDs are delegated, there may not be a distinction on the technical level. The goal is to make sure that this group is using consistent terminology.
     *   Comment: The term “applied for label” would work for the application process, but it might not make sense as a term once the application process is complete, for example if additional variants are activated in future rounds. The concept is still important to capture in some form, but the terminology might need to be different.
     *   Comment: As a reminder, the EPDP has agreed that there will be a single RA for the set, meaning the applied for labels and applied for variants that successfully complete the evaluation process.
     *   Comment: It may be helpful to look at the terminology that would be appropriate at different stages of the TLD lifecycle.
     *   Response: For the charter questions, it’s clear when the question is about the application process, evaluation, delegation, and operations. So those distinctions are implicit in the structure of the questions.
     *   Leadership summary: We all seem to have the same thing in mind when we talk about the primary or source label. The term primary may elevate the importance even if that is not the intent. As we draft the Initial Report, it may be clear that a different term is better.
     *   Comment: For the application, evaluation and delegation phases, “applied for label” is appropriate. This term is no longer appropriate after delegation.



     *   Next topic – what are we talking about when we use the term set? Is there a distinction between application phase and post-application phase?
     *   Comment: The set represents a set of labels where each label has a tag associated with it. The primary/source label plus all variant labels generated through the RZ-LGR would form the set. Over time, some of the labels may change states, but they remain part of the set.
     *   Comment: “Set” might mean different things in different circumstances. For example, in an application it might mean the primary + variants that are being applied for.
     *   Comment: From one perspective, set should mean applied-for TLD plus all requested variants or, after delegation, the primary string plus all delegated variants.
     *   Comment: There can be many potential sub-sets of the larger set, for example variants labels that are blocked, allocatable, delegated, etc. We may want to identify some of these sub-sets and fix some terminology to them.
     *   Comment: If “primary” is used later in the process there needs to be a way to give a different label in the set the primary designation in case the original primary is retired.
     *   Leadership summary: It seems appropriate for the group to move towards “applied-for” in the application process instead of primary.



Strings Ineligible for Delegation

  *   Slide 15 – Charter Question E5 (Part 2): Should the strings ineligible for delegation for existing and future gTLDs be updated to include any possible variant labels?
  *   Slide 16 – Context for discussion
  *   Slide 17 – Possible Approach 1 - Keep the list of strings ineligible for delegation intact and not to update it to include variants
  *   Slide 18 – Possible Approach 2 –
     *   Keep the list of strings ineligible for delegation intact and not to update it to include variants
     *   Prevent applications for all variants of the protected strings, and link to a resource for calculating the variants
     *   Variants can only be applied for by the relevant organizations AND as part of a 'set' that includes the primary string on the list
     *   Make it clear that preventing application for variants is expressly NOT an expansion of rights for the protected strings

Action Item 1: EPDP Team members to review slides 15-18 of today’s deck. The Team will return to the topic of strings ineligible for delegation on the next call.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20220804/fddbc88a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EPDP Team Meeting #46 Slides.pdf
Type: application/pdf
Size: 824478 bytes
Desc: EPDP Team Meeting #46 Slides.pdf
URL: <https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20220804/fddbc88a/EPDPTeamMeeting46Slides-0001.pdf>