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

From: "Mohsen BANAN"@mail.intra.cnri.reston.va, [email-masked]
Date: 06 Aug 2002 06:42:23 -0700

Good!

After many years, the Internet technical
community (save ICANN and IETF cult's chiefs)
has now arrived to the general recognition
that the concept of parallel root server clusters
are in fact practical, workable, stable and democratic.

It may now be a good time to re-visit other DNS problems
and recognize that they can also be solved.

Most notably, The DNS Notation Backwardsness.

Parallel root server clusters and the fixing of the
DNS Notation Backwardsness problem are very related and
can be done at the same time.

I explained all of this in reasonable detail more than
3.5 years ago. It is comforting to see that parts of
the solution that I proposed is now in place.

Below is the main email from the thread that I introduced
in 1998/1999.

At that time, with hope, I said:
   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.

>From a historic perspective it is worthwhile noting that
shortly after Bob Allisat suggested that the IETF build
on the concepts that I had introduced, he was banned from
the IETF mailing list by the then IETF Chair,
Fred Baker.

While I address this message to the
Internet technical community,
if in fact IETF does not stand for
Innovation Extermination Task Force,
then perhaps even IETF can get involved
in cultivation of these concepts.

--- 1999 Original Message Follows ---

To: IETF Mailing List <[email-masked]>
Subject: Re: Now: Next Generation Domains and DNS -- Was: Re: No More Central Authority: Not NSI/ICAN! Not ORSC!
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, 06 Aug 2002 12:41:21 -0700

>are in fact practical, workable, stable and democratic.

Mohsen,

Perhaps you can point us to the technical specification that demonstrates 
this practical, workable, stable solution and can further point us to the 
basis for claiming that the Internet technical community has "arrived to 
the general recognition of the concept"?

d/

----------
Dave Crocker <mailto:[email-masked]>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 6 Aug 2002 15:13:58 -0500

Thus spake <"Mohsen BANAN"@mail.intra.cnri.reston.va>;
<[email-masked]>
> are in fact practical, workable, stable and democratic.

The "Internet technical community" has decided no such thing.

Perhaps having multiple roots *with identical information* would be stable and
workable, but that requirement inherently negates the motivation for having
multiple roots.

> Most notably, The DNS Notation Backwardsness.

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

> the IETF mailing list by the then IETF Chair, Fred Baker.

Fred banned him at popular request, as with Jim Fleming.

> www.ietf.org.r1

Who will distribute root selector information?  That entity then becomes another
root which *someone* must control to avoid collisions.  Wait, here you describe

> like to call Next Generation DNS.

Oh great, now we re-create ICANN all over again to manage -- get this -- the
root!  As if they don't do that miserably today.

> The likes of Bob Allisat want to empower the user.

No.  Bob Allisat has an agenda to disrupt legitimate work, and he uses his
"power to the people" message to disguise it.

> And, the Network must remain stable and reliable.

Telling 300M (and growing) internet users that Amazon.com has suddenly become
nsi:com.amazon is not the paragon of reliability or user-friendliness.

> peer universes is outside of any particular

Users do not care who runs the root.  Users, by and large, do not know the root
even exists!  The only people who want "multiple roots" are the people that want
to *run* these alternate roots.

S

---

From: Fred Baker <[email-masked]>
Date: Tue, 06 Aug 2002 14:00:18 -0700

>workable, but that requirement inherently negates the motivation for having

from that perspective, we have multiple roots now - 13 of them - and call 
it a "single root". The reason we can call it that is that they are 
indistinguishable from one another from the perspective of the information 
they deliver - ask any of them for example.com and they will invariably 
point you to a .com server, and if you ask a .com server, it will point you 
to the appropriate prefix for that name.

As you say, what is being asked for is multiple roots with different and 
uncoordinated information. What this requires, of course, is for the end 
system to know all the roots it might need to ask, and have a magic decoder 
ring that tells it which root to ask about which name. This is fine if the 
TLD itself tells you which root to ask, but if someone adds a root to the 
net that is not generally known, then most end systems trying to translate 
the name will generally be unable to do so. I, personally, find that kind 
of service pointless - why use a name which nobody can translate into an 
address?

---

From: Dave Crocker <[email-masked]>
Date: Tue, 06 Aug 2002 14:26:23 -0700

This confusion in the public discussion has been persistent.  We really do 
need to use two different terms.

One is multiple name spaces.

The other is multiple servers.

d/
At 02:00 PM 8/6/2002 -0700, Fred Baker wrote:
>from that perspective, we have multiple roots now...
>
>uncoordinated information.

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 07 Aug 2002 01:35:22 +0200

At 23:00 06/08/02, Fred Baker wrote:
>point you to a .com server, and if you ask a .com server, it will point 
>you to the appropriate prefix for that name.

Dear Fred,
This is a very interesting comment. Actually what you call "root" in here 
is the master file.

1. the data of this master file must be collected
2. that master file must be generated
3. it must be loaded into the alpha server
4. it must stay uncorrupted in  the alpha server
5. the alpha server must stay in operations
6. it must be disseminated to the other root servers
7. it must stay uncorrupted in each server
8. the servers must stay in operation in a large number enough (nine right 
now?)
9. it must be responded to resolvers
a. connectivity and delays to the resolvers must be reasonable enough
b. the global demand load must be match by the root server system capacity
c. all this under any circumstances: incidents, war, terrorism, hacking, 
catastrophe, development, new technologies
d. in ways matching 189 local national laws, governmental emergency decisions
e. through the evolution I suggested towards DNS2 and DNS+ services
etc.

No process is fool/hacker/manager/politically/military etc. proof: some of 
the processes above are definitely not, or are at least subject to real 
world threads, loads, instabilities and states' sovereign decisions.

Multiple parallel asynchronous root servers clusters are the only response 
to that problem (at least three clusters and probably much more). Each 
cluster being managed asynchronously according to identical specifications, 
separately accessing possibly mirrored information sources and possibly, 
operating different technologies, each cluster monitoring the others for 
consistency. When a cluster reports an inconsistency the reported and the 
reporting clusters are to be frozen and investigated. Secure requests being 
obtained by multiple identical responses.

As ICANN ICP-3 suggests it, this calls for investigation, testing, 
development, validation and documentation. This is the target of the 
"dot-root" project we started one year ago. So far we have worked on the 
stability of the management of an experimental mini-root system, on the TLD 
data collection process and a generic TLD manager. We have also carried one 
year of active political lobbying to get support for that project. From the 
obtained interest/support we started organizing it (still mostly documented 
in French). I informed ICANN as it may affect their ERC thinking. The plan 
is to have the site in French, Spanish and English, an open mailing list 
and some prospective partners (we target 30) by early September. The target 
is to enter the EU R&D sponsoring cycle to have four initial projects 
sponsored: a request simulator, an e-learning system, a generic TLD manager 
and the data collection system.

All this is intended to be "done in a manner that does not threaten the 
stability of name resolution in the authoritative DNS. Responsible 
experimentation is essential to the vitality of the Internet." (ICP-3). We 
certainly aim at studying the possible "ultimate introduction of new 
architectures that may ultimately obviate the need for a unique, 
authoritative root'" (ICP-3). A draft memo on that can be found under 
http://dot-root.com/icp3.pdf .

I took advantage from your mail to introduce the project. But let me be 
clear, this is just a project open to all those who want to bring a machine 
and their competence in. At this stage we just try to gather machines, 
teams, basic objectives and competences. I do not know if this will go 
through, but from the intelligence we gathered, multiple roots will be more 
than probably under test operations by end of 2003. My hope is that it can 
also be through a project like dot-root and not only by Govs, even if we 
are certainly willing to participate into any mutual experimentation.

jfc

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 07 Aug 2002 01:35:22 +0200

Dear Fred,

jfc

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 07 Aug 2002 01:35:22 +0200

Dear Fred,

jfc

---

From: Caitlin Bestler <[email-masked]>
Date: Tue, 6 Aug 2002 19:24:06 -0500

On 8/7/02, JFC (Jefsey) Morfin wrote:

>
>Dear Fred,
>This is a very interesting comment. Actually what you call
>"root" in here is the master file.
>
>8. the servers must stay in operation in a large number
>enough (nine right now?)

The mechanisms for distributing the information can, and
should be distributed. In fact, given that virtually all IP
hosts direct their DNS queries to a local DNS server means
that this is already the case.

I do not believe there is any need to achieve five nines
availability on the capacity to add new TLDs.

High availability, fault-tolerant, updating is required of
the more popular TLDs themselves, not of the root. Unless I
am overlooking something, that solution is already feasible
without any protocol modifications.

Even for the TLDs, the availability requirements are
relatively low. The Internet could easily survive without
the ability to create new .coms for a few minutes a year.

---

From: Einar Stefferud <[email-masked]>
Date: Tue, 6 Aug 2002 16:55:59 -0700

At 2:00 PM -0700 8/6/02, Fred Baker wrote:
>from that perspective, we have multiple roots now - 13 of them - and
>call it a "single root". The reason we can call it that is that they
>are indistinguishable from one another from the perspective of the
>information they deliver - ask any of them for example.com and they
>will invariably point you to a .com server, and if you ask a .com
>server, it will point you to the appropriate prefix for that name.
>
>As you say, what is being asked for is multiple roots with different
>and uncoordinated information. What this requires, of course, is for
>the end system to know all the roots it might need to ask, and have
>a magic decoder ring that tells it which root to ask about which
>name. This is fine if the TLD itself tells you which root to ask,
>but if someone adds a root to the net that is not generally known,
>then most end systems trying to translate the name will generally be
>unable to do so. I, personally, find that kind of service pointless
>- why use a name which nobody can translate into an address?

Hi Fred --  You are hitting on some key points;-)...

