ICANN ICANN Email List Archives


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

Comments on "Proposed Implementation Plan for Synchronized IDN ccTLDs"

  • To: sync-idn-cctlds@xxxxxxxxx
  • Subject: Comments on "Proposed Implementation Plan for Synchronized IDN ccTLDs"
  • From: Andrew Sullivan <ajs@xxxxxxxxxxxx>
  • Date: Wed, 14 Apr 2010 18:10:09 -0400

Thank you for posting, and for the opportunity to comment on, the
"Proposed Implementation Plan for Synchronized IDN ccTLDs"
(henceforth, the Plan).  Thank you also for the clarifications you
posted in the form of a set of Questions and Answers on 8 April, 2010.

We are individuals who work on the DNS protocol and on DNS
operations, as participants in the Internet Engineering Task Force.
We have read the documents carefully.

Prior to the posting of the Q&A, we had several concerns about what
might be entailed for the DNS by the Plan.  The Q&A, however, makes
clear that the Plan is exclusively focused on administrative
arrangements, and has no implications for the DNS protocol.  We
therefore understand that under the plan, whatever delegations are
made from the root zone are simply different DNS delegations with no
interdependencies.  We understand that synchronization is to be
understood entirely in terms of user expectation, and that users'
expectations could be more or less satisfied in any number of ways,
including by using completely different servers to address the needs
of different communities.  It is very difficult to make a general rule
about what users might expect, particularly at delegations below the
second level in the DNS name space, and we understand the clarified
Plan to say that no such general rule is contemplated.

In light of that, we have two suggestions.

First, it would be helpful in the present case, and in similar future
cases, if ICANN did not use the terms "resolve" and "address" when the
ordinary meaning of those terms is not what is intended.  Both the
Plan and the Q&A web page use the expression "to resolve to the same
address or value".  In the Internet context, "resolve" almost always
entails an entanglement with the DNS.  Similarly, in the Internet
context, "address" almost always means an IPv4 or IPv6 address.  For a
name to resolve to an address, therefore, means that there be an entry
in the DNS such that a lookup of the name results in a response
containing the target IPv4 or IPv6 address.  Since the Q&A web page is
clear that there is no such requirement, given that the different
delegations are completely distinct in the DNS, ICANN should use other
terms to make its point or risk continuing confusion.  It is not clear
to us what it means for something to resolve to "a value".  We are
aware that there are many DNS resource records that do not contain
addresses (NAPTR records, for instance), and that this is perhaps what
is intended.  If that is the case, it should be avoided, because the
Plan as clarified does not require any real "sameness" in the DNS

Second, question and answer 9 in the Q&A should be updated.  The
answer there says, "DNS responses must produce equivalent
results. . ."  We would prefer that language be removed or somehow
altered, because despite the disclaimers immediately following it, it
could be misinterpreted as a constraint on what may be part of any of
the zone data in question.  The test of synchronization is that users
should not be surprised, and not that there be any congruence of
answers in the DNS.  Most users have no direct experience of the DNS,
and there need be no requirement of any kind on DNS responses.  The
example should be modified to include the case where delegations under
S1 and S2 have similar names, but where the addresses at those names
are different.  As long as the results the user experienced were what
the user expected, (e.g. because the different servers each served
localized but otherwise-equivalent content), that would be consistent
with ICANN's stated condition for synchronization.  It should also be
made clearer that the target systems are not only web systems, but any
systems; so MX records and such should also be part of the examples.

Thank you for this opportunity to contribute to the completion of
ICANN's Fast Track process.


Eric Brunner-Williams
Ólafur Guðmundsson
Patrik Fältström
Paul Hoffman
Peter Koch
John R. Levine
Erik Nordmark
Jim Reid
Andrew Sullivan
Ondřej Surý
Paul Vixie
Yoshiro Yoneya

[Submitted on signatories' behalf by]
Andrew Sullivan
Shinkuro, Inc.

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

Privacy Policy | Terms of Service | Cookies Policy