[Gnso-epdp-idn-team] Notes and action items - IDNs EPDP Meeting #58 - 17 November 2022

[Emily Barabas]

Dear all,

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

Kind regards,

Ariel, Steve, and Emily


Notes and Action Items - IDNs EPDP Call – 17 November 2022

Action Items

Action Item 1: EPDP Team members to review input from ICANN org and send any clarification questions to the mailing list.
Action Item 2: Leadership Team to draft text in response to Charter Question B4 based on today’s discussion.

Notes

Welcome and Chair Updates

  *   The GNSO Council approved the EPDP’s Project Change Request during the November Council meeting. There was some discussion on this list about the timeline, to which the leadership team provided a reply. As a reminder, the EPDP Team seeks to complete the Phase 1 Initial Report by April 2023. Donna may request to make calls two hours in length to continue making progress towards this goal.
  *   ICANN Org has provided early input on the EPDP’s stable recommendations. The substance of this input will be covered on calls once everyone has had a chance to review.
  *   Multiple org SMEs provided input on operational impacts of the recommendations. The org document includes three types of input: substantive, non-substantive, and assumptions (org’s interpretations of the text to be confirmed by the EPDP). There are also some general comments at the top of the document that apply to multiple sections of the text. There is an impact analysis of the String Similarity hybrid model at the end of the document. The org team did not explicitly look at other models but could do so upon request of the EPDP Team.
  *   This may be something the EPDP Team requests in the future if it can’t find a path forward.

Action Item 1: EPDP Team members to review input from ICANN org and send any clarification questions to the mailing list.