Lets look at the issues of extending the "root" higher by labeling
roots with an additional root identifier.  Or doing the reverse, as
WIPO appears to want to do.

++++++++++++++++++++++++
Case 1 - Raise the Roof:

This moves the argument about who is in charge of everything one
level higher, but the argument does not end because all the politics
remain in place, and we just have to live the whole sequence over
again.

Having coordinated roots is what is needed, whether roots are
multiple or singular, but this is not the only criterion that
matters.  There are the economic and social issues to consider in the
context of open cooperation among the stakeholders.

If the people in control of the root servers do not consider these
other factors, so as to meet all the legitimate technical, economic
and social factors, they will at best have a rough time of it, as at
least some despotic rulers have learned over the centuries.  We are
but seeing a replay of much of history.

+++++++++++++++++++++++++++
Case 2 - Tear off the roof.

WIPO already wants to control the SLD level to avoid multiple
instances of the same SLD name, and appear to want to eliminate all
TLDs, and if they had their way, as I see it, the entire Domain Name
Space would have to be flat to satisfy their desires.  (Not
considering that trademarks are not a flat structure in the first
place.  They come in classes or categories.)

In this case, tearing the roof off and rebuilding it down one level
at a time, is at the least an unending process as domain name holders
keep adding new names under the SLDs that they are allowed to keep,
or until the DNS is converted to a single flat space.

