Subject: [DNSOP] draft-yao-dnsop-idntld-implementation-01.txt

From: Andrew Sullivan <[email-masked]>
Date: Thu, 5 Nov 2009 15:59:21 -0500

Dear colleagues,

I have read the document
draft-yao-dnsop-idntld-implementation-01.txt.  I note that there is an
agenda item on the DNSOP WG agenda to consider this draft.

I am strongly opposed to the draft, and wish to express my opposition
to it being adopted by the WG.  In my opinion, the draft places
altogether too much confidence in the notion that data consistency can
in any way be enforced across two completely different delegations.

If we are to take at all the idea of variants seriously, then what we
must suppose is that any name must be _functionally the same_ as all
the other variants of that name.  The only mechanism we have in the
DNS that approaches that functionality is DNAME.  DNAME is far from
ideal: it does not actually mirror the root of the tree, and there are
other nasty issues (MX is an obvious one).  The authors are correct
that a DNAME deployment could indeed lead DNS operators lower in the
tree to do broken things.  But neither of those issues holds a candle
to the mistaken notion that two actually different delegations may be
relied upon to be the same.

If we encourage NS delegation from the root into different zones that
are supposed to be the same, then in the absence of complicated,
as-yet-unwritten tools to enforce the lock step consistency of those
different delegations (and to check them all the time), the chances of
the different zones actually being the same all the time approaches
zero.  Since the principle of a variant is that it just be another
spelling for the name (as though we granted colour.com automatically
to the registrant color.com), any difference in the answer you get
from the servers for one and the servers for another is by definition
a problem.  

I appreciate the problems the authors are trying to solve, and I
understand why they are taking this path; but it is still the wrong
path, and I believe it to be a greater threatl to the stability of the
DNS than the introduction of DNAMEs near the top.

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Alex Bligh <[email-masked]>
Date: Fri, 06 Nov 2009 19:06:38 +0000

I have read this draft. I do not think it should be adopted in current form.

My reason is essentially that this draft appears to be mixing operational
and/or technical considerations with matters which are essentially policy
which should be determined at the local internet community level.

What the authors state is recommended may well be right for one TLD, but
not for another.

The flaw in the argument starts early on, in my view. Under section 2
>    the original IDN TLD and its IDN TLD variant SHOULD be
>    identical in the DNS resolution.  For example, the ".com" is
>    identical to ".COM" in the DNS resolution.

This is not a valid comparison. ".com" is identical to ".COM" because,
for historical reasons, the comparison of DNS names is performed in
a case insensitive manner. However, ".COM" is not identical to ".C0M"
(that's a zero), or ".il" to ".i1" at the protocol comparison level.
The fact that two labels appear similar (or even identical) does
not *at a technical level* (i.e. in the scope of this working group)
mean that there should be an RFC2119 "SHOULD".

I quite agree that ICANN should not allocate a TLD to one operator,
and a variant of that TLD to anyone but that operator. That is
a laudable policy, but probably outside the scope of this group.
That doesn't necessarily mean they should allocate variants at all,
but if they do, how they are handled should it seems to me not
be prescribed here. There must be some situations where the
variant is a perfectly acceptable alternate way of expressing
the same name, some where the variant is a replacement of
a historical artifact, and some where the variant is a "phish"
(i.e. something that looks just like the original but isn't).
Ways to deal with this would include:

  1. do nothing
  2. block allocation of variant (but put no records in)
  3. Put NS records in root (could point to different servers
     operated by same operator), operator puts minimal information
     in (compare '.uk' and '.gb').
  4. Ditto with same servers
  5. As per (4), but with DNAME at apex of delegated zone. Some
     seem to be arguing this is legitimate (though I thought not)
  6. As per (5) with same servers
  7. As per (5) but (for TLDs with second level domains, e.g.
     ".uk", put DNAME in for the TLD names, e.g. make
     com.uk a DNAME of co.uk)
  9. Put DNAMEs in at the delegation level
  10. Synthesize identical zone files

Now I am sure there are technical advantages and disadvantages to
each of these. It seems to me these are dependent on the problem
one is trying to solve. If the only problem is avoiding phishing,
I'd go for (2). If the problem is that half the users write
the CCTLD using one unicode character, and half with a different
but identical looking one (that appeared to be the implication
of the example in section 2), then the problem is quite different.
I think it's up to the registry concerned (with local community
input) to determine the best policy.

Sure, we could have a draft which sets out the various technical
advantages and disadvantages of different option, but in current
form, this isn't it. See, for example (from s3):

> Any policy or technology SHOULD be used to guarantee that the IDN TLD
>    and its variant SHOULD belong to the same registry; the DNS
>    administrators SHOULD try their best to make the IDN TLD and its
>    variants be identical in the DNS resolution.

That is far too prescriptive.

I should probably declare my hand in that I think in most cases the
variant stuff is a non-problem (blocking is adequate apart from
where the user is likely to mistype themselves), and that attempting
to generate DNS equivalence is a non-solution (because end user
software, e.g. HTTP requests for web sites which rely on the domain
name in the request) will themselves need to handle every permutation
of equivalence. In most cases, the appropriate answer is NXDOMAIN.
Whilst I can see that there might be other cases, this seems
to me to be an issue for local policy, not DNSOP.

-- 
Alex Bligh

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 6 Nov 2009 14:33:23 -0500

On Fri, Nov 06, 2009 at 07:06:38PM +0000, Alex Bligh wrote:

> where the user is likely to mistype themselves)

