Subject: Re: Now: Next Generation Domains and DNS -- Was: Re: No More Central Authority: Not NSI/ICAN! Not ORSC!

From: Mohsen BANAN <[email-masked]>
Date: Tue, 26 Jan 1999 00:41:34 -0800 (PST)

[This is a summary response which covers comments
 which were in reply to my: 
     <[email-masked]>
 message with the subject of:
 Re: Now: Next Generation Domains and DNS -- Was: Re: No More Central Authority: Not NSI/ICAN! Not ORSC!
 dated Thu, 21 Jan 1999 22:41:13 -0800 (PST).]

I ended my previous note, by saying:

>>>>> On Thu, 21 Jan 1999 22:41:13 -0800 (PST), Mohsen BANAN <[email-masked]> said:

  Mohsen> ...

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

Many got the point -- that there is a "notation backwardness" problem.

For example:

>>>>> On Fri, 22 Jan 1999 08:42:32 -0000, "mark.paton" <[email-masked]> said:

  mark> I hate to admit it but he has a point!

and:

>>>>> On Fri, 22 Jan 1999 14:50:41 +0400, Peter Dawson <[email-masked]> said:

  Peter> ...

  Peter> How come  the folks don't admit the mistakes and just
  Peter> keepcontinuing..  ?? we all understand it is human to err..  !!

and:

....

