ksh@cbosgd.UUCP (Karen Summers-Horton) (07/03/84)
Summary of UUCP Project for June The UUCP Project is proceeding on schedule. As of this date, a first attempt at mapping the UUCP network has been made. This data has been divided up into eight pieces, and given to a regional coordinator to maintain each part. Attempts are now being made to gather data on sites that we know nothing about, and to update the information we do have. To assist us in this effort, the entire UUCP map will be posted to Usenet sometime in the next two weeks. It will be posted over a period of several days, so as not to flood the net with traffic. The main progress made in June, was made at the Usenix Conference in Salt Lake City, Utah at the beginning of the month. Many of our volunteers were able to attend the conference, and we met on Tuesday, June 12 for about 4 hours. We spent about an hour and a half arguing about Lauren's registry, and whether it made sense to register hosts in a flat name space as opposed to a heirarchical domain space. Rob Warnock was the major "devil's advocate" in this discussion, which we finally decided could be resolved by thinking of Lauren's registry an "address" registry rather than a "name" registry. Several things were decided concerning the issue of sub-domains. (1) The current practice of using names like cbosgd.UUCP (e.g. a machine name directly underneath the UUCP domain) will cause problems unless we think we can handle a flat name space forever. Since we acknowledge that we can't, we should discourage such names from being used much. We will establish a date beyond which we will not support them (meaning we won't keep such a registry) which may be sometime around June 1985. There will instead be a push toward putting hosts into subdomains, e.g. cbosgd.ATT.UUCP in the ATT subdomain. (2) We don't have the resources to ensure that there will be a domain available for everybody who wants to hook in, based upon some globe spanning property like geographic regions. Instead, we will establish a set of rules for subdomains, and encourage reasonable subdomains to form and take in smaller hosts. In particular, since the host.UUCP syntax won't be supported forever, hosts will have to group together into subdomains, appoint responsible people, and register in order to be supported by our effort. We will encourage reasonably large groups based upon affiliation (e.g. AT&T), location (e.g. New England), or any other criterea they feel logically groups them. Here are some of the ideas for rules that were proposed. These rules are for second level subdomains (e.g. FOO.UUCP), these subdomains can in turn set up their own rules for third level subdomains as they see fit. (a) Subdomains must have a central contact person. Whether this person is labelled "responsible" is an open issue. (b) Subdomains must keep a registry of all members (hosts or their own subdomains) including routing information and contact information. When something goes wrong, there must be a clearly defined chain of contacts to enable us to contact the appropriate person to fix the problem. (c) Subdomains must be at least a certain size. We haven't chosen a size, but the idea is to not have every startup company appearing as a second level domain underneath UUCP. We want to keep the second level list small enough that we can manage it - perhaps a hundred or so subdomains. (d) Subdomains must provide at least one gateway machine that is well supported and widely available. Better yet is if there are a few gateways, a good ratio might be one gateway for every one hundred members. (e) The gateway machines provided by a second level subdomain will form the backbone of the UUCP net. The pathalias style information about how these machines connect to each other will be made public and published regularly. These gateways should be well connected - ideally each gateway will have a direct UUCP connection to each other gateway. (f) The gateway machines must be willing to pass a reasonable amount of traffic for other hosts. While we will encouarge machines that exchange a significant volume of mail to set up a direct UUCP connection, there will be occasional misdirected or unusual mail that will go up the tree to the backbone and back down. Backbone machines must be willing to pass such traffic. (They are also entitled to shut off service to hosts or people who abuse them by sending mail through them regularly instead of setting up a direct link.) The mail software group met to outline the work that must be done to get the first phase of the mail software ready. The following areas were outlined. (1) Static routing Paul Bame (done) (2) Domains Paul Bame (done) (3) Generating Headers Paul and Berry Kercheval (with input from Doug Kingston) (4) Gathering statistics Erik Fair (5) Control of abusers Erik Fair (6) Gateways Paul, Mark Horton, Gary Murakami (input from Doug) (7) Dynamic Routing John Gilmore, Rob Warnock, Rick Kiessig, Doug (8) User Interfaces Larry Auton (MH), Laura Crieghton (Mail) (9) Sendmail config file Gary (10) Partially Qualified Names Paul (or headers person) (11) Routines to read/write headers (John - from sendmail) As usual, comments and suggestions concerning the UUCP Project are always welcome (mail to cbosgd!ksh). Karen Summers-Horton