[council] Re: Regarding issues report on IDNs

[Marilyn Cade]

I am much appreciative of this kind of exchange which can advance the understanding of many of the non technical councilors, and our constituency members. 

Sophie, I think you have identified a concern I personally have abt DNAMES as I understand them, but I must study further. Does a DNAMES approach advance an extension of present Latin character gTLDs into non Latin character, but do not expand the underlying infrastructure competition. 
Or do more? 


For instance,  when we created the policy guidance for sTLDs, and unrestricted/open TLDS, my view was that to fully understand and take into account the implications of whether policy for non Latin character strings policy was needed to determine issues such as:

 1) extend operation of non Latin versions to that registry operator 2) prohibit that string in non Latin character 3) assume new policy that would ask these questions. 
4) Address non-Latin chacteri gTLDs as is presently being studied.

DNAMES is a technological solution to address the IDN challenges in a particular way?

The questions asked by Sofia -- and asked in the recent international meetings I attended on Internet governance -- are broader. And need to be understood. There may be technical realities to what answers "work".  I find this dialogue of considering the options, most welcomed. 

Marilyn
-----Original Message-----
From: Sophia B <sophiabekele at gmail.com>
Date: Fri, 3 Feb 2006 20:38:01 
To:John C Klensin <klensin at jck.com>
Cc:Patrik Fältström <paf at cisco.com>,       Tina Dam <dam at icann.org>, council at gnso.icann.org,       Cary Karp <ck at nic.museum>
Subject: Re: [council] Re: Regarding issues report on IDNs

Hi John, 
 
Thanks for your reply and your point well taken...specially about the complexities of IDNs and getting to know it better.  While we are certainly not members of the flat earth society, we do desire to keep both feet on the ground as well.   As such, the  I do not see the DNAME dealing with greater problems of addressing a 'solution'. 
 
The DNAME may be ok solution from a technical point of view, as each current TLD can have equivalent TLD domain names in ALL languages, IDNs in ALL languages pointing to English domain names, but would present a greater issue from a the perspective of policy, politics, control, competition etc.   
 
This creates BIG problems, a political one I must say, as for eg. US would have an equivalent in Chinese, Arabic, and others managed by Neustar.  I am not sure if the Chinese or Arabs will like that.  On the other hand - Iran and Syria will have a Hebrew TLD  - I am note sure the Israelis would like that.  
 
Without being a cause for WWIII, how could we resolve the issues of 'why should Verisign have.com in all languages?  Don't they have half the domain names in the world already?   I suppose some people have their eye on the end of the rainbow, rather than t rained on the cobble stones looking out for the next stray copper penny.  
 
But, these are some of the problems I believe made DNAME unpopular, even if it is OK technically.  As you have already said John, - all technologies have pros and cons (and we know them already...) 
 
Finally, should NOT the above be one of the main reasons as to why the testbeds should be considered to be open for eveyone, as oppose to only existing TDLs? or even a consideration for entirely dropping it and go for policy making? 
 
Have a nice weekend. 
Sophia  
 
On 30/01/06, John C Klensin <klensin at jck.com> wrote: 

--On Monday, 30 January, 2006 22:15 +0100 Patrik Fältström
<paf at cisco.com > wrote:

> On 30 jan 2006, at 18.07, John C Klensin wrote:
>
>> Sophia, there are two main groups of issues with DNAMEs.  Let
>> me see if I can oversimplify and summarize them (please see 
>> footnote below):
>>
>> (1) If I have a domain a.b.c.d. and want to make a DNAME
>> reference from y.z pointing to b, I set up a DNAME record
>>
>>       x.y.z.  IN DNAME b.c.d.
>
> Hmm...I am confused of your example,

Fooey.  I got it wrong and thought I had corrected it.  I knew I
was a bit too tired when I wrote it, sorry... See below

> if you want the domain 
> name  anything.b.c and anything.x.y be the same, for any value
> of anything,  you can do one of three things:
>
> (1) Have records anything.b.c and anything.x.y in the zones
> b.c and  x.y  respectively. There is in this case nothing that
> synchronize the  two records with each other. The records are
> two completely different  ones.
>
> (2) Have CNAME for anything.b.c -> anything.x.y . This requires
> addition of CNAME (and removal) in the b.c zone anytime any
> record is  added (or removed) in the x.y zone.
>
> (3) Have a DNAME for b.c -> x.y which will make sure that
> anything.b.c. is rewritten to anything.x.y and the query is
> restarted, just like CNAME but without any need for CNAME RR's
> for  all of the RR's in the x.y zone.

This is what I meant to write above.
 
> This implies that the zone owner for x.y have an alias that is
> b.c.  Anyone can query for anything.b.c. and get responses for
> anything.x.y.
>
>> The zone files for y.z. and c.d. may be located on different 
>> servers, with different connectivity, different refresh
>> intervals, different TTLs, different administrations, etc.
>> This raises a number of issues that are long-standing topics 
>> in the study of fully-distributed databases (not hierarchies
>> with a single point of control for each node such as the
>> DNS).  The solutions for some of those topics are well
>> understood but the DNS doesn't have the necessary tools for 
>> dealing with them. Others remain research problems.  I won't
>> even try to begin to try to explain them but suffice it to
>> say that it becomes very hard to tell when changes that occur
 >> somewhere, especially if e.b.c.d is, itself, a label on a
>> DNAME record pointing into yet another part of the tree.
>>
>> But a reference within a single zone file, e.g., a DNAME
>> record in the root zone that points to a name in the root 
>> zone, doesn't raise any of those issues (although, if I were
>> asked for recommendations about how to be very conservative,
>> I'd tell people to be very careful about DNAME entries in any
 >> subdomain for which a superior domain is pointed to by a
>> DNAME).
>
> Correct.
>
> The safe usage of a DNAME that we know of is to have in one
> zone  the following (for example): 
>
> $ORIGIN foo.com.
>
> fratz IN DNAME bratz
> bratz IN NS ns.bratz
>
> This implies when one look up foo.fratz.foo.com  the lookup
> will in  reality be for foo.bratz.foo.com. It is even said it
> can be resolved  by having synthesized CNAME be returned to
> the client.

Yes.  I was trying to avoid quite that much detail (and I try to 
never use $ORIGIN statements in examples but only FQDNs), but
this may help make it more clear.

> The record in the example itself is in the zone bratz.foo.com.
> No RR  exist with the owner foo.fratz.foo.com.

Right.  Again, sorry about the confusion.

   john

-- 
Sophia Bekele
Voice/Fax: 925-935-1598
Mob:925-818-0948
 sophiabekele at gmail.com
SKYPE: skypesoph
www.cbsintl.com
 
Regards,
Marilyn Cade