I. GENERAL TLD POLICIES *

II. REGISTRATION POLICIES DURING THE START-UP PERIOD *

III. REGISTRATION RESTRICTIONS *

IV. CONTEXT OF THE TLD WITHIN THE DNS *

V. VALUE OF PROPOSAL AS A PROOF OF CONCEPT *

EXECUTIVE SUMMARY *

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 *.

We propose that:

• Registrars will continue to become accredited by entering and fulfilling the requirements of the ICANN Registrar Accreditation Agreement.
• The registry operator will enter agreements with ICANN accredited Registrars authorizing them to act as Registrars for the ".dir" TLD. These agreements could be similar to the NSI-Registrar License and Agreement.
• Tucows, Inc., as the registry operator, will enter an agreement with ICANN which will grant them the authority to act as the registry operator for the ".dir" TLD. This agreement could be similar the ICANN NSI-Registry Agreement.
• Novell, Inc., as the Sponsoring Organization, will enter into an agreement with ICANN which will grant them policy-formulation authority for the new ".dir" TLD. This authority will be consistent with ICANN’s goals for delegation of authority to sponsors of new TLDs.
• All registration disputes will be resolved according to the already accepted and understood terms of the UDRP (see section E4).

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.

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.

We propose a unique 3^rd 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 2^nd level labels under .dir as well.

For example, take the existing 2^nd 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 2^nd 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 2^nd 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 3^rd level approach also leaves open the potential of 2^nd level naming in the future as the new .dir TLD grows and matures.

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.

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.

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.

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.

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.

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.

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

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

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

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.

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.

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.

None.

1. REGISTRATION POLICIES DURING THE START-UP PERIOD

 

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.

2. REGISTRATION 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:

• RFC 2251
• RFC 2252
• RFC 2253
• RFC 2254 and RFC 2255 (Referrals and continuation references when returning LDAP URLs)
• TCP
• SSL Version 3 with X.509v3 certificates per RFC 2459

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.

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

• A domain name already registered in an existing TLD (as described by the naming conventions in section E3), and
• Deployed software that conforms to the LDAP2000 brand requirements as defined by the DIF.

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.

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.

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.

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

See the Executive Summary (page *).

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 *).

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

• Authentication
• Highly granular authorization and access control capabilities
• Relationship Management
• Role Management
• Extensible schemas
• Scalable and robust partitioning and replication
• Referential integrity

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 *).

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.

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.

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

• Allows for differentiated marketing schemes from each of the multiple registrars
• New names are expected to be added to the ".dir" TLD at a slower, more steady rate rather than perhaps other more unrestricted types of TLDs. To use an analogy, it is not likely that there will be any massive "land grabs", but at the same time there will be very few "ghost towns". Therefore, the long-term endurance of each of the registrars is important. Those that can sustain long-term, consistent registration loads will be more successful than the flash-in-the-pan, type that grab the spotlight, but can not endure.
• Registration is enhanced with those that can automate and even guarantee higher levels of interoperable services.
• Perhaps, some of the registrars could enhance their visibility by providing not only name registration services for the new .dir TLD, but they could also provide hosted content services themselves. This could range from free directory service support for charitable organizations to new services like personal DNS names in a hosted site designed specifically for end user directory entries (like all of the global white pages that are starting to appear in the "www" space).

1. VALUE OF PROPOSAL AS A PROOF OF CONCEPT

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.

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

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

• Number of registrations: .dir will be successful not in a high number of initial registrations, but in a steady growth pattern with an ever increasing number of domain registrations occurring over time.
• Number of different uses: .dir will be successful as more and more Internet applications take advantage of the directory services available in the new domain. Number of DNS resolves will be fairly low, but number of operations across TCP connections to addresses in the domain will be very high.
• Level of interoperablity: High levels of interoperability will validate correctness and completeness of the DIF recommendations.

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.

None.

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.

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:

• Instead of prompting users for large sets of personal data each time a transaction is enacted over the web, the e-business server simply queries the directory and retrieves only the personal data has been authorized for release by the user. The data is fresh and accurate. To date, many Internet applications have tried to maintain this data in a server specific database or in cookies that are tied to a machine or browser, not to the human being. With a .dir namespace, identities that already exist can be used and the information associated with those identities is always available and is always secure.
• Instead of logging into each web site with different identities, the web user uses a single identity and is then granted rights to various sites based on a common authentication model.
• A certain ISP can grant rights to groups of users that span multiple ISP directories. Perhaps a coalition has been formed or some trust-relationship has been built up where site authorization is shared between ISPs, but dial-up authentication has been reserved for each single ISP.
• An ASP can more efficiently and more accurately manage and deploy software based on publicly available data in multiple, previously unrelated directories.

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

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:

• Browser Wars: Some browsers implement one set of features and other browsers implement other sets. This has been the biggest failing of the web to date. In addition, are the overlapping features consistently implemented?
• Versioning and Evolution: How many pages are simply not viewable by older browsers? Does "www" imply the use of the most current HTTP standard or the most common?
• Ubiquity: Does a site that does not use "www" imply the absence of any web services?
• Interoperability: Just because a web page "works" at one site does not guarantee that a linked site will not have problems in display, presentation, or execution. Consider the myriad of back-end technologies that are not compatible with one another.
• Computing Platform vs Web: Is the Internet a truly new computing paradigm with its own globally deployed development and execution platform, or is it just a set of uncooperative and independent processors failing to realize the synergy of the system to which they are attached?

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.