A. General Description of the Application
- TLD String(s) Requested.
General Purpose. General.
The JVTeam, LLC (“JVTeam”) requests the .biz TLD. JVTeam .biz targets a broad registrant base, large end user group and focuses primarily on commercial applications. As a result, JVteam’s .biz request qualifies for the general purpose category, general group.
- Sponsor, Registry Operator and Subcontractor.
b. Registry Operator.
JVTeam is a newly formed, limited liability company, organized under the laws of the State of Delaware, created to function as a registry. JVTeam's parent companies are NeuStar, Inc. ("NeuStar") and Melbourne IT Ltd. ("Melbourne"). Melbourne was founded in 1996 as a wholly owned subsidiary of the University of Melbourne. In 1999 Melbourne became a publicly traded company listed on the Australian Stock Exchange. Melbourne's products and services include: (1) domain name registration, maintenance and related service and products, (2) advanced telecommunications services and products, (3) an incubator program and (4) research and development. Melbourne’s principal place of business is Melbourne, Australia. NeuStar, a Delaware corporation, was originally founded in 1996 as an independent communications industry services business unit within Lockheed Martin. NeuStar designed, built and continues to manage one of the largest databases in the world and now serves as the North American Numbering Plan Administrator. It operates the telephone numbering registry for the North American Numbering Plan as a Public numbering resource. NeuStar is also the Local Number Portability Administrator for the US and Canada, operating the routing registry, the Number Portability Administration Center Service Management System for North America. NeuStar’s principal place of business is in Washington, D.C.
- Registry-Registrar Model.
JVTeam intends to follow the existing guidelines for registry/registrar relations established by ICANN for the .com, .net and .org registry.
B. Technical Review
- Summary Description of Proposal.
The proposed TLD.biz will be an alternative to the .com TLD. The domain will be for commercial use only. Registrations will be made only at the second level.
Proposers will build their own DNS server network to handle those duties, rather than rely on existing solutions.
Note that the proposal for this TLD is substantially similar to JVTeam’s proposal for .per. Most of the comments here are common to all three proposals.
- Support of the Business Plan by the Technical Plan.
a. Total Capacity.
The business plan assumes that several million names will be registered. Capacity is based on a distributed server system modeled after previous experience with providing data base services for the North American Numbering Plan and telephone customer/provider assignment. The build plan is based on providing three times the projected steady state load.
b. Projected Growth Rate.
Growth rates are based on surveys and models driven by the survey results. The estimated rate is about one million names per year.
Resource requirements are projected to be about half that of the JVTeam’s similar proposal for .per.
c. Startup Period.
Special provisions to process registrar request in bulk during a startup period. Bulk processing will be used to provide fairness to registrars. This scheme will effectively select names for registration randomly from registrars. The new registry protocol (XRP) would not be used until after the start-up phase. There will be a pre-registration period where trademark holders may provisionally claim names related to their trademarks.
d. Fault Tolerance.
Fault tolerance is based on using redundancy. Physical redundancy is based on using two or more geographically isolated sites. Communications between sites are duplicated and systems within each site are duplicated. Provisions include capability to maintain system operation and performance even with the complete loss of one site.
Geographical redundancy is based on two registry sites and possibly two additional name server sites. Two of the required sites are already in existence and operating in essentially the same manner as the proposed registry and name server sites.
The two data centers will cross replicate critical databases in real time. The proposal does not make entirely clear if both data centers will be simultaneously live for update or in a master/backup configuration. In addition, conventional off-site back up will be used.
The system will use automated tracking of component status with the intention of detecting problems before they occur.
Security measures are based on using end-to-end encryption techniques of off-the-shelf and proprietary origin. JVTeam appears to use current techniques for both physical and transactional security. The billing and collection system is based on password protection, rather than more advanced techniques. Similarly, remote administrative access to the data centers will be authenticated with passwords, rather than more advanced techniques.
- Summary of Relevant Experience.
NeuStar has experience in operating a registry-like service related to numbering and tracking in the telephone industry. Melbourne has experience in operating a registry for .com names in Australia. Experience includes the operation of large, reliable databases and of providing and supporting registry services.
- Apparent Implementation Risks.
The implementation will involve a joint effort between technical teams located in the US and Australia. The teams have a somewhat complementary backgrounds.
Use of a new registry protocol (XRP) will require cooperation between the TLD provider and the registrars.
- Available of Human, Operational and Technical Resources to Cope with Unexpected Events.
The response to anomalies is based on prior experience in supporting large databases and large name registry operations. Experience includes releasing and tracking changes to large software systems.
- Advancing the State of the Art.
The core of the proposal depends upon the use of a new registry protocol (XPR) that would provide a distributed general TLD registry capability. The new registry protocol would be open and would be migrated to standard status. The proposal envisions the addition of many more general TLDs in the near future. JVTeam proposes using the “thick” registry model.
The basic implementation plan is to make the registry services more robust and the registrar services simpler. The reliance on the registry service to maintain all information will provide experience with a different approach to this problem.
The plan envisions fast update to zone files and Whois database, using the XML and high-performance server architecture. The proposal claims to significantly reduce domain-name update time from stated current time of 24-48 hours to less than one hour. The process is based on sending smaller zone file updates more frequently to the name servers using a “diff” approach.
The proposal envisions that the registry will contain the Whois database, but that the individual registrars will provide the front-end for access to the database so that they can “brand” it. The approach is based on an XML-defined approach that would become a standard. The registrars would be capable of adding additional information to the Whois data base (possibly for a fee).
- Other Comments.
The proposal depends upon maintaining name translation table in RAM at each server. Although large the size is manageable. It is assumed that only the basic translation table would be in this table. This mechanism is part of the efficiency basis of proposed scheme.
The Whois inquiry rate seems very high. This appears to be due to anticipated data mining operations, which might be more attractive due to the XML based data record system that is intended to provide more information than currently available from Whois queries.
The registry will build a special laboratory to act as a test bed for registrars and the extended registration protocol.
JVTeam’s proposal is very strong on fault tolerance. Their design uses redundant hardware in all possible places and seems likely to achieve the reliability they regard as necessary for the kind of TLD they propose. The JVTeam has done research to determine likely demand and has designed to meet that demand, while also designing in enough capacity to handle failures and enough expandability to grow for higher levels of demand. The security plan in is generally strong, though it does depend on password authentication in some places. However, it shows good understanding of proper password management.
The JVTeam suggests some fundamental changes to how registration services work, including maintaining all information at the registry and using a different protocol to control interactions between registries and registrars. Its plans for these changes are mature and well considered.
C. Business Review
- Applicant’s Representations.
The operator is the JVTeam formed by Melbourne, and NeuStar.
Melbourne offers domain name registration and maintenance, advanced telecommunications, incubator program, and research and development. In 1996, Melbourne became the delegated administrator of the com.au domain space and in 1999 was selected to be one of the five test-bed registrars for the introduction of competition in the .com, .net, and .org domain space. NeuStar offers regulated services and deregulated commercial services. NeuStar operates the telephone numbering registry for the North American Numbering Plan and serves as the Local Number Portability Administrator. JVTeam can draw upon 353 people, 238 of those are actively engaged in technical disciplines.
JVTeam’s mission is to provide the next generation domain name registry and to contribute positively to the evolution of the domain name system. The application states that the company will innovate by building on the strengths of the existing DNS and will ensure its integrity by acting as a responsible member of the Internet community. The proposed TLD will require applicants to warrant and acknowledge that the site is for business or commercial purposes. However, JVTeam is not intending to audit the applicants.
The revenue model is subscription based. The annual price will vary from a high of $5.30 to a low of $3.75, including discounts, depending upon the volume of registrations. JVTeam is expecting demand at the 50 percent confidence interval of 760,000 and 3.85 million registrations for the years one and four respectively. The company also expects to employ 68 employees by the end of year four.
- ICANN’s Evaluation.
This application has many strengths. It contains a thorough assessment of the market, including primary market research. The target market and marketing plan is well laid out and includes a discussion of the early adopters, followers and laggers. Further, the estimated demand and required resources were thoroughly explored. The company is currently planning on investing significant sums. This is due in part to the forecasted losses in the early periods. The weakness in this application involves large losses forecasted in the early periods. Should the losses continue beyond the firm’s ability to withstand, the firm would have liquidity issues. Overall, this application is a stronger application in this category from a business perspective.
D. Summary of Public Comments
- Number of Comments.
- Opposition to Application.
Three comments are the same negative comments sent to all of the .biz applications. They claim that either .biz is already in existence or that .biz would infringe on .bz. One comment references JVteam’s offer to pay ICANN legal bills.
“The introduction of “.biz” TLD would create substantial confusion among Internet users and also intefere with the “.bz” ccTLD and the existing rights of the country of Belize due to identical pronuciations and the likely meanings under which each TLD would be marketed… The country of Belize has recently licensed its ccTLD for marketing domain names to businesses. The present application for “.biz” also specifics an inten to target and license domain names to businesses. Due to the identical pronunciations and business connotations associated with “.biz” and “.biz,” Internet users would be confused as to which TLD must be used to locate a business related resource. The granting of a “.biz” TLD would therefoe not enhance the diversity and services available under the DNS but rather threaten them by allowing confusion to be created. Thus, a “.biz” TLD would not meet any needs which are not already met by the existing “.bz” registry. JVTeam’s application for “.biz” should therefore be rejected.”
“How come people don’t already know this? .biz exists in the Open Root Server. If ICANN approves a .biz application, then there will be massive chaos. There will be a huge conflict with existing .biz names.”