[council] Re: Regarding issues report on IDNs

[Cary Karp <ck@nic.museum>]

> 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