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

[Edward Lewis <[e-mail]>]

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 [phone]

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