Comments on WHOIS Policy Review Team Final Report

[Andrew Sullivan <asullivan@xxxxxxx>]

Dear members of the WHOIS Policy Review Team,

Dynamic Network Services Inc. ("Dyn") appreciates the opportunity to
comment on the WHOIS Policy Review Team Final Report.  We read the
report with interest.  We paid particular attention to issues raised
during the public comment period for the (previously posted) draft
version of the report.

We regret to say we have reservations about the document.  We believe
it is a poor basis for ICANN action, and the wrong starting point for
future policy.  This is neither because we like the current state of
affairs with WHOIS, nor because we disagree radically with the
report's description of that unsatisfactory state of affairs.  Instead
it is because we do not think the report's recommendations will result
in improvements.  The WHOIS we have is a house with a bad foundation;
this report proposes to paint the siding.

We have three types of concern, two major and one minor.  First, the
report contains a number of embarrassing errors.  These naturally
undermine the rest of the report's credibility, but they also indicate
that the report starts from the wrong assumptions.  Second, as a
result of those wrong assumptions, the report does not ask the most
fundamental questions about the suitability of the WHOIS service model
to the modern Internet.  By failing to confront the central issues
directly, the report cannot offer a realistic plan for action.  In our
opinion, asking such questions would have been entirely in line with
the scope of work for the team.  Finally, and less important,
recommendation 11 proposes to introduce a needless single point of
failure in the WHOIS system, and props up a protocol that ought to be
retired.

We are dismayed to discover some issues in the report that were not
addressed even though they were raised by commenters in response to
the draft report.  These include, in our view, the most central
issues.

    RECOMMENDATIONS THAT HELP

On the positive side, some of the recommendations seem to be
worthwhile.  Recommendation 2, for a single WHOIS policy, would appear
to be useful, though it is not at all clear how this recommendation
might be practically achieved given the independence of ccTLD
operators.  Recommendation 4, to ensure that compliance functions are
managed according to best practices, seems like a good idea, if
perhaps difficult to test.

We are generally supportive of recommendations that have operational
meaning, and therefore applaud the emphasis on measurable outcomes in
recommendations 6, 7, 9, 14, and 16, even where we think the
recommendations themselves are not a good idea.

    SERIOUS ERRORS

Despite these high points, the report is marred by a number of errors.

