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