Regarding the "Summary of Application of Novell. Inc." for .DIRThe summary states:
"In practice, the system will only work with LDAP servers."
Comment: There are
many types of directories that exist today. These range all they way from personal
directories (email lists, personal address books, memos, notepads, etc) to full service
enterprise directories (HR databases, Authentication and Authorization systems, name-to-address
look up systems, hierarchically organized locally administered autonomous systems
with relationship management, etc). Each of these systems can have, and usually
does have, different access protocols and languages and programming interfaces.
The .DIR application proposes the use of LDAP as the open standard of choice.
LDAP is not a proprietary protocol. It can be used to access all types of disparate
data, independent of the local data storage mechanisms and software implementation
choices.
*********
The summary states: "They anticipate an oddly slow
initial growth rate, perhaps predicated on the restrictions to register, particularly
the restriction of having running LDAP services."
Comment: The slower growth
rate is entirely predicated on restrictions of the TLD that will allow only conformant
LDAP servers to be registered. Since the proposal opens up many new opportunities
for relationship management and secure data sharing, we expect that initially there
will be planning and deployment issues that will take some time, but as the new .DIR
TLD continues to grow, we expect its growth to be at an exponential rate. Look
at the growth rate of names in .com. Initially the registration rate was slow
and then it exploded at a skyrocketing rate. We anticipate .DIR to behave in
the same fashion.
*********
The summary states: "Nonetheless, their estimate
that only 1000 names will be registered the first day, without any artificial methods
of their own to limit the number, seems very low."
Comment: The proposed
infrastructure will support hundreds of transactions/second. Even if the number
of registrations on the first day were to be in the hundreds of thousands, there
is sufficient capacity to support that number.
*********
The summary states:
"This should be acceptable, although it is unclear how the traffic to a directory
might differ from the traffic to “normal” services."
Comment: Once the directory
is registered with DNS, there is no change in the amount of DNS traffic whether the
directory is registered in .com or .dir or any other TLD. The type and nature
of LDAP traffic on port 389 is currently well understood. It is projected that
there will actually be less traffic on the network as a whole since there will be
fewer widely distributed broadcast messages being used to "look for" instances of
a specific directory.
*********
The summary states: "While Whois is not
a critical application geographic distribution would improve the overall “image”
of system reliability."
Comment: This could certainly be enhanced to whatever
level ICANN recommends were the .DIR TLD to be approved.
*********
The summary
states: "There is no discussion of logging and monitoring facilities for security
purposes, nor of periodic security reviews of the system. The proposal would benefit
from inclusion of details on how audit trails would be performed to track changes
to the registrar database. For example, it would be useful to track changes
in registration."
Comment: All systems support logging and monitoring for audit
trails and security reviews.
*********
The summary states: "Novell … will apparently
primarily be involved in defining policies and perhaps in independently building
solutions to use the new capabilities of the TLD."
Comment: In the application,
it clearly states that all technical compliance issues regarding directories and
LDAP servers will be defined by The Open Group's Directory Interoperability Forum
(DIF). Novell has no plans to define or declare that only certain, proprietary
policies be implemented. The application calls for a restricted domain, but
restricted only in the sense that it applies open directory technology, not restricted
in Novell specific technology or products. Yes, Novell is currently, and will
on an ongoing basis be, building solutions based on secure, distributed, and federated
directories and directory technologies that will be entirely relevant to the new
.dir TLD.
*********
The summary states: "The architecture does not make a very
clean separation between the registry and registrar software, which could lead to
problems since this TLD allows external registrars to communicate to the registry.
There is, in particular, no specification of how a registrar outside of their administrative
and physical domain might properly and safely interoperate with the registry service."
Comment:
This apprehension might arise due to the finite amount of information contained in
the application. It would not come from the technical merits and capabilities
and reputation of either the sponsor, Novell, and the registry operator, Tucows.
The reliability and performance of these companies speak many more volumes than proposals
on paper.
*********
The summary states: "Apparently, that software has
no history of running registries, so there is a risk that it is flawed."
Comment:
This is not true. The software has been testing with actual registry data and
registry access patterns both normal and atypical.
*********
The summary states:
"It is uncertain whether the proposed architecture will be up to peak demands for
registrations."
Comment: The proposed system infrastructure will be able
to handle the peak loads demanded of the new TLD. The system is designed
as the presumption states it should.
*********
The summary states: "Unlike
many other proposals, this one has a noticeable impact on the existing DNS system.
The .dir TLD will only register domain names that are variants on domain names that
already exist in other TLDs, and hopefully only to the legitimate owners of those
names."
Comment: To make an analogy: It does take more effort to build
an indoor bathroom than an outhouse, but once it is built, there is overall less
"traffic" to get to the indoor bathroom than the outhouse. Once the registration
traffic is over, there is less "finding" traffic on the net in the long run.
Say it takes X amount of traffic to register an LDAP directory agent in the new .DIR
TLD and it takes Y amount of traffic to find the LDAP directory agent in some other
TLD. Let X > Y. However, the overall amount of traffic is for .DIR is
X*1 which is known and finite and without .DIR the traffic is Y*N, which is unbounded
and essentially infinite since since N is not known and will only increase over time.
*********
The summary states: "Over the course of 4 years, the .dir service
expects perhaps 10 million registrations, a drop in the Whois bucket over that period.
There is some possible concern, however, that the registration spike during the early
days of the service (or whenever they expect their sudden growth to occur) could
temporarily burden the Whois services of existing TLDs."
Comment: That same
spike will occur to Whois independent of whether or not .DIR is approved. As
directories become more and more common in the Internet, the information must be
made available and will be accessed. The .DIR application shows that it can
be done in a "reasonable and managed" approach. Without .DIR there are no compliance
checks, no validation checks, no consistency checks.
*********
The summary states:
"Further, unless some care is taken, spurious requests for registration of non-existent
domain names under the .dir TLD could be used to launch denial of service attacks
on other domains’ Whois services."
Comment: Again this is not affected by
.DIR at all. The denial of service attack could happen today with or without the
.DIR TLD. That is like saying we should shut down .com since HTTP denial of
service attacks can occur against somedomain.com. This is NOT a .DIR application
issue.
*********
The summary states: "Since Tucows has not run a production
TLD, there is some risk that they lack some skills required, …"
Comment:
This is like saying ICANN will only approve registry operators who are already registry
operators of existing gTLD and ccTLD domains. I am sure this is not the case.
Tucows does have the necessary experience with registrars and registry software to
be the registry operator for the .DIR TLD.
*********
The summary states: "The
proposal calls for using the Internet naming system for a new purpose, with potentially
large benefits. These benefits would largely be realized by those making use
of the fairly modest new capabilities of the new service itself, but rather by those
who use those modest services to hook together things that were previously hard to
connect."
Comment: This is a great overall summary of the application.
It is not about new technology as much as it creates a marketplace and synergy for
existing open directory technology. The proposal realizes all the gain of innovation
with none of the risk of untested technology at its base.
*********
The summary
states: "This is a novel idea, somewhat underdeveloped in its more radical
implications."
Comment: Again, a very good analysis of the application.
Could the inventors of IP have envisioned an IP address at every device and phone
and computer and consumer appliance throughout the globe? No, but it has happened.
Could the inventors of HTTP have envisioned where web servers now live? No,
but they are ubiquitous across both devices and appliances. The potential of
.DIR is even too big to fully describe in an application let alone in the industry
as a whole right now.
*********
The summary states: "A more rigorous approach
would involve a test of the target against a standard with appropriate diagnostics.
Periodic testing and notification might also be advisable. In the case of this
proposal it would seem that this testing could be fully automated."
Comment:
Agreed and will be implemented if the .DIR TLD is approved.
*********
The summary
states: "This application’s strength is because it contains a different approach
in bringing new services to the top-level domain."
Comment: Agreed.
*********
The
summary states: "The weakness of this application is that its marketing plan is not
sufficiently discussed."
Comment: The market already exists. Novell estimates
that the number of LDAP servers already deployed is in the hundreds of thousands
if not millions. There are 4 millon NetWare servers deployed throughout the
globe and a good percentage of those support LDAP. Many of the other major industry
system vendors also support LDAP. It is not a matter of building a market,
but satisfying the demands of the existing market. A more full marketing plan
is being put in place, but it was not expected that it would necessarily be a significant
part of the application.
*********
The summary states: "There are also
questions regarding whether or not the market will accept the new service."
Comment:
The market already has accepted it in LDAP. What lacks is a common namespace,
set of verifiable criteria for deployment, and rendezvous points for relationship
management all of which are provided for or solved with the introduction of the .DIR
TLD.
*********
The summary states: "From a business plan perspective, this application
might result in a successful venture given the capabilities of Novell, but the risks
of market acceptance are great."
Comment: In other words, the evaluation
team feels that there are no significant technical issues associated with the .dir
application. It is a new service that has already been proven technically and
now simply needs an opportunity for common deployment. The risks of market
acceptance have already been mitigated with the introduction and acceptance of LDAP.