Uniregistry told ICANN in its comment filed on the subject,  that one year was too short of a period.

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 20­45 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.

Name Collisions

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.

Bidder Agreement

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.

A. Anti­Collusion

The agreement includes an anti­collusion 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 post­Auction 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 anti­collusion 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 pre­auction 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 anti­collusion 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 anti­collusion provisions are overly vague and leave too many details up for interpretation.

The anti­collusion 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 anti­collusion 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 close­knit nature of the ICANN community, the anti­collusion 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.