Brief Overview

Section I: Description and Explanation

ICANN is pleased to announce the publication of an updated version (2013.12.12) of the Auction Rules, the Bidder Agreement, the Bidder Forms, and a Draft Auction Schedule for community review. The Auction Rules have been updated since the initial release of the Preliminary Auction Rules on 1 Nov 2013 based on feedback received including during the Auctions Webinar on 7 November 2013 and the ICANN 48 Meeting in Buenos Aires. The documents being published for comment are:

Auction Rules version 2013.12.12 – provides a detailed insight into all facets of the Auctions program, including eligibility, scheduling considerations, preparation procedures, deposits, bidding limits, bidding procedures, the conclusion of auctions, payments and refunds. This version of the Auction Rules only addresses Contention Sets with direct contention relationships; an update or addendum will be published at later time to address Contention Sets with both direct and indirect contention relationships.

Bidder Forms – allows an applicant to designate itself or another entity to act as the bidder on its behalf. These forms will be used by ICANN and Power Auctions (the Auction Manager) to perform due diligence, set up a bank subaccount and a user account on the Auction Site. The bidder forms must be completed for each application participating in an Auction.

Bidder Agreement – an agreement between the Applicant and/or Bidder and Power Auctions, detailing the roles and responsibilities of each of these parties in the Auction process. The Bidder Agreement must be executed at least one time for each Applicant, and if an applicant utilizes a Designated Bidder, the agreement must be executed for each unique configuration of Applicant and Designated Bidder.

Draft Auction Schedule – Using the preliminary contention sets which do not include the effect any objection determinations may have, a Draft Auction Schedule has been created. This schedule utilizes the scheduling criteria defined in the Auction Rules but, due to the dynamic nature of application status, does not take into account the eligibility requirements for a contention set to be sent to Auction by ICANN as defined in the Applicant Guide Book and the Auction Rules. Should contention sets either resolve prior to their scheduled Auction or not yet be eligible for an Auction, ICANN will adjust the schedule in attempt to maintain approximately 20 contention sets per Auction.

ICANN intends to publish a Master Escrow agreement between ICANN, Power Auctions and the Escrow Provider for informational purposes prior to the conclusion of the public comment period. It is not envisioned that Bidders will execute an agreement with the Escrow Provider; rather the Bidder's Agreement will create a relationship where the Bidder will be a third party beneficiary to the Escrow Agreement. The Escrow provider will establish accounts by Bidder to securely hold deposits, issue refunds to Bidders based on the Auction Results, and collect winning fees on behalf of ICANN.

All feedback will be taken into account, but community feedback on the following topics will be especially helpful.

The pace and schedule of auctions to resolve all outstanding contention sets

The duration of auction rounds and recesses between rounds

The effects of the Name Collision issues on the eligibility for auction of a contention set

With the input from the community in this public comment period, ICANN will complete and publish the Auction Rules, Bidder's Agreement, Bidder Forms and move forward to administer Auctions to resolve string contention sets on the new gTLD program.

Section II: Background

Section 4.3 of the Applicant Guidebook describes auctions as the last resort method to resolve string contention sets. This section provides for an Ascending Clock Auction methodology and provides an overview of the process and simplified illustrations of the execution of a contention set auction. On 1 November 2013, a preliminary version of the Auction rules was published. The Auction Rules were published as preliminary because there were several aspects related to scheduling that would benefit from community feedback prior to finalization and execution of the Auction program. The Auction Rules have since been updated to provide more details of the Auction processes and procedures as well as to incorporate community feedback received since the initial publication.

A note about tracking cookies:

This site uses cookies to deliver an efficient user experience and to help us see how the site is used. If you would like to read more about the use of cookies, click here

This notice is intended to appear only the first time you visit the site on any computer.OK

Domain Name System

Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."