[Gnso-epdp-idn-team] Notes and action items - IDNs EPDP Meeting #55 - 20 October 2022

[Emily Barabas]

Dear all,

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

Kind regards,

Ariel, Steve, and Emily


Notes and Action Items - IDNs EPDP Call – 20 October 2022

Action Items
Action Item 1: Leadership Team to develop draft recommendation in response to Charter Question D1b based on EPDP Team discussion.
Action Item 2: Leadership Team to draft recommendation on discussion question 1.
Action Item 3: In relation to discussion of Charter Question B4, staff to investigate the consequence on the process an applicant delegating a variant ahead of a primary.


Notes

Welcome and Chair Updates


  *   Donna will join the GNSO Council meeting today to provide an update on the timeline for this EPDP and the plan to split the work into two parts. She will provide the EPDP with an update on that interaction with the Council.
  *   Request to Chinese, Japanese, and Korean Generation Panels regarding single-character labels: Leadership Team sent the request to the Generation Panels following review of the draft letter by the EPDP Team.
  *   Update on responses to Charter Questions D2 and D3: No substantive comments on the draft text were received, so this text will be considered stable for the purposes of including in the Initial Report

Charter Question D1b

  *   At ICANN75, the EPDP Team did a detailed review of the process flow diagram, which was intended to help the group understand how recommendations fit into the 2012 process flow: https://community.icann.org/download/attachments/208208408/New%20gTLD%20Application%20Process_With%20IDN%20Variants_v3.0.pdf?version=1&modificationDate=1663385299000&api=v2
  *   Slides 4-5 – Strawman Process Flow – Observations

     *   Understand which elements in the New gTLD Program will be impacted by variant implementation: The same stages/steps in the New gTLD Program are applicable to an application for an IDN gTLD variant label, just like a regular gTLD application
     *   Consider how such elements will need to be modified to accommodate variant gTLDs: Around half of the elements in the New gTLD Program will require specific consideration/modification, in accordance with the recommendations proposed by the EPDP Team, to accommodate variant gTLD applications
     *   Analyze the level of effort of evaluating variant applications and the associated cost/fees: Only 44 existing gTLDs (35 Chinese gTLDs and 9 Arabic gTLDs) have allocatable variants; Most Chinese gTLD ROs and two Arabic gTLD ROs who responded to the survey indicated interest in applying for variants; It may be expensive and impractical to develop a standalone round to accommodate these registries, given the observations related to items 1-2 above.

  *   Slide 6 - D1b: What should be the process by which an existing registry operator could apply for a variant for its existing gTLD? Based on the observations, is there a compelling reason to create a standalone round for existing Chinese and Arabic TLD registry operators to apply for variant gTLDs?
  *   Comment: From one perspective, it should be more about a standalone process as opposed to a separate round, because it is complicated from a technical perspective. This could be a way for more IDNs to be used. If you call it a separate round, it would need to before the next round or after. The idea is to have something like the Dast Track for IDNs. But ROs should also be able to apply for their variants during the next round.
  *   Response: Based on the flowchart, if an existing gTLD operator wants their variants, they are likely going to through many of the same steps that a regular applicant for a TLD would go through, so it doesn’t make sense to create a standalone process.
  *   Support expressed for the idea that the activation of variants of existing TLDs should be handled in the same round as everything else. Those monitoring the application process will know when those windows are available for comment/objection. It’s much more efficient from a cost recovery perspective to put this together along with an ordinary round. If there is a standalone process for handling a relatively small pool of labels, prohibitively high costs could be an obstacle to having more IDNs.
  *   Comment: If there is a separate process for activating variants, the costs may be high, but that’s up to the RO if they want to use the process. From this perspective, we don’t know when the next regular round will be and we shouldn’t prevent ROs from getting the variants for the TLDs.
  *   Supporting the previous point: Many people from Macao registered IDNs using traditional Chinese. They can use the traditional Chinese at the second level and use simplified at the top level. The Chinese community has been eager to allow variants for years. We should make this happen as soon as possible.
  *   Comment: The most expedient path forward for existing ROs to get variants for existing TLDs is through the next round. To recommend otherwise may result in prohibitive costs, and the time taken to make it happen will collide with the implementation timeline of the New gTLD timeline for the next round.
  *   Question: What will determine when we are ready for a next round?
  *   Response: ICANN org is currently in the Operational Design Phase. Org is considering costs and resources needed for implementing the SubPro report. The ODA document will be released in December. The Board will consider the ODA and the SubPro PDP recommendations. Org will work with an Implementation Review Team to develop the AGB, based on recommendations approved by the Board. There will be a lot of things that have to happen during the implementation phase besides the development of the AGB. The Board will approve the AGB. There will be a communication period for the round before it opens, and then the round can open.
  *   Response: This group is looking to have the Final Report for top level recommendations in 2024. There will still be a period for the Council and then the Board to consider those recommendations before they can be implemented. It does not seem feasible to have a round focused on variants before the next regular round.
  *   As a reminder, the Board previously resolved that variant TLDs can’t be delegated until the necessary questions are addressed.
  *   There are second level questions to be addressed as well, which will take time to work on.
  *   Comment: SubPro recommendations call for a prioritization of IDNs in processing order. This group could say that IDN variants of existing TLDs could have priority within that priority group. The EPDP Team could even give absolute priority IDN variants of existing TLDs.
  *   Support expressed for this proposal regarding prioritization.