Now, we just have got to leave behind those who
after all of this, still don't get it and can't
(or don't want to) follow.

I -- and many others -- have known about this
notation backwardness for more than 10 years.
Prior to last week, I had never brought up this
issue publicly.

There is a good reason why I chose 1999 as the
time to bring it up. That is because, I believe
it is only now that we have an opportunity to
plant the right seeds so that the "problem" can
be fixed over time.

Taking advantage of this opportunity to fix it
is a lot more reasonable than "living" with it.

>>>>> On Fri, 22 Jan 1999 04:14:55 -0500 (EST), "Theodore Y. Ts'o" <[email-masked]> said:

  Theodore> ...

  Theodore> 	Whether or not you call this a "Problem" depends on your point
  Theodore> of view.  But this is reality.  Live with it.  

Ted, you live with it. If you want to.

I am an engineer. I try to fix problems when
the opportunity presents itself.

Please consider what I refer to as the
"opportunity to plant the right seeds", with an
open mind for a moment.

May be it is workable. 
May be it is not.

Worstcase, we live with it.

I want to try.

Yes. This problem has widespread roots.

>>>>> On Fri, 22 Jan 1999 10:09:02 -0800 (PST), Ned Freed <[email-masked]> said:

  Ned> I am in complete agreement with Ted here. I also have issues with the way
  Ned> things work and the way things were done, but I recognize that this stuff is
  Ned> far too widely deployed at far too many levels to change now. 

Ned, I understand (and respect) the
significance of the installed base as much as
the next guy.

That is why I don't refer to this as a "quick fix"
but as a "planting of the seeds" type of an
approach.

In order to understand what I am proposing we
have to consider it in the larger context of
Domains and DNS ambiance of 1999.

Let's put everything on the table and take a
quick look.

 - We have a DNS-mess grid-lock. 

   At least according to some (me
   included). The idea of
   expanding top level domains have gone
   nowhere. Introducing competition at the 
   root-server and registration level has gone nowhere.
   General confidence in progress is low ...

 - Updates to DNS Software (both client and
   server) for beyond IPv4 addresses are needed.

 - Updates to DNS Software (both client and
   server) for security, public keys, certificates,
   ... are needed.

 - As phone numbers and Domains keep coming
   together, the domain notation's backwardness
   is becoming more visible and significant.

 - ...

Since it appears that we have to go through a
global DNS client software update, it makes
sense to address all of the above issues more
or less in one shot.

Now, I am suggesting that as we consider
updates to DNS Software (particularly client),
it is reasonable and good to plant the seeds
for a forward domain notation as well.

I am also suggesting that we loosely link the
new notation to the concepts of completely
independent and seperate Top Level Registries
and independent root-server clusters. [Note
that these two concepts (notation and multiple
independent root-server cluster) are not
necessarily connected to each other.]

Let me explain what I consider a workable
approach that will address a number of current
DNS challenges.

First, I need to introduce some names for the
needed concepts.

Let's call:

Plain Old Domain Notation (PODN):
--------------------------------- 
   today's domain notation. 
   For example:
        www.ietf.org

Forward Domain Notation (FDN):
------------------------------
   The new forward notation for domains.
   This notation includes a 
     "Name Resolution Selector (NRS)"
   For example:
	r1:org.ietf.www

Backward Domain Notation (BDN):
------------------------------
   The new backward notation for domains.
   This notation includes a 
     "Name Resolution Selector (NRS)"
   For example:
	www.ietf.org.r1

   BDN is same as PODN but has the 
   the Name Resolution Selector on top of what
   used to be the TLD.

Name Resolution Selector (NRS):
-------------------------------
   An identifier which says which root-server
   cluster should be used. 
   For example:
     r1:org.ietf.www (or www.ietf.org.r1)
     says use "r1" root-server cluster
     to resolve www.ietf.org (PODN).

   Note that the NRS is capable of identifying
   the method (i.e., protocol) in addition to
   the root-server cluster.

Forward Bind:
-------------
  Updates to the bind (or its equivalent)
  package which includes the 
  Forward Domain Notation as its canonical
  notation and which supports name resolution
  based on multiple co-existing but separate
  root-server clusters.

I am claiming that the above ingredients can
break the DNS-mess grid-lock and can position
us to address the backwardness of the Notation
over time.

To look at how this all is supposed to fit
together we need to consider at least the
following dimensions:

	- The Protocols
	- The Resolver Software
	- Operation of Root-Server Clusters

Then, we also need to consider the "Motivations" and
"Transition".

The Protocol
============

Initially, DNS requires no protocol changes.

This needs to be verified by a quick
proto-type or ....

The Resolver Software
=====================

What I call "Forward-Bind" needs to have the 
following key characteristics:

 - Support access and use of multiple
   root-server clusters.

   Presently a single 
     /etc/named/named.ca 
   file is used by Bind.

   Forward-Bind can use multiple root-server
   clusters and therefore multiple root cluster 
   information is needed. For example
	r1.named.ca
	r2.named.ca
	...

 - Support the explicit 
   Name Resolution Selector (NRS) notation.

   When FDN or BDN are used, the use of the specified 
   root-server cluster is explicit.

 - Support implicit name resolution selection.
   This is essentail for the transition period.

   When PODN is used, selection of the root-swerver
   cluster to use is determined by a somewhat static 
   map of TLDs to root-server cluster. 

   The assumption is that through agreement amongst
   root-server cluster operators there will be no 
   duplicate TLDs across root-server clusters.

   If there is a problem, still the user gets to
   choose.

 - The software supports all three notations --
    PODN, FDN, BDN -- from the very beginning

The key attribute of this software is that by
supporting choice in selection of root-server
clusters, it empowers the user.

Operation of Root-Server Clusters
=================================

Each Root-Server Cluster runs its root serves and
has its own independent registration policy. 

There is little, if any co-ordination that is
required amongst the Root-Server Clusters. 

These Root-Server Clusters compete to provide the
cheapest and the most reliable domain registration
capabilities to their users.

Something like part of ICANN can be considered the
consortium of Root-Server Cluster operators which
can accommodate distribution of the generally static
information needed for smooth operation of what I
like to call Next Generation DNS.

In the interim, while use of FDN and BDN is not
widespread, uniqness of TLDs and the distribution
of TLD to NRS map is another thing that the
consortium of Root-Server Cluster operators needs
to do.

Having covered what it takes to make this happen,
let's see Why people may want to do this.

*MOTIVATIONS*
-------------

The likes of Bob Allisat want to empower the user.

All kinds of people want to compete with NSI ...

And, the Network must remain stable and reliable.

What I am suggesting here involves no changes to the
current operation. It just allows for peer universes
to co-exist with the current established one.

Because this idea centers around selection of the
root-server by user's software, creation of these
peer universes is outside of any particular
authority. 

It is in the collective user community's interest
that the Network remains stable. Therfore, we are
likely not to end up with anarchy.

To make this happen, no particular permission is
needed from anyone. Just make what I have been
calling Forward-Bind widespread and set up the
parallel root-server clusters. 

As an example, let's say that the 
AOL, Netscape, Sun, ... combo wanted to mass
register domains without going through NSI.

They can easily make Forward-Bind widespread.  Then,
they can set-up their own root-server cluster.  Then
mass register domains (say under r2:nom such as
john.smith.nom) for their users and everybody else.

Now NSI has competition and the user has choice.

*TRANSITION*
------------

Using the above example, initially the root-server
selector map will look something like:

  org, net, com            :r1  # Current (NSI, ...)
  nom, web                 :r2  # Example: AOL, Netscape, Sun, ..
  store, www               :r3  # somebody else

This is likely to be quite a static map which gets
distributed with the software. I don't consider
occasional updates to this map or addition of
r4.named.ca a difficulty.

Initially there can be no conflict between TLDs
across root-server clusters.

Once Forward-Bind is widespread, then addresses of
the form acme.com.r1 and acme.com.r2 can even be
used and the "no same TLD across root-server
clusters" limitation goes away.

Next step is to gradually transition to FDN.

FDN and BDN can easily co-exist for a long time.

Because FDN was planted in the Forward-Bind from the
beginning, transition to FDN is a matter of its
support in application protocols. This requires
Architectural Leadership. But, where is that going to
come from? IAB? :-)