+++++++++++
Conclusion:  At present we appear to be at some happy medium, but
with one primary problem in hand.  It is called "learning to live
together!"  It has a few technical issues involved, but mostly it is
a game of "King of the Hill".

So, moving the roof of the root up and down will not be likely to
have any effect what so ever. Aside from creating lots of pointless
work.

Now for the other issue:  The argument about whether the Brits had it
right with their big Endian logic, vice the US little Endian logic,
mostly boils down to whether we are all driving on the same side of
the road, or not.

I thought that argument was resolved when the Brits chose to go along
with the little Endian DNS game.  May I ask how the Endian wars were
resolved in the binary computer and communication worlds?  Are some
still one way and the rest the other?   Does it really matter?

I do not see any reason to engage in either of these games;
	of raising/lowering the roof;
	or changing the direction of traffic.

In terms of human interpretation of the "meaning" of a domain name,
the little end is clearly the most critical distinguishing
characteristic to be seen by a human.
Knowing that  my domain name ends with .com is important, but the
left hand end is even more important to humans, along with the middle.

++++++++++++++
My bottom line logic is that finding a way to resolve differences
through constructive resolution processes is what we need, vice
lobbing written grenades over walls, and building fortresses to close
out communications.

But, I fear this is off topic because it is not technical enough;-)...

Cheers...\Stef

---

From: Einar Stefferud <[email-masked]>
Date: Tue, 6 Aug 2002 20:18:54 -0700

Someone said:
>Perhaps having multiple roots *with identical information* would be
>stable and workable, but that requirement inherently negates the
>motivation for having multiple roots.

This analysis (above) is a little short on completeness.
Needs a few more words.

The key issue is to have one composite root, including all TLDs who
wish to be included, with technical requirements for stability,
security, and global service, to form what some of us call "The
Inclusive Root", as compared to some kind of Exclusive Roots.

Note the plural, because any instance of an Exclusive root must mean
that some TLDs must have been Excluded, and so will be present in
some other root, which may be the Inclusive root, or may be some
other root which is also Exclusive.  There can only be One All
Inclusive Root.

I believe these words (Inclusive & Exclusive) are well known and that
I am using them in their common dictionary meanings.  No tricks here.

These two words are really critical for us all to understand, and
more or less agree on their meaning and implications.  If we cannot
get past this point without an argument and a fight, then we are
stuck right here.

