Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!cwruecmp!hal!ncoast!tdi2!brandon From: brandon@tdi2.UUCP Newsgroups: news.sysadmin Subject: UUCP domains (and a few misunderstandings) Message-ID: <145@tdi2.UUCP> Date: Tue, 3-Mar-87 17:23:06 EST Article-I.D.: tdi2.145 Posted: Tue Mar 3 17:23:06 1987 Date-Received: Fri, 6-Mar-87 02:08:21 EST Reply-To: brandon@tdi2.UUCP (Brandon Allbery) Distribution: world Organization: Tridelta Industries, Inc., Mentor, OH Lines: 100 I'm going to try to suggest a reasonable UUCP domain scheme. However, first to correct a misconception: An earlier posting contained a complaint about UUCP domains, and used the site "hplabs.HP.COM" as an example. THIS SITE IS NOT A UUCP DOMAIN SITE, IT IS AN ARPA INTERNET DOMAIN SITE. There's a big difference: the Internet was set up for domains to begin with, so the map from everyone in one large ARPA domain to smaller subdomains COM, HP.COM is easy. UUCP is not domainized. Most UUCP mailers don't even recognize user@site.UUCP, much less static-route it, much less *dynamic* route it. And an easy solution doesn't exist, unless the FSF wants to release GNU Mail or I can get UA-Mail finished. --And even then, people have to install it. Ha! IF we can get past that fundamental barrier, or convince AT&T to provide a domainized mailer, we can get started: The UUCP domain should be split up into regions; each region has one or more ``primary'' sites which is known to the regional ``primary'' sites of other systems. Each site then can be a subdomain, to subdivide the high-level domain. Each of these may then have sites defining subdomains, etc. Example, using states as regions: REGION: Ohio -> OH Primary sites: cbatt (Columbus) -> CBATT.OH cwruecmp (Cleveland) -> CWRU.OH Secondary sites: ncoast (Cleveland) -> NC.CWRU.OH Ncoast is a news feed for many minor sites in the area. hal (Cleveland) -> HAL.CWRU.OH Hal is Case Western's news machine; might want to hide this internally as part of CWRU.OH. cbosgd (Columbus) -> CBOSGD.CBATT.OH Cbosgd is apparently retired from the backbone, so a secondary status is probably applicable. On the lowest level, machine addresses in the domainized form: tdi2.NC.CWRU.OH cbosgd.CBOSGD.CWRU.OH (i.e. cbosgd as both machine and domain) sys1.NC.CWRU.OH (really ..ncoast!peng!homer!sys1) Each low-level site keeps a map of the sites it talks to and sends the map to the higher-level site; thus, the hard path collection is broken into manage- able pieces. Higher-level sites then integrate the maps they receive. High-level sites DO NOT HAVE TO CONNECT DIRECTLY: a slower but cheaper path can be used. Thus, the OH domain masters can talk to the IN domain masters via smaller systems, but the externally-visible path includes only the large sites. Note that this can be treated as a backbone-type setup, but it can be split into smaller chunks to hold down the load on a backbone. Nothing precludes having a site that is only a "path server" for many smaller sites, so that you can have 30 machines comprising the top level of the OH domain, but are visible only as the OH domain with the "path server" providing path infor- mation as to which of the 30 should get the mail for which lower-level domain. (NOT site -- domain. The mythical machine oh-server doesn't have to know about sys1, just about the CWRU subdomain. Or the CLE subdomain, if that's how OH gets divided up.) from x.BAR.FOO.IN to sys1.NC.CLE.OH -> sys1!...!ncoast!...!cwruecmp!...!oh-serve!...!in-serve!...!foo!...!bar!...!x end full full server server full full end ANY of these sites may be just a "path server" rather than a full forwarding site. Of course, the basic idea has to be fleshed out, etc. The path server mechanism, however, should allow automatic sending of mail via the "best way" rather than the specified domain route. Sort of a reduced-scale pathalias for domains/subdomains only; each subdomain host can keep a pathalias-style database for leaf sites *directly attached to it* and subdomains of the domain it serves, ONLY. Exported information is a path line between domains (full to full) or path lines to internal distribution sites (path server sites). I'd like to discuss this *admittedly unclear* idea, try to define it better, come up with ways to implement it, etc., remembering the two goals are to (1) make site addresses manageable via domain/subdomain specification rather than full UUCP paths, and (2) keeping the master domain servers from being swamped as a "normal" UUCP domain/subdomain setup would cause. (For those still confused about path servers: path servers ~ HIDDENNET.) ++Brandon -- ``for is he not of the Children of Luthien? Never shall that line fail, though the years may lengthen beyond count.'' --J. R. R. Tolkien Brandon S. Allbery UUCP: cbatt!cwruecmp!ncoast!tdi2!brandon Tridelta Industries, Inc. CSNET: ncoast!allbery@Case 7350 Corporate Blvd. INTERNET: ncoast!allbery%Case.CSNET@relay.CS.NET Mentor, Ohio 44060 PHONE: +1 216 255 1080 (home) +1 216 974 9210