Continued Discussion of Charter Question B4 [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1LlorzuwJlZ1jUZTw9Frwy-wJkTdQ559p0R2ogGRRTTU/edit__;!!PtGJab4!4hAeImyxiBfQZX0bH1wzyavbOEHm1nicx5lL8D4WnTqbgZAHntZKfkqK5vDZCigj4ESGXR1swsWBg_eSy0kU_rz-nq5ZyFg$> - Delegation of variants gTLDs vis a vis primary string

  *   Introduction: The EPDP Team previously discussed the possibility of delegating the variant string ahead of the primary string. From a technical perspective, it is possible to delegate the variant ahead of the primary string. But is it what we want to do from a policy perspective? Should strings in a set be delegated within the same set timeframe or should this be flexible?
  *   Slide 4 – B4 Additional Discussion Topic
  *   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 or activating their allocatable variant TLD labels?
  *   Discussion Questions: 1. Should a variant gTLD be allowed for delegation prior to delegation of the primary string? 2. Should the primary string and allocatable variant labels that pass evaluation be delegated within the timeframe as affirmed by SubPro recommendations? 3. Should the variant string and the primary be delegated at the same time?
  *   Slide 5 – Question 1 Example and Factors for Consideration
  *   What are the assumptions of the group about whether the intent is that all of the TLDs in a set need to be delegated in close timing to one another or whether it can be done over a period of time? As a reminder, the group previously discussed that whichever string is delegated first must be delegated within a 12 months.
  *   Comment: There are four steps 1. Application for a variant set 2. Evaluation process 3. Execution of the RA with expectation of delegation 4. Sunrise. The question of whether the primary needs to be delegated first is not trivial. The 12 month timeframe for delegation results in all of the contractual obligations kicking in. If there were different options for the timing of strings in a set, someone would have to manage that. There is no requirement for sunrise and the timing is up to the RO. In that way, they can manage the sequencing while complying with the obligations for those variant sets. The concern is the burden of managing the variants in the set. Is that something for ICANN org to manage or for the RO to manage?
  *   Clarification: Sunrise is the process of starting to offer registrations in the TLD. This is done by the RO based on certain requirements, but the RO picks the date to sunrise.
  *   Comment: Support for the idea that if an applicant applies for several variant labels that they all need to be activated at once or in a small window of time. The RO could decide to wait on a sunrise for certain strings based on business choices. But what would this mean for fees that the RO pays? The RO may not want to pay fees for a string it is not ready to sunrise. Additional point: If we say that the main string always needs to exist along with the variant, would you be able to delete/remove/sunset the main label and keep that variant?
  *   Comment: On the one hand, it might benefit end users to have all of the TLDs in a set available at once. On the other hand, the RO may end up paying more fees for strings they are not yet ready to use. If there is one contract for a variant set, they should all be launched within 12 months.
  *   Comment: It seems more complex to have serial launch of TLDs in a set and then manage that coordination/harmonization by retrofitting. It seems hard to imagine a use case where you would want that complexity rather than launching at the same time and doing coordination/harmonization of the set at once.
  *   Response: This is something that we will have to deal with anyway, because every TLD operator will be able to apply for variant TLDs in later rounds, and the complexity associated with this later activation will need to be managed.
  *   Question: It was noted that for Chinese TLDs from the first round, the ROs were disadvantaged because they couldn’t get their variants. When they are able to get their variants, how will this be managed?
  *   Response: Currently without the IDN variant TLD, there are users who are not able to access certain domains as expected. This will be resolved once variants are available. It is up to the registries to deal appropriately with the addition of variants. Their plan to do so will be evaluated as part of the application process.
  *   Comment: What does appropriate mean respect to the operation of variants?
  *   Response: There is no guarantee of a consistent user experience. The policy is intended to enable the possibility of a consistent user experience. But it is up to the registry, registrar, and registrant to make that happen in practice.
  *   Comment: We should not talk about guaranteeing the experience of the end user in the context of this work. There are too many steps between this work and the final experience of the end user. We can seek to make a better experience, but we can’t make guarantees.
  *   Comment: There is a different between delegation and use. Delegation means introduction to the root. Once the applicant gets the TLD and the variants, we could have a baseline position that those strings get delegated into the root. They would be subject to the associated fees. We should not go into questions related to sunrise. This is up to the RO to manage. If an RO wants to delay delegation of the set or part of the set, they should apply to ICANN for an extension. Why are we looking beyond delegation in this discussion?
  *   Response: Agree that our discussion should focus on delegation. But reviewing the details of sunrise helped the group understand what happens after delegation.
  *   Suggestion: The policy doesn’t mandate the order in which the strings are delegated. There is an expectation that the primary and the variants will be delegated within a set period of time.
  *   Slide 6 – Question 2 – Factors for Consideration
     *   Question 2: Should the primary string and allocatable variant labels that pass evaluation be delegated within the timeframe as affirmed by SubPro recommendations?
  *   Clarification regarding SubPro recommendation: based on the rationale, the term “use” draws on the existing definition – delegation into the root and meeting of the associated contractual commitments.
  *   Staff note: The question with respect to applicant intent on slide 6 may need to be revisited and restructured for clarity.
  *   Comment: We intend to be consistent with the SubPro recommendations regarding required timeframes for entering into an RA and for delegation. If multiple strings are under the same RA, it makes sense that they all follow the same timeframe requirements. To do otherwise would create excessive complexity.
  *   Summary: There seems to be support for the idea that the sequence for delegation should not be mandated in policy, but the set should be delegated within the same timeframe. The question of how annual fees will be incurred is still outstanding and will be discussed in the future.

Action Item 2: Leadership Team to draft text in response to Charter Question B4 based on today’s discussion.


  *   Additional potential question for future consideration: Should an applicant be able to apply for a variant and not the primary label of a set.


Continued Discussion of Charter Question E2 [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1glGuJwSoYlYFvdRWtDWf9UvrLKk2hq7kW-osHJeGK14/edit__;!!PtGJab4!4hAeImyxiBfQZX0bH1wzyavbOEHm1nicx5lL8D4WnTqbgZAHntZKfkqK5vDZCigj4ESGXR1swsWBg_eSy0kU_rz-Ic9e9_A$>- Options for Legal Rights and Community Objections

  *   Deferred to a future call.

AOB

  *   No call next week.
  *   Joint Meeting between IDNs EPDP Team and ccPDP4 is on Tuesday 29 November 2022 at 14:00 UTC for 90 minutes.
  *   Next regular EPDP call is on Thursday 1 December at 13:30 UTC.

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