Action Item 1: Leadership Team to develop draft recommendation in response to Charter Question D1b based on EPDP Team discussion.

Charter Question B4

B4: What should an application process look like in terms of timing and sequence for an existing and future Registry Operator with respect to applying their allocatable variant TLD labels?

  *   Discussion Question 1: During an application round, are all these options allowed? (A) A new applicant applies for a primary IDN gTLD only. (B) A new applicant applies for a primary IDN gTLD AND one or more of its allocatable variant label(s). (C) A registry operator applies for one or more variant label(s) of its existing IDN gTLD.
  *   Discussion Question 2: Based on the observations, is there a compelling reason to allow applications for variant gTLDs of existing gTLDs between application rounds?


  *   Comment: For question 1 – all of these should be included and nothing is missing.
  *   General support for the three categories in Discussion question 1.

Action Item 2: Leadership Team to draft recommendation on discussion question 1.



  *   For question 2 – if an applicant applies for variants along with a primary string, does it need to activate them all? Or might they choose to activate one or more at a later date?
  *   Response: SubPro recommendations provide minimum requirements for delegation (putting it in the root). It’s possible that this group could recommend an exception.
  *   Comment: Are we considering activation and delegation the same? Is the question about delaying sunrise?
  *   Response: SubPro only looked at timeline to delegation. If activation means sunrise, SubPro doesn’t have recommendations on that.
  *   From SubPro: Affirmation 40.2: The Working Group supports maintaining the timeframes set forth in the 2012 Applicant Guidebook and base Registry Agreement; namely (i) that successful applicants continue to have nine (9) months following the date of being notified that it successfully completed the evaluation process to enter into a Registry Agreement, and (ii) that registry operators must complete all testing procedures for delegation of the TLD into the root zone within twelve (12) months of the Effective Date of the Registry Agreement. In addition, extensions to those time frames should continue to be available according to the same terms and conditions as they were allowed during the 2012 round.
  *   Question: are there specific payments related to delegation?
  *   Response: Yes, ICANN starts billing you the minimum fee once delegated.
  *   Comment: One reason registries might want to activate/delegate one of their TLDs later is because they might have to pay for each (variant) TLD fees to ICANN. In that case, they just want to activate/delegate, when they actually have use for it ... but they don't want to be restricted to rounds.
  *   Comment: The fee structure (per label vs. per set) may impact this discussion.
  *   Suggestion: Consider creating an exception where the primary must be delegated within the timeframes in SubPro, but perhaps a longer period is given for the variants.
  *   Question: Should there be a possibility of applying for a source label and variant, holding back delegation of the source label but going ahead with a variant label?
  *   Response: There is no real difference between the primary and the variant except that one is what you pick first. If you want to launch one first, this should be the primary.
  *   Response: The variant set you generate is based on the source label you pick. Depending on the source label you choose, the set will be the same, but the properties of allocatable or blocked could vary depending on which one you pick as source. In other words, variant relationship among labels is symmetrical, but disposition values are unidirectional.
  *   Comment: The problem is that if you start with ".strasse", the variant ".straße" will be blocked. But if you start with ".straße", then ".strasse" is allocatable. But maybe you first want to use "strasse" and keep "straße" open for later.
  *   Potential variation on the above proposal: The operator must delegate one label in the set. The other can be withheld until a later time.
  *   Question: Is there a compelling reason to activate a variant but delay activation of the primary in a set?
  *   Comment: In the application process, application evaluators, commenters, objectors etc are looking at the case the applicant is making for the TLD. It is consistent with the model and with the principle of transparency that the registry should activate the primary string. There is no good reason except gaming the system to activate the variant first and then the primary later.
  *   Counter example: You might have a brand name, which is an IDN (using ß). At first you would like to play safe and go to the international market and use the string with ss. But you would like to keep it open that later on you also use the IDN string. The relation from ss to ß is blocked, so there are limits to which can be the primary if you ultimately want to use both.
  *   Response: In the counter example, the applicant also has the option to delegate both strings and pay the fees. This is an edge case.
  *   Comment: SubPro’s concern was about warehousing. Suggestion to provide an additional 12 months for variants.
  *   Question: Why is warehousing a concern? Why is there a concern about holding those strings when no one else will ever be able to use them anyway? There is no reason to force activation. The applicant is just planning ahead in case there is a long period of time between rounds.
  *   Response: If regular intervals are adopted this shouldn’t become an issue. Perhaps this can be a way to impress on ICANN how important it is to have regular rounds.
  *   Leadership suggestion on next steps: Apply SubPro recommendation regarding time to delegation for the primary string. EPDP Team to give additional consideration to timeline for delegation of variants.


Action Item 3: In relation to discussion of Charter Question B4, staff to investigate the consequence on the process an applicant delegating a variant ahead of a primary.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20221020/b70e162f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EPDP Team Meeting #55 Slides - D1b & B4.pdf
Type: application/pdf
Size: 682014 bytes
Desc: EPDP Team Meeting #55 Slides - D1b & B4.pdf
URL: <https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20221020/b70e162f/EPDPTeamMeeting55Slides-D1bB4-0001.pdf>