According to some people I'm inclined to believe (I can't say this
from personal experience), in non-alphabetic scripts there is indeed a
serious problem with respect to variants.  It's not actually like the
case of (say) colour vs. color, because users tend to have access to
one version or another of the "same" character, but that character is
actually encoded under Unicode as a different character.  This is, I
am led to believe, a very common problem in areas where, for instance,
Simplified and Traditional Chinese characters are both in regular use.
The upshot is that every competent user of the language will recognize
two different arrangements of symbols as "the same word", each user
will be able to type one or the other of the arrangements (but not
both) at their keyboard, and yet the two different arrangements do not
constitute equvalent labels.  So, it's as though by configuring your
system with locale en-CA, you were _unable_ to type "color.com" into a
resolution context.  There is a genuine user problem here (though
whether one should actually solve it is still an open question).

Best,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Alex Bligh <[email-masked]>
Date: Fri, 06 Nov 2009 19:41:06 +0000

> whether one should actually solve it is still an open question).

Right. So in that example, there is clearly a problem, and it
may well need addressing.

All I am saying is that not every problem needs addressing the same
way. To take your particular example, it is not inconceivable that
in the scheme you have mentioned, labels below the TLD either
have, or have not, commonly got the same variant problem.

-- 
Alex Bligh

---

From: Eric Brunner-Williams <[email-masked]>
Date: Fri, 06 Nov 2009 18:32:15 -0500

I too have read the document.

Let N = the number of entries in the IANA root associated with the 
territories listed in the ISO 3166-1, and {N} denote that set.

One or more of Verisign, Afilias and NeuStar operate two or more ccTLD 
entries, each with an optional, not required, nominally distinct 
policy and set of registrants. The RW and CD registries share 
technical contact (and possibly related dysfunctional properties). Etc.

There exists a substantial class of SLD registrations which are 
present in multiple entries within {N}, and under the theory of 
"subsidiarity principle" offered by the chair of the ccNSO, it is 
possible for two or more ccTLDs to consist entirely of registrations 
of this class, and to have the same operator.

Therefore the DNAME or NS choice of mechanism is present whether or 
not any increase occurs to {N}. Granted, the likelihood of DNAME is 
much less likely than NS, but other than government or FOJ client 
acquisition, and IANA change request management, no technical or 
policy barrier exists to preference NS over DNAME as the choice of 
mechanism.

Next, an increase in the number of entries O(N/5) without a 
corresponding increase in N, expands the instances of multi-entry 
operations. It has been asserted, though the final policy guidelines 
are not yet available, that each instance in this step-wise increase 
in {N}, which will be an entry of the form "xn--*", will be operated 
by the operator of the existing corresponding entry in the IANA root 
associated with the territories listed in the ISO 3166-1.

