TLD wildcards, innovation, and DNS integrity.

[John C Klensin <klensin@xxxxxxx>]

After reviewing other postings in this forum, and thinking back
over the various discussions I've had with others over the years
about the principles involved here, I am reluctantly going to
comment here.   Little that is said below is new.  Parts of it
have been explained during the Sitefinder discussions, in
discussions with some of those involved with Tralliance before
the .travel TLD was awarded, and in other discussions within
ICANN.  I find it very troubling that this issue keeps coming
up, requiring considerable community investment each time to say
"no, it wasn't a good idea before, it isn't a good idea now, and
it is not going to turn into a good idea in the future".  

I have never been a believer in the general theory that all
wildcards are inherently bad.  The careful use of wildcards on
MX records was key in bootstrapping many organizations and
indeed whole countries, onto the Internet.  Within particular
enterprises, wildcards, even wildcards on Address-type records,
have been extremely useful tools in namespace management.  But
TLDs are another matter, simply because most of them do not
operate in environments in which the customers/registrants are
part of the same enterprise, with the same goals and
decision-making processes as the registries.  That difference is
closely connected to what the technical portion of the DNS
community is taking about when the words "administrative
hierarchy" are used.  It is better illustrated by a recent
comment that may illustrate a profound difference in philosophy.

In a posting attributed to him, Ron Andruf says "travel is ...
designed to do one thing and one thing only: Serve its
constituency.".  Contrast this with the language in RFC 1591,
which I believe ICANN still recognizes:

   2) These designated authorities are trustees for the
   delegated domain, and have a duty to serve the community.

      The designated manager is the trustee of the top-level
      domain for both the nation, in the case of a country code,
      and the global Internet community.

The "constituency" is the entire Internet community, including
users who have a reasonable expectation that the network will
behave in particular (and especially predictable) ways, not just
registrants in a domain or members of a sponsoring organization
or shareholders in a registry operator.

How, then, are these interests to be considered and balanced?

(1) In general, wildcards are a bad idea.  The IAB statement
seems fairly clear to me and, unlike Danny Younger (who may not
have intended this reading), I don't see the IAB statement as
suggesting "if this is no worse than .museum, it is ok".  The
burden of demonstrating safety rests with the proposing gTLD and
I don't see the .travel folks as even having attempted to meet
that burden -- neither their initial proposal, nor the "travel
community" endorsement letter, seem to say anything more than
"we want to do this, it will help our users (and our
constituency as we define it)".    The DNS should, above almost
all else, be stable: the fact of registering or unregistering a
name should not change the destination of a protocol (any
protocol) except as approved of by the domain holder of to or
from "no domain".   If that criterion were applied to maximize
stability and predictability, it would require extended
waiting/shutdown periods for a transfer of names between
unrelated (and unconsenting) parties.  ICANN has chosen not to
do that, to my disappointment, but wildcards are even more of an
issue than interparty transfers or name expirations.

(2) I have long believed that, when one looks at wildcards as a
potential impediment to innovation (a different issue from the
security and stability one, but one that I consider at least as
important), I think that one might be able to accept such a
wildcard if it did not lead to any unpredictable behavior that
would not be expected from all relevant hosts in the domain.  In
other words, if every host accessible at a given level of the
domain, or a given naming convention within it supported exactly
the same set of protocols -- no more and no less-- than it might
be acceptable, from an innovation standpoint, to have a wildcard
that supported exactly the same set.  In that situation, the
wildcard doesn't restrict innovation or introduce confusion when
innovation is attempted: the restriction comes from the policy
of uniformity within the domain.   However, for this to be
plausible, there must be a domain-wide policy about the services
to be supported and the naming conventions to be used.  That
policy must be supported by explicit agreements to which all
registrants agree. The registry must have a clear and plausible
intention of enforcing the agreement, and ICANN must be prepared
to guarantee registrants and the broader Internet community that
it will insist that the registry, in fact, enforce the agreement.

Those are extremely tough criteria and I don't believe that
ICANN is up to establishing or enforcing them.  But, from the
standpoint of impeding innovation --a topic discussed
extensively during the Sitefinder debates and, e.g., with
protocols other
than HTTP-- I believe it is the only acceptable path.   That
criterion is necessary, but not sufficient: sufficiency would
require addressing the security and stability issues as well,
but my guess is that similar principles would apply.  See above
and below.

(3) While I find myself in general agreement with the ALAC
analysis, there is another key difference between .travel and
the .museum (and .aero) models that has nothing to do with size
and little to do with experimental/demonstration status.  Both
of the latter are organizationally-structured TLDs, with models
of service and support to organizational members whose
membership structure and criteria predate, and are not dependent
on, the existence or marketing of the TLD.  Modulo distortions
that I suggest were introduced by ICANN rather than being
inherent in either model or domain, the domain operations exist
as services to those organization members.

That distinction identifies two important differences between
.museum and .travel.  The first is that a domain-wide search
page for .museum, no matter how accessed or structured, operates
as an index to the museums who choose to participate, presumably
including even museums who are not actively using .museum as
their primary domain locations, while such a page for travel
operates as a revenue source for the domain administration
(whether revenue is a primary objective or not).  Second, a
community/ organization-based domain such as .museum (or
probably .aero) might be able to conclude that a uniform
structure of naming and services would serve its members and
users and hence adopt such a structure in a way that would meet
the criteria of (2) above.  I don't see that as being plausible
for a commercially-operated domain, which .travel certainly is,
protestations about "communities" notwithstanding.   If one
needs to test the "community" criterion, the mechanism might be
to examine how many of the organizations that use or belong to
.travel would be members of a Tralliance-led organization in the
absence of any TLD or similar arrangements or the prospect
thereof.

(4) The one thing that has changed on this landscape in recent
weeks involves the set of issues that are being discussed on the
IETF list under the topic "DNS abuse".  It seems to me that
having arbitrary ISPs return records of their choice, rather
than what is actually in the DNS, in return to DNS queries
(whether those queries would produce resource records or errors)
_is_ a threat to Internet integrity and stability.  But, to the
extent to which it is happening, it seems to me that ICANN puts
itself into an extremely uncomfortable position --technically,
ethically, and with regard to the potential for litigation-- if
it asserts its "right" to pass out the profits from
pay-for-placement web pages to TLD operators when others are
trying to access those profits in other ways... especially if
that benefit/ opportunity was not specifically advertised when
the TLD applications were solicited and evaluated.

    John Klensin