Re: [council] Re: Regarding issues report on IDNs
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@gmail.com> Date: Fri, 3 Feb 2006 20:38:01 To:John C Klensin <klensin@jck.com> Cc:Patrik Fältström <paf@cisco.com>, Tina Dam <dam@icann.org>, council@gnso.icann.org, 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@jck.com> wrote: --On Monday, 30 January, 2006 22:15 +0100 Patrik Fältström <paf@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@gmail.com SKYPE: skypesoph www.cbsintl.com Regards, Marilyn Cade
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.
Nobody has suggested that all TLD labels should/will/can be entered into the root in every language that appears elsewhere in the namespace. Nor is English the default language of the root. There is apparently also still a great deal of confusion about the distinctions between script and language, and between names and identifiers. Although it is certainly worth Council's time to delve adequately into such matters, the short path out of the present quandary is by noting that the potential number of non-ASCII labels that are likely to be suggested for inclusion in the root zone is utterly independent of the way in which those labels might ultimately be registered. As has already been pointed out in the present sequence of exchanges, an IDN TLD can be established either with conventional delegation records or with DNAME records. We can postulate the unsuitability of DNAME for that purpose (for which it was not initially intended), or we can postulate the opposite (if we feel like being reckless), or we can test them in the new context before proceeding any further in the discussion of their being an alternative to the current way of expanding the root (which might be reckless, anyway, but is an absolute necessity given the threat that our failure to do so represents to the single global namespace). The outcome of such a test will neither brake nor further the demand for including new scripts in the TLD repertoire. There will be situations where two TLD labels in different scripts are deliberately intended to be semantically equivalent (in two or more languages using those scripts), but are to be associated with separate name trees. There are also situations where the intention will be to attach the same name tree to different representations of the TLD ID. Both cases are fraught with political and IPR concerns, and both will be encountered in the gTLD and ccTLD spaces. The thing that DNAME brings to this -- the only thing -- is the possibility that it provides for injecting a weak modicum of referential integrity into a database environment that lacks any such native mechanism.
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?
If the only means that were permitted for the registration of an IDN TLD were the assignment of a CNAME record to a pre-existing name tree, the effect on competition might be arguably different than would be the case if both forms of IDN TLD delegation were implemented. It would exclude transliterated and translated versions of pre-existing TLDs from delegation to separate operators, and there would be disputes about what might constitute adequate semantic differentiation for a new TLD label. If the only mechanism that were permitted for the registration of an IDN TLD were the conventional delegation of authority for a separate name tree, the potential for dispute would be significantly greater (to say nothing of the encumbrance to prospective name holders). This is not, I would have thought, something that the GNSO Council would wish to precipitate if there were any way to avoid it.
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.
As long as we are immersing ourselves in policy details of the internationalization of the domain namespace, we would be well advised to think more than twice before making any statements that assume the legitimacy of the notion of language ownership. Which national government owns the English language? Which owns the Latin alphabet? Which owns Cyrillic? Are the Chinese language and script any easier? Arabic?
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?
Made DNAME unpopular? For whom? In what context? We are talking about testing a new application. One informed expectation of its outcome is as good as another. I am amazed that Council seems to believe that its interests might be better served by that test not being made at all, as though it were an unnecessary impediment to the serious work of policy making. (But, of course, that's just my opinion. :-) ) /Cary
If the only means that were permitted for the registration of an IDN TLD were the assignment of a CNAME record to a pre-existing name tree,
That should be DNAME, not CNAME (a well understood beast which we all safely rely on). Sorry!
participants (2)
-
Cary Karp -
Marilyn Cade