[SubPro-IRT] GAC Advice on Private Auctions and ICANN Last-Resort Auctions

Thu Jun 20 20:27:02 UTC 2024

I was considering, as we were al kvetching about the fees in another
thread, that one concept that might be a creative method of isolating the
contention set resolution _stuff_ might be to withhold any discounting
refunds for the applications within those sets until the contention set is
resolved, and isolate any fees associated with the remedy of the contention
to being funded from that pool of moneys, isolated from the other
applications.

Here is an illustration hypothetical example of how this might work:
Marc applies for .cryptoschmutz, I apply for .cryptoschmutz, and there are
maybe eight others that apply for .cryptochmutz, for a population of 10
.cryptoschmutz TLD applications.

We all paid a higher application fee, based upon ICANN's prediction that
there would only be 1000 applications, and ICANN receives a thundering herd
more than that, say 3000, to where the fee is reduced and a portion is
eligible to be refunded.  To keep it simple, let's use 50k as the
refundable amount.

Because we were all in a contention set, the refunds would be withheld, and
there would be a pool of 10x50k, 500k available to use as the contention
set resolution funding pool to cover any costs associated with the
.cryptoschmutz TLD.  Whatever occurs to narrow the pool of applicants to 1,
any costs, legal or otherwise, are paid solely from that pool, and then
1/10 of any remainder is distributed to each applicant AFTER the contention
set is addressed.  So, let's say it cost 50k to resolve, then there is 450k
remaining and that gets distributed as 45k each to the applicants.

This could financially disincentivize intentionally joining a set, as you
end up with stuck money, and the attraction of being refunded could be an
incentive for more applicants rapidly arriving at contention set
resolutions.

-Jothan

Jothan Frakes
Tel: +1.206-355-0230

On Thu, Jun 20, 2024 at 12:08 PM trachtenbergm--- via SubPro-IRT <
subpro-irt at icann.org> wrote:

> Personally,  I think that permitting private auctions in the next round
> will completely distort and destroy it as the majority of applications will
> be speculative in nature trying to get a payout via private auction.  We
> already know anecdotally that there are a number of people setting up funds
> to do this and many others have already publicly expressed an interest in
> doing this.  And certain strings are obvious targets.  This will junk up
> the process, waste ICANN resources, and increase time and cost for all
> applicants, and be detrimental to the general public.  Frankly, I don’t
> know anyone that thinks permitting private auctions is a good idea and will
> be beneficial other than those who have expressed interest in participating
> in them.
>
>
>
> Of course it is a different question of *how* to prohibit private
> auctions. I am not sure how this can be effectively accomplished.  Maybe we
> prohibit all private resolution of contention sets for monetary (or
> equivalent) consideration other than the ICANN  auction of last resort.
> Could applicants still do this secretly – of course.  But if they wee found
> out, the winner could lose its TLD. If we all think that having private
> auctions is detrimental then we should take steps here to prohibit them, as
> ICANN is not doing so (although they have expressed concern) and have
> kicked it back to the GNSO.  Yes of course there will be ways to game any
> method we choose but the possibility of gaming is too often used in
> ICANN-land as a reason/excuse not to do things and to keep the status quo.
> The reality is that any system/rule/process can be gamed and the best we
> can do is try to set up the process to reduce opportunities for gaming and
> increase penalties for doing so.
>
>
>
> Best regards,
>
>
>
> *Marc H. Trachtenberg *
> Shareholder
>
> Chair, Internet, Domain Name, e-Commerce and Social Media Practice
> Greenberg Traurig, LLP
> 77 West Wacker Drive | Suite 3100 | Chicago, IL 60601
> T +1 312.456.1020
>
> M +1 773.677.3305
> trac at gtlaw.com <trachtenbergm at gtlaw.com> | www.gtlaw.com | View GT
> Biography <https://www.gtlaw.com/en/professionals/t/trachtenberg-marc-h>
>
>
>
> [image: Greenberg Traurig Logo]
>
>
>
>
>
> *From:* SubPro-IRT <subpro-irt-bounces at icann.org> *On Behalf Of *Sam
> Lanfranco
> *Sent:* Thursday, June 20, 2024 1:20 PM
> *To:* subpro-irt at icann.org
> *Subject:* [SubPro-IRT] GAC Advice on Private Auctions and ICANN
> Last-Resort Auctions
>
>
>
> **EXTERNAL TO GT**
>
> Comment by Sam Lanfranco
>
> I do not believe that the GAC understands the complexities in its advice
> with regard to not using auctions in the resolution of contention sets.
>
> FIRST: Once a contention set is determined, there is really no mechanism
> by which the contenders can work out a resolution on their own that can be
> prevented by ICANN. In a contention set an agreed payment scheme would
> avoid an auction, but an auction ban could not be enforced. Even insisting
> on an ICANN auction of last resort could not prevent a prior agreement
> between contending parties, and the ICANN auction would just a formality in
> terms of a private agreement.
>
> SECOND:  Auctions exist to solve a problem of excess demand for unique
> (non-fungible) commodities. A gTLD is a unique supply of one item, the
> thing being sought is right to be the registry for that one item (vertical
> supply line at Q = 1). Money as the numéraire in which the price is
> expressed and the auction as a way of selecting a buyer when there are
> competing interests are a “form follows function” solution to the competing
> interests. It was invented precisely for this purpose when there is no
> overriding reason to award the "item" (gTLD registry) to any one contender.
>
> GAC proposed no alternatives to resolving the contention set without an
> auction. Any alternative would require a consensus on an outside agent who
> would have neither regulatory guidelines not case law to reach a decision.
> That would mean that there are no objective criteria for selecting an
> outside agent.
>
> My view here would be to explain this to GAC, and politely ask if they
> have guidance on how an acceptable outside agent might be identified. In
> the end I see no way around an ICANN auction of last resort, even if there
> is a way of preventing a private resolution within the contenders in the
> contention set. This situation is precisely why humans with agency created
> auctions in the first place.
>
> Sam Lanfranco
> ------------------------------
> If you are not an intended recipient of confidential and privileged
> information in this email, please delete it, notify us immediately at
> postmaster at gtlaw.com, and do not use or disseminate the information.
> _______________________________________________
> 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/20240620/85e644e5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 12852 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/subpro-irt/attachments/20240620/85e644e5/image001-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 6018 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/subpro-irt/attachments/20240620/85e644e5/image002-0001.png>