It is perfectly logical for many users to seek to use a partial root
that excludes certain stuff that they wish to be protected from, such
as porn, to cite just one form of unwanted content.

I know of, and applaud, one local community ISP that offers services
that block selected unwanted content.  Of course, all customers of
this ISP agree that they want this blocking service, or they would go
to an easily accessed competitor.  And though I do not subscribe, I
applaud those who do, and those who provide this service.  Without
it, the subscribers would likely not access the Internet at all.  Of
course, the subscribers EMail addresses are ICANN ROOT resolvable,
but are also likely to be filtered for unwanted spam.  I now
subscribe to an ORSC compatible POP Mailbox service for myself.
Works great!

In this kind of mixed world of inclusiveness and selected
exclusiveness, it is possible to envision that there is some kind of
Composite Inclusive Root that is kept free of collisions through
careful and considerate cooperative collegial efforts.  This idyllic
state may not be easily attained, but it has very high value, so
social tendencies will tend to bring it into existence, while other
forces might tend to resist any kind of self-organized cooperative
arrangement.

There seem to exist some people who cannot countenance existing in a
world without someone "in control" from whom it is good to ask and
get permission for doing all manner of tings.  I do not seem to be
one of the lucky few who always have permission to do whatever they
do.

The Internet as a whole is pretty much self organized and working
amazingly well considering how many people do not like to even think
about self organizing systems.  But then, I recall that the United
States of America was self organized once upon a time, and it seems
to be working pretty well, but is not without some faults.

Also he US and the Global Economies are self organized and are not
centrally controlled.  Central control of economies has gone out of
style of late.

Also, it should be noticed, the Internet actually has no "center" in
any sense of the word "center" so there is no logical site at which
to place a central control point.  Sole ownership and control of the
Internet disappeared when IP/TCP became dominant and the competitive
cooperative IP backbone confederation/association came into being.

The NSF appropriate Use Rules were cast aside by NSF in 1995, and
since then central control has withered for all but the DNS, which I
see as the last vestigial tail of the original ARPANET.  Valiant
efforts have been displayed in the efforts to retain this vestigial
tail.

But, getting back to the future fate of the DNS;-)...

We only need to avoid collisions and assure technical conformance to
standards for service performance, communication, and security.
And we need a structure that will induce mutual trust among the
contributors to the Inclusive root service, and its derivative
Exclusive (sub)Root services..

Any root service (ISP or other service) that wishes to subset the
inclusive root, and sell it to customers who know what they are
buying, should be allowed, and if someone wants to sell a fully
Inclusive Root Service with some added private TLDs that do not
collide with anyone in the Composite  Root, I see little reason to
prohibit this.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
So, the main problem is to establish coordination and cooperation.
Including technical coordination and cooperation which is the forte
of IETF.  At least it used to be so, there is no reason to let it get
away.

Some people prefer to appoint a Name and Numbers czar (as we all
lovingly called Jon Postel) to wisely keep things organized and
working.

Would that we could build our cooperative arrangement as a monument for Jon.

But, back in the days when ARPANET was a network, and not an
Internet, and top down management was the rule.  ARPA actually owned
the entire network, including all the access ports.  Every user of
the ARPANET was subject to withdrawal (by ARPA) of access privileges
in the event of misbehavior.  We all had passwords for TIP access,
and passwords on our computers connected to the Internet under APRA
contracts.  Such an overhanging sword of central control kept most
users away from any serious misbehavior.  Cooperation was the
operative rule then.

But, the advent of IP/TCP allowed other networks, like CSNET and
BITNET, and such as CERFnet, and NYSERnet,  UUnet, and NorduNet, etc.
to connect togehter without having to adhere to the NSFNET
Appropriate Use Rules, and thus a self organizing backbone community
came into being, and is engaging in self regulated control of the
routing of packets though cooperative endeavor.

