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

["Roberto Gaetano" <roberto@xxxxxxxxx>]

I can forward this to the Board when you have the final version.
(better if approved by Annette)

Roberto Gaetano
ALAC
ICANN Board Liaison
 

> -----Original Message-----
> From: owner-alac@xxxxxxxxx [mailto:owner-alac@xxxxxxxxx] On 
> Behalf Of John L
> Sent: 03 October 2006 03:58
> To: ALAC -- ALAC; alac@xxxxxxxxxxxxxxxxx
> Subject: Re: [alac] dot travel wildcard, take 2bis
> 
> 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.