Re: [ga] VeriSign offering Chinese IDN-TLDs?? Which root??
At 05:49 27/10/2006, Karl Auerbach wrote: Gomes, Chuck wrote:Sorry for the delay in responding George. VeriSign is not operating an internationalized top level domain name (TLD)registry or registrar. The service offered by the Digital Brand Management Service (DBMS) business unit of VeriSign, Chinese internationalized TLD domain name registrations, is offered by CNNIC Karl, I explained that already many times. Please tell what you do understand, or where do you stop understanding. There is NO unique solution. Architecturally, there is the Chinese externet with different forms of access. Just stop thinking in terms of a single supernet created by the DOD, managed by ICANN, etc. along with RFC 4690 outdated Mono-Internet vision. This is just plain Hollywood. The Chinese system is only a network from the network of networks. And it has several access policies at the networks level. There are other externets around and plans to deploy a few thousands as part of the Multilingual Internet (by way of usage). ICANN competes with this fact of life, and with ISO (with the help of some IETF lobbyists). We will start discussing this more seriously on Monday, in Athens. jfc PS. Here is a post I just made on the ccTLDs which alludes to a possible I* community consensus leading to an advanced and rewarding management of the name space by a few stakeholders. Not easy to follow, but probably many problems and responses are there.
An analysis of what ICANN might be engaged into. This memo summarises the questions raised by the ".name" contract to the ccTLD community. It was written in co-operation with the other members of the NICSO Think-Tank, with the intent to use it and propose it to all the stakeholders as a reference in the coming IGF meeting as well as the following months/years. odd premises On a pure technical DNS stability Governance issue, this contract says that ".cc.name" cannot be used as a suffix unless either the concerned ccTLD and Government agree, or the ISO 3166 MA accepts it on a global basis. Questions Explanations are necessary and expected on the following points: - if there is such possible "minuscule" or not fully reported DNS stability problem why is ICANN not discussing it with the TLD Managers? Why is it contracting about it? Is the problem technical or legal? - when I invited Brian Carpenter last year to attend the ccTLD meeting in order to investigate a liaison between ccTLDs and IETF, he and the IAB hair declined because they thought there was no matter to discuss. They proposed to use the AD channel if there would be a need. Have the IETF ICANN Technical liaison been informed of this technical problem? - why does the ISO 3166 MA have more power to decide about such a technical problem than Governments, ccTLD Managers, IAB, ICANN, and IETF? - is it a true hazard that at the same time ICANN is becoming active in the ISO 3166 MA committee after not attending for years? - is it a true hazard that at the same time there is an IANA registry (RFC 4646), also competing with the ISO 3166 document, which is being created and actively developed? While there is no documentation on the way in which new ISO 3166 codes are delegated as ccTLDs (we currently have Montenegro; two French territory codes will be created in the coming months). - why is there no debate - as part of the IDN test preparation in particular - about the delegation of the country language codes should they be supported as NS and not as DNAME? - etc. This concerns all the TLDs All of the non-ASCII countries are concerned, and therefore everyone on the mid-term. - Because US law, the Tunis declaration, and the new ICANN contract certainly give ICANN legitimacy to follow the implications of Jon Postel's Mail #1 to ccTLDs and create many new ICANN chosen(?)/ISO 3166 decided(?) language ccTLDs, the same way as they created a language gTLD (.cat). - Because Verisign tests a "language-country-code.country-code" with the CNNIC. This permits a plug-in or a local ISP to add/remove the suffix and operate these names as ML.ML names. This is a solution of interest to every ccTLD. All the more, IE7 seems responsive to the IETF new standards, as Microsoft was quicker to support RFC 4646 (with the worrying results to confuse the Apache language function) than the IESG is (resulting in major risks on the IANA independence). However, once tested and supported, nothing will prevent Verisign to offer ".lcc.com" names that would probably be soon universally supported by ISPs (this could be a side effect of another project, such as RFIDs). This solution is already in use (cf. MINC-ICMC) but it is controlled by the concerned countries/ccTLD Managers, and not by ICANN. A strategy using technology I proposed the first possibility and warned about the consequences of its secondary effects. This was at the IETF WG-IDNA: I was by then fiercely opposed... It is noteworthy that this can be deployed parallel with DNSSEC support. Let us keep in mind the DNSSEC oriented entity that ICANN wants to create. It is to address DNSSEC support, with the possible structural co-operation of the TLD Managers (along the August 2005, NTIA statements). It would seem logical that this entity would structurally be a spin-off of the current ICANN structure, associating the GTLD constituency and ccNSO with special technical co-operation with the ISP Constituency. The ccTLD concern So, the real concern is not that NAME can use a ".cc.name". It is rather that there is an ICANN co-controlled credible alternative (including a possible replacement of RFC 1591) towards this solution for the ML.ML problem (the homographs are to be addressed in parallel). This results from (1) the NAME contractual trick, (2) an expected "we are not concerned" response from the ISO 3166 MA, (3) the engaged ISO/IANA competition on language, script, country, and locale files designation referents. Technically this will lead to the solution ICANN has documented in its ICP-3 document: an IDN class for IDNs (that would replace the IN class), an easier way for the applications to support ML.ML than to massage ".IDN" or ".lcc.com" labels at the application level. This only means a second parallel root, for this IDN alternative class. An interesting fall-out for the ICANN community stakeholders is that such an ICANN IDN class could be submitted to a domain name pricing policy that would be comparable to the one they discuss with the gTLDs, with the same Internet leading stakeholders possible dominance creep, impacting their ccTLD "competition". Why are explanation so slow? All theses are questions only. All of them certainly have good responses. What is worrying is that they are neither debated nor answered by Kim Davis or anyone else from ICANN. Yet? Or until it is too late for adopting alternative courses? Or risking a DNS split? This memo may seem strange to some, confusing to others, or extremist even. This is not: this is simply the core of the IGF debate. This means that we need a good clarification now. Otherwise our normal business precaution and the best interest of our constituents should lead us to work on the worst case assumption, during the IGF meeting and its follow-up, as long as ICANN/IANA does not speak-up. On Monday the first act is finished, let begin the second one From this Monday, F2F meetings, contacts, and decisions on these very issues alliance relations will begin to weave that will probably last throughout the next decade. ICANN can be a leader, an ally, a coopetitor, or a competitor. It is up to them.
|