Google Registry in its comment filed on the ICANN Last Resort says ICANN plan to conduct all of the Last Resort Auctions within one year is too long.
Google wants the ICANN Last Resort Auctions to be all held within 6 months.
Google Registry also makes a very good point that under the proposed ICANN Last Result Auction rules, there is a 30 days prohibition, once the date of a Last Resort auction is scheduled, from the parties to the auction to communicate.
In the case of applicants that have a many strings in contention like Google, if they are in an auction for March for one string, lets say against Amazon, Donuts, Famous Four and Top Level Domain Holdings they would be barred from talking to each other about any other strings they had applied for thereby eliminating the possibility of private auctions for many other strings that are not scheduled for auction.
Here is Google Registry’s letter to ICANN:Duration of Auction Process Still Too Long
ICANN has stated that the public auction process will not last longer than one year.
We feel that this is still too long to wait for all string contentions to be resolved especially given the late stage we are in within the new gTLD program.
While it is understood that ICANN may be trying to promote other means of resolving contentions by constructing less than advantageous auction conditions, in many situations we expect that contention sets will be required to proceed to ICANN auction, especially given that an entire contention set must agree to a designated path forward (e.g., all must agree to do a private auction or all must agree to form a partnership, etc.).
We feel a more appropriate time window is to have all auctions completed within six months, which would still allow ICANN ample time to carry out auction events while at the same time not significantly disadvantaging applicants with higher draw numbers.
B. Timing between Auction Rounds is Still Too Short
ICANN has set the initial auction round time at 30 minutes and all subsequent rounds at 20 minutes.
We appreciate the increase in time ICANN has provided (up from 10 minutes) in this draft, but still feel that more time is needed.
In some situations, Applicants will be making decisions potentially impacting millions of dollars and 20 minutes is simply not a sufficient amount of time to make these kinds of decisions.
The Applicant Guidebook (AGB) initially envisioned 2045 minutes between rounds and, therefore, we would recommend ICANN allow a maximum of 40 minutes between rounds, which still falls within the originally constructed window.
Given that ICANN is only allowing 10 rounds total, increasing the time to 40 minutes would only be a total increase in the overall auction time by a little more than 3 hours. ICANN could allow applicants within a contention set to shorten the timing between rounds in the event that all applicants mutually agreed.
Research suggests that in order to increase the efficiency of an auction it makes sense to increase the number of concurrent auctions while at the same time lengthening the timing between auction rounds. The speed of the auction is generally determined by the step size multiplied by time per step. The efficiency loss associated with a step size is roughly proportional to the step size squared, so if the step size is 10%, that is a 1% efficiency loss or less. Thus one thing ICANN can do to increase efficiency within this system is to have a sizeable step size (more simultaneous auctions) coupled with more time between steps (more time between auction rounds), thereby keeping the auction running briskly while at the same time providing time for deliberation.
As it currently stands, ICANN is allowing applicants to proceed into auction who have received the TLD specific Name Collision Occurrence Assessment based on the Name Collision Occurrence Management Framework. However, in some cases the remedy prescribed by the Name Collision Management Framework may adversely impact the perceived value of the string and, therefore, may impact individual bidding strategies.
ICANN should allow all TLDs, which are impacted by the name collision mitigation plan, to have the option to delay going to auction until the final mitigation plan is released. However, ICANN could provide an “opt in” option where if all applicants within the contention set would like to proceed to auction, they will be given the option to do so.
Conversely, the Name Collision Occurrence Assessment singled out 25 strings not receiving a Management Framework and, therefore, ICANN has noted that these 25 strings will not be able to participate in public auctions until the final mitigation plan is released. ICANN should also allow an “opt in” option for these strings as well. If everyone within the contention set agrees to move forward toward auction, then they should be allowed to do so.
Rules Governing Indirect Contention Sets Still Not Decided
We understand that the AGB outlines the general rules for how ICANN will deal with indirect contention; however, ICANN has still not finalized the relevant procedures. The process is obviously more complicated than was likely initially envisioned. Since only a handful of contention sets are involved,
ICANN should simply move all applications in a contention set, whether through direct or indirect contention, into a single grouping for the purposes of the auction procedure. This approach is simpler for ICANN to administer and more predictable for applicants.
We appreciate ICANN releasing the Bidder Agreement with the other auction documents as this agreement is an important part of the auction process. That being said we have many critical concerns with the draft agreement as written, which we outline in detail below. A main point to stress, however, is that if this agreement were to go forward as drafted it would likely be incredibly difficult for many applicants to sign in its current state.
The agreement includes an anticollusion provision tied to a severe penalty for any violations. It states that Bidders are:
prohibited from cooperating or collaborating. . . , discussing with [or disclosing to] a competing applicant . . . bids or bidding strategies, or discussing or negotiating settlement agreements or postAuction ownership transfer arrangements . . . until after ICANN has received full payment . . . .
Any violations of this rule are considered to be a “serious violation” under the agreement, subjecting Bidders to complete deposit forfeiture or Registry Agreement termination.
While Google strongly supports anti-collusion and confidentiality protections, in this case we are concerned that ICANN is sending decidedly mixed signals to the community.
On the one hand, the AGB and ICANN itself has promoted applicants working together to resolve string contentions, before they are sent to a formal public auction, calling the auction process the “contention resolution means of last resort.” Working together will necessarily involve negotiation and, if the negotiation is successful, concerted action among applicants.
On the other hand, ICANN has now included anticollusion language that not only prohibits negotiation once the contention set is formally sent to public auction, but may be perceived as discouraging alternative resolution prior to the last resort auction.
Parties in contention may become Bidders in the auction, after having already engaged in negotiation.
Further, applicants with more than one application will be concurrently negotiating resolution for some strings while simultaneously being involved in auctions for other strings where such contact is prohibited.
Concerns may arise over whether such previous or concurrent contacts create actual or apparent, explicit or tacit coordination between Bidders in the auction.
As a result, there could be a significant chilling effect on the preauction negotiations that the AGB encourages.
We believe that the issues posed by Section 2.10 can be mitigated by amendments which reaffirm ICANN’s commitment to resolution of contention sets prior to the last resort auction and make clear that arrangements reached prior to the deposit deadline, including arrangements for joint bidding, do not violate the anticollusion provision add clarity as to the precise nature of the prohibited conduct; and expressly outline the methods of investigation and fact finding.
As written, the current anticollusion provisions are overly vague and leave too many details up for interpretation.
The anticollusion and penalties provisions should identify: 1) who will determine whether collusion has taken place; 2) what constitutes a “serious violation” of the Bidder Agreement; and 3) the appropriate remedy along the spectrum. Further, ICANN should clarify that the anticollusion rules contained within the agreement will only apply to the specific TLD that has reached the auction stage and for which the agreement was expressly signed and will not prohibit parties with remaining contention sets to continue negotiating a potential resolution for other TLDs.
The remedy for serious violations of the Bidder Agreement should also be limited to the specific TLD at issue and should not result in forfeiture of other TLD applications or termination of other Registry Agreements. We, thus, recommend that a neutral third party with investigative powers serve this role, akin to the “mutually acceptable mediation provider entity” described in the Bidder Agreement.
In addition, given the closeknit nature of the ICANN community, the anticollusion provision should set forth a burden of proof, perhaps clear and convincing evidence, necessary to establish collusion. For example, employees from two applicant entities sharing dinner during an ICANN meeting should not necessarily raise the specter of collusion (as there are many reasons unrelated to gTLDs why people meet) whereas something like a written admission could naturally suffice. These obligations should also be mutual, and the Auction Manager should be required to represent and warrant that it is independent and has no relationship to any Bidder in any Auction.
B. Bidder Agreement Amendments
The agreement also includes a sweeping amendment provision that provides limited notice to applicants (and the ICANN community in general) for when the Agreement might be amended by ICANN. ICANN is “entitled to amend the Auction Rules for any Auction at any time prior to the Deposit Deadline for that Auction” and will “inform the Bidder of such changes via electronic written notice,” causing the changes to “be effective immediately.”
The ability for ICANN to amend the agreement at any time is particularly troubling when coupled with the potential for severe penalties for violations of the Bidder Agreement. This language welcomes scenarios where the Bidder Agreement is amended, electronic written notice is only sent to “Bidders”, and the entire remaining pool of applicants in string contention, who have notalready signed the Bidder Agreement, receive no such notice. This language also leaves the possibility for substantive changes that will take place mere moments preceding an auction taking Bidders completely by surprise and providing them no recourse.
Accordingly, notice regarding modified or additional language should also be published conspicuously by ICANN for all applicants on the New gTLD website, and the start of any auctions scheduled to take place within seven calendar days should be automatically delayed until seven days after notice so that Bidders may reevaluate their strategies to comport with the new rules. In addition, only changes made for legal reasons—such as developments in the governing law—should be effective immediately with notice given at least seven calendar days absent any retroactivity.
C. Indemnification, Waivers Of Liability, And Release
The agreement includes a unilateral indemnification provision with a singular limitation for cases of gross negligence or willful misconduct.8 First and foremost, the language in this provision is overly broad. “The Bidder expressly releases, indemnifies and holds harmless the Auction Manager from any and all claims … whether direct or indirect, which may arise from, or be related to the Auction ….” Id.
Consider a scenario where a Registry wins an auction due to a “disturbance in the technical process” or failure in receipt of bids that negatively impacts a competitor. According to this provision, were the Competitor to sue the Auction Manager, the Registry would be required to indemnify against that claim despite the fault lying purely with the Auction Manager. That is why indemnification provisions are ordinarily tethered to third party claims arising out of your own (e.g., the Registry’s) conduct, breach of the agreement, improper use of the service, or breach of any laws or rights of a third party. Accordingly, the language must be circumscribed to limit indemnification to all claims raised by third parties which may arise from the Bidder’s conduct.
In addition, the closest thing resembling a warranty on the part of the auction provider reads, “the Auction Manager acknowledges its obligation to make a goodfaith effort to administer the Auction in accordance with the Auction Rules.”9 There should be a clause pertaining to the Auction Manager clarifying their obligations under the agreement and their duty to run a working auction platform. As written, there will be no recourse for any Bidder, where the auction site experiences a glitch changing your bid, due to the negligence of the auction provider, as this is explicitly excluded in the agreement.
In general, there is no reason that the Bidder’s representations and warranties in Sections 2.1, 2.2, 2.3, 2.5 2.6 should not be mutual.
D. Dispute Resolution Through Arbitratio
The mediation and arbitration provisions in the Bidder Agreement mirror the same provisions in the new gTLD Registry Agreement.
Similarly, both the Bidder Agreement and Registry Agreement provide the Auction Manager with the ability to request uncapped punitive or exemplary damages, or operational sanctions in the event the arbitrator finds repeated and willful material breach. Such language is inappropriate in the Bidder Agreement, particularly given that an uncapped extra level of damages cannot serve as a deterrent where there will be little or no future conduct between the parties. We also note that Section 2.10 already provides for operational sanctions and forfeiture of deposit for “serious violations” of the Bidder Agreement. Although we believe Section 2.10 needs to be reworked, the penalties in Section 2.10 ultimately should be more than adequate to serve as a deterrent against repeated and willful breaches of the Bidder Agreement. We, therefore, propose removing the punitive damages, exemplary damages, and operational sanctions language from the dispute resolution provision.
In the event punitive or exemplary damages remain in the Bidder Agreement, they should be mutual accounting for where the arbitrator finds repeated and willful material breach of the Auction Manager obligation to “make a good faith effort to administer the Auction in accordance with the Auction Rules.”
While we appreciate all of the work by ICANN staff in revising the auction rules, we still feel that improvements could still be made, specifically shortening the overall auction timeline to six months as well as increasing the length of time between specific auction rounds to 40 minutes.
In terms of the Bidder Agreement, which is a new document, we feel that more work needs to be done here to protect the interests of ICANN and Bidders alike.
Specifically, ICANN’s ability to unilaterally amend the rules or agreement at any time without notice, the severe penalties for infractions with no corresponding definition of what constitutes an infraction, and the odd indemnification language render the document likely incapable of being signed by many applicants at this time and we urge ICANN to adopt the recommendations noted above.
We look forward to working with ICANN as we move forward into the public auction phase of the new gTLD program.
Policy Manager and Primary Contact