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

Justine Chew justine.chew.icann at gmail.com
Wed Jun 26 03:44:41 UTC 2024 

Dear Kristy and Sam,

Many thanks for your replies.

Kristy, just a couple of points in response to your reply:

1. You are right in that there are too many open variables in the equation
right now, which is why I sought to make certain assumptions in reducing as
many variables as I thought sensible, and simply focusing on the policy
rationale for a bid credit/multiplier or other similar mechanism to
"increase the chances" of a supported applicant prevailing. I took no
position on the quantum of the bid credit/multiplier being the ultimate
deciding factor to ensure whether some or all supported applicants would
prevail in auctions. I personally think this is inappropriate.

As such, it is more important to advocate that (i) a second-price
sealed-bid auction method be used; (ii) only a single bid is requested for
every application such that there is no ascending-clock or ascending-price
bidding; and (iii) that the single bid amount be obtained prior to any
indication of possible contention sets being formed, i.e. at application
submission time would be best.

2.  You sought input on mechanisms A and B, which I noted both rely on "a
target win rate" and my response was that, *if at all*, a target win rate
would only be an aspirational one. I had imagine that, again, if at all, an
aspirational target win rate would be used to establish a fixed bid credit
/ multiplier. If this is not the case, then I'm happy to relinquish any
misunderstanding on my part.

*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.*


Further, in A. Bid credit you had the scenario of multiple round auctions,
and in B. Set-asides, you had "ICANN requests maximum bids". Both seem to
add to the complexity unnecessarily, in my opinion. And in the case of the
later, I am suggesting that only one bid is requested per application,
essentially, equivalent to the value which the applicant places on each of
its applied-for gTLD string.

Sam, in reply to your question, I had suggested something earlier, which I
now revise for greater clarity:

*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=4 and an ASP
> supported applicant placed a bid US$100k then its bid is effectively
> US$100k multiple by X=4 and so valued at US$400k, and if it won that
> auction where the second-highest bid was US$300k, then it would pay US$300k
> divided by X=4, i.e. US$75k. *



But let's discuss further at the next call.

Kind regards,
Justine



On Wed, 26 Jun 2024 at 02:13, Sam Lanfranco <samlanfranco at gmail.com> wrote:

> Kristy pretty much sketches out the issues where we are to a large extent
> flying in the dark. There is no *a priori* knowledge of how many
> applicants there will be,. There is no way of knowing the extent to which
> assisted applicants will be in contention sets. There is no way of knowing
> what a (hopefully sealed bid) auction will yield as the successful bid
> price across how many contention set auctions.
>
> What ICANN can do in advance is reduce uncertainty by stating what will be
> the level of financial support for qualified contenders. The higher that
> amount the greater the likelihood that an assisted applicant in a
> contention set would win. The actual cost to ICANN (as revenue lost) being
> determined by the next-best bid.
>
> One issue that may not be clear is what happens if a supported contention
> set bid wins, and the bid submitted is treated as the sum of applicant
> funds (A$) plus ICANN support funds (I$), i.e. Bid = A$ + I$.  Suppose the
> winning bit is greater than A$ alone. Does the applicant pay A$ plus a
> portion of I$, or does the applicant pay I$ plus a portion of A$.
> Hopefully, it is the first option.
>
> Sam Lanfranco
> ------------------------------
> *From:* SubPro-IRT <subpro-irt-bounces at icann.org> on behalf of Kristy
> Buckley <kristy.buckley at icann.org>
> *Sent:* Tuesday, June 25, 2024 10:38 AM
> *To:* Justine Chew <justine.chew.icann at gmail.com>
> *Cc:* Jessica Villaseñor <jessica.villasenor at icann.org>; Diana Middleton <
> diana.middleton at icann.org>; subpro-irt at icann.org <subpro-irt at icann.org>
> *Subject:* Re: [SubPro-IRT] [Ext] Re: Follow-up: ASP Bid Credit Options
>
>
> 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>
> 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/20240626/e9ca3bd8/attachment-0001.html>

More information about the SubPro-IRT mailing list