This kind of organization did not arise for the DNS, perhaps because
Steve Wolfe (of NSFNET Fame) somehow did not notice that DNS was in a
region of danger of where someone would seize central control, such
as DoC, or WIPO, or whoever.  And, so, here we are, with a
centralized DNS control system.  I asked Steve why one day, and he
said "I just never thought of it."  And I have to admit that I also
did not think of it, or I would surely have mentioned it to him.  I
suspect that nobody thought of it.  Routing Packets was much more
critical in those days, with serious threats of monopoly takeover or
of government control, or maybe even Mafia Control, but those
nightmares never came to be, although it is hard to imagine the some
of the IP backbone players do not wish the others would give up and
go away;-)...  Lucky for us, the situation seems to be stable without
singular central controllers (or regulators; Just a bunch of
cooperating coordinators, thank you very much.

So be it!  It is not czarism that I see causing trouble.  It is the
lack of cooperative collegial interests among all the stakeholders in
resolving issues that arise, like collisions, that hamper the
formation of broadly acceptable arrangements among the stakeholders.

Building a cooperative stakeholder coordination system is what we
need, and what we do not have.  Maybe after ICANN crashes itself and
burns, a Phoenix will arise from the ashes and fly into the sky above.
Hopefully is will be organized as a cooperative coordination body
that might do for DNS what IETF has done in the past for IP/TCP, et
al on the technical side of things.

But, clearly, as the tone of this list shows, this is not the place
to self organize such a thing as a coordinating body for the DNS.
The issues are much too political for the technically oriented and
focused IETF to touch.

Sorry for the long length, but this all fell out in one piece.

I can assure you that ORSC is not seeking to become a DNS Czar.
None of us like the idea of czars running things.
Well, maybe in the beginning, before I got involved.

When I arrived in he ORSC game, all the czars had fled.
We now just want to find someone to cooperate with.
Preferably people who are not hell bent to bash our heads in.
But, cooperative head bashers could be useful.  Y'all come;-)...

Cheers...\Stef

---

From: Einar Stefferud <[email-masked]>
Date: Tue, 6 Aug 2002 20:18:54 -0700

Cheers...\Stef

---

From: Einar Stefferud <[email-masked]>
Date: Tue, 6 Aug 2002 20:18:54 -0700

Cheers...\Stef

---

From: Einar Stefferud <[email-masked]>
Date: Tue, 6 Aug 2002 20:18:54 -0700

Cheers...\Stef

---

From: "Jim Fleming" <[email-masked]>
Date: Wed, 7 Aug 2002 10:02:59 -0500

----- Original Message ----- 
From: "Einar Stefferud" <[email-masked]>
> mostly boils down to whether we are all driving on the same side of

Stef,

This is not rocket science. There are 160 bits in most IPv4 headers.
That is 5 (fiive) 32-bit words. It is a data structure. Any 8th grade
computer programmer can define the fields and lay out the bits. Any
Internet technologist should be able to tell you what all 160 bits are
in less than 1 minute. You might want to walk up to a person at an
IETF meeting, and ask them to run thru the fields. See if they can even
get them in the right order. Would you expect to ask a chemist about
the periodic table of the elements, and find they do not know it, cold ?

There are 128-bits in the 128-bit DNS system. Hmmm, wonder how
that happened ? The 32-bit DNS system has 32-bits. 32 is smaller than
128, at least for most people. You can go to a remote region and place
32 stones in one pile and 128 stones in another pile, and most people
would agree the pile with 128 is larger. You can build on these basic
UnirVersal truths. If you find someone who disputes it, you are likely
wasting your time.

Imagine a simple DNS to IPv4 header mapping. Take the 128-bits from
the 128-bit DNS and toss them into the first 128 bits of the 160 bit IPv4
Header, and send the packet. One problem, most humans agree, that
128 is less than 160 bits, so you would not fill all the places. Does that
mean you should advocate for a 160-bit DNS ? You could try. You might
also sit back and figure out how many of the 160 bits can be "touched" or
set via the DNS. How fast can you answer that question ? You might want
to walk up to a person at an IETF meeting and ask them that question.
Can they reason through the fact that the 4-bit Version field is set at 0100,
the 4-bit header length is set at 0101 (5), the 8-bit TOS field is usually 0,
the 16-bit Length field can not be touched...etc. etc. etc. In other words,
in the first 32-bits, can they instantly note that only 8 of the bits can be
touched ? 160-32=128...can you figure out which of the other 128 bits
can be touched ?

Are you starting to see that with 128-bits, and a 160-bit header, 128-bits
allow people to touch all of the fields they can touch with bits left over.
Now what does one do ?...the 128 bits do not fit in the 160 bits...because
not all 160 bits can be set via the 128-bit DNS and have the EXISTING
routers and servers all work...

Looking at a bigger picture starting point, one sees that UDP and TCP
dominate scene beyond the first 160 bits....and there are 16 bits of port
number that would be nice to be able to set....that was not possible with
32-bit DNS...all 32-bits got blindly tossed into fields of the 160 bits in
the trivial, "toy", 32-bit Internet....

If you look at the 128-bits as a starting point for a new computer architecture
addressing scheme, you will quickly see that you will likely want to save some
room for the 16-bit UDP/TCP Port number....you are then down to 112 bits...
You likely will also want to give people a 32-bit IPv4-like address field to
help them preserve their look and feel and intranet addressing...112-32=80
You now have 80 bits and might want to consider taking 64 of those for
various transition mechanisms, and opcodes, etc. That leaves you with 16 bits
because 80-64=16....you now have 16 bits to try to put into the EXISTING
IPv4 header....can you do it ?....and still have all routers continue to work...?

Does the IETF do technical work ?

Jim Fleming
2002:[IPv4]:000X:03DB
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt

---

From: [email-masked]
Date: Wed, 07 Aug 2002 11:02:57 -0400

> But, I fear this is off topic because it is not technical enough;-)...

