Re: grandfathering of .us domains?

["JZP" <crimson@sidehack.sat.gweep.net>]

[us-domain clipped, as my comments aren't relevant or have already been
stated there.]

Brett wrote:
> The problem with new TLDs, as a solution, is that without abolishing .COM
> we will still have a problem in that realm. And people will fight over who
> gets to administer the new ones. And on and on.
>
> I fear that adding more TLDs would DILUTE the problem but retain a
> dysfunctional paradigm.

Agreed!  As I've been saying since the "commoditization" of domain names
began, pushing the mess down to the root of the tree only masks the problem
in a myopic wish that the solution-space becomes large enough that
collisions are few and far between.  The right answer is twofold:
	- to carve up existing spaces to push the mess _up_ the tree
	  [radical extension: eliminiating all non-ISO CC TLDs. no more
	   generics!]
	- depoly a global, distributed _directory_service_.  The DNS is 
	  NOT (and really CANNOT be) the directory service some people
	  are trying to hammer it into.  this is not to say that similar
	  (or the same?) tools that run the existing distributed database 
	  which IS the DNS could not be used to run this other distibuted
	  database (tho i'm sure the directory service crowd would argue
	  BIND, etc as poor tools to do this job).

> Jeff Williams wrote:
> > Unattributed Person wrote:
>  >> What would the characteristics of such a scheme be? Among other things, 
> it would:
> > >
> > >   1. Allow for multiple entities with the same name without according 
> > special
> > >      privilege or advantage to any of them;
> > >   2. Prevent a single entity (in particular, a business) from seizing 
> > exclusive
> > >      use of a generic term, such as the name of a commodity;
> > >   3. Prevent newcomers to a market or business category from being 
> > disadvantaged
> > >      relative to existing players;
> > >   4. Allow for truly decentralized registration and operation (so as to 
> > avoid the
> > >      current disastrous situation in which one company holds the keys 
> > to the
> > >      kingdom and refuses to relinquish them);
> > >   5. Resist tampering (It's currently FAR too easy to muck up someone's
> > >     domain registration by impersonating him or her in a message to 
> > InterNIC);
> > >   6. Enable instantaneous changes to primary server IP numbers, rather 
> > than requiring
> > >      an overnight wait (so as to allow for an immediate shift to a 
> > backup in case of
> > >      disaster);
> > >   7. Provide a more generalized database of information rather than 
> > just a database
> > >      of IP numbers, host names, and mail servers;
> > >   8. Protect registrants' privacy and avoid exposing them to spam;
> > >   9. Make it simpler to set up and update secondary servers; and
> > > 10. Provide hooks for backward compatibility so that the transition to 
> > a new
> > >      and better system can be graceful.
> >
> >   Good points all here.  And I would add, that many have been suggested
> >before as well as what I suggested as a extension of the existing legacy
> >root structure of the DNS would provide for.
>
> Some of the concepts CAN be extended; we've definitely learned some good
> lessons about what works and what doesn't. But adding more TLDs doesn't
> change the STRUCTURE; it just adds more items to it. I'd propose looking at
> some fundamentally different ways of finding what one is after on the Net.

Again, this thread comes to the logical conclusion that a distributed
directory service is required [cf points 1 2 and most especially 7 above].
The DNS does what it does - map labels to numbers for the purpose of
keeping the net RUNNING - very well.  Any argument that calls for an
overhaul of the DNS system itself is one that is quite simply doomed to
fail.

Joe
                 http://www.gweep.net/~crimson/pgp.txt
 crimson@sidehack.gweep.net * jprovo@gnu.ai.mit.edu * jzp@rsuc.gweep.net
 Disclaimer:  "I'm the only one foolish enough to claim these opinions."
          RSUC / GweepNet / Spunk / AAC / FnB / Usenix / SAGE