Revisiting The DNS Notation Backwardsness Problem and Multiple Parallel Root Server Clusters

Mohsen BANAN <public@mohsen.banan.1.byname.net> Thu, 08 August 2002 02:23 UTC

Received: from loki.ietf.org (loki [10.27.2.29]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17646 for <ietf-web-archive@odin.ietf.org>; Wed, 7 Aug 2002 22:23:31 -0400 (EDT)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id WAA04819 for ietf-outbound.10@loki.ietf.org; Wed, 7 Aug 2002 22:24:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id WAA04792 for <ietf-mainout@loki.ietf.org>; Wed, 7 Aug 2002 22:23:00 -0400 (EDT)
Received: by ietf.org (8.9.1a/8.9.1a) id WAA17624 for ietf-mainout@loki.ietf.org; Wed, 7 Aug 2002 22:21:46 -0400 (EDT)
X-Authentication-Warning: ietf.org: majordom set sender to owner-ietf@ietf.org using -f
Received: from submit8.mail.intra (12-230-105-33.client.attbi.com [12.230.105.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA17619 for <ietf@ietf.org>; Wed, 7 Aug 2002 22:21:40 -0400 (EDT)
Received: (qmail 6175 invoked by uid 1001); 8 Aug 2002 02:20:50 -0000
Message-ID: <20020808022050.6174.qmail@submit8.mail.intra>
To: Stephen Sprunk <ssprunk@cisco.com>
Cc: Internet Technical Community <ietf@ietf.org>, public@mohsen.banan.1.byname.net
Subject: Revisiting The DNS Notation Backwardsness Problem and Multiple Parallel Root Server Clusters
References: <20020806134223.1611.qmail@submit8.mail.intra> <075e01c23d85$d3316690$dd876540@amer.cisco.com>
X-Envelope: envelope@mohsen.banan.1.byname.net
From: Mohsen BANAN <public@mohsen.banan.1.byname.net>
Date: Wed, 07 Aug 2002 19:20:50 -0700
In-Reply-To: <075e01c23d85$d3316690$dd876540@amer.cisco.com>
Lines: 254
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf@ietf.org
Precedence: bulk
X-Loop: ietf@ietf.org

>>>>> On Tue, 6 Aug 2002 15:13:58 -0500, "Stephen Sprunk" <ssprunk@cisco.com> said:

  >> Most notably, The DNS Notation Backwardsness.

  Stephen> You'll note that JANET originally used the notation you refer to as "forwards"
  Stephen> and it was decided that was a bad idea, and they joined the "backwards" notation
  Stephen> crowd.

I spent a fair amount of time in early 1999 and 
educated IETF cult's chiefs about 

    The DNS Notation Backwardsness Problem


The conclusion of that thread was that indeed
we have a genuine architectural DNS Notation Backwardsness 
Problem. I included samples of acknowledgement of the
problem in my previous message. Was hoping by now
that would be enough.

Perhaps you have not been around long.

I don't feel like leading that educational 
process on this list again. However, I am 
attaching to this message a summary from the 
January 1999 thread which adequately describes the
problem.

My thinking now, as it was in 1999, is that those who 
insist on denying real problems can be left behind.


The key point now is that the effort that Stef is now
leading towards the natural parallel server clusters
evolution provides a unique opportunity towards 
fixing the notation problem as well.

As we consider raising the DNS name space roof we have an 
opportunity to deal with other aspects of the 
DNS notation.

Despite previous failures of the IETF in dealing
with architectural problems, I'd like to think 
that the clear nature of this opportunity to 
fix the notational problem may resonate
with some in the Internet Technical Community 
and result into a movement towards a 
solution ...  Perhaps along the lines that I suggested.


--- Original Jan 21 1999 DNS Backwards Notation Problem Description Follows ---

From: Mohsen BANAN <mohsen@neda.com>
To: Brian E Carpenter <brian@hursley.ibm.com>
Cc: ietf@ietf.org
Subject: Re: Now: Next Generation Domains and DNS -- Was: Re: No More Central Authority: Not NSI/ICAN! Not ORSC!
Date: Thu, 21 Jan 1999 22:41:13 -0800 (PST)


[This is a summary response which in addition
to Brian's message addresses others' related
comments.]


>>>>> On Thu, 21 Jan 1999 16:24:12 +0000, Brian E Carpenter <brian@hursley.ibm.com> said:

  Brian> What I meant, and I think conveyed very accurately, is that
  Brian> both computers and humans can parse strings in either direction,
  Brian> so there is no "right" and "wrong". That being so, there is no
  Brian> reason to change anything and introduce confusion.


>>>>> On Thu, 21 Jan 1999 21:20:14 +0400, Peter Dawson <peterdd@gto.net.om> said:

  Peter> no doubt that computers parse in either directions..zats
  Peter> because people programmed them to. ...


This is not about parsing of strings.

It is about a fundamental architectural design
decision.  Based on what we have learned over
the past 15 years, the "right" and the
"wrong" are quite clear now. 

Key architectural attributes for "right" and
"wrong" are consistency, uniformity, cohesion,
fitness in bigger pictures, usability,  ...

These are not any "strings". Naming and
addressing are an integral part of the
architecture of any network. One of the
reasons why X.400 died is because its
addressing design was unworkable. 

With a variety of methods, even in an
evolutionary way, we have an opportunity to
improve on the current Domain Notation situation.

Yes, we have a problem. Our notation for
Domains *IS* backwards. The first step is to
recognize and acknowledge that.

Brian, the fact that you, the Chair of
Internet Architecture Board, is denying the
existance of this architectural problem -- and
consider it a string parsing issue -- is quite
disturbing to me.


Let me try again and make the existance of the
problem more clear.



Right now Internet Domains don't fit right
with numbers and the rest of the user's
integrated environment.


Any time that numbers and Domains have to work
together, it becomes un-natural, inconsistent
and backwards.  I call that "wrong".

Examples:

 IP Addresses: 
 -------------

 To find the name corresponding to
 the IP address of your nameserver which
 is: 194.196.110.155

 I have to enter it backwards (wrong).

 155.110.196.194.in-addr.arpa	name = sp2tr5.hursley.ibm.com

 In that case the natural (right) could have been.

 arpa.in-addr.194.196.110.155


 Fax Numbers:
 ------------

 To send a fax to +1.888.555.2222 using say
 tcp.int:

 I have to put the numbers in backwards.

 remote-printing.Name@2.2.2.2.5.5.5.8.8.8.1.tpc.int

 
 Phone Numbers:
 --------------

 If the Domains were straight I could imaging
 doing stuff like:

 Call net.ByNumber.1.888.555.3333:voiceOverIP:"collect"

 Can't do that with today's Domain Notation.



Let's go beyond numbers now.
 
Any time that anyone tries to use a consistent
mechanism for "completion", network objects
fail.  

The file system guys got it right. The OS guys
got it right. The language guys got it
right. Us, the network guys, got it backwards!

I can't even try to use completion for URLs, I
can't use completion for email addresses,
can't ...

To me, "completion" is the ultimate test of
designing naming and addressing machinery.



Before people come back and say, 

 "Oh, this is not a network or a protocol
  problem it is just a User Interface problem."

Let me say: If the protocol gets it wrong, in
practice the User Interface can't fix it.
There is no reason for not also fixing it at
the protocol level (evolutionary of course).

For example, the fact that no nslookup program
(that I know of) over the years have provided
a "straight" User Interface for in-addr says
something ...


As for the merits of mimicing the US Postal
Service. First let me point out that the
"backwardsness" problem goes beyond email
addresses and currently touches all service
identifiers.

More importantly to the extent that the
production of addresses on USPS envelops do
not involve a machine, for obvious reasons, the
drivers are human-to-human factors. Even then,
the human is expected to assist the machine
(in the US) with ZIP+4 numbers.  ZIP+4 is the
man-machine part of the address.  Now, ZIP+4
has the "right" order characteristics. 

For example, my ZIP+4 is: 98008-5765.  The
left most digits "98" correspond to the State
Of Washington. What is on the left is the
larger entity.

Now, if I want to use the Domain Notation to
set up a Physical Delivery Access Unit, then
the address would become something like:

  Mohsen.Banan@5765.98008.ByZipCode.us

Again backwards!


You see, the USPS doesn't have much of a
problem here. Not much needs fixing there ...


To move the Internet forward, our Domain
Notation can benefit from some improvement.



Now, after all of this if there was to be an
acknowledgment that there is an architectural
problem here and that this is not a "strings
parsing" issue which can go either way, then
may be we can work on solutions ....


Or, we can just sweep known problems under the
rug.

Your Call!


us.ByZipCode.98008.5765@Mohsen.Banan