[SubPro-IRT] Follow-up: ASP Bid Credit Options

Sat Jun 22 05:50:13 UTC 2024

Dear Kristy,

Apologies for missing your timeline for input; I will preface by admitting
that I am uncertain whether the following will allow you and your team to
continue working on the ASP bid credit.

I am responding in *my personal capacity*, having not had an opportunity to
consult the ALAC/At-Large. For the same reason, the following remarks are
made on *an interim basis* but are substantially in line with the newly
issued ALAC Advice on Contention Resolution
<https://atlarge.icann.org/en/advice_statements/13945> (see attached). By
"interim basis" I mean that the ALAC might wish to subsequently put forward
a different or modified proposal.

As mentioned during the SubPro IRT Call #48, I am of the opinion that the
notion of a Bid Credit / Multiplier is intrinsically linked to that of
auctions, in that one cannot conclusively discuss the Bid Credit /
Multiplier without first understanding how the auction would work.

After considering the elements to the 2 proposed mechanisms of A. Bid
credit and B. Set-asides, I conclude that both are seemingly more
complicated than what is needed. Let me pose the following as food for
thought.

   1. Referring to what was introduced in SubPro PDP Recommendation 35.4
   (albeit Rec 35.4 was not submitted by GNSO Council to the ICANN Board for
   consideration) - the notion of ICANN Auctions (of Last Resort) being
   conducted using the *second-price sealed-bid auction method or what is
   known to many as the Vickrey auction*, with certain rules and procedural
   steps.
   2. *Such an ICANN Auction would only require a single US$ amount to be
   specified in a sealed bid, which is proposed to be submitted for every gTLD
   string application submitted.* The rationale for this is found in the ALAC
   Advice on Contention Resolution
   <https://atlarge.icann.org/en/advice_statements/13945>.
   3. Submission of this sealed bid must be done as early as possible,
   preferably at the same time a string application is submitted but certainly
   prior to any indication of possible contention sets being formed.
   4. Any applicant that does not submit a sealed bid for its gTLD string
   application will be deemed to submit a bid of zero and will not be able to
   participate in any ensuing ICANN Auction involving that gTLD string.
   5. Once the application submission period closes, the String Similarity
   Evaluation for all applied-for strings must be completed prior to any
   application information being revealed to anyone other than the evaluators
   and ICANN org.
   6. After the end of the String Similarity Evaluation period,
   non-confidential information submitted by applicants in their applications
   will be published (i.e., “Reveal Day”), including the composition of
   contention sets and the nature of the applications, (e.g., community-based
   applications, .Brand applications, etc.)
   7. Concurrently, all applicants whose applications are identified as
   being in contention sets will be informed of the number of other
   applications in their contention set and requested to place a deposit with
   ICANN Org. Deposits must be collected within a fixed amount of time after
   Reveal Day.
   8. The deposit collected would likely need to be a flat sum for all
   participants in order to preserve the confidentiality of the amount
   specified in each sealed bid. If the deposit payable by ASP supported
   applicants is not "discounted" by the Bid Credit / Multiplier, then
   it would have to be low enough to not become a barrier for those
   applicants.
   9. Applicants may at any time withdraw their sealed bids but are not
   allowed to change their sealed bids or put in fresh bids.
   10. There will be neither ascending-clock bidding nor ascending-amount
   bidding. Each ICANN Auction shall only entail the unsealing of sealed bids
   of participating applicants.
   11. On the ICANN Auction date, the applicant that submitted the highest
   sealed bid amount (inclusive of the Bid Credit / Multiplier for ASP
   supported applicants) pays the second-highest bid amount.
   12. If an ASP supported applicant is determined to have won an auction,
   it pays the second-highest bid amount discounted by the Bid Credit /
   Multiplier. For eg, if the Bid Credit / Multiplier was X and an ASP
   supported applicant placed a bid US$100k then its bid is effectively
   US$100k multiple by X, and if it won that auction where the second-highest
   bid was US$90k, then it would pay US$90 divided by X.

Now, skipping ahead to the Bid Credit / Multiplier itself

13. Since applicants are limited to just the single sealed bid, the need
for complicated calculations for a bid credit / multiplier can be avoided.
14. A. Bid credit and B. Set-asides both rely on "a target win
rate". However, it has been said that the use of such a target win rate to
influence the outcome of ICANN Auctions is not provided for by consensus
policy, so, *it seems that the only role, if at all, of a target win rate
is an aspirational one* (as suggested by Sam Lanfranco)* just for purposes
of establishing an actual FIXED bid credit / multiplier to be made
available to all ASP supported applicants participating in an ICANN Auction*
.

15. ICANN sets the one fixed bid credit / multiplier for all ASP supported
applicant bids *(this is where I see NERA's input as critical)* and the
same fixed bid credit / multiplier is added to all ASP supported
applicants’ auction bids as the means to increase their chances of
prevailing at auction.
16. The aspirational target win rate does not determine the outcome of how
many supported applicants prevail in ICANN Auctions – that is dependent
solely on whether an ASP supported applicant’s auction bid with the fixed
bid credit / multiplier applied bests all other bids placed for that
auction.

I am sure there will be other considerations, but for now, I'm happy to
discuss on any of the points above with you and other IRT colleagues, to
the extent feasible.

Kind regards,
Justine

On Wed, 19 Jun 2024 at 06:48, Kristy Buckley <kristy.buckley at icann.org>
wrote:

> Greetings IRT members,
>
> It was a pleasure meeting with you in Kigali. Thank you again for your
> inputs to the ASP bid credit discussion.
>
> As a follow up from that conversation, there seemed to be interest in
> exploring whether and how we could combine aspects of Options A and B from
> the presentation during
> <https://community.icann.org/download/attachments/322994373/ASP%20Bid%20Credit_Multiplier%20for%20IRT.pdf?version=1&modificationDate=1718109969000&api=v2>IRT
> Meeting #48
> <https://community.icann.org/download/attachments/322994373/ASP%20Bid%20Credit_Multiplier%20for%20IRT.pdf?version=1&modificationDate=1718109969000&api=v2>.
> For those who expressed interest in that request, we would like to solicit
> your feedback on what particular aspects you would like to look at
> combining so that we can consult the auction experts on those ideas.
>
> Please send any additional questions or comments regarding the ASP bid
> credit on-list by 20:00 UTC Friday, 21 June 2024. This will allow us to
> continue moving that work forward.
>
> Kind Regards,
>
> Kristy Buckley, on behalf of the ASP Project Team
>
>
>
> _______________________________________________
> SubPro-IRT mailing list
> SubPro-IRT at icann.org
> https://mm.icann.org/mailman/listinfo/subpro-irt
>
> _______________________________________________
> 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: <https://mm.icann.org/pipermail/subpro-irt/attachments/20240622/2b4d023b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AL-ALAC-AC-0624-01.pdf
Type: application/pdf
Size: 86241 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/subpro-irt/attachments/20240622/2b4d023b/AL-ALAC-AC-0624-01-0001.pdf>