NOVELL, INC.

1. TLD String(s) Requested.

   .dir

2. Category.

   New Services, Other.
   
   Novell, Inc. (“Novell”) requests the .dir TLD to allow for the joining of new and existing directory services. This type of directory service is generally not available on the Internet today and qualifies Novell for the new services category, other group.

3. Sponsor, Registry Operator and Subcontractor.

   a. Sponsor. Novell is a public (traded on Nasdaq-NMS), for profit corporation incorporated in Delaware. Novell claims to have helped invent the corporate network in the early 1980s and that it continues to drive technology for the Internet today. Novell worked with local area networks ("LANs") in the early 1980s and has seen those develop into wide area networks ("WANs"). Novell now envisions and is working toward solutions to allow intranets, extranets, the Internet, corporate and public, wired and wireless work together.

   b. Registry Operator. Tucows, Inc. ("Tucows") was formed in 1994 and incorporated on May 1, 1999 in the state of Delaware with its principal office in Toronto, Ontario. Tucows describes itself as a leading distributor of e-business services and applications on the Internet and to have a network of more than 4,000 Internet service providers, web hosting companies and domain name resellers in more than 100 countries around the world. Tucows further purports that its website offers over 30,000 software titles in libraries located around the world, providing users with fast local downloads. Tucows is an ICANN accredited registrar and claims to be a leading provider of wholesale domain name registrations and related services.

   c. Subcontractor. None listed.

4. Registry-Registrar Model.

   Novell intends that registrar selection and competition will occur within the existing structure as set forth in current and future ICANN Registrar Accreditation Policies for the existing general TLD namespace. End-user domain-name holders will exclusively register through registrars.

1. Summary Description of Proposal.

   Novell proposes a .dir TLD. This TLD would, in principle, allow all existing directory services to be joined via entries in this TLD. For example, this service could be used to allow a human user to hook up to differing devices under different circumstances, while providing him service customized to each device without ever changing his name. In practice, the system will only work with LDAP servers. The applicants suggest a naming scheme where only names already registered under another TLD could be registered in .dir. They are registered in the new domain under their old domain name with a “.dir” appended. For example, the owner of amazon.com could register for amazon.com.dir. Only systems running conformant LDAP servers would be registered.

2. Support of the Business Plan by the Technical Plan.

   a. Total Capacity. The application does not provide enough detail to determine whether they are prepared for the load that will eventually result, if successful. There are some concerns about their ability to handle peak loads. Details of the billing and collection system are sketchy.

   b. Projected Growth Rate. They anticipate an oddly slow initial growth rate, perhaps predicated on the restrictions to register, particularly the restriction of having running LDAP services. Nonetheless, their estimate that only 1000 names will be registered the first day, without any artificial methods of their own to limit the number, seems very low. Eventually, they expect to grow to vastly larger size, up to 5-10 million domains in four years.
   
   The applicant states that the current database will support up to 250 transactions per second (registry). This should be acceptable, although it is unclear how the traffic to a directory might differ from the traffic to “normal” services.

   c. Startup Period. Novell and Tucows make no special provisions in the startup period.

   d. Fault Tolerance. Tucows will use Exodus Communications to run their hardware. The plan calls for duplicate registries in widely separated locations, and even more DNS servers in even more locations. Backup procedures and data escrow seems appropriate.
   
   It appears that the Whois facility is duplicated only within the central location and is not duplicated geographically. While Whois is not a critical application geographic distribution would improve the overall “image” of system reliability.

   e. Security. The use of Exodus Communications offers strong physical security measures. Some issues of security are a little underspecified, such as the password procedures used and whether links between sites are properly secure. Issues of securing the connections between the mirrored facilities should be more completely discussed. There is no discussion of logging and monitoring facilities for security purposes, nor of periodic security reviews of the system. The proposal would benefit from inclusion of details on how audit trails would be performed to track changes to the registrar database. For example, it would be useful to track changes in registration.

3. Summary of Relevant Experience.

   Novell brings vast experience in computing and networking to the proposal. They will apparently primarily be involved in defining policies and perhaps in independently building solutions to use the new capabilities of the TLD. Tucows will actually run the registry. Tucows has served as a registrar, and has developed registry software that others at least propose to use. Tucows has run a fictional TLD to test their software, which has successfully handled approximately 200,000 registrations.

4. Apparent Implementation Risks.

   The architecture does not make a very clean separation between the registry and registrar software, which could lead to problems since this TLD allows external registrars to communicate to the registry. There is, in particular, no specification of how a registrar outside of their administrative and physical domain might properly and safely interoperate with the registry service.
   
   The XML-based registration protocol they propose to use is apparently largely untested. While they will also support RRP, it is possible that the inclusion of the experimental protocol will lead to problems. Similarly, they propose to use their own software to run the registry. Apparently, that software has no history of running registries, so there is a risk that it is flawed.
   
   It is uncertain whether the proposed architecture will be up to peak demands for registrations. Presumably the system should be designed for some significant fraction of all registrations in all TLDs. The proposal claims that several servers, each capable of handling 286 registrations per second, will handle peak capacity adequately, and, since more servers can be added, the system can be expanded as necessary.
   
   Unlike many other proposals, this one has a noticeable impact on the existing DNS system. The .dir TLD will only register domain names that are variants on domain names that already exist in other TLDs, and hopefully only to the legitimate owners of those names. Thus, whenever the .dir TLD wants to register a new name, it must perform a Whois lookup or something equivalent on the existing name that has been submitted, to verify that it belongs to the entity making the request. As the load of new requests for names in the .dir TLD goes up, additional traffic is added to the Whois service of existing TLDs. Over the course of 4 years, the .dir service expects perhaps 10 million registrations, a drop in the Whois bucket over that period. There is some possible concern, however, that the registration spike during the early days of the service (or whenever they expect their sudden growth to occur) could temporarily burden the Whois services of existing TLDs. Further, unless some care is taken, spurious requests for registration of non-existent domain names under the .dir TLD could be used to launch denial of service attacks on other domains’ Whois services.

5. Available of Human, Operational and Technical Resources to Cope with Unexpected Events.

   Surprises unrelated to the special mission of the .dir TLD can probably be handled with the available resources. Since Tucows has not run a production TLD, there is some risk that they lack some skills required, but their experience with registrars and registry software is comforting.
   
   The special features of .dir tread new ground, and thus more, and bigger, surprises are likely to come from this direction. If Novell is strongly committed to the enterprise, they are likely to have reasonable human, operational, and technical resources to cope with such surprises.

6. Advancing the State of the Art.

   The proposal calls for using the Internet naming system for a new purpose, with potentially large benefits. These benefits would largely be realized by those making use of the fairly modest new capabilities of the new service itself, but rather by those who use those modest services to hook together things that were previously hard to connect.

7. Other Comments.

   This is a novel idea, somewhat underdeveloped in its more radical implications.
   
   Although the applicant proposes a new registry protocol, it would still directly support the current protocol. It appears this will be done using separate server subsystems. This should improve reliability during the period when the new protocol is under development.
   
   This proposal assumes that any registered name will “connect” to an LDAP service. This is only verified during initiation. In any case the verification seems very cursory in that only a simple check will be done. A more rigorous approach would involve a test of the target against a standard with appropriate diagnostics. Periodic testing and notification might also be advisable. In the case of this proposal it would seem that this testing could be fully automated.

1. Applicant’s Representations.

   Novell provides Net services software that delivers services to secure and power all types of networks – the Internet, intranets, and extranets; wired to wireless; corporate and public, across leading operating systems. Novell’s vision includes a world in which all types of networks work together as one Net to simplify the complexities of e-Business and provide the power and flexibility organizations need to succeed in the Net economy. For the fiscal year 1999, it has approximately $1.3 billion in net sales and $1.5 billion in shareholder’s equity.
   
   Novell’s application states that while the Internet has revolutionized the world, it has also created the problem of multiple identities including multiple email addresses, phone numbers, web sites, and mailing addresses. This has compounded the problem of finding anyone or anything. Novell plans to solve this problem with the new .dir TLD. This TLD will become a rendezvous point for all existing and new directories. With the .dir namespace, identities that already exist can be used and the information associated with those identities is always available and is always secure.
   
   Tucows was originally founded as a distributor of software on the Internet and also offers Internet users software reviews, a rating system and editorial resources. The company is an accredited registrar and operates the Open SRS, which is a source of wholesale domain names. Tucows has over 200 employees.
   
   The revenue model is subscription based with a registry price of $6 per name per year with a one-time license fee from the registrars. The total expected demand in years one and four is approximately 1.5 million and 6.4 million, respectively. There is an expected 88 percent renewal rate.

2. ICANN’s Evaluation.

   This application’s strength is because it contains a different approach in bringing new services to the top-level domain. The weakness of this application is that its marketing plan is not sufficiently discussed. There are also questions regarding whether or not the market will accept the new service. From a business plan perspective, this application might result in a successful venture given the capabilities of Novell, but the risks of market acceptance are great.

1. Number of Comments.

   15

2. Support for the Application.

   Novell’s experience with the technology extends back 7 years.
   
   .dir will provide a simple mechanism for a company to register its participation in the Public Directory Network.
   
   The standard access and simplified namespace offered by the proposal will help accelerate e-business applications.
   
   Novell’s proposal will assure that the identities of people and organizations are “unique and that their associated attributes and values are accurate and secure.”

3. Opposition to Application.

   .dir is too narrow.
   
   The proposal is lacking in technical specificity and has other potential technical problems.