Re: [ga] Re: and if we addressed the problem at its real root? (was Re: Names Council Resolution on Reform)

["J-F C. (Jefsey) Morfin" <jefsey@club-internet.fr>]

Hi, Todd,
speaking Frenglish helps me a lot to spot when natives speak biased Eglish :-)
I am afraid you lost that fundamental point in my proposition for a serious 
debate (is that only possible?)

On 18:47 05/08/02, todd glassey said:
>Pure BS Jefsey. The basis of the commentary - the RFC you site, is just
>that, pure BS and is totally based on a personal opinion of
>the author and not technical fact.(I am referring to the specific
>portions of the RFC you site as 2826 has all kinds of good
>material in it pertaining to the operations of DNS systems.

That RFC (which is a comment) refers to the global namespace. The ICANN 
only controls the arpa domain sub-namespace. The global namespace is made 
of whatever string of 37 codes you want for 0 to 9, a to z and dash, from 
left to right. If you want to read it by dot separted labels, the DNS 
convention is to read it from right to left, starting wigth a dot, to limit 
it to 257 codes and to forbide double dot sequences. This Louis Pouzin's 
concept, initiatied with the 256 codes of the 4 digits IPv4 addressing, 
significantly increases the number of its possible organizations by less 
than one order of magnitude and gives a better readability and 
memorization. The common global namespace includes also spaces and is read 
from left to right having no dot.

The global namespace has obviously a single global root (the empty dot). 
What the RFC 2826 says is that the systems needs a global "coordinated" 
management of the master file. We have many instances in here - including a 
mail of Joe Sims - showing that when an American means coordinated it means 
a loft of different and contradictory things to other language. If I read 
correctly what Joe expressed here about the management of the ICANN, I read 
that a "coordinated" management means a "concerted registration policy" and 
only means that who ever adds TLD in the real life namespace, they do not 
add conflicting TLDs.

This has always been the case (except by lack of inffomation) until ".biz". 
See the RF/BP please.
http://boroon.com

>However - A simple solution based on  NAT and Search Engines,
>and perhaps an LDAP lookup for the root server tables,
>which did not exist when DNS was formulated or evolved, is
>easily fielded and answers all the questions about mutli-roots.

There are certainly several solutions. The one you quote is a possible one. 
I only regret that you do not respondmy proposition to join the 
experimentation of a multiple parallel root servers system. This includes 
the call on different technologies and ways of disseminating the DNS 
information.

<snip>

> > May I try to initiate a positive discussion on the subject. Everyone knows
> > that I am operating a small experimental root, so no one can think I am
> > biased when I say this as a starter;
>
>Congrats!
>
> >
> > 1. I fully accept the RFC 2826 main text. I quote it here so it is clear.
> > <quote>
>
>Please Jefsey I need a set of "waders" the BS is flowing thick here.
>Especially this next concept.

No. The BS is the confusion that many people steadily make - for a lot of 
reasons - between the global namespace and the arpa namespace.

> >     To remain a global network, the Internet requires the existence of a
> >     globally unique public name space.
>
>Anghhhhhhh - Buzzer sound. This is simply not true and at the very best it
>is a personal opinion so it has no place in a RFC.

This is totally true. But:

1/ the namespace is the global namespace as created in 1977, developped and 
proposed under FCC license for the US and the world: where ARPANET 
registered "arpa". Where many "other systems" (RFC 921) were already 
registered.

2/ the DNS is a method of managing thet namespace in a value added way.

3/ Bind is only a way to implement the DNS support. djbdns, the one you 
quote etc. are other ways.

<snip>

> >     The
>
>EXISTING
>
> >     DNS name space is a
> >     hierarchical name space derived from a single, globally unique root.

The global namespace does exist in itself.
The DNS is a way of managing it, that way should be improved. This is what 
I name DNS.2 and which has to be worked on.
There are also a lot of extended services to be proposed above the DNS. I 
name DNS+.

>yes this is true as  we know from DNS Services from yesterday.
>And we also know that this is not true going forward.
> >     This is a technical constraint inherent in the design of the DNS.
>
>No - it is an opinion and only that.

This text only say that there is a sky and that by design it has a zenith. 
The BS is to believe that this text which says that white is white is 
considered as important by many poorly reading it. But since they consider 
it important and it says nothing new, I have no reason not to accept it.

> >     Therefore it is not technically feasible for there to be more than
> >     one root in the public DNS.
>
>This is an out and out lie. It speaks to something that is just blatantly
>not true. And yet it is the cornerstone of the IETF's stance. If the "Look
>we printed it in an RFC, so it damn well is the truth..."

They just printed the sky has a zenith. If this is the cornerstone of the 
IETF stance they will fall down from high :-)


> > That one root must be supported by a set
> >     of coordinated root servers administered by a unique naming
> >     authority.
>
>Of course, but even Verisign and Vixie himself have backed
>away from BIND, so maybe the Berkley Internet Name Domain
>technology is just that - technology built to run the UC Berkeley
>internal network and not that of a global solution even in spite
>of the IETF.

This is why it is urgent to work on coordinated "root servers systems" 
under a unique global naming authority made of the concerted relations of 
the main namespaces such as ICANN (arpa), USG (mil, gov, us, edu), EU (eu), 
ORSC, New.net and others, ccTLDs; ITU, namenclatures etc. before the Govs 
introduced into the game by Mike Roberts' letter and by Stuart Lynn's call 
come and decide that they are the roots of everything.

> >     Put simply, deploying multiple public DNS roots would raise a very
> >     strong possibility that users of different ISPs who click on the same
> >     link on a web page could end up at different destinations, against
> >     the will of the web page designers.

I am afraid however you confuse the nature of the namespace. The name space 
conforms wih the UN EDI recommentation to use mnemonics. Alphanumeric 
mnemonics are not to be used into various namespace but for a common 
understanding among people. Brainware. There is only one global human 
namespace, a single DNS reduction, a single X.121 reduction etc.

There are however the possibility of different views. The interest is 
howver that the different views do not confuse the system. IMHO what you 
confuse is parallel namespaces and abreviated addresses. Let consider the 
network address : abc.def.ghi : if you are in the sub-network "ghi", using 
abc.def is enough to clearly identify whee you are: this is what new.net 
proposes for the web.
jfc

<snip>

>No it doesn't unless they are all working off the same address space
>and that is the key to separating root's - that is in being able to have
>independent address spaces. Hence the need for Global NAT
>Gateways and like technology.
>
>The RZP or  Root Zone Resolution Protocol proves that this is
>IETF allegation is simply untrue... And if the addresses and
>names are constrained by their root zones this also allows total replication
>of name space per root zone. A simple fix for the IP issues and Name Space
>Crowding.

OK. Let use it to resume the "fra" adressing. So I may use the 
"14.7.89.fra"  IP address. Now tell me what DN I am to use to access it 
from an arpa domain IP address. To do that I need the nets to have 
organized as pr RFC 920/921 - ie a globally transparent namespace managed 
by compatible name system managers using different root names and to 
simplfy my use non conflictng ULDs (upper level domain names in the used 
technology/system)/

Instead of disputing, why not just to help developping a workgroup for a 
real experimentation respecting the IPC-3 (non BS parts).

jfc