[Gnso-epdp-idn-team] [Ext] 回复: REMINDER: Phase 1 Initial Report for Approval - by EOB Tuesday, 11 April

Nigel Hickson nigel.hickson at dcms.gov.uk
Tue Apr 18 09:40:05 UTC 2023


Good afternoon

This is very good news; I had drafted an email with comments but lost
it.....

The only real point I was going to make was the use of "must" in many of
the recommendations (not least those on charging issues) whereas "should"
is often used in Recommendations; but am sure there is good reason for
this;

best

Nigel  ;

On Wed, 12 Apr 2023 at 15:38, Ariel Liang <ariel.liang at icann.org> wrote:

> Dear All,
>
>
>
> The leadership team and staff met today to discuss the issues raised by
> Zuan regarding *Preliminary Recommendation 3.11-3.14*. Please find
> attached the PDF document that provides the proposed revision to enhance
> the clarity of the recommendations, as well as their rationale. The
> proposed revision is consistent with staff’s suggestion shared previously
> on list and should have addressed Zuan’s questions.
>
>
>
> Per leadership team’s direction, Rec 3.11-Rec 3.14 in the Initial Report
> will be updated accordingly, and the public comment related materials will
> be sent to ICANN org for processing asap.
>
>
>
> Thank you all for your review and contribution! Staff will keep the group
> posted when the public comment is officially launched.
>
>
>
> Best Regards,
>
> Ariel
>
>
>
>
>
> *From: *Gnso-epdp-idn-team <gnso-epdp-idn-team-bounces at icann.org> on
> behalf of Ariel Liang <ariel.liang at icann.org>
> *Date: *Tuesday, April 11, 2023 at 11:17 AM
> *To: *Zhang Zuan <zuanzhangpetergreen at hotmail.com>, "
> gnso-epdp-idn-team at icann.org" <gnso-epdp-idn-team at icann.org>
> *Subject: *Re: [Gnso-epdp-idn-team] [Ext] 回复: REMINDER: Phase 1 Initial
> Report for Approval - by EOB Tuesday, 11 April
>
>
>
> Hello Zuan,
>
>
>
> Thank you so much for taking the time and conducting a thorough review of
> the report!
>
>
>
> Please see my respond to the points you noted below. Welcome Donna,
> Justine, and others to chime in as well.
>
>
>
>    1. Page 34 – the typo has been fixed. Thank you.
>
>
>
>    1. Page 35 – The proposed revision to the sentence is as follows: “*Except
>    for Arabic, the language communities of the other six scripts have already
>    limited the number of allocatable variant labels that can be applied for as
>    gTLDs (i.e., one to four variant labels of the primary label are
>    allocatable)*.” Similar revision has been applied on page 77, the
>    first bullet point under rationale for rec 8.1, as well as page 98,
>    analysis for difference no.2.
>
>
>
>    1. Page 32 – Rec 3.11-3.14
>
>
>
> In summary, staff understood that the agreed points are as follows:
>
>    - Discounted base application fee MUST apply when variant labels, no
>    matter how many, are applied for separately from the primary label
>    - ONE-TIME WAIVER for base application fee applies to existing ROs
>    from 2012 round when up to 4 variant labels are applied for in the NEXT
>    ROUND
>    - Additional fees MAY apply when more than 4 variant labels are
>    applied for in an application, whether together with the primary string or
>    separately
>
>
>
> As such, staff is proposing the following refinement of *Rec 3.11-3.14*
> (revised portion highlighted in yellow)
>
>    - *Rec 3.11* (text unchanged)
>
> *A future IDN gTLD applicant applying for a primary IDN gTLD string and up
> to four (4) of that string’s allocatable variant labels during an
> application round must incur the same base application fee as any gTLD
> applicant who does not apply for variant labels in that round.*
>
>
>
>    - *Rec 3.12-3.13, order switched  *
>
>
>
>    - *Rec 3.12* (text unchanged):
>
> *A future registry operator applying only for allocatable variant label(s)
> of its delegated primary IDN gTLD must incur a discounted base application
> fee that ICANN org considers to be proportional to any costs associated
> with evaluating the application and consistent with the cost recovery
> principle.*
>
>
>
>    - *Rec 3.13*:
>
> *An application for more than four (4) of a primary IDN gTLD string’s
> allocatable variant labels may incur additional fees that ICANN org
> considers to be proportional to any additional costs associated with
> evaluating the application and consistent with the cost recovery principle.
> *
>
>
>
>    - Note: previously the rec started with “A future IDN gTLD applicant
>       applying for a primary IDN gTLD string and more than four (4) of that
>       string’s allocatable variant labels in an application…”; this revision
>       attempts to make it clear that when more than four variant labels are
>       applied for in an application, whether together with the primary string or
>       separately, may incur additional fees.
>
>
>
>    - *Rec 3.14: *first paragraph text unchanged; second and third
>    paragraphs have switched order to align with Rec 3.12 and Rec 3.13
>
>
>
> *As a one-time exception for the immediate next application round, the
> base application fee for up to four (4) allocatable variant labels of an
> existing IDN gTLD applied for by its existing registry operator from the
> 2012 round will be waived. *
>
>
>
> *If an existing registry operator from the 2012 round applies for
> allocatable variant labels of its existing IDN gTLD in any application
> round subsequent to the immediate next application round, that application
> must incur a discounted base application fee as any other future registry
> operators who apply only for allocatable variant labels, as set out in
> Preliminary Recommendation 3.12.*
>
>
>
> *If an existing registry operator from the 2012 round applies for more
> than four (4) allocatable variant labels of its existing IDN gTLD in an
> application during any round, that application may incur additional fees as
> set out in Preliminary Recommendation 3.13.*
>
>
>
>    - Note: The second paragraph previously included the phrase “may
>       incur” with regard to discounted base application fee; it has been updated
>       to “must incur”. The third paragraph previously included the phrase “in the
>       immediate next application round”; it has been updated to “in an
>       application during any round”.
>
>
>
>
>
> Thank you!
>
> Ariel
>
>
>
> *From: *Zhang Zuan <zuanzhangpetergreen at hotmail.com>
> *Date: *Tuesday, April 11, 2023 at 7:48 AM
> *To: *Ariel Liang <ariel.liang at icann.org>, "gnso-epdp-idn-team at icann.org"
> <gnso-epdp-idn-team at icann.org>
> *Subject: *[Ext] 回复: [Gnso-epdp-idn-team] REMINDER: Phase 1 Initial
> Report for Approval - by EOB Tuesday, 11 April
>
>
>
> Dear all,
>
>
>
> Thanks to Donna, Justine and staff, without your leadership and support
> work, the Phase 1 Initial Report would not be done.
>
>
>
> After reviewed the whole Initial Report, I have the following
> observations:
>
>
>
> *1.Page 34, the last paragraph *
>
>
>
> “*since the delegation of gTLD variant labels will be a new and……….*”, is
> it a typo? If it is, should it be revised as “will be new”?
>
>
>
> *2. Page 35, Rationale for Preliminary Recommendation 3.11-3.14 *
>
>
>
> It is mentioned that “*[s]ince the EPDP Team decided not to impose a
> ceiling value for the delegated top-level variant labels*”, while in the
> next paragraph, it is mentioned that “*[e]xcept for Arabic, the language
> communities of the other six scripts have already put a ceiling value
> (i.e., one to four variant labels of the primary label are allocatable) to
> limit the number of allocatable variant labels that can be applied for as
> gTLDs”*.
>
>
>
> It might be confusing by first mentioning “*not to impose a ceiling
> value” *and later “*already put a ceiling value*”. As a matter of fact,
> the language communities of the other six scripts proposed a threshold
> number of variants, which was the threshold number for deciding whether to
> charge base application fee or not.
>
>
>
> So it might be revised as “the language communities of the other six
> scripts have already proposed a threshold number (i.e., one to four variant
> labels of the primary label are allocatable) to limit excessive number of
> allocatable variant labels that can be applied for as gTLDs”, just to be
> aligned with (Page 36, the second paragraph) “*[t]he EPDP Team recommends
> this threshold number based on the known upper bound for allocatable
> variant labels permitted by the RZ-LGR for the scripts that have
> allocatable variant labels (with the exception of Arabic)*”.
>
>
>
> *3.Page 32 *
>
> *{Preliminary Recommendation 3.13: A future registry operator applying
> only for allocatable variant label(s) of its delegated primary IDN gTLD
> must incur a discounted base application fee that ICANN org considers to be
> proportional to any costs associated with evaluating the application and
> consistent with the cost recovery principle. *
>
>
>
> *Preliminary Recommendation 3.14: If an existing registry operator from
> the 2012 round applies for allocatable variant labels of its existing IDN
> gTLD in any application round subsequent to the immediate next application
> round, that application may incur a discounted base application fee as any
> other future registry operators who apply only for allocatable variant
> labels, as set out in Preliminary Recommendation 3.13. }*
>
>
>
> When I read the above recommendations, I find some ambiguities regarding
> the discounted base application fee.
>
>
>
> Does the discounted base application fee apply to all of the variants
> applied separately by both future applicants and existing registry
> operators in a separate round rather than the round in which they applied
> for primary gTLDs? If it applies, in this scenario, is there any number
> limit of applied-for variants? In other words, is it the scenario that no
> matter how many variants are applied for, future applicants and existing
> registry operators might only pay a discounted base application fee?
>
>
>
> If there is no number limit of variants in the above scenario, there are
> no ambiguities of the recommendations.
>
>
>
> But in order to be aligned with the spirit of the proposed threshold
> number (4) of variants for one gTLD, I would suggest proposing the same
> number limit (i.e. 4 variants) in the above scenario to avoid excessive
> applications of variants for one gTLD.
>
>
>
> My two cents.
>
>
>
> Congratulations to all for achieving this milestone.
>
>
>
> Best Regards
>
> Zuan
>
>
> ------------------------------
>
> *发**件人:* Gnso-epdp-idn-team <gnso-epdp-idn-team-bounces at icann.org> 代表
> Ariel Liang <ariel.liang at icann.org>
> *发**送**时间:* 2023年4月11日 0:06
> *收件人:* gnso-epdp-idn-team at icann.org <gnso-epdp-idn-team at icann.org>
> *主**题:* [Gnso-epdp-idn-team] REMINDER: Phase 1 Initial Report for
> Approval - by EOB Tuesday, 11 April
>
>
>
> Dear All,
>
>
>
> This is a friendly reminder to review the draft Phase 1 Initial Report by *EOB
> Tuesday, 11 April*. As per instruction from the leadership team, please
> share on list if you come across any typos or minor issues that must be
> fixed.
>
>
>
> Thank you,
>
> Ariel
>
>
>
> *From: *Ariel Liang <ariel.liang at icann.org>
> *Date: *Wednesday, April 5, 2023 at 12:12 PM
> *To: *"gnso-epdp-idn-team at icann.org" <gnso-epdp-idn-team at icann.org>
> *Subject: *Phase 1 Initial Report for Approval - by EOB Tuesday, 11 April
>
>
>
> Dear All,
>
>
>
> On behalf of the EPDP Team leadership, we are sending the draft Phase 1
> Initial Report for your approval by *EOB Tuesday, 11 April*. Please see
> the message from Donna and Justine below.
>
>
>
> ==
>
>
>
> Dear Team
>
>
>
> Congratulations! We did it!
>
>
>
> Attached is the Initial Report for Phase 1 that we intend to post for
> public comment by the end of the month. If you have time to review please
> do and let us know if you come across any typos or minor issue. However,
> please note that at this stage of the process the Leadership Team has
> agreed that it is too late for substantive changes.
>
>
>
> We intend to publish the report for the minimum comment period of 42 days.
> However, if we receive requests to extend the duration we will certainly
> consider it.
>
>
>
> On behalf of the Leadership Team, I want to thank everyone in the Team for
> your respective contributions and dedication that got us to this point. I
> appreciate these efforts can become tedious and at times hard to maintain
> interest so sincere thanks for sticking with us.
>
>
>
> I know we still have work to do, quite a bit as it turns out, but we now
> have a good chunk of it behind us. Buy yourself a drink, or chocolate or
> ice cream to celebrate 🎉
>
>
>
> We’re going to take a mini-break and when we come back on 20 April we’ll
> start what will largely be an administrative discussion about how to tackle
> Phase 2. And also just a heads up that I have requested 4 sessions at
> ICANN77 and I hope to have some news to share in that regard.
>
>
>
> Big thanks to our support team of Ariel, Emily and Steve. Where would we
> be without Ariel’s presentations 😀. And thanks to Sarmad and Pitinan for
> your expertise and analysis of data that has been so helpful to our
> consideration of the charter questions. Special mention to our Board
> Liaisons Edmon and Alan as well for their contributions; and Michael
> Karakash for joining the calls.
>
>
>
> Have a great weekend. We’ll see you in a couple of weeks.
>
>
>
> Donna and Justine
>
>
>
> ==
>
>
>
> As an additional note, policy staff are in process compiling content for
> Annex E (EPDP Team membership and attendance), and it will be ready before
> the report is submitted to ICANN org for processing. We will also discuss
> with the leadership team regarding any new input received on the D1b draft
> text circulated yesterday.
>
>
>
> From the staff team, a BIG THANKS to Donna and Justine for their
> diligence, kindness, and leadership. And congratulations to everyone for
> the great work done! It has been an amazing journey and we have come a long
> way together!
>
>
>
> Best Regards,
>
> Ariel, Emily, Steve
>
>
> _______________________________________________
> 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/20230418/14dfa6a6/attachment-0001.html>


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