As a policy matter, this assumption is problematic. Consider for 
instance the problems of the existing operators for .US or .CA in 
operating a "US-or-CA-in-Chinese" registry, or the existing operator 
for .CN in operating a "CN-in-Tibetan" registry, or the existing 
operator for .IL in operating a "IL-in-Yiddish" registry. It is 
possible that each of these example registry operators will have 
constraints which preclude users from creating persistent resource 
identifiers using these example non-Latin scripts used by non-trivial 
populations having a preferential association with the corresponding 
existing ISO 3166-1 entry. These are of course, just examples, and not 
intended to describe actual policy limitations or present or plan of 
record practice.

The problem is elided temporarily by the assumption that each 
government or FOJ will select only one (or two) additional strings to 
add to {N}, and so minority languages, and therefor multiple distinct 
policy goals, will not be present.

This increase is the ccTLD IDN "FastTrack".

Next after, an increase in the number of entries O(M*N), again, 
without a corresponding increase in N, expands the instances of 
multi-entry operations. It is not yet asserted whether each instance 
in this subsequent step-wise increase in {N}, which will be an entry 
of the form "xn--*", will also be operated by the operator of the 
existing corresponding entry in the IANA root associated with the 
territories listed in the ISO 3166-1.

This increase is the ccTLD IDN PDP.

This will present this problem more fully, whether the additional 
entries are in scripts which are non-Latin only, a restriction present 
in the "FastTrack", or non-Latin, and decorated Latin, and potentially 
even non-decorated Latin.

In general, DNAME as the choice of mechanism for multiple instances of 
entries in the IANA root associated with the territories listed in the 
ISO 3166-1 is unlikely to promote the use of minority languages as 
resource identifiers, as is NS, where the two or more delegations 
share a single or ordered hierarchy of policy goals.

Finally, there is the matter of equivalence classes within character 
repertoires which exist in work product of the IDNAbis WG, now in LC.

The SC/TC equivalence class is well known. Less well known, outside of 
the IDNAbis WG, is the Arabic and Persian YEH non-equivalance, and 
other examples, and other equivalence classes in other scripts.

By abuse of notation these are all commonly referred to as "variants", 
and by a similar abuse of goals ordering, "anti-phishing" using 
"variants" is frequently presented as a controlling design goal, 
rather than enabling the use of scripts to form persistent resource 
idenifiers, even by linguistic minorities in the territories 
associated with ISO 3166-1.

Independent of the limitations of DNAME, the NS choice of mechanism 
allows the possibility of distinct policies associated with two or 
more elements of {N} associated with a single ISO 3166-1 entry, 
possibly through physically distinct operators. This has been argued 
to be a weakness of the NS choice of mechanism. I hope I've conveyed 
my impression that there are foreseeable circumstances where a single 
policy over two or more "variants" is also a non-desirable outcome, 
independent of the choice of mechanism.

I don't know if there will be an application by the United States for 
a Cherokee Syllabary equivalent to "US" or by Canada for a 
Carrrier/Cree/Dene/Innu/Inuktitut/Siksika Syllabic equivalent to "CA", 
but as we look to the ASCII-only ISO 3166-1 use in the IANA root 
tending toward something approximating a sparse subset of the product 
of that and ISO 639, consistency for "anti-phishing", overlooking the 
expectations of the users forming and using persistent idenifiers, to 
the point of selecting which "variants" have no meaning other than 
visual dissimularity (or simularity, depending on the particular 
choice of edge case in the IDNAbis work product), and restricting the 
choices of identifiers (or more generally, vocabularies in scripts 
users might select, which may not exist in the "official" standards 
associated with a territory to which an ISO 3166-1 entry has been 
allocated.

Finally, there is the eventual non-step, monotonic increase of entries 
in the IANA root which are not associated with the territories listed 
in the ISO 3166-1. This number is presently quite small, but is 
conjectured to grow O(2xN) annually, or perhaps O(2xN) in year 1, and 
O(N) thereafter. Unlike the two prior anticipated increases in the 
number of entries, no bound is known, and at least one proposal for 
"single registrant" TLDs creates the possibility that the number of 
globally protected trademarks, O(10^^5) is a lower bound for this 
growth in the IANA root.

Absent any restriction, it seems reasonable that substantial numbers 
of "single registrant" TLDs could be implemented using DNAME, with 
each having a SLD set similar to the set of addresses defined in 
RFC2142 {info, marketing, sales, support; abuse, noc, security; ...}, 
disambiguated at the application layer by the mass-registry operator.

I've written this note because I'm not satisfied with the bivalued 
approach to the variant problem in the Yao draft, nor with the unitary 
semantic approach to variants offered, even by a single, unified 
registry operator, nor the implicit constraint of the operational 
problem as the number of entries in the IANA root associated with the 
territories listed in the ISO 3166-1 grows, and as the number of 
entries in the IANA root not associated with the territories listed in 
the ISO 3166-1 grows.

I'm sorry I can't be in Hiroshima so that I can attempt to field spit 
balls for such an excess of Layer 9 persiflage, and my typical bad to 
worse writing.

Like Andrew, I believe I know why the Yao draft had to be written, and 
unlike Andrew I think DNAME is the wrong answer, and the view that 
"any name must be _functionally the same_ as all the other variants of 
that name" concerns me as it appears to put one commercial interest 
above all non-commercial interests in IDN policy.

Written while interrupted by children and so on. All errors mine, 
everything correct stolen from others, etc.

Cheers,
Eric

---

From: James Seng <[email-masked]>
Date: Sat, 7 Nov 2009 20:10:02 +0800

"There is a genuine user problem here (though whether one should actually
solve it is still an open question)."

