Today ICANN put out a request for a contractor to add yet another layer of complexity, expense, delay, and unnecessary bureaucracy to the ICANN's "new Top Level Domain" process.
One can only wonder how the statement of work for this contactor was generated in advance of ICANN completing its new TLD criteria project. Is this yet another instance of ICANN's "staff" simply doing what it wants to do and ignoring ICANN's board and the community of internet users? There is definitely more than a hint of that smell.
In either case, ICANN's new TLD policy has grown beyond all rational bounds. All that ICANN should be asking is whether applicants will abide by well established technical standards and practices regarding their name servers.
In order to speed things along, I have taken the liberty of putting together the first draft of a form that ICANN could use to for TLD applications; this form also sets forth the basic terms of operation. The idea here is to dispense with all of ICANN's massively expensive machinery that reviews all of those irrelevant things that ICANN so loves to stick its nosy nose into. For example, ICANN has no more legitimate right or need to evaluate how a TLD will operate its front office registration systems than does the FAA to evaluate whether an airline serves Pepsi or Coke to its passengers.
So here it is:
Version 1.0
This form is for use by those people and organizations that wish to obtain a "slot" for a Top Level Domain delegation in the root zone file published by NTIA, ICANN, and Verisign as provided in agreements between those three entities.
A "slot" is a right to have an applicant selected character string placed into that root zone along with applicant provided name server information as necessary to activate a domain name system delegation from the NTIA/ICANN/Verisign root zone to the applicant's own name servers.
The character string proposed by the applicant must be a valid Domain Name "label" as defined by RFC 1035, the character set for the string must be a valid "ARPANET host name" as described in RFC 1035, and the string must conform to internationalized name requirements as described in "Guidelines for the Implementation of Internationalized Domain Names".
The applicant proposed character string must not have been previously used in the NTIA/ICANN/Verisign root zone.
The applicant must anticipate that in the event that this application is accepted that it will be required to provide operational name server information before the proposed name will be placed into the NTIA/ICANN/Verisign root zone.
The applicant must also anticipate that it will be required to perform yet unspecified activities with regard to Domain Name Security (DNSSEC) deployment.
Neither ICANN, NTIA, nor Verisign will review the semantics or other meanings or uses of the proposed string. The applicant is responsible for any and all conflicts. NTIA, ICANN, and Verisign reserve the right to promptly respond to any legally valid order ordering NTIA, ICANN, or Verisign to take an action regarding the status of the applicant's slot or proposed name.
Neither ICANN, NTIA, nor Verisign will require that applicant adhere to any particular business plan or any restrictions on the use of names it may subsequently place into its own servers under the delegation obtained via this application.
The applicant must, however, recognize that the internet spans many nations and that the applicant must conform its activities to the requirements and constraints of an evolving and sometimes conflicted background of national laws, regulations, and international agreements.
By making this application, the applicant explicitly recognizes each person and aggregate entity that makes use of the internet is an intended third party beneficiary who, by virtue of this application, is entitled to have standing to bring legal actions to enforce the obligations imposed directly or indirectly through this application.
The applicant must anticipate that ICANN may impose (and, over time, modify) technical obligations on the applicant's name server operations. These obligations will define how the applicant shall operate its name servers in accord with certain broadly accepted and utilized written technical standards.
The applicant must anticipate that ICANN may impose (and, over time modify) certain obligations of fair and equitable access to its domain name service, including, but not limited to, the following:
The applicant will be required to publish to the public a signed statement from an auditor skilled in the practice of preservation of business assets that describes and evaluates whether the applicant's actual business asset preservation practices are adequate to allow the applicant or a successor in interest to revive the applicant's name services and client base should the applicant or its systems suffer a human or natural disruption.
The applicant must recognize that the total number of top level domains, albeit large, is finite and that ICANN may impose constraints on the number of applications that may be accepted at any one time.
All applications, except those that are explicitly rejected, will be maintained in an active status.
ICANN reserves the right to utilize various mechanisms to chose among the active applications. Among these are auctions in which active applicants may bid for a slot or a lottery in which a limited number of random selections may be made among all active applications.
| Applicant Name: | ||
| Applicant Address: | ||
| Applicant email: | ||
| Applicant telephone: | ||
| Proposed string: |