Once FDN is inside of Forward-Bind, it is possible
for us to define new network object identifiers such
as:
     r2:net.ByNumber.1.888.555.2222:voiceOverIp:"collect"

for new protocols and at least move forward with
FDN.

At a component level, may be there is not all that
much that is new in what I am suggesting. But, may
be the combination of:

  - Enhancing the desktop software to provide for 
    choice and selection amongst root-server
    clusters.

  - The creation of multiple indpendent root-server
    clusters.

  - Enhancements to the notation which makes the
    traditional TLDs not absolute and breaks the
    current monopoly.

  - Providing the user the ultimate control and
    selection.

is new.

I think there is enough detail in this message to
let people decide if this idea is workable or not.

Because I think this (or some variation of it) is
workable, I needed to get this out.

Those who feel this is worthy of exposure in
various DNS-mess related forums are welcome to
forward it to other relevant mailing lists.

For now I consider my part done.

I know that something like this is likely to be
controversial.

I am likely not to further participate in this
thread. You don't need to insult me on that
account. Questions and comments that are expressed
politely have a better chance of tempting me to
respond.

...Mohsen.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 26 Jan 1999 18:04:33 +0800

At 12:41 AM 1/26/99 -0800, Mohsen BANAN wrote:
Now, we just have got to leave behind those who
>>(or don't want to) follow.

Mohsen,

listening only to those who agree with you is not a very useful approach to 
debate.

in any event, if you wish to pursue something other than an unproductive 
philosophical debate (some would say, attack) then you need to formulate 
and propose a work plan, and garner sufficient community support to ensure 
that there will be a significant group to do the development and a 
significant group willing to deploy the result.

d/

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Dave Crocker                                       Tel: +60 (19) 3299 445
<mailto:[email-masked]>             Post Office Box 296, U.P.M.
                                          Serdang, Selangor 43400 MALAYSIA
Brandenburg Consulting
<http://www.brandenburg.com>                       Tel: +1 (408) 246 8253
Fax: +1(408)273 6464              675 Spruce Dr., Sunnyvale, CA 94086 USA

---

From: Dave Crocker <[email-masked]>
Date: Tue, 26 Jan 1999 18:04:33 +0800

Mohsen,

d/