ICANN ICANN Email List Archives

[At-Large Advisory Committee]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [alac] dot travel wildcard, take 2bis

  • To: ALAC -- ALAC <alac@xxxxxxxxx>, alac@xxxxxxxxxxxxxxxxx
  • Subject: Re: [alac] dot travel wildcard, take 2bis
  • From: John L <johnl@xxxxxxxx>
  • Date: Mon, 2 Oct 2006 21:58:25 -0400 (EDT)

I haven't heard anything suggesting I change these comments on the dot
travel wildcard since I sent them out last week.  So unless I hear
otherwise in the next couple of days, I will do a little more editing
to make the language read more smoothly and send them along as the
consensus viewpoint of the ALAC.

Bret and Roberto: what are the most useful places to send this? I know there's a comment forum, but beyond that, to the GNSO? Board members?

R's,
John

======

The ALAC has significant concerns about the proposed wildcard in
.travel, and strongly urges ICANN to reject the proposal.  Our
concerns echo the concerns of the SSAC, although of course ours
primarily are related to stability and security issues experienced by
Internet users.  Stability of the DNS is ICANN's paramount
consideration, and this TLD wildcard would cause stability problems
for all of the reasons the SSAC identified during its evaluation of
SiteFinder. TLD wildcards introduce confusing and unpredicable
behavior in a core part of the DNS that has hitherto been very stable.

We also have specific competition-related concerns that we believe
merit examination by relevant national authorities.

1.  Before moving into the substance of our concerns, we note that
much of the justification in the .travel wildcard proposal is that
they claim that its behavior will be similar to that of the existing
wildcard in .museum.  But the seven gTLDs introduced in 2000 were
designed to be a "testbed." ICANN did some unusual things with those
seven to see what worked well and what didn't. The fact that .museum
was allowed to test wildcards doesn't mean that it was a good idea, or
that it's now a precedent for every other TLD, and its very small size
keeps it from being useful as a model for other TLDs.

2.  Any TLD wildcard decreases user choice and impairs competition.
We note that many web browsers recognize domain lookup failures and
offer a variety of spelling correction and directory services.  A
wildcard such as the one proposed for .travel disguises a lookup
failure as a success, and directs the user to the TLD's directory
rather than the service the user chose, thereby replacing a
competitive set of services with the TLD's monopoly service.

This issue is identical to the one that arose with SiteFinder.
Although the .travel domain is currently fairly small, its monopoly
search engine would set a precedent that would be extremely troubling,
which is why we believe that an analysis of the effect on competition
of per-TLD wildcards is appropriate.

3.  We note that the search.travel directory proposed for the wildcard
web site is already available. This directory is extremely confusing
to users, and even if one grants that the .museum wildcard is benign,
which we do not, it is disingenuous to compare the proposed .travel
directory to the one for .museum. The .museum wildcard leads to a page
that lists domains within .museum that most closely resemble the one
the user entered.  The search.travel site is a pay-for-placement
directory where the vast majority of entries are in domains other than
.travel.  For example, when we went to search.travel and entered
"bermuda", it returned a page with listings of three .travel domains
and 21 domains in other gTLDs and ccTLDs.  When we entered the
misspelling "bermudda", the kind of entry likely to lead via a
wildcard to this directory, it returned a page with 20 entries, none
of which were in .travel.  Whatever branding and consistency the
.travel domain is supposed to provide to consumers is utterly negated
by the random admixture of domains they present.

4.  The .travel TLD, like all gTLDs, is intended to be a global
resource, but the search.travel directory speaks only English.  When
we searched for "france", it returned 27 sites, 26 of which were in
English.  When we searched for "mexico", it returned 19 sites, all in
English.  All of the links and text on the site are in English.  As a
minimum, we would expect a global search engine to honor a browser's
language preferences and to return results in the user's preferred
language when possible, but this ones does not.

5.  The proposed wildcard completely fails to deal with Internet services
other than the World Wide Web, again leading to serious user confusion.

The most notably failure is that of e-mail.  The proposal says that
they will provide no mail server on the host to which the wildcard
points. This will have an confusing and undesirable effect on users
who attempt to send mail to .travel addresses and mistype the
domain. Currently, misaddressed mail is rejected when the domain
lookup fails, and the user immediately gets a notice that his or her
mail couldn't be delivered. The wildcard's responses are technically
indistinguishable from a server that exists but is temporarily
unavailable, which means that typical mail systems will retry for up
to a week before returning the message as undeliverable.

The proposal notes that this is similar to what .museum does now,
implying that makes it acceptable.  The .museum domain is too small to
provide a useful model, and in any event, mail to one's travel agent
is more likely to be time sensitive than mail to a museum.  When this
same issue arose with SiteFinder, all of the proposed remedies had
serious problems of user confusion, of user privacy, or both, and the
situation is identical here.

6. The wildcard proposal admits that it would break a highly effective
anti-spam technique that checks addresses in incoming mail for
non-existent domains.  It airily assumes that maintainers of all of
the world's spam filters will work around the problem by adding
special case code for the .travel domain.  This is arrogant and
absurd.

7.  The proposal doesn't even acknowledge the existence of other
widely used services such as secure HTTP (https), Jabber, and FTP, all
of which would suffer the same user confusion problem, that a wildcard
makes a non-existent domain indistinguishable from a host that is
temporarily offline.

For all of these reasons, the ALAC urges ICANN to reject the proposed
.travel wildcard, and any other TLD wildcards that may be proposed.



<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy