ICANN/GNSO GNSO Email List Archives

[ga]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [ga] Re: alternative root DNS systems which resolve ICANN domains as well?


At 11:31 24/05/2006, Karl Auerbach wrote:

Stephane Bortzmeyer wrote:

It cannot work because you need a way to resolve collisions like
".biz" or ".home" (which appear in several namespaces).
If you want uniformity (every name leads to the same resource
everywhere), you need an unique root (see RFC 2826). Period.

Well, as you knew I would, I have a different point of view. ;-)

Well, as you knew I would, I have a different approach ;-)

Both of you are correct in what we can call the Internationalised US Internet. That is once ICANN has decided the way to address the ML TLD issue (CNAMEs with 40% (?) of the root servers unable to support them if the SSRAC was convinced - or NS names meaning 100s of new TLDs). I note that none has yet considered the impact of the typos on the root servers with ML TLD: each typo in the TLD label goes to the root servers as an unknown TLD: with complex typing TLD typos will dramatically increase. Today only 2.5% (two years old figure) of the calls to the root system are legitimate.

But this is far more complex in the Multilingual Internet I preach and work for for years and the IGF now is to build.


There we have four popular naming systems supported in the world (not talking of Handles, etc.).
- Internationalised DNS using punycode "xn--" names with major IP problem I discuss with the WIPO (xn--TM issue)
- Unicoded DNS using (the) Unicode charset(s) as some TLD seem to do.
- Keywords as countries like Korea, China, Turky, ...
- Aliases everyone can use (when I want to access ICANN I enter "nuts", what leads to enthousiats reactions when I quote my URLs)


Today we have significant efforts to embody externets (structured walled gardens) such as China, GMSA, Arabic effort, etc. as shown everyone the ITU/UNESCO meeting. This is not just some Jefsey's stupdity. This is even 80% of my time with people all over the world.


All this is complex and leads to serious technical/personal conflicts.

As an example, Stephan is among people having engaged an action to fire me from the IETF. This is because I defeated their proposition supported by the US industry main leaders to consistently support languages as 150 variants of English. FYI our open source proposition (and several ISO/JTC1 efforts) is about 20.000 entities and 6 billions language support units to be able to address local emergency calls everywhere - what the linguistic and emergency support technology [not administration yet] now permit.

The IETF/UNICODE approach Stephane supports is named "globalization". This is the addition of the "internationalization of the Internet" (exemple: the IDNs) and of the "localization" of the ends (locale files). This is NOT a wrong proposition. What is detrimental to the Internet and to the people is to consider it final and exclusive (defeating their equal linguistic opportunity Human Right). This is a first layer.

The layer above is multilingualisation. It consists in giving everyone the same linguistic opportunity as English mothertongue people. You will note that "e-mail" is pronounced in French with an English "e-" and not a French one. It litterarily means "English inside" (From: To; Subject:, etc.). This is OK for a prototype, not for a real life mature system.

The good thing of Stephane's friends action is that it helps thinking and clarification (to be honest they used my weak to strong strategy: which lead me to obtain (against me :-)) the clarifying consensus I was denied. This consensus accepted by the IESG one or two hours (after a one year fight) after they reach an agreement in Tunis, now worries them and they try to by-pass it. The appeal I have with the IESG and I will escalate to the IAB is to help all of us to clarify all this and if the IETF works for the Internationalised US Internet or for the IGF Multilingual Internet.

This has important consequences concerned leaders fully undertsand.

- the root server system has preserved the unity of the Internet under Jon Postel in preserving our 1984 agreement to the letter, except the ".biz" violation. But now it is a fragmentation incitation as we see it in the Chinese externet case. This can be seen in the way even people like Karl have difficulties in understanding the Chinese set-up. This is because they think the Internet architecture is mono-authoritative, along the current US root set-up. The ICANN ICP-3 document called for the experimentation of the future of the DNS. I ran such an experimentation, along the ICP-3 lines (community experiment, reversibility, non-profit, respect of the global operations, etc.). It shown that the Internet technology can be [to some significant extent] structurally multi-authoritative, not only via limited constrained exceptions or local NATs.

This means that an externet like China, or GSMA (NeuStar), etc. and now the Internationalised US Internet created by the Congress and the Tunis agreement, can very well live together in the world digital ecosystem. But those who want to fully benefit from this must be freed from the momo-authoritative solutions (mono-authoritativeness does not fit and scale in a distributed system). Practically it means the end of the root server system as a mandatory system for all, and the consistent management of the name/keywords/alias at ISP, national, private, etc. levels. This is the necessary consequence of the multilingualisation, multilateralisation, and increasing expectation of network services.

Or we go into the mess Stephane describes through a generalisation of what Karl describes.

Stephane is right: the current Internet legacy system has to work the way he describes. This was our 1984 consensus.

But the 1984 Internet has become the world system and it needs to support the world expectations. Karl describes the way it can do it. This kills what Stephane tries to preserve. Both wants what the IETF is supposed to pursue: that the Internet works better.

I say, the solution is to upgrade the architecture to address what Karl documents in the way Stephane demands it. This is possible because the upgrade can be carried (at least for now) at the meta layer (brainware, the way we use and understand the network).

- This does NOT make ANY change in the Internet architecture.
- BUT it means a change in practice - for those who want to unleash to theior advantage the Internet architectural power ICANN is curbing. Tunis has given the solution if ICANN accepts to respect it (and this is in its mission documented by the NTIA a few days ago). The problem is that those who want to keep the status-quo (Stephane) must trust the ones who want to go ahead (Karl) will not endanger their stable operations. To achieve that the best would be a technical consensus over an MoU/RFC where:


- ICANN accepts to manage the NTIA root file and addressing plan without conflicts with other name and addressing spaces.
- IETF accepts to document how and where to manage the name, keywords and alias spaces


Otherwise this will be carried as for China and what many push ITU to do due to the IETF/ICANN delays and lack of understanding: in a grassroots way. Will this work?

I suppose it will as most will strive to avoid fragmentation. Except may-be ICANN and the USA, to show their power - this would be a poor idea as there is no more a need for a "nuclear" option: the resulting limited confusion would be detrimental enough to the USA.

Then we will most probably see an evolution using the externets basic notions of classes (Internet uses only one "IN" class), groups (we only use 2 "A" and "MX"), using the metadata registries (what I do with the MDRS [multilingual distributed registries system]) to replace and dramatically extend the IANA functions and scope. In this the ICANN will continue to play its role as the US agency of the Internationalised US networking solutions, naming industry union, and regalian services support over the world digital ecosystem. With border conflicts to address at the IGF with their foreign equivalents. Something very similar to other transportation services (ships, trains, airplanes, posts, road, etc.).

May be then we would have gained the surety, security, stablity, scalability, etc. we long for.
jfc





<<< Chronological Index >>>    <<< Thread Index >>>