Revisiting The DNS Notation Backwardsness Problem and Multiple Parallel Root Server Clusters  
 
    ⋆ To: "Stephen Sprunk" <ssprunk at cisco.com>  
    ⋆ Subject: Revisiting The DNS Notation Backwardsness Problem and Multiple Parallel Root Server Clusters  
    ⋆ From: Mohsen BANAN <public at mohsen.banan.1.byname.net>  
    ⋆ Date: 07 Aug 2002 19:20:50 -0700  
    ⋆ Cc: "Internet Technical Community" <ietf at ietf.org>, <public at mohsen.banan.1.byname.net>  
    ⋆ In-reply-to: <075e01c23d85$d3316690$dd876540@amer.cisco.com>  
    ⋆ References: <20020806134223.1611.qmail@submit8.mail.intra> <075e01c23d85$d3316690$dd876540@amer.cisco.com>  
    ⋆ Sender: owner-ietf at ietf.org  
    ⋆ User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp)  
 
>>>>> On Tue, 6 Aug 2002 15:13:58 -0500, "Stephen Sprunk" <ssprunk at 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 at neda.com>  
To: Brian E Carpenter <brian at hursley.ibm.com>  
Cc: ietf at 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 at 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 at 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 at 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 at 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 at Mohsen.Banan  
 
 
 
 
    ⋆ Follow-Ups:  
          o Re: Revisiting The DNS Notation Backwardsness Problem and Multiple Parallel Root Server Clusters  
                + From: Stephen Sprunk  
          o PTR records and software support (was Re: Revisiting DNS Notation  
                + From: Valdis . Kletnieks  
          o Re: Revisiting The DNS Notation Backwardsness Problem and Multiple Parallel Root Server Clusters  
                + From: Dave Crocker  
 
    ⋆ References:  
          o Revisiting - Re: Now: Next Generation Domains and DNS -- Was: Re: No More Central Authority: Not NSI/ICAN! Not ORSC!  
                + From: Mohsen BANAN  
          o Re: Revisiting - Re: Now: Next Generation Domains and DNS -- Was: Re: No More Central Authority: Not NSI/ICAN! Not ORSC!  
                + From: Stephen Sprunk  
 
    ⋆ Prev by Date: RE: [Feedback] Word Template  
    ⋆ Next by Date: Re: Revisiting The DNS Notation Backwardsness Problem and Multiple Parallel Root Server Clusters  
    ⋆ Previous by thread: Re: Revisiting - Re: Now: Next Generation Domains and DNS -- Was: Re: No More Central Authority: Not NSI/ICANN! Not ORSC!  
    ⋆ Next by thread: Re: Revisiting The DNS Notation Backwardsness Problem and Multiple Parallel Root Server Clusters  
    ⋆ Index(es):  
          o Date  
          o Thread  
 
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.