No Stef, you're quite right here - we *do* need to remember the following:

1) Technical solutions for social problems almost never work.

2) We aren't designing technology for technology's sake, we are designing
technology to be deployed and used.  As such, we *will* end up with the
occasional design wart - we've had protocols done in weird ways because
some player had a patent on an algorithm.  I was going to add "and if
the US Govt said every third bit had to be painted green", and then I
remembered that we produced RFC1508 on GSSAPI - an interesting tap dance
around the "crypto in the hole" problem of the time.

There exist players big enough that they can mandate "there will exist
something like ICANN" and make it stick.  We're also stuck with the
technical considerations in RFC2826.  Any proposed solution will have
to deal with *both* those sets of issues.
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

---

From: "Jim Fleming" <[email-masked]>
Date: Wed, 7 Aug 2002 10:31:32 -0500

----- Original Message -----
From: Einar Stefferud

In this kind of mixed world of inclusiveness and selected exclusiveness, it is possible to envision that there is some kind of
Composite Inclusive Root that is kept free of collisions through careful and considerate cooperative collegial efforts.
....
But, clearly, as the tone of this list shows, this is not the place to self organize such a thing as a coordinating body for the
DNS. The issues are much too political for the technically oriented and focused IETF to touch.
....
====

Stef,

The new 128-bit DNS software (software, not people) builds the "Inclusive Root" dynamically.

You might want to study how dynamic directory software works.
http://freenetproject.org
http://freenet.sourceforge.net

Jim Fleming
2002:[IPv4]:000X:03DB

---

From: Keith Moore <[email-masked]>
Date: Wed, 07 Aug 2002 12:54:07 -0400

> 1) Technical solutions for social problems almost never work.

a bit of thought will reveal that technical solutions often do help 
with social problems, though they might not solve the problems 
entirely or forever.  

for example, locks on doors and surveillance cameras are technical 
mechanisms to deter theft.  they don't prevent theft, but they do
discourage it.

of course there are also plenty of ineffective technical solutions, and 
of technical solutions that do more harm than good.  (car alarms might 
be a good example).  but social solutions for social problems don't
always work well either.   sometimes a combination of the both kinds of
mechanism works better - e.g. locks on doors coupled with prison terms 
for convicted thieves probably discourages theft better than either 
mechanism could do alone.

both engineers and legislatures seem to have too much faith in their
tools of choice.

Keith

---

From: Einar Stefferud <[email-masked]>
Date: Wed, 7 Aug 2002 10:11:39 -0700

Hi Valdis -- Thanks for the support.
I wish it could be sent to the IETF list for contrast with all the foolishness.

But it is your choice;-)...  Thanks for your support;-)...\Stef

At 11:02 AM -0400 8/7/02, [email-masked] wrote:
>Content-Type: application/pgp-signature
>
>Attachment converted: Viking5:Untitled (????/----) (000072F0)

---

From: Mohsen BANAN <[email-masked]>
Date: 07 Aug 2002 19:20:50 -0700

>>>>> On Tue, 6 Aug 2002 15:13:58 -0500, "Stephen Sprunk" <[email-masked]> 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 <[email-masked]>
To: Brian E Carpenter <[email-masked]>
Cc: [email-masked]
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 <[email-masked]> 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 <[email-masked]> 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.

 [email-masked]

 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:

  [email-masked]

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!

