National and Local Characters for DNS Top Level Domain (TLD) Names
draft-klensin-idn-tld-05

[Ballot comment]
Fundamentally, I think this is well written, but could be badly read.
Knowing John's history with this topic, I believe I understand the
impetus for putting forward a fourth choice in this critical architectural
discussion, and I appreciate the time and effort he has put into this.
Knowing as well his role in the IAB during the time in which RFC 2826
was produced, I am certain his depth of understanding of many of
these issues exceeds my own.

But I am concerned about what will happen when this is read by someone
who is not aware of this history and has no insight into the issues which
John knows so well.  (And I will happily admit that my own ignorance may
be driving my empathy for this position).  If read by someone without
a deep understanding of the need for a single DNS root and an un-partitioned
URI space, will this give rise to mischief?  I believe it could.  It is moderately
obvious that someone using local translation could translate .中 國 (4e2d, 570b)
to .tw where the dominant view would translate it to .cn .  A local translation doing that has the same
partitioning effect in URI space as multiple roots do in the DNS:  it creates a situation in which local
resolution context over-rides the overall system's ability to ensure a consistent view of the namespace.

I recommend that we ask the RFC Editor not to publish this document until it contains a discussion of
this problem (hopefully using a less hot-button example than my haste forced me to use)

[Ballot discuss]
I have a concern with this document, and I do not believe that it
  ought to be published until this concern is addressed.

  Comparison is not discussed.  In my view, comparison must be
  performed on the ASCII representation of a domain name.  If a
  local character set is used for comparison, then differences in
  translation tables could lead to undeterministic results.  False
  positive and false negative comparisons might result.  This is
  especially bad if domain names of this form are part of an access
  control list.

[Ballot discuss]
I suggest the following be sent to the RFC Editor:
 
    The IESG thinks that this document extends an IETF protocol in a
    way that requires IETF review and should therefore not be
    published without IETF review and IESG approval.  In particular,
    comparison is not discussed.  If comparison is performed using
    a local character set representation of a domain name, then
    false positive and false negative comparisons might result.

[Ballot discuss]
Comparison is not discussed.  In my view, comparison must be performed
  on the ASCII representation of a domain name, otherwise differences in
  translation tables could lead to undeterministic results.

[Ballot discuss]
Fundamentally, I think this is well written, but could be badly read.
Knowing John's history with this topic, I believe I understand the
impetus for putting forward a fourth choice in this critical architectural
discussion, and I appreciate the time and effort he has put into this.
Knowing as well his role in the IAB during the time in which RFC 2826
was produced, I am certain his depth of understanding of many of
these issues exceeds my own.

But I am concerned about what will happen when this is read by someone
who is not aware of this history and has no insight into the issues which
John knows so well.  (And I will happily admit that my own ignorance may
be driving my empathy for this position).  If read by someone without
a deep understanding of the need for a single DNS root and an un-partitioned
URI space, will this give rise to mischief?  I believe it could.  It is moderately
obvious that someone using local translation could translate .中 國 (4e2d, 570b)
to .tw where the dominant view would translate it to .cn .  A local translation doing that has the same
partitioning effect in URI space as multiple roots do in the DNS:  it creates a situation in which local
resolution context over-rides the overall system's ability to ensure a consistent view of the namespace.

I recommend that we ask the RFC Editor not to publish this document until it contains a discussion of
this problem (hopefully using a less hot-button example than my haste forced me to use)

[Note]: '2005-02-10: I''ve reviewed this and do not believe it conflicts with
any IETF work. I think is fine to be published as an Independent
Submission' added by Thomas Narten