Aliasing & Policy & China

[zfreud]

Not to beat a dead horse but I found this comment in the wrap up session kind of interesting:

"RSSAC [root server system advisory committee] is happy to provide advice on DNS specific technical aspects of test and deployment, and on the specific issue of aliases for existing names in the IDN space. Should aliasing become a requirement, RSSAC would work with ICANN to identify how to meet it. But it's our understanding that such a requirement has to come out of the policy processes undertaken by other bodies."

My take on this latest conference?

1: NS cTLDs within 12 months. Those being China, Japan, Korea and Russia. Possibly some solution for Arabic. More to follow rapidly after that.

2: NS gTLD is going to duke it out on a policy level with aliasing for at least a couple of years.

Is this good or bad for .com? As far as China goes, it will all boil down to whether the Govt. f*cks with .com to promote their own IDN NS TLD(s). Given the % of native businesses that use .com I think that scenario is unlikely. My prediction (granted it is driven by a healthy dose of self interest) is that the promotion of a hanzi IDN cTLD will also drive healthy adoption of hanzi.com

Comments from native mainland chinese would be very interesting!

[Rubber Duck]

Not to beat a dead horse but I found this comment in the wrap up session kind of interesting:

"RSSAC [root server system advisory committee] is happy to provide advice on DNS specific technical aspects of test and deployment, and on the specific issue of aliases for existing names in the IDN space. Should aliasing become a requirement, RSSAC would work with ICANN to identify how to meet it. But it's our understanding that such a requirement has to come out of the policy processes undertaken by other bodies."

My take on this latest conference?

1: NS cTLDs within 12 months. Those being China, Japan, Korea and Russia. Possibly some solution for Arabic. More to follow rapidly after that.

2: NS gTLD is going to duke it out on a policy level with aliasing for at least a couple of years.

Is this good or bad for .com? As far as China goes, it will all boil down to whether the Govt. f*cks with .com to promote their own IDN NS TLD(s). Given the % of native businesses that use .com I think that scenario is unlikely. My prediction (granted it is driven by a healthy dose of self interest) is that the promotion of a hanzi IDN cTLD will also drive healthy adoption of hanzi.com

Comments from native mainland chinese would be very interesting!

Well, I'll give you 6 out 10 for effort. At least you have been following events and tried to understand what is going on from interpretation of the discussions but you missed this vital clue:

>>First of all, that it might not be possible to separate internationalized top-level domains into ccTLDs, gTLDs, or any other categories. Now, what that, of course, means is that the ccNSO, GNSO, and the GAC IDN working groups have a large amount of overlapping issues that they all are considering, and they need to be solved together.<<

http://www.idnforums.com/forums/10258-tinas-report.html

http://www.icann.org/meetings/lisbon/transcript-public-forum-29mar07.htm

It is also now clear that NS can at best only provide a very provisonal solution to the aspirations of the community. DNAME is needed urgently for more than a patchy implementation.

[zfreud]

Listen Duck you are smoking IDN crack if you seriously believe that they will resolve all the DNAME issues before NS cTLDs are launched. Christ it took them 6 months to test a NS solution that almost everyone is the technical community believed was already a forgone conclusion.

DNAME may indeed arrive but not untill well after IDN.com and IDN.icTLD are well established in China.

Minimum 2 years. Probably more like 4.

And as I left school some time ago I'll leave it to your fantasy world to continue on as Professor DNAME and grade accordingly.

[Rubber Duck]

Well Tinas comments are Report to ICANN board following a very interesting Workshop session. These comments were clearly made after discussion with a number of senior board members, so if you choose to ignore them whilst making your calculations then that entirely your affair.

The bottomline is that Great and Good thought that iccTLD implementation was going to mirror the implementation of ccTLDs but the input from the Workshop makes that impossible.

The ccTLD extension lists were adopted from an ISO standard used by the United Nations. What is now clear is there is no definitive list of Country Names in their own scripts. Also, it now clear that full implementation of ccTLDs will require implementation of each ccTLD in each language, even ones like .co.uk and .us. This means than instead of a list you are going to end up with a Matrix, and it will take year to fill in all the boxes. Furthermore, the trick or reserving all two character combos at the Top Level is not acceptable to ccTLDs. They want their codes in whatever length they feel is appropriate. You cannot future-proof iccTLD except by reviewing each and every entry of every type of TLD.

