Subject: [dnsext] ICANN and sameness

From: Paul Hoffman <[email-masked]>
Date: Thu, 25 Mar 2010 07:24:39 -0700

Quite related to our recent discussion of making two zones look the same: <http://www.icann.org/en/announcements/announcement-22mar10-en.htm>. Maybe some of the submissions to this ICANN process will solve the sameness problem for us.

--Paul Hoffman, Director
--VPN Consortium

---

From: Edward Lewis <[email-masked]>
Date: Thu, 25 Mar 2010 10:23:04 -0700

At 7:24 -0700 3/25/10, Paul Hoffman wrote:
>Quite related to our recent discussion of making two zones look the same:
><http://www.icann.org/en/announcements/announcement-22mar10-en.htm>. Maybe
>some of the submissions to this ICANN process will solve the sameness
>problem for us.

We don't have the sameness problem, they do. ;)

 From recent conversations, I don't think all definitions of "the 
same" are equivalent.  (Drum roll, cymbal crash.)

Given the description of what is in that announcement, my reaction is 
that the only way to pull off this:

# 4.2. Demonstrated requestor success at use of convergence 
mechanisms at second
# and/or lower levels.

is to have the TLD "rewrite" the entire request before consulting 
downward zones.  Even a brute force population of a copy/clone/shadow 
zone isn't enough because that doesn't treat the "second and/or lower 
levels."

One could imagine the TLD server running recursively converting each 
label from one script to another.  Or one could imagine the TLD 
returning a CNAME that converts each label from non-canonical scripts 
to the canonical script.  Even if the TLD and the second level are in 
the canonical script, a third level that is not has to be converted 
(somewhere).

(Not to mention that the delegations have to know that they need to 
stick to the canonical script in setting up zones.  Or the name 
servers used have to know to convert to the canonical script.)

Note - these are extreme measures.  I'm just saying...

For one they assume the script is consistent in the entire domain 
name, not just the label the TLD handles, which is a subset of that I 
would have thought the problem to be.  I should stress that if ICANN 
sets that constraint on the problem, they are making the problem much 
easier to solve.  You can argue then whether such a simplifying 
assumption is appropriate - that goes to ICANN.  I do think it is a 
reasonable simplifying assumption to make.

What the announcement also tells me is that the equivalence of any 
two strings is known to be very subjective.  The rules for "equating" 
simplified and traditional Han characters are not the same rules for 
equating Greek or equating Arabic strings.  (Well, I don't think so, 
I'm  certain that I am not familiar with all the situations.)

I think the announcement is an appropriate expression of the 
requirement, at least in level.  It doesn't say that the DNS has to 
be modified, it says that the applicant has to provide the desired 
functionality.

This still gives me a problem:

# 4.4. Description of a registration policy requiring convergence at 
every level of the
# domain named by synchronized IDN ccTLDs.

my question should go to ICANN, but I'll lay it here - I can fully 
understand how the registration policy can "restrict" applicants to 
the canonical script and make it blazingly clear that the proper way 
to set up the name servers is for the canonical script - but what 
about subsequent delegations?  The non-canonical script zones might 
pop up lower in the tree (but never see a query).

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: John Levine <[email-masked]>
Date: 26 Mar 2010 03:47:41 -0000

>some of the submissions to this ICANN process will solve the sameness

Quite possibly, although their definition of "solve" may well be
rather unlike yours.

I expect that what will happen is that governments that want
synchronized IDN TLDs (China and Egypt are likely candidates) will
certify that they have adequate and verifiable procedures to enable
convergence at every level of the domain named by the synchronized IDN
ccTLDs.  They will do something like provision the two zones so that
they serve the same NS and glue records.  Then they will be done.

For the following decade, people will stand up at the ICANN meeting
open mike and express shock and dismay that registrants in such TLDs
routinely put completely different stuff in the two allegedly
synchronized domains, and that nobody does anything about it.  Someone
on the ICANN board will say gosh, we should certainly have someone
look into it.  They might even ask the SSAC to write a report.  Then
they will be done, too.

R's,
John, who spent several years on the ICANN At Large Advisory Committee