It is a genuine user problem but I disagree with your latter statement.

It is not an open question it must be solved. It is a serious enough problem
for Chinese that it must be resolve for the Chinese user. The open question
is "how", not "if".

For some background on CJK ideograph, you may refer to an expired draft I
wrote many years ago

http://james.seng.sg/files/draft-ietf-idn-cjk-01.pdf

RFC 3743 will also be a good point of reference.

-James Seng

On Sat, Nov 7, 2009 at 3:33 AM, Andrew Sullivan <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 07 Nov 2009 22:36:29 +0900

> for Chinese that it must be resolve for the Chinese user. The open question

Wrong. The problem is solved simply reverting back to ISO 2022
by making ISO 10646 obsolete

The question is "when", not "how" and the proper answer is "now".

							Masataka Ohta

---

From: Todd Glassey <[email-masked]>
Date: Sat, 07 Nov 2009 13:01:03 -0800

James Seng wrote:
> "There is a genuine user problem here (though whether one should 
> actually solve it is still an open question)."
If DNS was run more like a  search system the possibilities of address 
resolution are endless. The same is true of ENUM lookups as well. All we 
need is Root Search Servers and well known addresses for them and poof. 
DNS goes away and a fully TCP based authenticated http type query and 
response API could seamlessly replace DNS.

Todd Glassey
> It is not an open question it must be solved. It is a serious enough 
> problem for Chinese that it must be resolve for the Chinese user. The 
> open question is "how", not "if".
>
> For some background on CJK ideograph, you may refer to an expired 
> draft I wrote many years ago
>
> On Sat, Nov 7, 2009 at 3:33 AM, Andrew Sullivan <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     system with locale en-CA, you were _unable_ to type "color.com
>     <http://color.com>" into a
>     [email-masked] <mailto:[email-masked]>
>     Shinkuro, Inc.
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.5.425 / Virus Database: 270.14.52/2485 - Release Date: 11/06/09 19:39:00
>
>

---

From: Edward Lewis <[email-masked]>
Date: Mon, 9 Nov 2009 08:13:20 +0900

At 15:59 -0500 11/5/09, Andrew Sullivan wrote:
>I am strongly opposed to the draft...

Section 4.2.1.3 causes me to stop and think that there's something to 
this draft.

It's not a layer 9 problem, it's a layer 6 problem.  Remember layer 6?