[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Wed, 07 Aug 2002 20:15:01 -0700

At 07:20 PM 8/7/2002 -0700, Mohsen BANAN wrote:
>Problem.

Given that the ordering for domain names is the same as for postal 
addresses, you will no doubt also be seeking to have us write postal 
addresses differently.  After all, the problem for the paper world must be 
even worse than the computer world, given that people typically write out 
those postal strings.

d/

ps.  You have not yet provided the substantiation to your earlier claims 
that I asked about.  Going through the exercise of actually providing the 
basis for a conclusion is a hassle, but it does improve the credibility of 
the conclusion, don't you think?

----------

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 Aug 2002 13:43:42 +0200

Dave,

I don't think it's really worth cycles responding to those
who can't distinguish presentation, syntax, and semantics
from each other.

?redro drow rehtona desu evah I dluohs rO

  Brian

---

From: [email-masked]
Date: Thu, 08 Aug 2002 12:48:22 -0400

> a "straight" User Interface for in-addr says

'dig -x 132.151.6.21' should Do The Right Thing (although it in fact fails to
do so because of a missing PTR record - so while we're fixing the ECN problem,
we  might want to clean up the DNS while we're at it. (And yes, this is bcc'ed
to what's listed on the SOA...)

'dig' should be pretty widespread, as it comes as part of Bind 8 (for Bind
4 it was a separate package, but if you're still running 4 you have bigger
issues than getting 'dig' to work ;)

I'm quite sure that 'dig' was already around in 1999 when you wrote that
the first time - I seem to remember building it at my previous job (which
I left in May 1989).  I know the author is lurking and will comment if
I got it blatantly wrong.. ;)
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

---

From: John Stracke <[email-masked]>
Date: Thu, 08 Aug 2002 13:39:55 -0400

[email-masked] wrote:

>'dig -x 132.151.6.21' should Do The Right Thing
>  
>
So does "host 132.151.6.21".

-- 
/===========================================\
|John Stracke      [email-masked]  |
|Principal Engineer|http://www.centivinc.com|
|Centiv            |My opinions are my own. |
|===========================================|
|Newt Nuggets!                              |
\===========================================/

---

From: Mohsen BANAN <[email-masked]>
Date: 08 Aug 2002 10:59:16 -0700

Valdis,

Yes. It is possible to on a case by case basis
(say within dig) to do the reversal.

The key question is "Why is that reveral done in dig?"

Do you genuinely believe that DNS notation backwardsness
is all imaginary?

Please think about the real issue here.

The DNS notation is in fact backwards.
I am not making it up because I want to do
harm to .... There is a real problem here.

I live inside of emacs and use completion for everything.
Files, C/C++/Java/... identifiers, Data Base objects,
elisp commands, ... 

But we can't do completion on http://www.vt.edu inside of
emacs. Where you could on edu.vt.www. And the completion
ability becomes a lot more interesting as we have more diversity
on the top level. Or if the name spcae roof is raised.

Internet object naming rules (e.g., URLs) is inconsistent with the
rest of computing object naming rules.

The long term social value of fixing this fundamental problem is
huge. However, because people usually can't tell the importance of
what they are missing, recognising the significance of the problem is
tough.

Now, can you please tell me what is wrong with pointing this
out and hoping that cooperative measures can be taken towards 
fixing it? 

Admitting that we do have a problem is usually the first 
step towards progress.

Thanks.

...Mohsen.

---

From: John Stracke <[email-masked]>
Date: Thu, 08 Aug 2002 14:32:39 -0400

>out and hoping that cooperative measures can be taken towards 
You can hope for whatever you want, but it's not gonna happen.  It's 
like writing boustrophedonically: it supposedly lets people read faster, 
but the transition costs would be prohibitive.

-- 
/==============================================================\
|John Stracke      [email-masked]                     |
|Principal Engineer|http://www.centivinc.com                   |
|Centiv            |My opinions are my own.                    |
|==============================================================|
|No matter how tempting the prospect of unlimited power, I will|
|not consume any energy field bigger than my head.             |
\==============================================================/

---

From: Bill Manning <[email-masked]>
Date: Thu, 8 Aug 2002 12:03:31 -0700 (PDT)

% I'm quite sure that 'dig' was already around in 1999 when you wrote that
% the first time - I seem to remember building it at my previous job (which
% I left in May 1989).  I know the author is lurking and will comment if
% I got it blatantly wrong.. ;)
% -- 
% 				Valdis Kletnieks
% 				Computer Systems Senior Engineer
% 				Virginia Tech

The headers in DiG 2.0 indicate a 1987 date.

-- 
--bill

---

From: [email-masked]
Date: Thu, 08 Aug 2002 15:18:54 -0400

> on the top level. Or if the name spcae roof is raised.

You can't do completion in COM.anything anyhow, with some 60M entries in it.  A
optimal two-level split would require sqrt(64M) or 8K top level domains with 8K
entries each, and going to 3 levels would cut it to 400 at each level.

