[Gnso-newgtld-wg] Additional thoughts on Proposal 5

Mon Jul 27 13:14:04 UTC 2020

Jim,

I agree with you. 

And essentially "Board Concern #1" and "Board Concern #2" are identical:

The board is concerned that applicants are trying to facilitate financial
gain by strategically losing private auctions. For whatever reason: 

*        either just to bath in cash

*        or to finance other applications 

and in the end it doesn't matter. It's one and the same concern. 

It is however still beneficial to factor them in separately as the
countermeasure to Concern #2 can be easily mitigated by having all auctions
for clear cut cases (no objections, etc) all at once. Don't forget: "sealed
bid auctions" are now essentially just "reveals" - all of them can be
facilitated in a millisecond; whereas in the past we had to create auction
slots and auctions were time and resource consuming. The only real
difference between Board Concerns #1 and #2 is (as you indicate) "timing".

1.      Applicants apply for their strings.

2.      After the application window closes those who face contention
resolution are requested to submit a sealed bid (the only information they
have at this point is that they face some kind of contention - which could
be identical or similar strings. They don't know how many contention set
members or their identity or string names).

3.      That bid is valid for both auction types: the one where proceeds are
shared among losers - and the one where losers won't benefit (formerly:
"auction of last resort"). 

o   The latter one is very important, as applicants may announce upfront
that they will not allow losers to financially benefit (this deters fortune
seekers). 

o   Example: dotAIRPORT, LLC will make it crystal clear, that it won't
participate in any scheme where auction proceeds are distributed to losers. 

o   In fact we could have applicants OPT OUT of the private auction right in
the application - then contention set members would be informed that one
member opted out of auction fee distribution: the affected applicants could
quickly withdraw their application to maximize their application fee refunds
(overall loss); as they are now facing a mandatory ICANN auction of last
resort. 

4.      Auction deposits are due a few days before auction reveal
(regardless how auction proceeds are distributed). 

5.      Failure to pay the winning bid (2nd highest) results in losing the
deposit and any potential application fee refund.

Thanks,

Alexander

From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces at icann.org] On Behalf
Of Jim Prendergast
Sent: Montag, 27. Juli 2020 14:28
To: gnso-newgtld-wg at icann.org
Subject: [Gnso-newgtld-wg] Additional thoughts on Proposal 5

Apologies in advance. I will not be able to join the call later today as I
am cohosting a workshop at RightsCon at the same time.  I will review the
notes and recording and respond on list as necessary.

As Jeff noted during the last call, this is complicated because we are now
allowing the resolution of contention sets in ways that were not allowed in
the 2012 round.  A very simple, clean way to settle contention sets without
these measures is to have them all go to an ICANN auction of last resort or
a random draw.  But some people insist that losers should get paid so those
are off the table.

I also believe that we have to address BOTH Board concerns - 

Board Concern #1 - applications submitted for the sole purpose of receiving
a payout for losing private auctions

We have made good progress in addressing #1 and I think we can get there
with some tweaks.

Transparency requirements are good but they should not be rolled back for
the creation of JVs.  Not suggesting trade secrets be divulged but we should
know who the operator of the JV is and we should also know the circumstances
around what caused members of the contention set who are not part of the JV
to drop out.  

I also believe that the Bona Fide proffers should be reviewed and enforced
by ICANN, not just the outside evaluators.  Rationale is that at some point,
the evaluators will disappear.  They are temporary help.  ICANN has the
ultimate responsibility to administer this program so they should be the
ones reviewing theses Bona Fide requirements.

And along these lines - ICANN should oversee all auctions, not just the
Auction of Last resort.  As currently constructed in Paul's edit - there are
too many steps for revealing the results of private auctions.  With ICANN
overseeing this, it's a much cleaner process.  ICANN involvement also adds a
level of assurance that these auctions are being conducted in an aboveboard
manner.

As far as penalties for violations of the Bona Fide requirements - loss of
registry has to be there.  That is a major deterrent and should not be cast
aside.

Board Concern #2 - gaming for the purposes of financing other applications.

The base Proposal 5 does nothing to address Concern #2.  Donna stated that
she's "not convinced that means we have to address it."  I couldn't disagree
more.  

If we fail to address this now, there is a strong likely hood that the Board
will either 1) come back to us and ask us to develop a plan (slowing things
down again) or 2) develop a solution themselves.  Neither is an ideal
outcome so we have to do something to stop the gaming for purposes of
financing other applications.  

I and others believe that the Bona Fide requirements do not go far enough
here.  Others believe my sealed bid requirement goes too far.  So what are
alternative solutions that are enforceable and prevent this type of
activity?

Auction proceeds held in escrow? All auction conducted at once?  

Timing on when these auctions happen is the key to stop this gaming and that
is why I proposed the submission of all bids upfront.  With bids upfront,
auctions could be conducted whenever but there is a constraint on the
ability to roll funds over and over.

ICANN's right to refer to competition authority.  

We never got around to discussing why Paul felt the need to delete this
section completely and since the call there was a brief discussion on list
about whether ICANN has this as an inherent right or whether it should be
spelled out.

My proposal was based upon the RSEP process which is already in force of all
registry operators and will be required for all future operators.  It
specifically calls out competition authority referral if ICANN makes a
determination such referral is necessary.  I was surprised how
representatives of contracted parties reacted so negatively to that since it
is in existing registry agreements. 

My rationale for including this provision and calling it out specifically is
simple - if a JV or other form of private resolution raises competition
concerns for ICANN, they should have the right to refer it to relevant
competition authorities to ensure they are ok with it.    This protects
ICANN the institution from charges that it is fostering anticompetitive
behavior.

Jim Prendergast

The Galway Strategy Group

+1 202-285-3699

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20200727/bf7310a6/attachment-0001.html>