Let's say I am the operator of a bank in Wukesong.  (Unfortunately my 
[IETF] mail reader can't handle Chinese characters.) I want to 
register, in Simplified Chinese script "wu ke song jin heng . zhong 
guo(simp)" which is the way my customers recognize my bank branches. 
And, being in Wukesong, I am not too interested in an international 
presence other than overseas Chinese who probably grew up there.  (If 
I wanted to go international, I'd ask HSBC to buy me.)

And let's say that DNAME is used in the root zone, and CNNIC has 
elected to choose to continue to use "CN." as the "real registry" 
with DNAMEs redirecting "zhong guo (simplified)." and "zhong guo 
(traditional)." to "CN."

What do I configure in my servers? (Mindful of 4.2.1.3.)  I don't 
want to have to configure "Wu ke song. CN." because that involves 
latin characters?  Does the restriction with DNAME mean I have to?

The analogy in the draft of uppercase/lowercase as a precursor to 
IDNs doesn't work though.  Uppercase/lowercase is enforced in the 
"presentation layer" of the DNS protocol stack.  It would be nice 
if...IDNs were too, but that ain't gonna happen.

One of my favorite sayings is "don't let the bus drivers determine 
the route."  DNAME is very attractive to DNS protocol designers and 
operators because it is an easy way to configure the DNS to look like 
it fully supports IDN.  At first it seemed like a natural fit to me 
too.  The alternative of maintaining a copied tree seems fraught with 
consistency problems and other issues in comparison.

The alternative is fraught with problems.  No doubt.  But it can be 
worked to fit.  Sure some operators will have failures in 
consistency, but these problems can be worked out.  The question will 
remain open whether it is financially desirable to do so.  (Remember, 
if I have CN, ZG(simp) and ZG(trad) I will be loading three zones 
into the primary servers and slaving each, etc.  It'll be 3x the load 
of just one of them.)

It still comes down to the small enterprise owner though.  What is 
the Wukesong owner told to configure?  Do I have to hire on someone 
that knows "CN" or can they rely on someone who can handle just 
ZG(simp)? Or will this be taken care of at the presentation layer?

I think this draft is in the early stages of documenting a needed 
design choice.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

---

From: "YAO Jiankang" <[email-masked]>
Date: Mon, 9 Nov 2009 08:05:40 +0800

----- Original Message ----- 
From: "Edward Lewis" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, November 09, 2009 7:13 AM
Subject: Re: [DNSOP] draft-yao-dnsop-idntld-implementation-01.txt

> I think this draft is in the early stages of documenting a needed 

thanks .

 I will summarize the solutions and choose the solution that the WG thinks better.

Yao Jiankang
CNNIC

---

From: "YAO Jiankang" <[email-masked]>
Date: Mon, 9 Nov 2009 08:35:05 +0800

+1.
  ----- Original Message ----- 
  From: James Seng 
  To: Andrew Sullivan 
  Cc: [email-masked] 
  Sent: Saturday, November 07, 2009 8:10 PM
  Subject: Re: [DNSOP] draft-yao-dnsop-idntld-implementation-01.txt

  "There is a genuine user problem here (though whether one should actually solve it is still an open question)."

  It is not an open question it must be solved. It is a serious enough problem for Chinese that it must be resolve for the Chinese user. The open question is "how", not "if".

  For some background on CJK ideograph, you may refer to an expired draft I wrote many years ago

  -James Seng

    Best,

    A

    DNSOP mailing list
    [email-masked]

------------------------------------------------------------------------------

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 9 Nov 2009 05:44:55 -0500

> for Chinese that it must be resolve for the Chinese user. The open question

I understand that it is a serious problem.  But one solution is in
fact to solve this exactly the way we actually solved spelling
differences in English words: they're different zones, and we treat
them that way technically and use some non-technical policy rules to
solve the problem.

On this interpretation, the danger lies in acting as though there is a
mere technical solution for "variants".  Delegation (the "NS"
solution) just creates a new delegation, nothing more; and we ought to
be perfectly clear about that.  DNAME doesn't actually mirror an
entire tree, so it doesn't actually solve the variant problem for
real.  Therefore, if we want a complete solution to the problem of
variants, we need a new element in the DNS protocol.  It may require
server side processing, it may not work perfectly anyway, and it may
be subject to nasty subversions.

So, there is a clear benefit because there is a serious problem.  But
not all serious problems must be solved, because the solution can be
worse than the problem.  I don't _think_ the current example is a case
where the solution is worse than the problem; but I also don't believe
we have completely understood what exactly the problem is, whether
there is an actual technical problem here, and whether if there be a
technical problem we can invent or reuse any mechanism to solve it.
The proposals so far are, in my view, either completely wrong or just
mostly wrong.  (That includes using DNAME, by the way.)

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.