Section B of chapter 1 has a definition (or more charitably, a
description) of "domain name" that is either a misguided attempt at
oversimplification, or else is evidence of a complete misunderstanding
of the DNS on the part of the team.  The text appears to suggest that
the Internet and the web are the same thing; it fails to note that
"www.example.com" is a perfectly good, if unusual, domain name; and it
is circular, since URIs (e.g. http://www.example.com/resource) are
partly defined using the host part, which on the modern Internet
depends on the DNS name.  Even if the description in the text is good
enough for casual conversations, it is completely inappropriate from a
community that is supposed to oversee the co-ordination of the DNS.

Chapter 5 contains the too-common mistake of suggesting that domain
names are "in a language".  It also does not make clear enough that
the character encoding problems in WHOIS are a signalling problem, and
not a limitation of the protocol's data format.  Properly speaking,
the protocol has never been internationalized at all, so it is
undefined what will happen if a client sends or receives something
that is not ASCII.  The interoperability effects are worse than they
would be if the protocol actually were in ASCII, because in the latter
case it would be possible to return an error instead of garbage.  The
report authors might understand this, but a naive user coming to this
text will not.  In the same way, the report is not careful about
whether data can be registered using character encodings other than
ASCII.  EPP, for instance, has always supported UTF-8.  There are two
problems here.  First, while repositories could accept
internationalized data without trouble today, WHOIS users have a hard
time with that data.  If we stopped caring about WHOIS tomorrow, there
would be no technical barrier to complete internationalization of
contact data (for example).  The second, operational problem, would
remain, because for monolingual English speakers, registration data in
Chinese (for example) is unusable.  It is critical to distinguish
simple protocol problems from the broader operational questions, and
the report does not consistently attend to this difference.

Chapter 5 also fails to discuss IRIS, although it almost manages to
refer to it.  Footnote 36 refers to RFC 3707, which is the CRISP
requirements.  CRISP was the IETF Working Group that produced IRIS,
and it was convened at least partially in response to claims from the
ICANN community that WHOIS needed to be replaced.  IRIS -- which is
available right now for deployment -- can support any characters that
Unicode can provide.  IRIS also offers a data model that aligns
broadly with all the major (if not all) DNS registration protocols.
It uses XML, so it is machine parseable and yet easily converted for
presentation to humans.  IRIS has been almost totally undeployed.  The
reasons for this likely should have been explored by the report.

The recounting of the history of WHOIS itself, in section A of chapter
3, is troubling.  The text leaves out one author of RFC 812, and
claims the IETF published the specification fully four years before
the IETF came into existence.  (In any case, the IETF is not the
publisher of RFCs.)  Perhaps because of the indifferent attention to
history, the basic problem with the report stands out for us in this
section.  For the truth about the WHOIS -- both the protocol and the
service designed within that protocol's limits -- is that it has long
since outlived its usable life.  The report refuses to face the
consequences of that fact.

The modern Internet is only distantly related to the network that
existed when WHOIS was specified.  When RFC 812 came out, it was still
possible to get a list of all the hosts connected to the network.  RFC
812 was published more than a year before the very first RFC defining
the DNS.  It was also published before the official ARPANET cutover to
TCP/IP -- IPv4 wasn't even fully deployed yet!  The Morris worm was
six years in the future.  And, while the WHOIS protocol has been
updated over time (as the report notes), the basic assumptions of the
WHOIS service we have today reflect limitations of that earliest
protocol.  Data is available to anyone on the network who can issue a
query.  Everyone sees the same data.  No controls are needed.  All of
these assumptions were perfectly reasonable on a network inhabited by
friendly colleagues working together on a large research project.
None of them is remotely reasonable today.  We need to decide what
assumptions would be reasonable.

    THE CENTRAL ISSUES

By not questioning fundamental assumptions, the report comes up with
recommendations 5-10, 12-14, and 16; none of these seems to us to be
actionable.  We think there are two reasons:

        1.  The desires of the various communities interested in the
    WHOIS are inconsistent with one another.

        2.  The technology by which WHOIS data is accessed -- the
    WHOIS protocol and the services offered in web pages -- is
    inadequate to solving most subsets of the desires in (1).

The report hints at both of these problems without ever facing them
head on.  Issue (1) boils down to stating the purpose(s) of WHOIS.
The report mostly admits that (1) is an issue, but then just picks
some of the desires as winners without offering sound arguments why
those ought to win (the discussion is mostly in chapter 6).  Where the
report does not pick, it says that all laws need to apply -- as though
appealing to national laws which are themselves not consistent across
jurisdictions will somehow square this circle.

Worse, the report doesn't engage with (2) at all.  The report notes
that some people might be working on alternatives to the current
protocols, but it makes no recommendations about what ought to be done
about such efforts.  

We think that the report would be much stronger if it were to admit
that the current technical environment cannot possibly address all the
conflicting demands.  If the report did so, it could lay out the
arguments, offering ICANN scope in which to make policy trade-offs.
That scope could inform the development of new technical mechanisms
that would permit policy that could reduce some of the conflicts.
Without doing this, the report is, in our opinion, doomed to be one
more of "the studies" the report laments. 

Note that none of the above is to say that there is a mere technical
problem to be solved by "the technical community" before ICANN can do
something useful.  WHOIS is a mess because of a needs assessment
problem.  What is in the way are assumptions that stem from an
existing protocol and its limitations.  Those assumptions are part of
the problem.  They need to be discarded before any useful work can be
done.  The report does nothing towards that goal, taking as an
unanalyzed starting point the anonymous, poorly-differentiated
service model of the existing WHOIS services.

As a result of the above, we cannot support recommendation 15: we
don't see how ICANN can prepare a comprehensive plan within three
months, because we think the recommendations are unimplementable.

    A MINOR ISSUE

As a minor matter, we think recommendation 11 is silly.  There is no
reason for ICANN to get into the business of running a central WHOIS
service for domains it has delegated away (which is what this
recommendation proposes, even if it does not propose centralizing the
data).  The rwhois protocol, and the clients that rely on it, already
work perfectly well.  It is true that people who don't know how to use
WHOIS can't use it reliably; that is not a reason to create a single
point of failure on the Internet for this service.  Simple expedients
like user education are more likely to be useful for those who need
WHOIS data.  Moreover, as we argue above, part of the problem with
WHOIS stems from sticking with the obsolete protocol.  Recommendation
11 proposes a way to make the protocol (and its constraints) last even
longer.

    IN CONCLUSION

The report provides a good outline of the failings of the current
system, and is helpful because it collects a number of statements
about desired use cases and operational realities.  It is therefore a
useful starting point.  It is not, however, a good basis for ICANN
action, for it starts from the premise that the WHOIS system we have
can be fixed up to solve the problems we have.  It cannot.  A protocol
that offers real policy alternatives is needed.  It will be impossible
to know what that protocol might look like if we do not make
distinctions about policy alternatives free of the baggage of the
existing service model.

Respectfully submitted,

-- 
Andrew Sullivan
Dyn Labs
asullivan@xxxxxxx