This means that it is no longer feasible to think of iccTLDs as a quick win before continuing with igTLDs. Both are going to have to be implemented on a "ready to go" basis. Dot Com will almost certainly go either at the same time as dot CN or shortly after. Admittedly, it is only likely to be mirrored into a few major lanuages, but that is almost certainly what will happen in the near future.

DNAME is now essential for proper implementation iccTLDs, even more so than it is for igTLDs. It will now have to be expedited. And yes it is a big job which is why to complete the work allocated to a 2hr Workshop they have already booked all day for Puerto Rico!

Listen Duck you are smoking IDN crack if you seriously believe that they will resolve all the DNAME issues before NS cTLDs are launched. Christ it took them 6 months to test a NS solution that almost everyone is the technical community believed was already a forgone conclusion.

DNAME may indeed arrive but not untill well after IDN.com and IDN.icTLD are well established in China.

Minimum 2 years. Probably more like 4.

And as I left school some time ago I'll leave it to your fantasy world to continue on as Professor DNAME and grade accordingly.

[alpha]

..Professor DNAME..

another day...

another thread...

another dname debate...

and what have we learnt since the last one?

well apart from RD gaining another nick-name i'd say approximately - jack-shit.


here's looking forward to the next thread. I'd best start thinking of another witty nick name now..

[Rubber Duck]

I think what we have learnt, on balance, is that most people here do not believe that there is any connection between ICANN Summits and formulation of policy relating to new TLDs being put into the DNS Root.

It would also seem that most people here are of the view that ccTLD Registries have open access to the Root and can insert what they like at any time without any consultation whatsoever.

I am sorry my rather contraian opinions seem to be offending people.



another day...

another thread...

another dname debate...

and what have we learnt since the last one?

well apart from RD gaining another nick-name i'd say approximately - jack-shit.


here's looking forward to the next thread. I'd best start thinking of another witty nick name now..

[Giant]

The discussions of IDN.IDN is not a subject I concern much, because I believe the world will be using IDN.ascii and NOT IDN.IDN.

But I did see some very positive attitude towards IDN from these discussions, and it seems the whole world is waiting for IDNs.

The reasons I oppose the concept of IDN.IDN are:

1. IDN.IDN is NOT NECCESSARY, but IDN.ascii IS NECCESSARY.

2. IDN.IDN's implementation involves getting agreements from too many authorities and organisations, and more than 250 contries and communities have their own choices and these choices often conflict with each other and there's no a single authority been set up yet to deal with such conflicks. IDN.IDN's complexity is beyond ICANN's authority.
The technical part is not that much a problem, but before we decide which way to solve the technical problem we need to be guided by a uniform policy. A uniform policy for IDN.IDN will not be here for many many years, mankind have not learned to solve problems with such complexity YET. :-)

Again, VeriSign is celebrating.

[Rubber Duck]

Well the route map to a uniform policy has been torn up and thrown in the bin. What ICANN thought was the solution seems to have been built on false premise.
As a consequence iccTLD cannot simply be implemented using NS as previous thought and is now in the same boat at igTLD.

If they wait for a new uniform policy with complete lists for iccTLD, it will take forever to implement, indeed as you suggest. They have more or less now accepted that they are going to have to start implementing records using NS on an ad-hoc basis, whilst they set about reformulating policy.

Actually IDN.IDN is a necessity for some. You just cannot mix and match Right to Left and Left to Right strings. In this case you are thinking in your own little Silo. The Arabs need IDN.IDN and they need it now. Most of all they need it in dot com because they have no common ccTLD like the Chinese.


The discussions of IDN.IDN is not a subject I concern much, because I believe the world will be using IDN.ascii and NOT IDN.IDN.

But I did see some very positive attitude towards IDN from these discussions, and it seems the whole world is waiting for IDNs.

The reasons I oppose the concept of IDN.IDN are:

1. IDN.IDN is NOT NECCESSARY, but IDN.ascii IS NECCESSARY.

2. IDN.IDN's implementation involves getting agreements from too many authorities and organisations, and more than 250 contries and communities have their own choices and these choices often conflict with each other and there's no a single authority been set up yet to deal with such conflicks. IDN.IDN's complexity is beyond ICANN's authority.
The technical part is not that much a problem, but before we decide which way to solve the technical problem we need to be guided by a uniform policy. A uniform policy for IDN.IDN will not be here for many many years, mankind have not learned to solve problems with such complexity YET. :-)

Again, VeriSign is celebrating.