[CPWG] [registration-issues-wg] Auctions // At-Large/ALAC positions to New gTLD Subsequent Procedures Supplemental Initial Report

[Seun Ojedeji]

Hello Olivier,

Thanks for bringing this to our attention. I share the concern of CW but I
think the proposed text may be an incomplete solution.

Unless RFP is an acronym with different meaning within ICANN, if it means
Request For Proposal then it needs to be clear how the selection will be
done between all submitted RFPs as I think that is the difficult part. It
may be good to hear details/summary of how CW envisage this happening.

Regards

Sent from my mobile
Kindly excuse brevity and typos

On Fri, 14 Dec 2018, 09:45 Olivier MJ Crépin-Leblond <ocl at gih.com wrote:

> Dear colleagues,
>
> on our last CPWG call, Christopher Wilkinson presented his opposition to
> Auction being used as a mechanism of last resort to resolve contention sets
> within the Program.
>
> The current proposed ALAC response ( https://community.icann.org/x/Jh68BQ
> ) says:
>
>
>
> *The ALAC supports the retention of auctions to be conducted by
> ICANN-appointed auction service providers as a mechanism of last resort to
> resolve contention sets within the Program in the first instance, with more
> guidance and resources to be put in place to help applicants get out of
> contentions sets voluntarily. The ALAC further proposes the ICANN Community
> explore the introduction of a multiplier-enhanced Vickrey auction in place
> of the regular highest-bid auction process as the resolution mechanism of
> last resort. *Multiplier enhanced Vickrey auctions are sealed bid
> auctions where the applicants benefiting from Applicant Support Program, or
> Community Priority Evaluation, have their secret bid automatically upgraded
> by a fixed but capped multiplier (such as factor of 1.25 for example) (eg.
> such an applicant’s bid of US$400,000 is automatically deemed as US$500,000
> when eventually ‘revealed’ in a Vickrey auction)
>
> The ALAC response also says: "*The ALAC continues to hold the belief that
> auctions, by design wherein the highest bid prevails, will naturally favour
> applicants with access to the greatest financial resources or deepest
> pockets and by extension, disadvantage less wealthy applicants (such as
> Applicant Support Program applicants). Whereas it is not always the case
> that the “best” applicant is the one with the most resources.*"
>
> Christopher's proposed response says:
>
> *2.1.c.1    In general I do not support auctions They favour the parties
> with the 'deepest pockets'. They also burden the successful applicant with
> financial liabilities, particularly if the auction has been financed by
> debt or third party investment. Those additional costs will be passed on to
> the eventual registrants through fees and charges.*
>
> *It would be better if TLD registries were operated on a not-for-profit
> basis in the public interest. This would also reduce the financial
> incentive not to cooperate and to go to a forced auction.*
>
> and
>
> *2.1.d.2.1    Agreed. The RFP options should be thoroughly explored and
> codified. In the case of geographical TLDs the RFP should be undertaken by
> the public authority or other responsible entity in the geography
> concerned. The successful applicant's registry should be incorporated in
> that jurisdiction.*
>
> Thus Christopher favours a RFP process to choose the winner of a
> contention set.
>
> With only a few days to go until this Statement is frozen (19th Dec), we
> need to reach a consensus on this - as I have heard several people mention
> they do not want auctions, should a minority Statement be included in
> response to this question? Let's please discuss this topic now.
>
> Kindest regards,
>
> Olivier
>
>
> _______________________________________________
> CPWG mailing list
> CPWG at icann.org
> https://mm.icann.org/mailman/listinfo/cpwg
> _______________________________________________
> registration-issues-wg mailing list
> registration-issues-wg at atlarge-lists.icann.org
> https://mm.icann.org/mailman/listinfo/registration-issues-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cpwg/attachments/20181214/6f3e4700/attachment.html>