Skip to main content

Approved Board Resolutions | Special Meeting of the ICANN Board

Batching of New gTLD Applications: Secondary Timestamp

Whereas, the window for applying for new gTLDs opened on 12 January 2012, and is scheduled to close on 12 April 2012.

Whereas, the New gTLDs Applicant Guidebook (section <> indicates that if the volume of applications received significantly exceeds 500, then applications will be processed in batches.

Whereas, on 8 December 2011, the Board adopted a resolution (#2011.12.08.4a) authorizing the development of a plan to use a "secondary time stamp" for determining the processing order in the event that multiple batches are required.

Whereas, the New gTLDs program team has developed proposed operational details of a plan for implementing a secondary time stamp, now referred to as "digital archery".

Whereas, some members of the community have expressed concerns about whether the digital archery proposal is sensible and fair, and an informal subgroup of the Board has studied the feasibility, benefits, and risks of the proposal as well as alternative batching mechanisms such as auction.

Resolved (2012.03.28.01), the Board confirms the approval of secondary timestamp/digital archery as the mechanism for sorting new gTLD applications into batches, and directs that the operational details of the mechanism be communicated to applicants and the public as necessary and appropriate.

Rationale for Resolution 2012.03.28.01

The reaffirmation of the Board's commitment to the secondary timestamp/digital archery is taken after an review of alternate proposals for batching processes considered after hearing the community's comments and concerns as raised at the ICANN meeting in San Juan, Costa Rica. A small group of the Board intensively looked at the digital archery solution, a potential auction solution, and considered the prioritization comments provided by the community. For the ongoing application round, affirming the digital archery process is the fairest way to achieve a non-random batching solution that accounts for diversity across all regions of ICANN. The Board also reaffirms the Rationale for Resolutions 2011.12.08.04 – 2011.12.08.06.

The batching selection process determines how applications will be divided into batches and prioritized for evaluation analysis. Conceptually, the batching selection process is relatively straightforward and includes the following four steps:

  1. Applicants register in an online batching system to select their batching preference (i.e., earliest or any batch) and select a target date and time (e.g., Target Date: 10 May 2012 and Target Time: 12:00:00 UTC);
  2. Applicants re-enter the online batching system and generate a message that is sent from their computer/system to the online batching system. The online batching system records the date and time the applicant's message is received. (e.g., Message Received Date: 10 May 2012 and Message Received Time: 12:00:01);
  3. The system calculates the time variance between the applicant's Target Date/Time from step 1 and the Message Received Date/Time from step 2. This time variance is known as the applicant's "secondary timestamp" Based on the example in steps 1 and 2 above the secondary timestamp is 1 second. The closer to zero the secondary timestamp is the more likely the application will be processed in the earliest batch, assuming the applicant has opted in to the earliest batch.
  4. The batching selection process then combines the applicant's batching preference (i.e., earliest or any batch), the "secondary timestamp" (e.g., 1 second), and the geographic region to determine the batch/processing order for the specific application.

However, the implementation of the online batching system must be undertaken with care and it must ensure that a secure, consistent, and objective process is available for all applicants. The operational details of the online batching system have considered and addressed a number of concerns. Those concerns include ensuring that:

  1. The details of the batching selection process are clear to applicants, through direct communications with them;
  2. Only authorized applicants can enter the online batching system to perform the specific tasks necessary to complete the batching selection process;
  3. An opt-out mechanism is available so applicants can designate their batching preference (i.e. earliest or any batch);
  4. The online batching system allows applicants to perform their tasks without hindrance (i.e., system remains available during appropriate times);
  5. Latency concerns are addressed in a fair manner so that applicants are not put at an advantage or disadvantage based on their geographic location;
  6. The target time variance is measured at a level that allows ICANN to adequately determine batches; and
  7. Applicants are allowed to practice portions of the process to understand how the target time variance will be calculated.
  8. The goals of geographical diversity and fairness are taken into account.

Accordingly, to ensure that applicants and prospective applicants are aware of the batching selection process the Board has determined that it is appropriate to take this action now. The Board is therefore approving the operational details of the batching selection process and is authorizing the CEO to release the details of this plan.

Providing for this now will allow the community and applicants to understand when applications will be processed if a large number of applications (i.e., significantly more than 500 applications) are received by ICANN.

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"""" is not an IDN."