[Gnso-newgtld-wg] Compromise proposal on Auctions

[Justine Chew]

Jim,

Thanks for putting your proposal together for the WG's consideration; I
hope it will be discussed further some time next week.

In the meantime, how do you envisage your proposed bid credit (or the
multiplier equivalent) featuring in your proposal for applicants who have
qualified for Applicant Support and that end up in contention sets? Would
it be applicable for both the ICANN Auction of Last Resort and the 3rd
Party Auctions? Should it? What would be the consequence to the sum paid
for either type of auctions?

Thanks,

Justine
---


On Thu, 2 Jul 2020 at 10:27, Rubens Kuhl <rubensk at nic.br> wrote:

>
>
> > On 1 Jul 2020, at 21:28, Phil Buckingham <phil at dotadvice.co.uk> wrote:
> >
> > Jim,
> > Many thanks for this . I have been working on a very similar proposal.
> > This is excellent and eliminates many of the problems and issues that
> applicants encountered at great cost and delay in Round 1.
> > The issue I have is there are so many moving parts and so many different
> scenarios that could happen still and certainly did happen last time. I
> guess we simply can’t cover all bases.
> > This is a great start and clearly lays out the ground rules and a clear
> timeline for implementation guidance . Perhaps further down the line it can
> be tweaked for  special / exceptional scenarios.
> > I have a couple of points .
> > Firstly , I think 90 days is too short a period ( from once an applicant
> find itself in a contention set on Reveal Day ) to then have to put a bid
> valuation together, to completely revise it business model & strategy to
> then go out to the market  to raise substantial $Ms to win the auction.
> > Could they not let be know earlier by ICANN ?
>
> I believe Jim mentioned as early as the required string evaluations are
> done, so it can't be earlier. It could be longer.
>
> >
> > 2 I’m assuming that the financial and technical evaluation will / must
> come AFTER the contention set is resolved( and paid out/ back to the losers
> ). Surely the winner will need to resubmit their business models /
> financials to reflect the cost of winning the auction / its funding / its
> cashflows to enable it to pass the (old) Q46.
> > As we now know many applicants totally overpaid to win their auction in
> Round 1 , revenues and registrations are substantially below original
> evaluation budgets , such that many current TLDs are not viable . I think
> Q46 needs to much tougher this time around to get a financial evaluation
> pass.
>
> The WG decided to go pretty much in the opposite direction on Q46, in a
> way to match expectations with reality. ICANN didn't evaluate business
> models at all.
> Note also that technical evaluation might be very quick for applicants
> that decided to go with an approved RSP and vanilla-only services.
>
> >
> > 3. How do we incorporate a scenario of a losing CPE applicant having to
> go  to a contention set - which it will very likely lose through lack of
> extra auction funds. I guess the CPE applications will need to go first as
> priority for initial evaluation ,so if it fails IE & EE , only then can the
> private resolution / auction start.
> > Does this x ref to CPE recommendations ?
>
> I understood Jim's proposal to have already factored that, by starting the
> resolution clock only after CPE results are published.
>
> >
> > 4 . What of the same scenario but with an Applicant Support application
> that finds itself in a contention set .
>
> A multiplier is currently under discussion but it would make sense to
> apply in multiple scenarios.
>
> >
> > 5. I really don’t like & many applicants didn’t want at all  to go to
> the ICANN public auction last time  because it is just that - public .
>
> A private auction this time might not be secretive as last time, so this
> might not be a factor.
>
> > I totally agree with your idea that this Round that all proceeds from an
> ICANN public auction are redistributed back to the losing applicants as
> soon as possible.
> > ICANN can’t be seen to be making any money from these auctions .
>
> ICANN making money shouldn't be a goal, but it's not a problem per se, if
> that prevents other issues. I don't think even ICANN wanted such a pile of
> cash last time, and as long as we don't make ICANN revenue a goal, ICANN
> getting money might be the lesser of two evils.
>
>
> Rubens
>
>
> _______________________________________________
> Gnso-newgtld-wg mailing list
> Gnso-newgtld-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg
> _______________________________________________
> By submitting your personal data, you consent to the processing of your
> personal data for purposes of subscribing to this mailing list accordance
> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and
> the website Terms of Service (https://www.icann.org/privacy/tos). You can
> visit the Mailman link above to change your membership status or
> configuration, including unsubscribing, setting digest-style delivery or
> disabling delivery altogether (e.g., for a vacation), and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20200702/e61dbe7b/attachment.html>