mel@hogpc.UUCP (01/24/84)
A uucp domain does NOT need a person "responsible", anymore than netnews needs a person responsible. The purpose of the domain is to limit the number of sites that must be considered in chosing a unique site name, i.e. (415)vortex must be unique in the Bay area, and (617)vortex must be unique in the Boston area, but both may exist on uucp. It wouldn't take more than a day's research to find conflicts within the domain of an area code (a short query on Usenet would do it, as would asking the administrator of the nearest large node). The name server problem is a non-problem. The larger nodes in an area could easily serve to pass on traffic (as they do now) for the smaller systems around them. We don't need a centralized, militaristic, IBM type solution to the uucp domain problem. A simple, easy to use and understand, domain naming scheme needs to be defined and used. All the rest will come in the usual decentralized UNIX fashion. Mel Haas , (201)houxe!mel
rob@lzmi.UUCP (01/24/84)
[non-blank line]
Another voice in the wilderness crying out in support of
Area-codes as uucp domains.
--
{
{ {
__________ { { { {
(_)________) ==> {{{{{{{{{ ......throwing another log on the fire....
___________ Rob Coben ...!hogpc!pegasus!lzmi!rob
O (_)_________) O AT&T IS LZ - 3B225
__|_______ _______|__
(_)|_______))______|__)
=====|===============|======
T T preece@uicsl.UUCP (01/26/84)
#R:hogpc:-32500:uicsl:21300001:000:635 uicsl!preece Jan 25 07:47:00 1984 Area code seems like a useful domain specifier. I don't like the proposed punctuation, however. Using (areacode)name means that in addition to the domain specifier itself we would need to type two additional SHIFTED characters for each name in the path. That adds up to a substantial typing overhead. I'd suggest the punctuation should be a single character and not a shifted character. It should be noted, also, that a lot of the names do carry some mnemonic value. The domain-specified names will be much harder to remember; sure, Boston's easy, but some states have a lot of area codes. scott preece ihnp4!uiucdcs!uicsl!preece
robert@erix.UUCP (Robert Virding XT/DU) (01/27/84)
How would clashes caused by areas in different countries having the same
area-code? A country prefix to the code?
Robert Virding @ L M Ericsson, Stockholm
{decvax,philabs}!mcvax!enea!erix!robertglc@akgua.UUCP (01/29/84)
While I find much merit in the proposals for area-code domains,
I might raise a point...how many people in the East know the
area-code for Anaheim, Calif? There are currently 9 area codes
in California and always the possibility of one of them splitting
into two.
Those who are more familiar with the various newsgroups will
look in net.news.map for the site they wish to contact. The
area-code will usually be found there. But for the less
experienced users, or those who only know "Naperville is in
Illinois, but I don't know what part!" there is still a problem.
I don't say that using the state/provence/country name is the
best solution. And it is quite possible that with most netnews
users putting their area-code in their signatures, a responder
would soon adapt to the idea of using it for the uucp domain. I
would like to invite a bit more discussion from the standpoint of
the naive users on such a proposal. Remember, more and more of
them keep popping up on the net. Whatever domain scheme is
finally adopted needs to be simple enough in its usage for them
to grasp.
Cheers,
Lindsay
Lindsay Cleveland (...{ihnp4|mhux?|clyde}!akgua!glc)
AT&T Technologies/Bell Laboratories ... Atlanta, Ga
(404) 447-3909 ... Cornet 583-3909mather@uicsl.UUCP (02/03/84)
#R:hogpc:-32500:uicsl:21300003:000:227
uicsl!mather Feb 2 13:04:00 1984
Let's use zip codes instead. You know, the 9 digit one that the post
office wants !!
B.C. Mather
Le Maitre
uiucdcs!uicsl!matherrpw3@fortune.UUCP (02/03/84)
#R:hogpc:-32500:fortune:26900019:000:2608
fortune!rpw3 Feb 3 02:58:00 1984
To repeat Erik Fair, the discussion in net.mail is "better", since those
who are actively working on it are posting there.
But... Who can resist? I would just like to point out:
Geograhically based names are no good for geographically
dispersed sites in the same domain. (What SINGLE area code
is ".DEC", ".ATT", ".HP", or for that matter, ".Fortune"?)
Geographic names are good for selecting routes, hence should
be used for "addresses".
The concept of "domains" is precisely to isolate the "naming"
of resouces/hosts/people from the "route" to them. One wants
"user@group.org.UUCP" to be reachable by anyone who has a path
to ANY gateway into "org", no matter how many machines that
is or where they are, much less what "group" is. (The nature
of "group" is PRIVATE to "org" domain's administrator and itself
may be more than one machine. Only the "group" administrator
needs to know what machine "user" gets mail on.)
Some geographical sub-domains may be necessary to accommodate
a large number of single sites who do not wish to expend the
resources to maintain full routing tables. I strongly suspect
that these will follow the lines of the current regional
newsgroup names. For example, there will probably be a ".ba.UUCP"
for the San Francisco Bay Area, a territory that is naturally
treated as a unit and that extends over several area codes.
But many sites in the Bay Area will be part of nationally
(or internationally) dispersed domains; mutual encapsulation
will be needed (i.e., both "xxx.ba.org" and "xxx.org.ba").
In summary, the area code proposal should really be considered as
an "addressing" method, a refinement of which could be based (in the US)
on ZIP+4. Note that telephone and Telenet numbers are "addresses", like
ZIP codes; they tell you "where", not "who" or "what". Area codes or ZIP
codes MAY be useful as addresses, but not as domains. Current UUCP host
names are really "routes", but could evolve to either "addresses" or
"names within domains".
Rob Warnock
UUCP: {sri-unix,amd70,hpda,harpo,ihnp4,allegra}!fortune!rpw3
DDD: (415)595-8444
USPS: Fortune Systems Corp, 101 Twin Dolphins Drive, Redwood City, CA 94065
References (somewhat sketchy):
1. The John Shoch (Xerox) paper "Names, Addresses, and Routes" and the
Jerry Saltzer (MIT) follow-on commentary paper (with a similar name)
supply an excellent vocabulary and view of the issues.
2. The Oppen and Dalal (Xerox) paper on "Clearinghouse" (Tech Report OPD-T8103)
gives a good introduction to functions needed in in a name server, as well
as an overall rationale on domains.fair@dual.UUCP (Erik E. Fair) (02/06/84)
This discussion rightly belongs in net.mail, as you should know Mel, because you have been making noises like you were among those present at `the meeting' on that Tuesday night. I will attempt to move this discussion to net.mail, and I will direct my subsequent responses there. There are two discussions going on here, and we should separate them quickly, or forever be confused. Those two discussions are: 1) Splitting up our `name space' (or address space?) in such a way as to avoid overflowing the extant naming scheme and bury routing information into software, rather than people's heads. 2) Qualify for a top level domain so that we can legitimately speak to the ARPANET on better than furtive grounds. The idea, as I understand it, is to do number 2 first, and then subdivide the domain as necessary. To do #2, there are certain requirements, as stated by thomas@utah-gr.UUCP (Spencer W. Thomas). He said: > Date: Mon, 23-Jan-84 20:34:33 PST > > A domain must have two attributes: > 1) a person who is "responsible" for all the sites in the domain - a > domain administrator, and > 2) a name-server which knows the actual address of all sites or > subdomains. In short, ARPA wants someone they can talk to when things go wrong, and they want things such that they can mail to person@site.UUCP, and not worry about the routing. We could conceivably accomplish this with address translation at every ARPANET gateway. The problem then reduces to keeping an up to date map, and making sure that it is distributed to the gateways in a timely fashion. That, however, does not solve the problem I listed as #1 up there. Depending upon who you believe, the network will grow vigorously or explosively in the next few years, and the result will be more chaos than we're used to. We will have sites with duplicate names turning up in different parts of the country, and routing a letter from system A to system B will be a nightmare. Domains have been suggested as a solution to that problem, and I have yet to hear anyone make a better suggestion. So instead of arguing the merits of domains, let's formulate a plan of action. I submit the following: 1. Map the network (already underway) (Thanks to parsec!kolstad, cbosgd!ksh, and wjh12!sob) 2. Write routing software to handle domain addresses (underway?) 3. Write a name server for ARPA. 4. Distribute the software EVERYWHERE. 5. Qualify for the `.UUCP' top level domain. 6. NOW begin discussion for domain sub-division. Number 4 is one of the most important, because if the whole network doesn't participate, we're dead. We can provide a certain amount of backward compatibility, but we can't have two network routing schemes working side by side, particularly in light of the addressing problems. I'm trying to put off the sub-division discussion until we have the software ready to handle the problem. It does no good to discuss grandiose plans for sub-division, when the current routing systems don't handle domains at all. Erik E. Fair dual!fair@BERKELEY.ARPA {ucbvax,ihnp4,cbosgd,amd70,zehntel,fortune,unisoft,onyx,its}!dual!fair Dual Systems Corporation, Berkeley, California P.S. Can we avoid use of loaded phrases & rhetoric? It only serves to heat the discussion beyond rationality. (This means you, mel@houxe.UUCP)
bbanerje@sjuvax.UUCP (B. Banerjee) (02/07/84)
Is this a private discussion, or can anyone join in? If its public, I'd like to contribute my admittedly inconsequential two-bits. dual!fair writes - >> I submit the following: >> >> 1. Map the network (already underway) >> (Thanks to parsec!kolstad, cbosgd!ksh, and wjh12!sob) >> 2. Write routing software to handle domain addresses (underway?) >> 3. Write a name server for ARPA. >> 4. Distribute the software EVERYWHERE. >> 5. Qualify for the `.UUCP' top level domain. >> 6. NOW begin discussion for domain sub-division. >> >> Number 4 is one of the most important, because if the whole network >> doesn't participate, we're dead. We can provide a certain amount of >> backward compatibility, but we can't have two network routing schemes >> working side by side, particularly in light of the addressing >> problems. I'm trying to put off the sub-division discussion until we >> have the software ready to handle the problem. It does no good to >> discuss grandiose plans for sub-division, when the current routing >> systems don't handle domains at all. I substantially agree with this. However, the "anarchy" of the current situation may make this rather difficult to enforce. With news alone, you have many sites still running A news (out of inertia?). This is for a system of relatively recent vintage. When you are speaking of UUCP software, and mailers, you open up a whole can of worms. I somehow doubt that the inertia of the UUCP network can be easily overcome. The solution is easy, though rather draconic. * Don't * make the new software backwards compatible with the old. Then make sure that enough sites, including the backbone ones, change over that us little guys will have to convert out of necessity. A pot-pourri of other considerations regarding this. 1. The routing tables/name-server on the gateway machines has to be up-to-date. Preferably, the process of verifying links could be automated. Also, the process of updating routing tables (Shades of net.adm.sites!!). 2. It would be great if some order were imposed on the UUCP network, doing away with leaf nodes. Preferably there should be at least two paths to each node (I'll let the wizards figure out the topological considerations). 3. Once, 1. and 2. have been addressed together with domains; why not have the software provide adaptive routing? Each forwarding site would require to know the routes to a relatively small number of systems/sub-domains. 4. The new software should be free, or close to it. One of the reasons our site didn't get on the CSNET was that the 5K annually probably wouldn't have been justified in terms of the number of users requiring internet mailing facilities. 5. A semi-grumble! If there is a concerted effort to map the net, its still a mystery at this site. At least 2 months ago I read on the net that we could be expecting a "Cybernet plea for information" soon. I'm still waiting! Enough for now. Just voicing my opinions. -- Binayak Banerjee {allegra | astrovax | bpa | burdvax}!sjuvax!bbanerje