Re: [council] Re: Regarding issues report on IDNs

["Marilyn Cade" <marilynscade@xxxxxxxxxxx>]

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@xxxxxxxxx>
Date: Fri, 3 Feb 2006 20:38:01 
To:John C Klensin <klensin@xxxxxxx>
Cc:Patrik Fältström <paf@xxxxxxxxx>,       Tina Dam <dam@xxxxxxxxx>, 
council@xxxxxxxxxxxxxx,       Cary Karp <ck@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@xxxxxxx> wrote: 

--On Monday, 30 January, 2006 22:15 +0100 Patrik Fältström
<paf@xxxxxxxxx > 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@xxxxxxxxx
SKYPE: skypesoph
www.cbsintl.com
 
Regards,
Marilyn Cade