Return to tldreport Forum - Message Thread - FAQ

Username: Scott_I
Date/Time: Tue, November 14, 2000 at 6:26 AM GMT
Browser: Microsoft Internet Explorer V5.01 using Windows NT 5.0
Score: 5
Subject: Regarding the "ICANN Report" for .DIR

Message:
 

 
Regarding the "ICANN Report on TLD Applications" for .DIR

The evaluation states: "Since the registration process for Novell's proposed TLD requires verification that the registrant owns the base domain name example.com from which the .dir name is derived example.com.dir, this new TLD will put some new load on existing TLD services to check registration of those base names. In the long run, this traffic is unlikely to be heavy enough to cause significant problems, but it could produce excess traffic during any startup surge."

Comment: Agreed, in the long run the traffic is unlikely to be heavy enough to cause any problems.  Also, the traffic would exist with or without the .DIR TLD since applications already must use some non-standard mechanism for finding instances of directory services.  Consider a non-technical analogy. It often takes MUCH more energy to find a reference book of some type than to look up a specific piece of information in that reference book.

*********
The evaluation states: "Generally, Novell's proposal seemed to underestimate the initial demand for new registrations, which could cause various stability problems when it comes on line."

Comment: The proposed infrastructure is shown to be able to handle many hundreds of times the projected volumes of registrations.

*********
The evaluation states: "The Whois service is replicated only in a single central site, leading to possible loss of this service in case of catastrophe. Since the Whois service is not necessarily crucial to operations, this aspect of stability is of secondary importance."

Comment: Agreed. Replicated Whois services would me made available if the .DIR TLD were to be approved.

*********
The evaluation states: "Novell, or its registry operator, Tucows, Inc., apparently expects no marketing expenses. Novell does not adequately discuss its marketing plan or expenses."

Comment:  The market is already driven and created by significant industry players like Novell, I-Planet, IBM, Sun, Microsoft, Oracle, and others.  Consider the money that is already being spent to advertise and education the global enterprise and Internet customers on directory services and their values. The market already exists.  What doesn't exist is a standard way to name and deploy directory services across vendors other than LDAP.  LDAP has already been proven and the .DIR application calls for the use of LDAP."

*********
The evaluation states: "Technically the Novell proposal is straightforward. The translation process would point to a directory, in particular an LDAP-conforming directory object. However, there are other types of directory objects, so the allocation of a TLD to one particular type may be limiting."

Comment:  This evaluation comment shows a lack of understanding about directory services.  LDAP is the Lightweight Directory Access Protocol.  It is a common way of accessing directory data once the directory is found.  SNMP is a comparable example. SNMP does not dictate the implementation, OS type, management software within the managed system, etc.  It just defines the access and structure rules.  Consider DNS as well.  Does DNS imply a certain OS or a certain implementation?  No!  It simply states a model and set of operations for performing a certain function.  To acquire a DNS solution, some products are available as open source, some are free, some are shareware, some are free standing, some are embedded or bundled, and some are very expensive enterprise applications.  The same is true for LDAP.  Almost every major OS vendor supports LDAP.  LDAP is not Novell specific technology.  It is an open standard that any implementation can and should support.  The evaluation committee seems to think that LDAP is some sort of Novell specific technology.  This is simply not true.  It is an open standard that is implemented by most directory service vendors.  Look at the list of members in the DIF (Directory Interoperability Forum). There are other types of directory objects, but they are all made common by LDAP!

*********
The evaluation states: "In terms of meeting unmet needs, the service proposed for .dir could be provided in many other ways that do not require a new TLD."

Comment:  This statement is true for ANY one of the 47 TLD applications.  The .DIR TLD is a simple as straight forward approach that can be an easy to implement rather than the other approaches for finding and building relationships between autonomous directory agents.

*********
The evaluation states: "The .dir namespace is essentially a parallel partial duplication of the namespace of other TLDs. Arguably a more technically sound way to achieve the functionality of matching a DNS name to a directory server that keeps information on the name is to attach data to the existing name in some manner, rather than to create a parallel namespace.

Comment:  Approaches other than the .DIR TLD imply new technology and new standards and new ubiquitous deployments of new software/firmware.  It is true that it could be done, but it need not be done.  Think of all the instances of DNS servers that are already deployed that would have to be rev'ed and updated in order for some other solution to work.

*********
The evaluation states: "A significant amount of work on directories for the Internet is being done in other ways, and the proposal does not adequately address how it relates to that work and whether it would be compatible with it."

Comment: In other parts of the evaluation report, the committee states that the proposal is technically straight forward and achievable.  The proposal in the application is compatible with all other know directory discovery mechanisms being proposed.  If someone wants to send out broadcast messages, the LDAP servers in .DIR would correctly respond.  If someone wanted to build and host and maintain a directory of directories, the servers in .DIR could be registered.  If someone wanted to create replicated, potentially stale data from the directories in .DIR, they could do so and the applications that then query the actual directory would then find any discrepancies.  Think of all the web links that are broken because the HTML representation is NOT directly connected to the source of the content.  The same could happen with other directory approaches.

*********
The evaluation states: "The Novell .dir proposal is technically feasible and has an average business plan."

Comment: Agreed.

*********
The evaluation states: "Many alternative methods not involving new TLDs exist to attach directory services to existing names, raising the unanswered question of why a TLD-based approach is superior."

Comment:  The need for new standards, new technology, new system deployment, new management software, new interoperability guidelines, all point to effort that need not be expended.  It is interesting to note that most any technical problem can be solved in multiple ways.  The proposed .DIR TLD is a simple, straight forward, proposal that is acknowledged by the evaluation team as being technically feasible.  It can be done.  It can be done now.  It can be done with existing software and existing systems and existing infrastructure.  It can be done with no new implementations.  The other proposals requires some new standard or technology or deployment of upgrades servers and clients.

*********
The evaluation states: Novell's complete concentration on their own LDAP directory system, with no serious consideration of other directory systems, is a negative element in their proposal."

Comment: This comment clearly shows the lack of understanding that LDAP is an open standard, defined and ratified by the IETF.  LDAP is not a Novell product or technology.  Simple fact.  The proposal describes how any implementation from any vendor that is compliant with the open standard would be compliant and would be able to be registered in .DIR.

*********
The evaluation states: "In the absence of consensus on how to best handle distributed directories in the Internet, establishing a TLD that is tied to one of the approaches is perhaps unwise at this time."

Comment: The .DIR TLD is not tied to one of the approaches; it is one of the approaches.  With the approval of ICANN it would be a standard way of supporting distributed, replicated, and federated directories that can maintain local and secure administrative rights.  There are other ways, but none is standard, and even if there were a standard, very few, if any, could be done with existing software, technologies, and systems.  Each requires a new version of software or update.  This application is not about how directories work, but how different instances of multiple directories from multiple vendors can and would work together in a common namespace.  The problems that is solves far outweigh any concerns.  Most of the concerns have been misinformed.  They range from "how is secure data kept private" (directories have been doing this for 8+years, this is the reason why they were invented) to "there are other types of directories other than LDAP" (there are many types of directories, but they almost all can and should support LDAP).  LDAP is not a proprietary protocol, but an open standard ratified by the IETF.  There is a suite of RFCs that define LDAP.  LDAP is not a Novell specific technology.
       
  

 


Message Thread:


Privacy Policy | Terms of Service | Cookies Policy