mark@cbosgd.UUCP (Mark Horton) (01/04/85)
This is a draft of our requirements for becoming a UUCP subdomain. Please forward comments to cbosgd!mark. Philosophy: We are primarily trying to establish some notion of universal service in setting up domains. The current bang code was designed for an environment where every machine has a direct connection to every other machine, phone calls are free or cheap, and local area networks were just around the corner to replace this dialup kind of network. The UUCP network has evolved into a huge, anarchistic network, and none of these assumptions are valid anymore. Hence, we are conforming to the widely used, documented mail standard that is catching on in the electronic mail community, the ARPA domain standard. (The only other documented standard is X.400, which has not yet caught on well enough for us to consider. The old UUCP ! format is undocumented and unmanageable in a network the size of UUCP; we expect this format to continue to work indefinitly, but have chosen to support the ARPA standards at the user level.) The UUCP community has evolved as an anarchistic, loosely connected network with no central administration and no rules. An anarchy works if it is small, but with thousands of machines already on the network and the number of UNIX machines growing at breakneck speeds, it has already begun to break down. We are establishing a central administration to keep track of who is on the network, and who to contact in case something goes wrong. Nonetheless, we are keeping the established rules to a minimum, to retain the cooperative spirit of the UUCP world. We have determined that a flat name space is beyond our capability to administer, so we are dividing the UUCP world into subdomains. The current flat name space using the user@host.UUCP syntax will not be supported after a certain date [possibly December 1985] and all hosts will be expected to band together into subdomains. We intend to register UUCP as a top level domain. Direct subdomains of UUCP will therefore be 2nd level domains. (A subdomain is a domain which is beneath another particular domain in the tree. For example, ATT.UUCP is a 2nd level domain which is a subdomain of the first level domain UUCP, CB.ATT.UUCP is a 3rd level domain which is a subdomain of ATT.UUCP.) 3rd level, 4th level, and so on are also possible, but there will be different (presumably less restrictive) requirements for lower level subdomains. We want to keep the number of 2nd level domains manageable, since a complete list of 2nd level domains will be frequently published. We expect a hundred or so 2nd level domains to be a small enough number to be manageable and to allow frequent publishing of the list. These requirements are intended to keep the eventual number of 2nd level domains at around 100. Rather than having us arbitrarily divide the world into fixed subdomains, we have decided to encourage the world to divide itself up. Any group of machines can join together to become a 2nd level domain, provided it meets the requirements stated herein. Groups can decide for themselves the basis for subdivision, although geographic regions are an obvious choice. For example, New England and Northern California would be two obvious choices for 2nd level domains. Very large organizations might also decide to become a 2nd level domain, for example, AT&T is spread out over much of the United States, but accounts for nearly half the UUCP hosts in the world, so will probably have its own 2nd level domain ATT.UUCP. Small and medium sized organizations are encouraged to join up with other nearby organizations to become regional 2nd level domains, in order to keep the total number of subdomains small. An organization with a few machines may wish to become a 3rd or 4th level subdomain, but should not become a 2nd level domain. Individual machines will not be allowed to be 2nd level domains, hence, the user@host.UUCP syntax will only be supported until we can get the subdomain framework in place. All hosts that want to become part of the UUCP domain will have to become part of some subdomain. It is not necessary that all hosts attach into the domain tree directly off a second level subdomain; further subdivision is allowed if it makes sense locally. Individual machines may or may not be 3rd level or lower domains, according to the policies of the 2nd level domain. All individual machines are viewed as Nth level domains, for some N. Thus, if OSGD.CB.ATT.UUCP represents a particular machine, it is also viewed as a 4th level domain. The following is a list of requirements for becoming a 2nd level domain under the top-level domain UUCP. - Conformance with RFC920 We are operating under the guidelines established by the ARPANET document RFC920. That document describes the overall domain structure of the domain tree, and sets forth the requirements for domains. Some of these requirements apply only to top level domains, but many of them apply to all levels. Since subdomains of UUCP will be in the ARPA domain tree, they must conform to the rules specified there. Briefly, these rules are that each subdomain must have a responsible contact person, maintain a registry of all their subdomains and machines and the contact persons for them, provide some sort of access to that registry with a domain server, be at least a certain size, and register with their parent domain. - Responsible Persons There must be a minimum of two responsible people per subdomain. The main contact must be a technical contact, and the alternate may be either a technical or administrative contact. These people will be responsible to the UUCP Project initially, and to the UUCP community overall. When a contact person for a subdomain steps down, they must notify their parent domain, and either (a) find a replacement, (b) dismantle the subdomain, or (c) make arrangements with someone to be a temporary replacement. - Size A 2nd level domain must have a minimum of 100 machines, representing a minimum of 250 users. Exceptions to this rule will be made at the discretion of the UUCP Project. Exceptions are intended for situations where a subdomain is small but isolated from the rest of the community by an expensive bottleneck, for example, Asia and Australia should probably be separate subdomains because of their remote geographic location and the expensive dialup links to them. It is expected that Europe will have one or two subdomains as well. Note that this requirement is stricter than the 50 machine minimum recommended in RFC920. This is because the UUCP net is larger than the typical network envisioned by the authors of RFC920, is growing faster, and operates using a lower performance transport than the TCP/IP environment assumed in their environment. Single organizations (such as companies, universities, or government divisions) desiring a 2nd level domain must show that they represent 1/100 of the UUCP domain (so that if 100 subdomains are created, such organizational domains will be as large as other subdomains.) Medium sized companies that cannot meet this requirement but would like to become second level domains are encouraged to become gateways for a larger geographic subdomains in their region. Our expectation is that there will initially be 15-20 2nd level domains in the United States, 2-5 in Canada, 2-10 in Europe, one in Australia, and 1-2 in Asia. These numbers are based upon the current distribution of hosts running UUCP, and are subject to revision as needed. - Registry Each subdomain must keep a registry of all machines and subdomains within it. While we do not require the complete registry to be published, it must be possible to determine the organization and contact person for any user, machine, or subdomain within the UUCP domain. We expect that either a name server will be made available, or else the responsible persons will be able to track down any address within their subdomain and find out who it belongs to. This chain of responsibility is necessary in order to idenfify the source of messages causing problems for other sites, and is a requirement placed on us by the ARPA registry in order to become a top level domain. (These registries are different from the UUCP host name registry, which registers the 6-letter UUCP transport names.) - Unique names Each domain name must be unique within its parent domain. For example, within the UUCP domain, there cannot be two domains named CAL.UUCP and CAL.UUCP. There could, however be two domains called BA.CAL.UUCP and BA.ATL.UUCP, or CAL.UUCP and CAL.CSNET. - Domain Server Once a standard domain server protocol has been documented and public domain software made available to implement it in the UUCP environment, we expect each domain to support such a domain server and allow access to it to anyone. It is not necessary to provide a complete list of all registered hosts, but it is essential that requests of the form "who is abc.xyz.ne.uucp and who is their contact person" be answered, in order to track down the source of errant messages. It will also probably be necessary to provide a server that maps 6-letter UUCP names into domain names somewhere on the net. - Gateway The subdomain must provide at least one gateway machine for the subdomain. This machine must be able to handle all the traffic between the inside and outside of the subdomain, and must also be willing to forward traffic from outside machine to outside machine. This gateway machine or machines will become part of the UUCP backbone, and complete UUCP connection information for the gateway will be published regularly. Subdomains are encouraged to set up more than one gateway; however, in doing so, they should ensure that all gateways have good solid connections with each other and that all gateways run the same versions of routing tables for the subdomain. External nodes should be free to forward properly addressed mail to any gateway and be sure that the results will be the same as if the mail were forwarded to a different gateway. - Updates The responsible people will be required to ensure that their parent domain has up-to-date and correct contact and connection information for them. We expect that, unless no information has changed, that gateways will be updated every one week to one month. The contacts for the subdomain will probably want to keep connection information for all internal sites, but are not required to present this information to the UUCP Project. - Name length No hard limit is placed on the length of names used for addresses in the UUCP domain. However, for human factors reasons, we expect that names chosen will be both representative of the constituency of the subdomain, and short enough that people will not object to typing complete electronic addresses. It is recommended that typical fully qualified domain names be no more than 16 characters long, including periods, and that typical user names on the left of the @ be kept under 16 characters in length as well. For example, the ATT.UUCP subdomain will probably allow electronic addresses in two forms, a machine address form like "john@ihnp4.ATT.UUCP" and a person name form like "John.Smith@ATT.UUCP". (This is not a hard limit, but rather a guideline. The primary motivation is that short names are easier to type than long names. If there are other overriding considerations, longer names may be necessary.) - Software support All subdomains are expected to conform to the appropriate ARPA standards for syntax and semantics of mail and news, including RFC822, RFC819, and RFC850. (News need not be supported, but electronic mail is required.) Mail transferred within the subdomain is an internal matter and can be in any format, but all mail leaving the subdomain must appear to external software to have originated on an 822 conforming host, and mail conforming to 822 standards entering the subdomain must be accepted and properly dealt with. It is recommended that internal mail also use the 822/819 syntax, as this makes gateway issues much easier. Two consenting hosts are free to exchange mail or news in any format they mutually agree upon, so long as it does not cause problems for the rest of the network. For example, two hosts may choose to exchange news in notesfile format; there is no problem unless news passing through this link loses information and the resulting news is propagated throughout the rest of the net. A document will be published by the UUCP project summarizing how the 822/819 standards are to be interpreted in the UUCP domain. Subdomains must conform to the UUCP interpretation also. In practice, this will mean at least support of one extension, the dom.ain.name!user syntax as being equivalent to user@dom.ain.name. We expect to provide public domain software that meets these requirements in the next several months, but hosts are free to run any software that conforms to the appropriate standards. - Representative names We expect all our subdomains and their subdomains to choose names that are reasonably representative of the constituency of the subdomain. In particular, we discourage subdomain names that are chosen from "themes", and subdomain names that are just the name of the gateway. Thus, "ethel" (an example from an "I Love Lucy" theme) and "xyzvax" (a machine name which is also a gateway") should be avoided, in favor of names like "ne" (New England.) Of course, if the most descriptive name for the subdomain happens to be theme based (e.g. "homer" for the machines named "ulysses", "kalypso", etc, or "xyz" if the subdomain is the company named "xyz" whose gateway machine is also called "xyz") the name will be allowed. In general, a descriptive organizational name or geographic name is preferred, if it is meaningful outside the subdomain. The intent of this requirement is that it is easier for humans to remember names that are descriptive of the user or the user's organization than "cute" names, especially for infrequent users of the system. It is also more helpful when a user receives a message from someone in a domain they don't recognize, if the name is somehow indicative of the location or organization of the sender. Choosing a name for a new machine is hard, especially if the owners of the machine are new to the net and unfamiliar with customs and problems that can arise. A good name for the first machine a company gets is the name of the company. It is quite common to name a machine after the type of machine (e.g., "csvax" or "ucbvax") but this is a bad idea, because if you acquire more machines of the same type the names will be confusing. Plan for the day you have lots of machines, for example, "framusa" or "a.framus" if your company name is framus and your theme is letters of the alphabet, or "ethel.framus" if you are naming your machines after an "I Love Lucy" theme. Themes already being used include the Marx Brothers, stars, constellations, Homeric characters, musical tempos, brands of automobile, and the cast of Leave it to Beaver, as well as more mundane themes such as letters of the alphabet, numbers, colors, names of departments, names of the users of personal computers, and so on. Originality is encouraged, as long as the higher level domain name is descriptive of the organization. Bad names include "unix", "bigvax", "vax", "gateway", "sun", "framusvax". Also bear in mind that "UNIX", "VAX", and similar terms are trademarks of various companies. - Geographic domains There are two kinds of domains: geographic and non-geographic. A typical non-geographic domain would represent a particular organization, such as a university, company, government entity, or some other cooperative organization. A geographic domain is one that is intended to register anyone in that geographic region. A geographic domain need not accept top level registrations from sites in the region, but should allow any machine in the region to register somewhere under the domain. For example, a geographic domain called "ne" for "New England" may subdivide into domains "boston", "nh", "mass", and so on. The "boston" domain may in turn have a "bbn" subdomain for the BB&N company. A host "c70" at the BB&N company should be allowed to join the "bbn" domain as "c70.bbn.boston.ne.uucp", but need not be allowed to join the "ne" domain directly as "c70.ne.uucp". Non-geographic domains may establish any rules and requirements they wish upon their members. Geographic domains may also establish any rules and requirements, but it is expected that a rule obeying host which pays its own way can register somewhere within the geographic domain within which it is located. It is recommended that all hosts belong to some geographic domain, in addition to any non-geographic domains it joins. This will enable people to send you mail in terms of the geography. For example, the machine "osgd" may belong to the "cb.att.uucp" domain, but it should also register with the "cmh.mw.uucp" domain, since it is located in Columbus (cmh) in the midwest (mw.) - Growth plan When a domain grows, it may find that a once workable name space becomes unworkable because of its size, and that it should be subdivided. For example, "plus5.uucp" is an accepted convention now, but the size of the domain has grown to the point where subdomains have become essential. As a result, plus5.uucp will probably be renamed plus5.mw.uucp, or possibly even plus5.stl.mw.uucp. This causes an upward compatibility problem, and the old name must be supported for a reasonable period of time until people are using the new name. This is termed "growth by fission", where hosts become one level (or more) lower in the domain tree. Growth by fission is a difficult process, and we would like to avoid it where possible. We therefore ask that all subdomains make estimates of (1) their current size (in number of hosts), (2) size in one year, (3) size in 2 years, and (4) size in 5 years. We request that the subdomain structure of each domain be established so that growth by fission is not needed for 5 years, if possible, and not for 2 years in any case. This growth plan, including estimates and proposed subdomain structure, should be included when the domain applies for registration in the UUCP domain. We do ask that an appropriate balance be created between room for growth and length of addresses. If the part of a typical mailing address to the right of an @ sign is longer than 16 characters, chances are that the structure is too bushy. A domain name like osgd.osg.cb.att.uucp might reflect the organizational heirarchy, but is a lot for people to remember and type. Please try to keep the names short and the number of levels small. AT&T is probably the largest subdomain of UUCP, yet addresses no worse than osgd.cb.att.uucp are anticipated. - Initial domains To set the flavor of this structure, our intent is that the initial 2nd level domains under UUCP will be along these lines. This is not a firm requirement, just a guideline. Geographic 2nd Level Domains wa.uucp Washington State or.uucp Oregon State nca.uucp Northern California sca.uucp Southern California mtn.uucp Mountain states (AZ, UT, CO, NM, WY, ID, MO) sw.uucp Southwestern states (TX, OK) mw.uucp Midwestern states (ND, SD, NB, KS, MN, IA, MO, WI, IL, IN, MI, OH, KY, WV) se.uucp Southeastern states (LA, AR, TN, MI, AL, GA, NC, SC, FL) east.uucp Eastern Seaboard (VA, DC, MD, PA, NJ, NY) ne.uucp New England (CN, RI, VT, NH, MN) wcan.uucp Western Canada (BC, AB, SK, MB) ecan.uucp Eastern Canada (ON, PQ, etc) eur.uucp Europe uk.uucp Great Britain, United Kingdom and Ireland aus.uucp Australia asia.uucp Asia, including Korea and Japan Non-Geographic 2nd Level Domains ATT.UUCP the AT&T company HP.UUCP the Hewlett Packard company This is just a rough guideline, and the actual domains will determine their exact boundaries. Some areas are missing from the above list, for example, we don't know where to put Hawaii. There is room for a few additional domains, should some of the above be too big. For example, western New York state and Pennsylvania might wish to form their own domain, or North Carolina might. The names above are also only suggestions. - Right of refusal We reserve the right to accept or refuse 2nd level subdomain applications. For example, we would not accept two domains with an overlapping general purpose constituency; e.g. two domains that both claim to represent the state of New York. - Application The responsible person must make application to the UUCP project responsible person (currently Karen Summers-Horton, cbosgd!ksh) outlining who the domain represents, what the name of the domain is, showing how it meets these requirements, the growth plan, and giving the name, postal address, electronic address, and telephone number of both the administrative and technical contacts. - Routing The established convention on UUCP is that if two users on different machines exchange mail often, a direct UUCP link should be set up between the two machines. If this is not possible, a short path should be established between the two, and permission should be obtained from all intermediate hosts (since you are running up their phone bill and using their cycles.) For seldom used connections, the convention is that others will forward your mail (at their expense) if you will forward their mail (at your expense.) Domains are not the same as routes. Mail from cbosgd.att.uucp to seismo.arpa does not necessarily travel to machines att.uucp, uucp, and arpa. Direct links and known short paths should be used whenever possible. Routes that go up the tree and back down should be viewed as fallback routes, used only when no better route is known. Comments and suggestions on these requirements are encouraged. Please send them to cbosgd!mark. Thanks. Mark Horton and Karen Summers-Horton
hokey@gang.UUCP (Hokey) (01/07/85)
OK, lets get some intelligent discussion on this! I understand that Mark
wants comments mailed to him. One of the big reasons for this is because
that way a lot of unfiltered cruft can be removed.
There has been a lot of discussion about the issues surrounding the mail
project via mailing lists. It would be painful to rehash this discusison.
If a design document existed, I feel much of the rehash could be avoided.
I don't really want to be on the Bleeding Edge of a discusison. I am
reminded of one of my favorite quotes:
"Did they tell that to everyone?"
"Why, certainly. Everyone knows."
"But he never told me that."
"Oh, that's because you are a very educated man and are always
discussing stupid things."
See y'all in Dallas!
--
Hokey ..ihnp4!plus5!hokey
314-725-9492