From uucp Mon Oct 14 16:45:00 1985 >From cbpavo.cbosgd.ATT.UUCP !mark Mon Oct 14 17:29:33 1985 remote from cbosgd Received: from cbpavo.cbosgd.ATT.UUCP (cbpavo.ARPA) by cbosgd.ATT.UUCP (4.12/0.98.UUCP-CS.beta.4-27-85) id AA16978; Mon, 14 Oct 85 17:14:11 edt Received: by cbpavo.cbosgd.ATT.UUCP (4.24/3.14) id AA05186; Mon, 14 Oct 85 17:14:41 edt Date: Mon, 14 Oct 85 17:14:41 edt From: mark@cbpavo.cbosgd.ATT.UUCP (Mark Horton) Message-Id: <8510142114.AA05186@cbpavo.cbosgd.ATT.UUCP> To: backbone@cbosgd.uucp, uucp-project@cbosgd.uucp Subject: a proposal for a domain structure for UUCP Enclosed is a draft proposal for a way to structure the UUCP hosts into domains. This is a very early draft and I'd be very interested in feedback. The document was nroffed with -mm and underlining removed by col -b. If anyone needs MM source or a version with underlines and overstrikes left in, let me know. Mark Proposal for Integration of UUCP Hosts into the ARPA Domain Tree Mark R. Horton Bell Laboratories Columbus, OH 43213 ABSTRACT The UUCP domain software, based on the smail and pathalias programs and the UUCP map, is nearly ready to distribute. In order to actually use the software, a domain structure must be put into place. Several alternative structures are possible. This document pro- poses a structure based on the ARPA struc- ture. 1. Introduction_and_Goals The UUCP domain software, based on the smail and pathalias pro- grams and the UUCP map, is nearly ready to distribute. In order to actually use the software, a domain structure must be put into place. Several alternative structures are possible. This docu- ment proposes a structure based on the ARPA structure. The overall goals we would like to achieve are as follows: 1. Any host which has more than one kind of transport service (e.g. both ARPANET and UUCP) should still have only one name. Domains should not have to agonize over where in the domain tree to attach themselves. 2. User's addresses should be as guessable as possible by a person who is unsure of the exact address. 3. Each subdomain should have autonomy to manage itself. 4. Artificial UUCP layers in the domain should be kept to a minimum. Since UUCP is set up to be run by volunteers, the workload on the volunteers at the high levels should be kept as low as possible. 2. Alternatives There are several different ways to fit into the ARPA domain tree. Here are some of them. In each example, two addresses are given. The first is for a user in the CS department at the University College of London, in the United Kingdom. The second is for a user in the Columbus (CB) works of American Telephone and Telegraph (AT&T) in the United States. - 2 - 2.1 X.400_style The top level domain is always the country. The two letter abbreviation for the country is used. Beneath the country level, each country decides for itself. Since the country top levels will be managed by administration domains such as telephone companies and X.25 networks, it is safest if the UUCP community (or larger community including UUCP) in each country allocates itself a subdomain for its own adminis- tration. The community of interest would correspond to an X.400 Private Management Domain (PRMD.) The third level would probably be the name of the organization, corresponding to the X.400 Organization attribute. The fourth level and below is determined by the organization. For example, the academic community in the United Kingdom has allocated itself the "AC" subdomain of the "UK" domain, and all their addresses fall under .AC.UK, such as user@CS.UCL.AC.UK. A similar situation exists in Australia, where the ACS network is using the subdomain OZ underneath the AU domain. The AT&T address might read user@CB.ATT.UUCP.US. 2.2 Fitting_into_the_pure_ARPA_intent The top level domain is always one of EDU (for educational organ- izations), COM (for commercial organizations) or GOV (for govern- ment entities.) The second level domain is the name of the organ- ization. The third level and below is determined by the organi- zation. In this proposal, the entire world would fit under one of these three domains. International boundaries would not matter. For example, addresses might include user@CB.ATT.COM, or user@CS.UCL.EDU. 2.3 UUCP_as_a_top_level_domain For UUCP to completely administer itself, all UUCP hosts would have to come under a single point in the tree. This is the current (incomplete) structure. The exact name of this domain would be fixed, but not necessarily as UUCP. It might be renamed, e.g. "UU" or "UUMAIL", or it might be moved under the ARPA "NET" domain, e.g. UUCP.NET. There are many ways to set up the second level domains. The current structure states that any "large enough" set of hosts can apply for second level domain status. Any large company, such as AT&T, might have their own second level domain. Any large geo- graphic area, such as a country, continent, or large part of a country, might have a second level domain. Finally, any - 3 - confederation of other smaller organizations, bound together by interest group, specialty, geographic location, or any other cri- teria (such as the first letter of their name) might apply for second level domain status. So far, the de-facto evolution seems to be that the United King- dom, Europe, Israel, Asia, Australia, and AT&T would become second level domains. In addition, ten or so areas of the United States and Canada would tentatively become second level domains. Third level domains would usually be organizations, although they might be countries or organizational units. Example addresses include user@CS.UCL.UK.UUCP (where it is assumed that the UK would have a second level subdomain) and user@CB.ATT.UUCP. 2.4 UUCP_as_Top_Level_with_ARPA_Second_Level_Domains This alternative gives UUCP complete autonomy with a top level domain, but mimics the ARPA EDU/COM/GOV structure underneath it. Sample addresses include user@CS.UCL.EDU.UUCP and user@CB.ATT.COM.UUCP. 2.5 UUCP_as_Top_Level_with_X.400_Second_Level_Domains This alternative gives UUCP complete autonomy with a top level domain, but mimics the X.400 country structure underneath it. Sample addresses include user@CS.UCL.UK.UUCP and user@CB.ATT.US.UUCP. 2.6 Hybrid_Possibilities The pure X.400 world may actually materialize (it's too soon to tell) but the pure ARPA world has already evolved into a real world implementation that does not fit everything under EDU, COM, and GOV. Countries such as the UK are using top level country domains, network based domains such as NET are springing up, and several other top level domains have been created for no obvious reason (such as MIL and ORG.) The overall pattern that seems to be emerging is that the United States (and possibly Canada) prefer not to be geographically organized, but the rest of the world (especially Europe and Asia) prefers to organize along geographical boundaries, such as coun- tries or continents. The interest in the EDU/COM/GOV organiza- tion currently appears to be entirely within the United States. - 4 - 3. Comparison_by_Goals 3.1 Single_Name All the proposals that put UUCP under a separate subtree lose out on this point, which is a major goal. The best way to meet this goal is to match existing practice as closely as possible, since differences with existing practice would be the primary cause of multiple names. The hybrid proposal appears to come closest to existing practice, and so meets this goal best. 3.2 Guessable_Name The best way to make names guessable is to be completely con- sistent within UUCP and with existing practice. This would imply that either pure X.400 or pure ARPA would be best. However, existing practice does not appear to be self-consistent, since the United States has several top level domains, and other coun- tries are using the country name as the top level. While there is much to be said for viewing the several USA domains (EDU, COM, GOV, MIL, ORG, CSNET, BITNET, MAILNET) within a US top level domain (probably to be viewed as one or more private management domains in X.400 terms) it is unlikely that this will happen in the near future. Since the presence of some hosts in the USA in one scheme and others in a different scheme would be especially confusing to users, perhaps the best that can be done is to avoid adding any additional differences that aren't already there. As such, the hybrid scheme is probably best. 3.3 Subdomain_Autonomy The major entities that want to manage themselves are organiza- tions. Most organizations would be satisfied to plug into the tree anywhere. The primary difference here is between fitting into existing top level domains and into a separate domain for UUCP. The former gives UUCP no autonomy, the latter gives it full autonomy. However, speaking as a representitive of the UUCP administration, there appears to be little or no advantage to such autonomy for UUCP. Individual organizations have always been free to act on their own, and some will not conform to UUCP recommendations anyway. It may be better for each organization to choose which domain they will connect into. 3.4 Avoiding_Extra_UUCP_Layers Organizations are generally set up to administer themselves as subdomains. There is no strong need for higher levels of UUCP administration to exist. Indeed, since the work is done entirely by volunteers, it is preferable to minimize the amount of work done by any UUCP administration. This means that structures that - 5 - fit into existing domains are better suited to minimizing UUCP bureaucracy. 4. Proposal In this proposal, I propose that the hybrid structure be used. It best meets all the goals except autonomy, which would be better met by a proposal with a separate UUCP domain. The advan- tages to the existence of this level of autonomy are unclear, however, and a good argument can be made that such advantages are insignificant. The specific proposal is that each portion of UUCP be free to link into the domain they choose. The project makes a recommen- dation and provides a registry service within the United States1. 4.1 Outside_the_United_States Outside the United States, each country has a top level domain, using the ISO two letter abbreviation for their country, as out- lined in RFC920. Organizations within these countries are urged to register in their country domain as appropriate locally. If a significant UUCP community exists in the country, that community can make choices similar to those outlined above. Basically the two choices are to have a 2nd level UUCP domain (or 3rd level, as appropriate) or an integration which makes the UUCP part invisi- ble in the address. In the latter case, some of the ideas described here can be used to set up an invisible administrative registry layer. 4.2 Within_the_United_States We view the United States as several countries, including US, EDU, COM, GOV, MIL, and others as created by ARPA and outside networks such as DEC and BITNET. (In this sense, top level domain and country are synonomous.) We fit all US UUCP hosts into one of three domains: EDU, COM, and GOV.2 Three parallel registries are created, one each for EDU, COM, and GOV. (It is possible that there will be no members in the GOV ________ 1. This distinction is being made based on an assumption that only organizations within the USA want such a registry service. If regions outside the USA are interested in such a service, please contact the project to see what can be worked out. 2. UUCP hosts that choose to fit into other domains are free to do so, but the UUCP project will assume they have connections other than UUCP and can provide their own registration with the appropriate domain. If there is interest in MIL, etc. UUCP registries, please contact the project. - 6 - registry, if this happens then only EDU and COM will be created.) This section uses COM as an example. Each registry will be, in effect, an extra layer in the administrative heirarchy. Thus, for administrative purposes, we have: COM (top level, administered by the NIC) ARPA (second level, administered by the NIC) BBN (third level, administered by BB&N) SRI (third level, administered by SRI) ... UUCP (second level, administered by the UUCP project) ATT (third level, administered by AT&T) HP (third level, adminstered by Hewlett Packard) TEK (third level, adminstered by Tektronix) ... The key here is that the second level above is an invisible layer which is not apparent to software, nameservers, or users. It is an entirely administrative layer. To software, domains BBN.COM and ATT.COM all appear the same. (Nameservers and routers will handle them differently, since not all functions are possible. For example, a nameserver will return an internet address for BBN.COM, but will return a forwarder for ATT.COM, since it can only be reached through a mail gateway.) This is implemented by administrative cooperation between the NIC and the UUCP project. The NIC does the same handling of its registry as always. The UUCP project serves as a central collec- tor of registration information for the UUCP portion of the domain. Current copies of this information are forwarded by the UUCP project to the NIC on a regular basis (perhaps monthly, biweekly, or as-updated.) These entries are added to the NIC registry and forwarded to the ARPA nameservers. At the same time, a copy of the ARPA part of the registry is picked up by UUCP and added to UUCP copies of the registry. This table is used for UUCP routing, since mail to all names on this list is forwarded to an ARPA Internet gateway. (There are alternatives which are possible here, such as a regular dump of a nameserver; updating the UUCP registry whenever there is an update made to the ARPA registry; or defaulting all unrecognized names in the COM domain to the ARPA gateway.) The UUCP project will act as an information gathering and distri- bution agent. Each organization in the UUCP administrative part of the COM domain must meet all the requirements of the ARPA COM domain. (Some reasonable interpretation of the nameserver requirement will have to be made, since these domains are not accessable from the ARPA Internet.) The UUCP project will collect both information required by UUCP (e.g. connection information) and information required by the NIC (e.g. the responsible persons and the recommended gateway.) Such organizations are responsible to both the NIC and to UUCP. Failure by the organization to meet either set of requirements may subject the organization to - 7 - removal from the registry. (For example, if the host becomes disconnected from UUCP and hence is unreachable, it may be dropped by UUCP. If the contact persons leave the organization and no replacements are designated, it may be dropped by the NIC.) Some organizations may have both UUCP and ARPA connections. Such organizations appear in both the ARPA and UUCP portions of the registry. From the ARPA Internet, the ARPA entry will override the UUCP entry, in that a direct entry with an internet address will override a forwarder record. From the UUCP net, the ability to reach the host via the gateway will have a high cost attached, so that the direct UUCP links will be favored instead. The UUCP organization will be restructured within North America. Canada will become a separate region, preferably self admin- istered. The USA will be subdivided into EDU, COM, GOV, etc. The largest parts (COM and EDU3) will be subdivided into reason- ably sized regions. The subdivision might be geographic, or it might be alphabetical, or some other method might be used. The maps would continue to be maintained and distributed as before. However, since each organization would have only one entry in the map (or possibly one per gateway) rather than one per machine, the map would become considerably smaller. (For example, ATT.COM becomes a single subdomain with only a dozen or so entries, rather than accounting for half the net as it currently does.) The rules for allowing organizations to register would be the same as currently in force for the NIC administered domains, with the additional requirement that the organization have one or more gateway hosts that are reachable via the UUCP ! syntax. It is expected that each organization would be allocated a single sub- domain. For large organizations, this means one subdomain for all machines, although multiple gateways are possible. For small organizations with only one or two machines, a single subdomain would also be allocated. There are currently no plans to regis- ter individual persons, rather, the intent is to register com- panies; educational institutions such as colleges, universities, and secondary schools; and branches of national, state, and city goverments. Hobbyists could band together to form users groups which could apply for domain status. Individual customers of commercial services, such as Compuserve, Telemail, and AT&T Mail, would register under domains created by their service carrier (probably under national X.400 domains.) ________ 3. A current inspection of the USA UUCP map suggests that roughly 400 organizations are in COM, 125 in EDU, 6 in GOV, 6 in MIL, and 4 privately owned home computers. These counts treat large organizations, such as AT&T, HP, and the University of California as single organizations. The do not subtract off organizations which may already be registered in COM or EDU through direct ARPANET connections. - 8 - 5. Considerations This proposal requires a strong degree of cooperation between the ARPA Network Information Center and the UUCP Project. As this is being written, the NIC has not decided how to handle requests for domain membership from outside the ARPA Internet. Clearly the intent of the EDU/COM/GOV system is to allow such cross- registration. For this to work, a decision must be made by the NIC to cooperate with the UUCP Project in this endeaver. This also assumes agreement by the UUCP community to this sort of structure, at least as a rule. There will no doubt be many hosts which choose to continue with the bang syntax, at least for a few years. Some hosts may choose to join domains which do not fit in with the overall structure. Assuming proper gateways are set up, it should be possible to accomodate alternative top level domains.