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

Tue Jun 25 14:38:20 UTC 2024

Many thanks, Justine, for this comprehensive and thoughtful input--as always. This provides a lot of food for thought which I'm hoping we can discuss during an upcoming IRT session.

I'll just speak to the points on the ASP bid credit since I'm not as familiar with auctions overall. I think NERA and ICANN org were assuming that the bid credit for supported applicants would be a fixed, equal credit for all--perhaps something we should be more explicit about in in the slides.

NERA has indicated that we can set the fixed ASP bid credit without a "target win rate". I'm not sure that having an aspirational target win rate helps us much since the outcome is still an unknown and uncontrolled variable. When we set the bid credit for all supported applicants, we won't know if it is "too high" or "too low" until the results of the auction. And, as you all know, opinions will vary about what is "too high" or "too low". The policy rationale simply said that a bid credit/multiplier or other similar mechanism is intended to "increase the chances" of a supported applicant prevailing.

Since not all strings are valued equally, in some cases the set bid credit (equal for all supported applicants) may not make a supported bidder competitive in the auction they participate in. WIthout knowing which strings will be in contention, their market value, or a target win rate, it is possible that the set, fixed bid credit does not make any supported applicants competitive in the ICANN Auctions of Last Resort. It's also possible that it makes many supported applicants very competitive in those auctions, or a mix of both outcomes depending on the auction.

My understanding is that (even with NERA's expert guidance) setting a fixed bid credit for all supported applicants without a target win rate means that we won't be able to forecast the degree to which the ASP bid credit increases the chances of supported applicants prevailing at ICANN Auctions.

I hope this is helpful, at least on the ASP side. We are planning another opportunity to meet with the IRT next week to discuss.

Kind regards,
Kristy

________________________________
From: Justine Chew <justine.chew.icann at gmail.com>
Sent: Friday, June 21, 2024 22:50
To: Kristy Buckley
Cc: subpro-irt at icann.org; Jessica Villaseñor; Diana Middleton
Subject: [Ext] Re: [SubPro-IRT] Follow-up: ASP Bid Credit Options

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 [atlarge.icann.org]<https://urldefense.com/v3/__https://atlarge.icann.org/en/advice_statements/13945__;!!PtGJab4!770KhwdvBdQYb5zxZtebjMwOYJABdSC7p25KwIKmgMxeFWb-xy0cJpemYwuRopa6TQZQjnkJ-_LBTzRgIq7--w-1tZLEWqgZid_Rpg$> (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 [atlarge.icann.org]<https://urldefense.com/v3/__https://atlarge.icann.org/en/advice_statements/13945__;!!PtGJab4!770KhwdvBdQYb5zxZtebjMwOYJABdSC7p25KwIKmgMxeFWb-xy0cJpemYwuRopa6TQZQjnkJ-_LBTzRgIq7--w-1tZLEWqgZid_Rpg$>.
  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<mailto: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<mailto: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/20240625/71443d06/attachment-0001.html>