jww@sdcsvax.UUCP (Joel West) (06/07/85)
Thanks to the generosity of Mark Horton, I recently received a copy of
RFC920, "Domain Requirements", 10/84. (I'll forward a copy if anyone
doesn't have it and wants one, incidentally)
I agree with several points it makes:
1) subdomains are needed to localize the routing of mail.
2) The domain/subdomain scheme should be used in conjunction with the
host name to assure a unique address. My "frog" is UUCP'd to "clyde"
and apparently some people looked at published maps and assumed that
this was another "frog" 3,000 miles away! (-:
3) Every site should have only one name, at least outside its intimate
friends. Why should "sdcsvax!jww", "jww@UCSD" "jww@SDCSVAX.ARPA",
"jww@sdcsvax.UUCP" all have to be recognizable synonyms for the same
destination?
Then I took my current addresses, and transformed them under the proposed
scheme:
gould9!cacimv!joel joel@sdmv.caci.com (coming soon!)
joel@frog-nosc.arpa joel@frog.nosc.gov
ihnp4!sdcc3!gould9!joel joel@gould9.gould.com
jww@sdcsvax.arpa jww@eecs.sd.uc.edu
ihnp4!bonnie!jww jww@bonnie.att.com
Now what do these all have in common? The last four machines are each linked
together directly via tcp/ip or uucp; the first 4 are located within
a 10 mile radius of my office in San Diego. But, under the
proposed scheme, what do they have to do with each other? Not much.
Here are some of my friends, similarly transmogrified
ebbe@cc11.cs.uc.edu
newman@castor.mit.edu
russell@locus.la.uc.edu
shari@csd-gould.gould.com
dbw@sd.encore.com
tim@twg.???.com
ian@loral.???.com
lauren@vortex.???.com
It is my position (burn, heretic! (-:) that the use of domains and subdomains
should add to, not subtract from, the information contained in the address.
In some cases, the proposed scheme will follow natural organizational
affinities - e.g. UCSD, the UC system, DEC, ATT, and so on.
But otherwise, this whole idea stinks of a bureaucratic approach to stultify
an already working system. Who's going to volunteer to be the domain server
for "org"? or, for that matter, for "com"? Now you have all the disadvantages
of the ARPAnet without the advantages of a fast transmission scheme. What
does a small company (e.g. vortex) do when it's not part of a natural subdomain?
In short, the whole NIC approach proposes to re-invent the wheel and replace
it with a pyramidal rock. (-: Developed over a period of years, it ignores
existing natural addressing schemes that have evolved over decades or centuries.
There are many existing routing schemes that would do better, and correspond
to some existing, more natural approach. (such a geography)
The telephone co. uses a single-level hierarchy (area code), as do the airlines.
The post office uses both single (zip) and double (city,state).
joel@gould.sd.ca.usa
joel@gould.san (globally unique airport code)
or joel@gould.921.usa
or even joel@gould.619.usa
says more than the alternate approach. I don't know about you, but most of
our uucp links are local. Most of my contacts in the computer community are
local. It is my position (heresy! (-:) that the use of domains and subdomains
should add to, not subtract from, the information in the address.
Here are some alternate machine addresses. I didn't have to guess
"what subdomain is vortex?" Note also that the top-level geographic domain
becomes optional for local calls, as with your telephone.
frog.nosc.gov frog.nosc[.san] frog.nosc[.sd.ca]
eecs.sd.uc.edu eecs.ucsd
cc11.cs.uc.edu cc11.ucsd
bonnie.att.com bonnie.att.ewr bonnie.wh.nj
castor.mit.edu castor.mit.bos castor.mit.cam.ma
locus.la.uc.edu locus.ucla.lax locus.ucla.la[.ca]
csd-gould.gould.com csd-gould.fll csd-gould.ftl.fl
sd.encore.com encore.san encore.sd.ca
twg.???.com twg.sjc twg.sil.ca
vortex.???.com vortex.lax vortex.la
Without knowing much about each of these sites, I could guess their address.
(Even if I were slightly wrong, the San Jose server could hold the San Franciscotables, etc.) Not only that, the use of geographical name servers means
routing is unambiguous; my "frog" in San Diego is distinct from someone else's
"frog" in Boston; not only that, no one is likely to confuse them.
Even the subdomains shown aren't strictly necessary, since there aren't likely
to be many bonnie's within an hour's drive of Newark. (And for the UNIX
network, the "att" in att.ewr is redundant (-:).
As always, we welcome your opinions.
--
Joel West CACI, Inc. -- Federal
{allegra, decvax, ucbvax,ihnp4}!sdcsvax!jww
jww@sdcsvax.ARPA
Flaming to spark discussion is no sin. -- jww@some.where.or.anotherjonah@deepthot.UUCP (Jeff Lee) (06/10/85)
Joel,
I'd like to take you up on your offer of a copy of RFC920. I
don't know what the latest word is, but the domain/subdomain naming
conventions outlined in RFC819 are too restricting. I agree that a
geographically related addressing scheme could be appealing, but it
does have problems. Who, for instance, is responsible for creating
the addresses, or ensuring their uniqueness. Likewise, with sparce
electronic networks, a machine down the street may be harder to get
to than one in the next state. At least organizationally structured
domains make the addresses of electronically "near" machines similar,
reducing the address -> routing burden for small machines. Perhaps
someday there will be a strongly coupled network which will make
geographical naming practical.
My personal "flame" is that (at least as of RFC819), it does
not seem to be possible to create sub-domains which are largely
independant of their surrounding domains. The requirement that local
host and sub-domain names must be disjoint from the local host and
sub-domain names of all "ancestor" domains is only enforcable if coupled
with strong policing of name allocation. Relaxing this so that local
names need only be disjoint from the names of its "ancestor" domains,
and not their children, would make name allocation much simpler, and
would only make outgoing addresses one domain longer. That is, instead
of omitting the entire common portion of source and domain addresses,
the sender would omit all but the least most encompassing domain name.
This would also make it easier for small, local domains to
get access to the world. All they need is for a larger domain to
"sponsor" them, and route all mail to one or two gateways known to
the sponsoring network. Routing within the smaller domain need only
be a concern of the gateways. Let's here it for the small guy!
Am I flaming to no end? Has this already be suggested? Please
let me know.
--
jonah (Jeff Lee @ Dept. of Comp. Sci., The University of Western Ontario)
UUCP: ...!decvax!{utzoo|watmath}!deepthot!jonah
MLNET: jonah@deepthot.UWOjer@peora.UUCP (J. Eric Roskos) (06/10/85)
>The telephone co. uses a single-level hierarchy (area code), as >do the airlines. The post office uses both single (zip) and >double (city,state). While I agree with everything you said, the above statements are not correct. The zip code is a geographical hierarchy such as you are proposing: National Area | --post office or delivery area | | --segment | V V V -- -- 32811-7307 ___ -- ^ ^ | | | --Sector --Sectional center (SCF) or large city I.e., moving from left to right identifies the geographical location more and more exactly. The telephone numbers also have more levels than you listed; consider the country code, area code, and exchange, each of which identifies a geographical area. -- Full-Name: J. Eric Roskos UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642 "Erny vfgf qba'g hfr Xbqnpuebzr."
joe@fluke.UUCP (Joe Kelsey) (06/13/85)
Joel - You missed the most important idea behind the domain naming scheme. That is, the major purpose of domain names is to (almost) completely decouple the hostname from the transport mechanism. The motivation is mainly for mail, but it also extends to many other facilities when you are talking about a fully connected Internet. The current ARPA Internet consists of the main backbone ARPA/MIL network of IMPs with many local area networks directly or indirectly connected to ARPA/MIL hosts. In this environment, addressing a given host on a given connected subnetwork either requires HUGE host tables (in order to maintain the flat name space) or a change in the address/naming scheme. The actual address mechanism is sufficiently robust (Class A, B, and C netowrks), so the naming scheme needs to be changed. Basically, they are giving up a flat name space, but maintaining what looks like HUGE local name tables through (hopefully) user-transparent use of name servers/resolvers. In order to really understand the use of name servers/resolvers, I recommend that you get a copy of RFC 882 and 883 (FTP from SRI-NIC) and study them n conjunction with RFC920. The exact same arguments about giving up flat name space to save on routing table sizes applies almost directly to UUCP connections as they exist today. What we propose with whatever domain scheme come out is to decouple the UUCP address (the current hostname) from the actual site name. This may seem like a difficult concept to grasp, but many hosts already have to deal with having a hostname which is different from their UUCP address. After all, the physical address used to route in UUCP bang paths is restricted to 6 globally unique characters, single case, although special characters are technically allowed. This is almost completely user-unfriendly and non-intuitive when you consider the number of hosts that are reachable via UUCP today. I think that is important that anyone who is tempted to jump into the domain discussion consider that what we really want is a way to name hosts *independent* of their physical location or physical network address, since both of these are volitile. What we need is a user-intuitive way of finding out host names, then a set up protocols to implement some sort of limited distributed name server/resolver on the UUCP transport mechanism. This is possible, but an important step to take is to disconnect your idea of hostname from physically restricting ideas, like geographic or network addresses. /Joe
jordan@ucbvax.ARPA (Jordan Hayes) (06/15/85)
In article <2323@icarus.fluke.UUCP> joe@fluke.UUCP (Joe Kelsey) writes: > I think that is important that anyone who is tempted to jump into the > domain discussion consider that what we really want is a way to name > hosts *independent* of their physical location or physical network > address, since both of these are volitile. What we need is a user-intuitive > way of finding out host names, then a set up protocols to implement some > sort of limited distributed name server/resolver on the UUCP transport > mechanism. This is possible, but an important step to take is to disconnect > your idea of hostname from physically restricting ideas, like geographic or > network addresses. > > /Joe Independent of "physical network address", yes, of course, but I don't think that geographic reference in some instances is any more restricting than organizational domains. There are many UUCP sites that decide who to call (and how often) on the basis of COST. The ARPAnet has no such factor involved in its routing. Example: should a University in Germany be in the same domain as UC Berkeley because it is a University? ARPA says yes. UUCP should say no. Geography is counter-intuitive in the ARPA world. Not always in the UUCP world. True enough, the physical network address can be very volitile, but the geographic location is not. Machines don't move about in space (see "inertia" for similar examples). Likewise, Northern California isn't on its way anywhere in a hurry (don't tell that to seismologists ;~> ) /jordan ------- ARPA: jordan@ucb-vax.BERKELEY.EDU UUCP: jordan@ucbvax.UUCP
henry@utzoo.UUCP (Henry Spencer) (06/17/85)
> Now what do these all have in common? The last four machines are each linked > together directly via tcp/ip or uucp; the first 4 are located within > a 10 mile radius of my office in San Diego. But, under the > proposed scheme, what do they have to do with each other? Not much. Just how much do "amd!pesnta!lsuc" and "utzoo" have to do with each other? Yet these two machines are within a couple of miles of each other, and call each other on demand plus polling. For that matter, "utcsri" and "utastro" are 2000 miles apart (U of Toronto vs. U of Texas). Names and routes are already very different animals. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry