Based on comments, I've added some text and reworded a little.
It would be nice to get this wrapped up in the next few days, so if
you think this is good or think it is bad, tell us so we know whether
we have consensus one way or the other.
=====
The ALAC has significant concerns about the proposed wildcard in
.travel, and strongly urges ICANN to reject the proposal. We 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. 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 a monopoly service determined by the
TLD.
This issue is identical to the analogous one that arose with
SiteFinder. Although the .travel domain is currently fairly small,
the precedent its monopoly search engine would set is 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 directoriy, 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 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 will be 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 considerably 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.