Sponsored ".dir" TLD Application

Description of TLD Policies

 

Novell, Inc.

 

Document Revision 1.0

10/2/2000

 

 

 

 

This document is one of a set of seven (7) documents that support an application for a new ".dir" gTLD. The application is being submitted to ICANN under the guidelines set forth in "New TLD Application Instructions" (http://www.icann.com/tlds/new-tld-application-instructions-15aug00.htm). The full set of documents include: A completed and signed Sponsored TLD Application Transmittal Form. A separately bound and clearly labeled Sponsoring Organization's Proposal. A separately bound and clearly labeled Registry Operator's Proposal. A completed and signed Description of TLD Policies, with a completed and signed cover sheet. A completed and signed Statement of Requested Confidential Treatment of Materials Submitted. A completed and signed Sponsoring Organization's Fitness Disclosure. A completed and signed Registry Operator's Fitness Disclosure.

 

TABLE OF CONTENTS

I. GENERAL TLD POLICIES *

E1 – General Description *

E2 – TLD String: "dir" *

E3 – Naming Conventions *

E4 – Registrars *

E5 – Intellectual Property Provisions *

E5.1 – Discouragement of Domain Names that Infringe *

E5.2 – Pre-Screening *

E5.3 – Minimizing Abusive Registrations *

E5.4 – Trademark and Anti-cybersquatting Measures *

E5.5 – Famous Trademark Special Protections? *

E5.6 – Whois Data *

E6 – Dispute Resolution *

E6.1 – Uniform Dispute Resolution Policy *

E6.2 – Supplemental Dispute Resolution Procedures *

E7 – Data Privacy, Escrow, and Whois *

E8 – Billing and Collection *

E9 – Services and Pricing *

E10 – Other Policies *

II. REGISTRATION POLICIES DURING THE START-UP PERIOD *

E11 – Start-up Phase *

E12 – Initial Rush *

E13 – Limits *

E14 – Pricing Mechanisms *

E15 – Sunrise Period *

III. REGISTRATION RESTRICTIONS *

E16 – Restricted TLD *

E17 – Registration Detail *

E18 – Application Process *

E19 – Enforcement Procedures *

E20 – Appeal Process *

E21 – Third Party Cancellation *

IV. CONTEXT OF THE TLD WITHIN THE DNS *

E22 – Benefits of the new TLD *

E23 – Distinguishing Features *

E24 – Community and Market *

E25 – Meeting Unmet Needs *

E26 – Enhancing the Utility of DNS *

E27 – Enhanced Competition *

V. VALUE OF PROPOSAL AS A PROOF OF CONCEPT *

E28 – Proof of Concept Overview *

E29 – Concepts That Are Likely To Be Proved/Disproved *

E30 – Evaluation of Results *

E31 – Long-range Management of the DNS *

E32 – Other Reasons *

EXECUTIVE SUMMARY *

The World Wide Directory: The Problem *

The World Wide Directory: The Solution *

  1. GENERAL TLD POLICIES

For a brief overview of the purpose, rationale, and potential of the new TLD, see the "Executive Summary" section on page *.

E1 – General Description

E1. In General. Please provide a full and detailed description of all policies to be followed in the TLD (other than those covered in response to items E11-E21). If the TLD's policy on a particular topic is proposed to be identical to that reflected by a particular version of any of the following documents, it is sufficient for your response to identify the topic, to give a brief summary of the policy, and for the details to reference the document and section:

Your response should comprehensively describe policies on all topics to be followed in connection with the proposed TLD. The following items (E2-E10) are examples only and should not limit your description.

We propose that:

The details of the Novell and Tucows agreement (Novell acting as the Sponsor and Tucows acting as the Registry Operator for the new ".dir" TLD) are covered in section C18 of the Sponsoring Organization’s Proposal.

Our proposal for the new TLD is generally consistent with existing agreements; it is not our objective to vary from significant, existing policy as it relates to ICANN and DNS.

E2 – TLD String: "dir"

E2. TLD String. Please identify the TLD string(s) you are proposing. For format requirements for TLD strings, see the answer to FAQ #5.

We propose the label "dir" for new TLD. "dir" is short for directory. This label is compliant with section 3 of RFC 1034 and section 2.1 of RFC 1123.

E3 – Naming Conventions

E3. Naming conventions. Describe the naming conventions and structure within the TLD. E.g., will registrants have names registered at the second level (directly under the TLD, as in registered-name.com), or will the TLD be organized with sub-domains so that registered domain names are created at a lower level (as in registered-name.travel.com)?

We propose a unique 3rd level approach. We propose using the labels for existing TLDs (or any others that are approved by ICANN as new TLDs) to be the 2nd level labels under .dir. For example, if Novell, Inc. were to register a new name in the new .dir domain, instead of registering novell.dir, Novell, Inc. would register novell.com.dir. In order to register in the new .dir name, a registering entity must already have a name registered in one of the other TLDs. The 2 character ccTLDs would be included as 2nd level labels under .dir as well.

For example, take the existing 2nd level label "answers" from the .com, .org, and .net domains. The organization that has registered answers.com could register a new name under .dir as answers.com.dir, the organization that has registered answers.net could register a new name under .dir as answers.net.dir, and so on.

There would be no rush for new names in the new namespace. There would be no new disputes. There would be no ambiguity. There would be no new "Dispute Resolution Policy" to define or enforce. There would be a preservation of famous trademarks as well as all rulings and agreements and findings on all past and current and future disputes of names in other TLDs.

Not only does the proposed naming system solve many of the problems that ICANN is concerned about with the introduction of a new TLD, it is, in fact, a technically superior solution as well, considering the purpose of the new .dir TLD. For example, directory information is often associated with a web site. This directory information includes owner information, access rights, relationships, and configuration information. If a web browser were already pointed at a page off of "somedomain.com", it would simply need to append ".dir" in order to get at the correct instance of directory data associated with that web site. There would be no such guarantee with the 2nd level "somedomain.dir" approach. If the browser were pointing to "somedomain.net" or "somedomain.org" it would not be able to, always and correctly, assume that the directory instance associated with that site would be at "somedomain.dir". There would be a many-to-one name mapping problem that would introduce ambiguity. In fact, the 2nd level naming approach would introduce the need for a meta-directory outside of DNS in order to provide information about which sites contained directory info about other sites.

The 3rd level approach also leaves open the potential of 2nd level naming in the future as the new .dir TLD grows and matures.

E4 – Registrars

E4. Registrars. Describe in detail the policies for selection of, and competition among, registrars. Will domain-name holders deal through registrars, directly with the registry operator, or some combination of the two? What are the respective roles, functions, and responsibilities for the registry operator and registrars? If registrars are to be employed, how and by whom will they be selected or accredited? If the number of registrars will be restricted, what number of registrars will be selected? Have the qualifying registrars already been selected? On what basis will selections among those seeking to be registrars be made, and who will make them? If registrars are to be used, what mechanisms will be used to ensure that TLD policies are implemented?

Registrar selection and competition will occur within the existing structure as set forth by the current and future ICANN Registrar Accreditation Policies for the existing gTLD namespace. We do not intend to request modification of these principles.

We do however intend to communicate the benefits of accreditation to organizations that, for a variety of reasons, are suitable accreditation candidates, but have not yet pursued this option. We believe that these efforts will largely focus on organizations that possess capabilities and talents that are not adequately represented by the current roster of accredited registrars. Examples of this include specialized local marketing capabilities, multi-lingual assets and other capabilities that truely reflect the global import of domain services, DNS and other related technologies.

To this end we are prepared to continuing providing business, technical and operational assistance to organizations seeking accreditation. End-user domain-name holders will exclusively deal through registrars.

The Registry Operator will be responsible for ensuring the stable, reliable and continuous operation of the related domain name service systems, the shared registry system services, the centralized, authoritative whois service. These services also include, but are not limited to, maintaining audit ready registrant data-sets and name history, Registrar technical support services, continued development of the related Registry software and infrastructure systems as well as technical coordination between the larger DNS community, the relevant technical policy organizations and the contemplated Registry Operator and associated Registrars.

Registrars are expected to provide front-line registration services including Registrant customer service and assistance, registrant policy enforcement as well as providing the underlying technical, operational and business structures to support the continued stable operation of the registration services component of the DNS.

With ICANN's consent, we propose to select and accredit Registrars in accordance with the existing Registrar Accreditation Policies. As a result, all registrars that are accredited by ICANN, currently and in the future, will also be eligible for accreditation within this namespace. Accredited Registrars will be required to execute an additional contract with the contemplated registry and pay any associated fees. Neither the fee's, nor the contracts will create any additional obligation or burden beyond what the current gTLD Registrar/Registry contracts and fees contemplate.

TLD Registrar policy implementation and enforcement will be conducted by the Registry Operator's current Customer Affairs and Reseller Compliance department. This group currently implements and enforces policy for Tucows Registrar operations and over sees the administrative, legal and policial operations of over 1.5 million end user domain-holders and in excess of 5000 resellers for .com, .net, .org, .ca, co.uk and .org.uk. Further, this group is also responsible for customer affairs and reseller compliance for the additional 100 top-level domains that Tucows Registrar Operations will be adding throughout the remainder of 2000 and through 2001. The Registry Operator will continue to augment the resources available to this group as growth and policy intricacy required to ensure stable and consistent policy application and enforcement.

E5 – Intellectual Property Provisions

E5. Intellectual Property Provisions. Describe the policies for protection of intellectual property.

Your response should address at least the following questions, as appropriate to the TLD:

E5.1 – Discouragement of Domain Names that Infringe

E5.1. What measures will be taken to discourage registration of domain names that infringe intellectual property rights?

Although the stated charter for the proposed gTLD (see section E16) requires that the Registrant only register domain name strings consistent with registrations in other TLD's (ie, icann.org.dir) the Registry Operator will require each Registrant to agree that their proposed registration is not a "bad faith" registration as defined by WIPO and further confirm that they hold the legal right to register the string that they wish without infringing on the intellectual property rights of any third party.

The Registry Operator proposes to adopt Verisign Global Registry Services policy as found in sections 2.7, 2.15 of the NSI Registrar License and Agreement and sections II.J.7.a, II.J.7.g, II.J.7.h, II.J.7.i and II.K of the ICANN Registrar Accreditation Agreement to facilitate this.

E5.2 – Pre-Screening

E5.2. If you are proposing pre-screening for potentially infringing registrations, how will the pre-screening be performed?

The Registry Operator does not foresee any requirement to pre-screen domain SLD applications for potentially infringing registrations. Should this become a requirement, the data submitted to the registry will be compared to existing SLD registrations in the various TLD namespaces to ensure that the ownership information as submitted is consistent with existing registrations. This will be conducted through an automated process that compares the data submitted with the existing whois data. The process contemplated will exist within the SLD registration availability check as performed by the Registry Operator for each registration application and approval.

E5.3 – Minimizing Abusive Registrations

E5.3. What registration practices will be employed to minimize abusive registrations?

All registration transactions will be cross-referenced against existing data at the Registry level. Further, as previously indicated, all Registrants will be required to contractually confirm the "good-faith" status of their registration. Registrations that do not comply with the Registry Operator's policy governing this matter will not be fulfilled or deleted in accordance with existing Verisign/ICANN policy referenced previously in this application.

E5.4 – Trademark and Anti-cybersquatting Measures

E5.4. What measures do you propose to comply with applicable trademark and anti-cybersquatting legislation?

In sum, Tucows will ensure that it conducts its affairs in accordance with the policies, procedures and law established by ICANN and any other such regulators with authority to govern the internet community. It should be noted that, as the .dir submission presupposes the existence of a .com, .net and/or.org registration, all applicants will have already agreed to be bound by a dispute resolution policy and existing legislation.

E5.5 – Famous Trademark Special Protections?

E5.5. Are you proposing any special protections (other than during the start-up period) for famous trademarks?

Tucows has not provided for any special protection for famous trademarks in its proposal, as it has always preferred that a determination of notoriety be determined by a judicial entity. Again, Tucows will comply with all governing policies, procedures and law.

E5.6 – Whois Data

E5.6. How will complete, up-to-date, reliable, and conveniently provided Whois data be maintained, updated, and accessed concerning registrations in the TLD?

See the Registry Operator’s Proposal section D15.2, "Technical plan for the proposed registry operations".

E6 – Dispute Resolution

E6. Dispute Resolution. Describe the policies for domain name and other dispute resolution.

If you are proposing variations to the policies followed in .com, .net, and .org, consider the following questions:

E6.1 – Uniform Dispute Resolution Policy

E6.1. To what extent are you proposing to implement the Uniform Dispute Resolution Policy?

The Registry Operator will be fully adopting and implementing the UDRP.

E6.2 – Supplemental Dispute Resolution Procedures

E6.2. Please describe any additional, alternative, or supplemental dispute resolution procedures you are proposing.

The Registry Operator is not contemplating the adoption of any addition, alternative or supplemental dispute resolution procedures.

E7 – Data Privacy, Escrow, and Whois

E7. Data Privacy, Escrow, and Whois. Describe the proposed policies on data privacy, escrow and Whois service.

The Registry Operator proposes to abide by existing ICANN and Verisign Global Registry Services operating policy for .com, .net and .org as found in section 2.9 of NSI Registrar License and Agreement, and sections II.F.1 through II.F.5, II.I and II.J.7.b through II.J.7.f of the ICANN Accreditation Agreement. The Registry Operator and Sponsoring Organization will review the efficacy of these policies on a twice-annual basis in consultation with ICANN.

E8 – Billing and Collection

E8. Billing and Collection. Describe variations in or additions to the policies for billing and collection.

The Registry Operator elects to conduct its billing and collection practices in accordance with the protocols adopted by Verisign Global Registry Services as outlined in section 5.2 of the NSI Registrar License and Agreement. Minor modifications will be made to the language of these terms to ensure that they are appropriate and specific to the Registry Operator.

E9 – Services and Pricing

E9. Services and Pricing. What registration services do you propose to establish charges for and, for each such service, how much do you propose to charge?

The Registry Operator will charge for new registrations, renewals, transfer of registrar and transfer of ownership of the SLD. Each of these services additions and or modifications will be made at the rate of $6 (USD) per transaction.

E10 – Other Policies

E10. Other. Please describe any policies concerning topics not covered by the above questions.

None.

  1. REGISTRATION POLICIES DURING THE START-UP PERIOD
  2.  

    E11 – Start-up Phase

    E11. In this section, you should thoroughly describe all policies (including implementation details) that you propose to follow during the start-up phase of registrations in the TLD, to the extent they differ from the General TLD Policies covered in items E1-E9.

    Given the domain naming structure as proposed in section E3, there is no need to have a special start-up phase in order to reserve special names for special registrants. The naming conventions proposed open up place holders for all existing and new names in all existing and new TLDs.

    The following questions highlight some of the areas that should be considered for start-up policies:

    E12 – Initial Rush

    E12. How do you propose to address the potential rush for registration at the initial opening of the TLD? How many requested registrations do you project will be received by the registry operator within the first day, week, month, and quarter? What period do you believe should be considered the TLD's "start-up period," during which special procedures should apply?

    It is not expected that their will be a significant initial rush for potential registrations with the inauguration of the TLD due to the charter imposed on the namespace. Further, the pre-existing registration policies will further mitigate the risk that there will be a substantial volume of registrations during the initial availability period.

    Additionally, the existing infrastructure in use by the Registry Operator has been field-tested during recent public trials and has been found to handle hundreds of thousands of registration transactions per day without creating instability or substantial stress to the registration/registry systems.

    It is expected that the Registry Operator will be required to handle 1K registration transactions in the first day, 2K in the first week, 5K in the first month and 50K in the first quarter, 750K after the first year, 5-10M after 4 years. Therefore, we do not believe that a "TLD start-up" period requiring special procedures should apply.

    E13 – Limits

    E13. Do you propose to place limits on the number of registrations per registrant? Per registrar? If so, how will these limits be implemented?

    The Registry Operator nor the Sponsoring Organization are contemplating limiting the number of registrations per registrant or registrar in any fashion excepting those noted by the TLD Charter.

    E14 – Pricing Mechanisms

    E14. Will pricing mechanisms be used to dampen a rush for registration at the initial opening of the TLD? If so, please describe these mechanisms in detail.

    No.

    E15 – Sunrise Period

    E15. Will you offer any "sunrise period" in which certain potential registrants are offered the opportunity to register before registration is open to the general public? If so, to whom will this opportunity be offered (those with famous marks, registered trademarks, second-level domains in other TLDs, pre-registrations of some sort, etc.)? How will you implement this?

    As registrations in this namespace are limited to applicants that have previously registered a domain name in another TLD, the benefits provided by a "sunrise period" are negligible. Correspondingly, because of the pre-existing registration conditions, the interests of intellectual property holders are significantly and uniquely protected.

  3. REGISTRATION RESTRICTIONS

E16 – Restricted TLD

E16. As noted in the New TLD Application Process Overview, a restricted TLD is one with enforced restrictions on (1) who may apply for a registration within the domain, (2) what uses may be made of those registrations, or (3) both. In this section, please describe in detail the restrictions you propose to apply to the TLD. Your description should define the criteria to be employed, the manner in which you propose they be enforced, and the consequences of violation of the restrictions.

We are proposing restrictions on both who may apply for a registration within the domain and what uses may be made of those registrations.

As described in section E3, Naming Conventions, we propose that only entities that have already registered an existing name in one of the other TLDs may register for name in the new .dir TLD. Also, in order to register, the registrant must show a conformance to a certain level of directory service functionality. This conformance level, we propose, will be set by the Open Group’s (TOG) Directory Interoperability Forum’s (DIF) (see http://www.opengroup.org/directory/). The DIF will issue formal recommendations and certificates of compliance against those recommendations. The current brand that is available to both directory vendors and directory enabled application developers is the "LDAP2000" brand. Currently, conformance to that brand is defined using the IETF’s suite of LDAP standards:

Since the new .dir domain becomes the focal point for directory federation across both public and private networks, the new .dir TLD will be reserved for only those servers that deploy conformant directory services infrastructure. We propose using the DIF for the ongoing collection of input about requirements for participation in the domain.

To summarize, the basic policy for the new .dir TLD is that all registrations will be restricted to those that:

  1. Already have a domain name registered in an existing (or new) TLD, and
  2. Conform to the LDAP2000 brand requirements as defined by the DIF.

Examples of matters that should be addressed are:

E17 – Registration Detail

E17. Describe in detail the criteria for registration in the TLD. Provide a full explanation of the reasoning behind the specific policies chosen.

Registrants will be required to demonstrate that for each name registered in the new .dir TLD, that the new name corresponds to:

 

E18 – Application Process

E18. Describe the application process for potential registrants in the TLD.

The application process for this TLD will be identical to the automated processes currently in place under the current gTLDs given restrictions as defined in section E16.

E19 – Enforcement Procedures

E19. Describe the enforcement procedures and mechanisms for ensuring registrants meet the registration requirements.

The applicant suitability enforcement will be automated by the Registry systems. The following process will be used:

  1. The DIF, as part of the set of conformance tests to show compliance with the LDAP2000 brand, will also identify a simple LDAP query that can be successfully processed by all compliant directory service instances.
  2. Upon registering a new name in the .dir TLD, the automated registry system can issue the simple LDAP query (as defined by #1 above) and process the result.
  3. If the actual result matches the expected result, the registration will be approved.
  4. If not, the registration will be rejected.

This process is similar to the process used some time back for the all DNS registrations. Not only would the contact information be provided, but a live, online test would be run. The test would have to pass before the registration would be complete.

E20 – Appeal Process

E20. Describe any appeal process from denial of registration.

Applications that have been found unsuitable by the automated systems in place by the Registry Operator may appeal by filling out and faxing the "Denied TLD Registration Appeal" documentation attached as [exhibit]. This documentation will be used by the Registry Operator to manually explore the suitability of the applicant for the SLD requested. This documentation will purely be used as a reference to determine whether or not the applicant requesting the TLD is indeed the Registrant of a corresponding SLD/TLD pair in an existing namespace. Registration appeals will not be conducted in situations where applicants have requested a domain name that does not have a corresponding registration in an existing namespace, nor will this process be used to resolve disputes concerning pre-existing registrations or disputes related to existing registrations in and existing gTLD.

Appellants that deem that their appeal has not been suitably resolved by the Registry Operator's appeal process will be urged to seek resolution via third-party arbitration or through existing legal channels.

E21 – Third Party Cancellation

E21. Describe any procedure that permits third parties to seek cancellation of a TLD registration for failure to comply with restrictions.

The Registry Operator will review the claims of any third party seeking cancellation of a TLD registration for failure to comply with the stated restrictions on a case-by-case basis. These claims will be reviewed in accordance with existing policy, precedent and applicable law under the guidance of the General Counsel by the existing Reseller Compliance and Customer Affairs department of the Registry Operator.

  1. CONTEXT OF THE TLD WITHIN THE DNS

E22 – Benefits of the new TLD

E22. This section is intended to allow you to describe the benefits of the TLD and the reasons why it would benefit the global Internet community or some segment of that community. Issues you might consider addressing include:

See the Executive Summary (page *).

E23 – Distinguishing Features

E23. What will distinguish the TLD from existing or other proposed TLDs? How will this distinction be beneficial?

One of the benefits of the new .dir TLD relates to X509.v3 digital certificates. Some parts of the X509.v3 certificate require a fully distinguished name (FDN), and the new .dir namespace gives us exactly that. This means that the ".dir" TLD approach to federated directories is significantly more compelling than federation being built up among other parts of the DNS name space. In the latter case, not all FDNs for Internet directory names would then fall under the .dir namespace, thus making federation under "." ambiguous at best. A common namespace for X509.v3 certificates makes them not only locally useful, but globally useful as well. X509.v3 certificates are used for authentication, message signing, encryption/decryption, etc.

As a side note, some directory services already include the ability to issue or mint these certificates based on information contained within the directory. For more information on the other distinguishing features of the new .dir TLD, see the Executive Summary (page *).

E24 – Community and Market

E24. What community and/or market will be served or targeted by this TLD? To what extent is that community or market already served by the DNS?

The Internet as a whole does not have federated directory services that can be leveraged for:

DNS is a name services that resolves names to addresses. The Internet as an whole can be served by an improved focus on common directory services functionality and interoperability.

For more information on how the Internet community and emerging online marketplaces will be served, see the Executive Summary (page *).

E25 – Meeting Unmet Needs

E25. Please describe in detail how your proposal would enable the DNS to meet presently unmet needs.

Today, an LDAP server can be on any host that has any registered DNS name, however there is no way of finding which DNS names have which LDAP servers and/or what level of capability that server supports.

Also, there is no well know federation point for building distributed relationships that will span and scale to the size of the Internet now, let alone even a few years from now as the Internet continues to grow. Novell has shown leadership in the industry with directory services technology that can support up to a billion objects in a single instance of a directory tree.

E26 – Enhancing the Utility of DNS

E26. How would the introduction of the TLD enhance the utility of the DNS for Internet users? For the community served by the TLD?

The introduction of .dir would be another link in the bridge from DNS names to X.500 type fully distinguished directory names.

Each mobile device could have not only a serial number or service number but also a DNS name that is used to manage it IP address. Wireless directory lookup is more efficient. Often, there are multiple addresses each user based on their type of connection device. The address of the connection device helps information providers and information consumers better negotiate data delivery and presentation. Consider the example of a end user that connect to the internet with either a cell phone, or a wireless PDA, or a lap top, or a desktop machine. At the time the connection is made, the user’s directory information could be updated in the users’ directory entry. As each additional Internet connection is made, the information server could determine, from the directory, the type of device that is being used and therefore the type of bandwith to allocate as well as the type of data (or at least the representation of the data) to exchange.

Each device need not store their own directories. Centralization (logically not physically) of information in a secure and accelerated manner can be stored in the end users directory. Each device accesses the directory rather than its own, redundant, often out-of-date local data.

E27 – Enhanced Competition

E27. How would the proposed TLD enhance competition in domain-name registration services, including competition with existing TLD registries?

The new .dir TLD enhances competition in the following ways:

  1. VALUE OF PROPOSAL AS A PROOF OF CONCEPT

E28 – Proof of Concept Overview

E28. Recent experience in the introduction of new TLDs is limited in some respects. The current program of establishing new TLDs is intended to allow evaluation of possible additions and enhancements to the DNS and possible methods of implementing them. Stated differently, the current program is intended to serve as a "proof of concept" for ways in which the DNS might evolve in the longer term. This section of the application is designed to gather information regarding what specific concept(s) could be evaluated if the proposed TLD is introduced, how you propose the evaluation should be done, and what information would be learned that might be instructive in the long-term management of the DNS. Well-considered and articulated responses to this section will be positively viewed in the selection process.

The new .dir TLD is expected to have a counterpart for most every registration in the current TLDs. Because of this potential many-to-one mapping, it will be important to test the relationships between names registered in this domain and names that are registered (presently or in the future) in other domains. It will be informational to track usage patterns from resolving names in other domains and then resolving names in the .dir domain. For example, analysis might prove that it is a useful optimization to support secondary indexing and/or new routing algorithms.

Matters you should discuss in this section include:

E29 – Concepts That Are Likely To Be Proved/Disproved

E29. What concepts are likely to be proved/disproved by evaluation of the introduction of this TLD in the manner you propose?

It will be informational to either prove or disprove the hypothesis that the proposed naming convention for the new .dir TLD will not only eliminate any new naming disputes, but open up names in the new domain for all other existing and new TLDs.

It will informational to validate that assumption that if

E30 – Evaluation of Results

E30. How do you propose that the results of the introduction should be evaluated? By what criteria should the success or lack of success of the TLD be evaluated?

The value of the new .dir TLD should be evaluated against the following criteria:

E31 – Long-range Management of the DNS

E31. In what way would the results of the evaluation assist in the long-range management of the DNS?

The results of the evaluation can show usage patterns and access relationships between names in multiple TLDs. This might lead to new indexing, routing algorithms, zone distribution schemes, or even identify more effective configurations of name servers.

E32 – Other Reasons

E32. Are there any reasons other than evaluation of the introduction process that this particular TLD should be included in the initial introduction?

None.

EXECUTIVE SUMMARY

The World Wide Directory: The Problem

Over the past decade, the World Wide Web has revolutionized our world. It has allowed us to get information in the click of a mouse and to purchase items to be shipped overnight, directly to our front door. It has been the killer app that has transformed the Internet from a research infrastructure into an essential part of our daily lives. However, as millions of new users and sites come online, the ability to find anything or anyone has become increasingly difficult.

This new Web technology, along with the addition of the mobile computing and communication devices (web phones, PDAs, smart cards, GPS devices, smart devices, spontaneous networking, etc.), has caused an increase in the number of personal identities that we each carry with us. We then need to maintain these multiple identities, often using separate, non-integrated management tools. Many of us have multiple phone numbers, email addresses, web sites, and mailing addresses. This has only compounded the problem of finding anyone or anything. Businesses also have multiple identities and relationships: employee to business (E2B), customer to business (C2B), and business to business (B2B). There has been increased awareness and concern over security, privacy, identity protection, and the lack of distributed transaction support. This, again, has only increased the number of identities and relationships that need to be maintained.

On the consumer side, every organization to which you belong or any site where you purchase goods requires yet additional sets of identification. This information is often replicated, and over time, becomes out of date.

The World Wide Directory: The Solution

In order to solve these problems, we propose the introduction of a new TLD labeled "dir", the shortened form of "directory."

The basic and most interesting premise for the new .dir TLD is that it becomes a rendezvous point and a federation point for all existing and new directories. The effect that full service directories have had in the enterprise has been significant. Providing more that just a name service, directories can offer authentication services, extensible schemas, robust partitioning and replication, very granular access control capability, object referential integrity, and other important services. These features have been used extensively as an infrastructure for providing applications inside the firewall to simplify users' access to information and systems.

Our goal is to extend these services into the Internet. We believe that providing a rendezvous point for all full service directories, ".dir" directory aware applications can take advantage of and leverage a very powerful infrastructure for business to business e-commerce.

The .dir TLD creates the opportunity for a World Wide Directory, which is a set of any number of autonomous directories, federated in a secure and reliable manner. The introduction of this new .dir TLD creates some new and very interesting scenarios that have been missing to date. Consider these examples:

A new .dir TLD with its associated policy of deploying and integrating interoperable directory services makes these scenarios, and more, a reality.

Why a restricted TLD?

The Internet community has experienced significant progress with the introduction of a very simple, yet consistent, "www" naming convention within existing, unrestricted DNS domains. Could this same type of approach be used for directories? No. Although the introduction of web servers at nodes bearing the name "www.something.com" has been extremely successfully, it has, at the same time, been tremendously problematic. Consider the following:

These problems exist because of the unrestricted nature of many of the existing TLDs. To eliminate similar problems the new .dir name space, we propose that it be a restricted domain in which both clients and servers, applications and infrastructure components can work together to provide a guaranteed level of directory features. The restrictions will be based solely on well-known and well-understood open standards and technologies, including the Lightweight Directory Access Protocol (LDAP) standards. As the sponsoring organization, Novell is not mandating that only Novell proprietary directory services and protocols are to be used within the new TLD. Rather, Novell is proposing that the new .dir TLD will be a domain in which identities and relationships, including previously defined identities that already exist in many different types of directories, can be linked together through common technologies.

As an enduring pioneer in designing and deploying directory services software, training, education, and certification, Novell has the experience and organizational strength to be the sponsor for the new ".dir" TLD. Novell is the world’s leading supplier of net services software, has over the past decade developed the world’s leading directory technology: Novell Directory Services (NDS) or eDirectory. This technology has been used in thousands of companies worldwide (over 80% in Fortune 500 companies) to help facilitate central user administration and organization integration. During this time, other companies have helped to develop directory technology.

The integration of these different types of directories, using standardized Internet protocols, has helped directory services evolve from being just an enterprise solution into a more full-service solution that supports the emerging Internet applications. Federated directories within the new .dir TLD can, for the first time, span the Internet and allow consistent, reliable, and secure access by all types of applications. These include e-Marketplaces, personal agents, role based systems, supply chain management, single-sign on, managed replication, common access control methodologies, schema management, relationship management, and even meta-directories.