Of course, political and operational concerns would probably dictate using
something less optimal than the square or cube root of the total number,
and to not be TOO fussy about keeping it as a valid tree.  (Remember, instead
of making one .COM server grovel through 8,000 entries for each completion,
and then one of 8K servers gets to grovel through its list to find what
you wanted - 2K at the root level and 32K at the next level may make more sense).

You're also asking 60 million domain holders and half a billion people to
switch.  And did you know that palindromically legal addresses broke ALL THE
TIME at the Janet gateway?  Happened every time a department of ours used a
2-char domain name that happened to be an ISO country code.  I finally got so
fed up with [email-masked]' bouncing that I stopped using it - I already
*knew* there was no 'vt' subdomain in the Cocos (Keeling) islands. Our CS
department escaped unscathed, but EE users trying to talk to Janet kept getting
bounce messages from Estonia....

And notice that there is *NOTHING* stopping you from entering DNS names in any
order you want to at the user-interface level, using some GUI widget that
prompts for .com/.edu/.org, then once it knows it's a .edu and you've typed a
'v', get all the possible completions, and then repeat to fill out www.

Then your little GUI presents an already validated 'www.vt.edu' (complete with
an already-fetched A record) to the program.

The vast majority of the time, there's no *NEED* to do completion - this note
is a "reply", so it knows all the hostnames.   Anytime you click on a URL, you
have a canonical hostname already.  The chances are that most of the sites you
visit are already in either your bookmarks or recent history. The people you
send mail to often are already in your address book.

And I didn't even need completion in the address book - because that was
populated from info I already had - the From: header from their mail...

You don't need completion for the other hosts at your site -- you probably
already have a "domain" line in resolv.conf or its moral equivalent.

Hell, even network engineers don't enter hostnames that often for traceroutes -
you slice-and-mice those from the trouble ticket into your terminal window ;

Your best bet here is build a little GUI widget/tool that does a "proof of concept"
see how it performs, how often you *really* need it, and how loudly the owners
of the name servers yell when you use it (hint - there's currently no good
way to ask the server for the .COM domain "Give me all the entries starting
with F" "Give me all the entries startin with FO.. with FOO, with FOOB, with FOOOGR 
and so on yuntil you hopefully find the 'foobar.com' soa, and get to repeat the
process until the server authoritative for that zone.

Worst part is that you can't even effectively cache the info - if the user
decided on 'www.ibm.com', you probably don't have enough information to
know what to do if the NEXT time he goes 'www-'.  Even if you cached the
fact that IBM has a www-1 through www-8 (except for a -2), *and* the fact
that they do some interesting CNAME stunts (especially on -4 and -7), you *STILL*
get to re-ask, just in case the user wants a just-deployed 'www-test.ibm.com'.

And no, you can't negative-cache the fact that www-test didn't exist, because
technically, you never actually specifically asked if it did exist....

---

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 8 Aug 2002 14:17:44 -0500

Thus "Mohsen BANAN" <[email-masked]>
> problem in my previous message. Was hoping by now

There is no consensus in the email quotes you supply -- just you ranting about a
problem the rest of us have decided isn't worth solving.

It's possible that domain names would be more logical or useful if they were
written in the reverse order.  However, they're not, and it's about 20 years and
500M users too late to change one of the most basic premises of DNS.  Stability
is more valuable than aesthetics.

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

Nobody is seriously considering "raising the roof".  Creating a new,
higher-level root will only cause pain and a quick repeat of the problems we
have today.

S

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 8 Aug 2002 15:43:56 -0600 (MDT)

> The headers in DiG 2.0 indicate a 1987 date.

According to my fading recollections, it was in about 1987 that I
petitioned the author of nslookup to fix it to look for PTR records
when given a dotted-quad, and he obliged.  The version currently in
BSD/OS, FreeBSD, and elsewhere seems to do about the same as dig,
except with less noise.  If you like noise, try `nslookup -d 132.151.6.21`.

In other words, would you guys please stop feeding the trolls?  It's
easy to filter their noise, but hard to filter your responses.  You
guys have put so much chum in the waters and made so much noise with
the pikers that one of the Tier 1 IETF Trolls awoke from what I had
hoped was a permanent sleep.  At the rate you're going, you'll have
the other two Tier 1s thrashing around here in a feeding frenzy.
These are the Dog Days of Summer, but isn't a quiet nap better
entertainment than troll feeding?  If not, isn't there a better
place to do it?

Vernon Schryver    [email-masked]