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

Nigel Hickson nigel.hickson at dcms.gov.uk
Thu Nov 24 12:23:42 UTC 2022 

Emily

Good afternoon; thanks for this; just realised no Call today (Happy
Thanksgiving to all); but also wondered about next week; 1st December, as
thought we were not meeting as many of us involved in UN IGF (but may be
wrong);

best

Nigel

On Thu, 17 Nov 2022 at 15:31, Emily Barabas <emily.barabas at icann.org> wrote:

> 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.
>
>
> _______________________________________________
> Gnso-epdp-idn-team mailing list
> Gnso-epdp-idn-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-idn-team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20221124/f41c682f/attachment-0001.html>

More information about the Gnso-epdp-idn-team mailing list