Hi Donna, thanks to you, Justine, and Ariel for the extra weekend work you put into this project. On 03.04.2023 05:30, Donna austin wrote:
Hi Team
I just wanted to give everyone a heads up that Justine and I have been reviewing documents over the weekend and today. I want to draw to your attention that there has been changes to documents posted by Ariel previously, most notably recommendation 1.2 under A3; and 2.25 and 2.29 under D1b.
You may recall that during our discussions last week about application fees, we agreed that an applicant may be subject to additional fees across multiple rounds if the cumulative number of allocatable variants they apply for exceeds [x]. As I reviewed the recommendation language earlier today on this matter, I found it difficult to justify such a recommendation because an applicant for allocatable variant label in future rounds will still need to pay the base application fee. If they are only applying for one variant label and that variant label takes them above the threshold of [x] for a previously applied-for and delegated primary gTLD, it seems hard to justify what could be an automatic additional fee. I’ve made notes in the draft to that effect, but I would welcome input from others.
there are two questions I'd like rise and discuss in this context and suggest a solution. For the future, take [x] as the number of "free" variants when a new gTLD label is applied for. 1. Do the free labels carry over to future rounds? If you applied for 1 variant first, will you be able to get [x-1] variants for free in the next round? My suggestion is: no, because this causes some overhead in work that the application should pay. 2. Is the price of adding variants to an existing TLD the same as applying for whole new TLD? My suggestion is: no, because it's (presumably) far more involved to start a new TLD application than to add some variants to an existing application. See attached document for a suggestion with some examples (sorry that it does not look as beautiful as Ariel's documents). In my opinion, this solution best reflects the cost-recovery paradigm, while at the same time it does not charge every single variant, which would discourage the use of variants. Happy to discuss this in today's call. Cheers, Michael -- ____________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeisser-Weg 9 44227 Dortmund Germany Dipl.-Informatiker Fon: +49 231 9703-0 Fax: +49 231 9703-200 Dr. Michael Bauland SIP: Michael.Bauland@knipp.de Software Development E-mail: Michael.Bauland@knipp.de Register Court: Amtsgericht Dortmund, HRB 13728 Chief Executive Officers: Dietmar Knipp, Elmar Knipp