Regarding the "ICANN Report on TLD Applications" for .DIRThe 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.