Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site hou3c.UUCP Path: utzoo!watmath!clyde!burl!hou3c!ka From: ka@hou3c.UUCP (Kenneth Almquist) Newsgroups: net.mail Subject: NameDroppers, 5/14/84 to 5/23/84 Message-ID: <588@hou3c.UUCP> Date: Thu, 24-May-84 13:10:50 EDT Article-I.D.: hou3c.588 Posted: Thu May 24 13:10:50 1984 Date-Received: Wed, 30-May-84 08:46:06 EDT Organization: Bell Labs, Holmdel, NJ Lines: 869 This is the ARPANET domain names discussion, reproduced here because a gateway has not yet been established. The last four messages deal explicitly with the UUCP domain. -------------------------------------------------------------------- Date: Mon, 14 May 84 09:53 EDT From: "Benson I. Margulies" Subject: Domain Names To: namedroppers@SRI-NIC.ARPA I think that an important characteristic of the Domain system is somehow overlooked here. I thought that any mail agent worthy of the name would use caches and server requests to avoid, in the vast majority of cases, the need to type the fully qualified name. In fact, if I were faced with the proposal as written, I would make it my local mailsystem's business go and make a map of all the interesting (to people on my host) names, thus producing the illusion of a flat (or semi-flat) name space. I think that like the X.400 folks, we could benefit from some work defining what those agents might be like. It is clear that you should only have to type d.osg.cbo.btt.att.cor ONCE, and after that its cbosgd (except for conflicts). No naming system is ever going to be both a) ABSOLUTE b) easy to use there are just too many names out there, and the qualification needed to specify is large. A smart agent, (an "expert"), though, armed with the domain servers and a good deal of local storage, can make this look reasonable. --------------------------------- Date: Mon, 14 May 84 16:46:08 edt From: cbosgd!mark (Mark Horton) To: Margulies@CISL-SERVICE-MULTICS.ARPA, namedroppers@SRI-NIC.ARPA Subject: Re: Domain Names I thought that any mail agent worthy of the name would use caches and server requests to avoid, in the vast majority of cases, the need to type the fully qualified name. Well, you can't assume this. There are lots of people out in the world building personal computers and dumb nodes that figure "I don't have to know anything, I'll just pass it upstream to my smarter neighbor". Unless the standards explicitly state a minimum amount of intelligence required by all agents (or by all above a certain point in the tree) somebody is going to build dumb ones. In fact, if I were faced with the proposal as written, I would make it my local mailsystem's business go and make a map of all the interesting (to people on my host) names, thus producing the illusion of a flat (or semi-flat) name space. I think that like the X.400 folks, we could benefit from some work defining what those agents might be like. It is clear that you should only have to type d.osg.cbo.btt.att.cor ONCE, and after that its cbosgd (except for conflicts). The problem here is that cbosgd may work locally, but if it creeps into the headers and goes out, nobody else will know what to do with it. Given the nature of user interfaces and transfer agents, this isn't easy to handle without more header munging than anyone wants to do. No naming system is ever going to be both a) ABSOLUTE b) easy to use there are just too many names out there, and the qualification needed to specify is large. Hmm, seems to me the US Postal Service meets both these requirements. The difference is that people sending paper mail are used to typing a 3 or 4 line address, and we electronic mail people are used to typing a 15 character address and we've gotten lazy. Someone who is used to paper mail and has never used a computer before probably will think that d.osg.cb.btl.att.cor is very convenient, since he's used to the 4 line paper address or a phone number consisting of a string of 10 digits that are impossible to memorize. A smart agent, (an "expert"), though, armed with the domain servers and a good deal of local storage, can make this look reasonable. The smart agent must also have a high performance network (like an Internet) to access the name servers. If you have to use phone lines with delays potentially of days, it's a whole different ball game. You know, one thing that would help us tremendously would be a simple way to tell for sure if an address is legal or a typo, without having to consult a name server. It could use local files, assuming the files don't have to be updated more often than every few months. One way to do this would be as follows: Any domain with no dots in it is assumed to be either (1) in the local domain (this means you get a legal address by appending the string LOCALDOMAIN to it, where LOCALDOMAIN is an almost never changed configuration parameter, like ".ATT.UUCP"), (2) a local alias, which means that you can look it up in a table in a disk file and replace it with a fully qualified domain name, or (3) a top level domain (I can picture an address like Mark.Horton@ATT being a fully qualified address if ATT does become a top level domain). In the former case, some program is going to have to append LOCALDOMAIN to the headers before it goes out. So the checker would first check for a top level domain on the right (from a known, static list of legal top level domains), and if the given address is not on the list, and it has no dots in it, first check for a list of local aliases, and if that fails, append LOCALDOMAIN and try again. The key to this working is that the number of top level domains has to be small and static enough that people can have a disk file listing them that is a few months out of date and still get very few rejections of valid mail. Mark Horton --------------------------------- Date: Mon, 14 May 84 10:02 EDT From: "Benson I. Margulies" Subject: Proposed top level names To: namedroppers@SRI-NIC.ARPA I think that some wires are crossed here. It seems to me that all of these top-level names are really just ARPA, or sometimes DDN, with an admixture of PUBLIC. There is no such administrative entity as CORPORATE. Who runs it, the US Chamber of Commerce? If the NIC, as administrator for DDN/ARPA wishes to organize the hosts for which it assign names, that is fine. But NIC is still doing the administering. THis suggests a much shorter list of initial domains: ARPA (under the grandparent clause) NIC all hosts assigned names via the NIC DDN (if any) all hosts assigned names under the authority of the DDN (assuming an administrative entity other than the NIC) Now, the question is, should there be NIC.EDU, NIC.COR, etc? I sort of doubt it. the NIC is still the server, here. Administratively, there are clearly different categories of hosts to which the NIC hands out names. Can anyone argue that we gain anything by making the names reflect? --benson --------------------------------- Date: 14 May 84 11:39:11 EDT (Mon) From: Liudvikas Bukys Subject: 100 hosts To: NAMEDROPPERS@SRI-NIC.ARPA I am uncomfortable with the 100-host minimum for the establishment of a second-level domain. Prospective domains with less than 100 hosts will be forced to accept something they don't want (many hosts in someone else's domain) until the big day when they can have what they want (domain names), but at the enormous expense of change of address for every resource (e.g., mailbox) on 100 hosts. Of course, it is painful to contemplate the large number of domain servers which would need to interact if the threshold was only 1. --> As a compromise, I suggest that there be two thresholds: 100-host minimum for running domain name servers; 1-host minimum for having a domain. Small-to-medium organizations will have to find somebody else to provide their domain name service. <-- This will help ensure that all the domain name server providers are big enough to really care. It will prevent cataclysms as 50-host organizations grow to 200-host organizations. It will prevent the "register every IBM PC and Apple Macintosh to get around the rules" syndrome. hoping that "ur-seneca.arpa" will become "seneca.rochester.arpa".... Liudvikas Bukys bukys@rochester.arpa P.S. 12 characters is a fine discouragement to silliness. --------------------------------- Date: Mon 14 May 84 10:13:50-PDT From: Peter Karp Subject: "What's all this talk about Romaine servers?" To: namedroppers@SRI-NIC.ARPA Cc: KARP@SUMEX-AIM.ARPA It almost seems like Emily Litella could help us make sense out of all of this... Seriously though: 1) A 100 host minimum for establishing second-level domains does seem a bit high assuming (a) we would want most universities, corporations, and other agencies to be named at the second level, and (b) by "host" we mean something more than a PC, and hence most of the above institutions do not have anything like 100 of them. 2) Initially the EDU, COR, etc domains do not seem like a bad idea. The real question is: are we going to take advantage of the ability of CNAME RRs to let us define reasonable aliases? E.G., even if IBM.CSNET and STANFORD.ARPA are the official names, is it reasonable to define IBM.COR and STANFORD.EDU as aliases? This question seems worthwhile to ask since (a) the recent discussion seems to ignore this feature of the naming scheme, and (b) the way the specification reads suggests that these aliases are only meant to serve as host nicknames within one subdomain, as opposed to defining aliases in subtrees of the name space which are quite seperate from each other. 3) Finally, consider that it might even be simpler to drop the ARPA top-level domain to begin with. After all, what entity in ARPA does not belong in one of COR, PUB, EDU, GOV ? Obviously this may be politically unacceptable. Peter ------- --------------------------------- Date: 14 May 84 13:31:24 EDT From: Charles Hedrick Subject: Re: 100 hosts To: bukys@ROCHESTER.ARPA Cc: NAMEDROPPERS@SRI-NIC.ARPA In-Reply-To: Message from "Liudvikas Bukys " of 14 May 84 11:39:11 EDT I strongly support Bukys's proposal to enforce limits only on the size of domain servers, but not on domains themselves. I believe his arguments are so self-evidently correct that there is no point in my saying any more on that subject. However I am not yet satisfied with the discussion involving the number of levels. Everyone seems to agree that no user will actually want to type foo.rutgers.csnet.edu. Several people have said that caching will solve that problem. But only if we can be fairly sure that RUTGERS is unique. At the very least we seem to need a rule that says that an organization's name should be unique within the network community that is likely to want to talk to it. This may involve more than one domain. (E.g. it seems clear that we should not have two different organizations with the same name in ARPA and DDN.) Next, we seem to need to make it explicit that the same organization can be a member of two different domains. There are two reasons for this: - some current domains are based on network structure, not organizational lines. Apparently ARPA and DDN are not going to go away (probably they should). Certainly UUCP is not going to go away. It is clear that the same organization may be part of ARPA, EDU, and UUCP. - even if we change the domain names, there are likely to be ambiguities as to where a given organization should be put. Since the purpose of computers is to serve people, we should opt for the design that makes it easiest for our users: namely letting them find the organization everywhere that it fits. This will mean that its name will have to be unique in all of those domains, but that is a good thing anyway. If these changes were made, I could probably live with the current set of proposed domains. The advantage of the domains like EDU is that they are based on obvious characteristics of the organizations, and so it is fairly easy to tell in advance that a given organization should be part of EDU or GOV, etc. (though one would need a rule about where to put State universities). ARPA, DDN, CSNET, and UUCP then become conveniences. I would be inclined to call them "secondary domains". They would contain duplicate listings of organizations that are likely to be interesting to their particular network, but which are also listed in EDU, etc. You might also consider specifying a canonical illegal top-level domain, for use by isolated systems, in case some of their mail ever finds it into the internet. E.g. LOCAL. Any scheme that is adopted must allow for the UUCP domain. It will not go away. At the moment we are hiding the inadequacies of the current RFC's behind %'s. You know: foo%bar.uucp@berkeley.arpa. Or something equivalent. There is a limit to how long this is going to be possible. Our system must be able to tolerate creation of new secondary domains by hackers. ------- --------------------------------- Date: Mon, 14 May 84 11:48:35 PDT From: Rich Wales To: namedroppers@SRI-NIC.ARPA Subject: Re: 100-host minimum on name servers? I thought that one of the (medium- to long-term) goals of the domain system was to allow servers to keep information all the way down to the mailbox-name (user-name) level if they wanted to. (See "Domain Support for Mail", on pages 52-55 of RFC833.) It seems clear to me that the only reasonable way for an organization to put mailbox-name info into the domain data base -- and keep said info up to date -- is for that organization to run its own name server. This data can change far too rapidly for a remote-storage scheme to be truly satisfactory. This would seem to conflict with the view that an organization needs a certain (fairly large) minimum number of hosts in order to run a name server. Am I missing some important point here? -- Rich --------------------------------- From: Larry Peterson Date: 14 May 1984 1600-EST (Monday) To: Rich Wales Cc: namedroppers@SRI-NIC.ARPA Subject: Re: 100-host minimum on name servers? In-Reply-To: Your message of Mon, 14 May 84 11:48:35 PDT. I believe it is a mistake to do "mailbox binding" with domain names. Mailbox addresses of the form user@domain should imply that the 'domain' part allows the mail system to locate a "mail server" to deliver a message to the mailbox object identified by the 'user' part of the address. Being able to name "mail forwarding machines" in addition to "regular old hosts" is a good idea, but taking that one step further to mailbox binding means that we are supporting a logically centralized nameserver that is merely physically distributed, rather than having a logically distributed system --> the way mail is now viewed. The tasks of locating a server to do something for us (e.g. deliver a message), and having that server do its job based on an identifier that IT is able to understand ('user'), should not be merged. The discussion to this point suggests that such a merger will only cause problems, and I don't see a single functional advantage to be gained --> the local mailer can do all the same things withoug being restricted to the domain name style. In addition, there are other questions of efficiency that could be raised. Centralized nameservers like "Clearinghouse" serve a useful purpose in environments where the authority is already centralized, (a local distributed operating system perhaps.) Computer mail is not such an environment. Larry Peterson --------------------------------- Date: Mon, 14 May 84 16:01:48 cdt From: jsq@ut-sally.ARPA (John Quarterman) To: namedroppers@sri-nic.ARPA Subject: Re: 100-host minimum on name servers? Here at U. Texas, we could easily arrange to have two gateways to the Internet running separate nameservers, and we already have an informal UTEXAS domain as far as mail, at least, yet we have nowhere near 100 hosts. Many other schools are probably in a similar position. I suspect no single fixed limit like a specific number of hosts will be adequate to decide who should have a domain or what domains should have their own nameservers. Shouldn't the capability to run a nameserver, for instance, enter in? It's not clear to me how limiting a host to having only one completely qualified domain name can be conducive to making the domain naming scheme easy to use. UTEXAS is affiliated with all of ARPA, CSNET, and UUCP; why should we have to pick just one, especially when the nameserver mechanisms already specified appear to be capable of handling multiple names. If we were to have to choose only one domain to be a subdomain of, and we chose ARPA (or EDU, or whatever), would the CSNET nameservers really be expected to either list us only as UTEXAS.ARPA or not at all? --------------------------------- Date: Mon, 14 May 84 19:58:19 edt From: watmath!bstempleton (Brad Templeton) To: namedroppers@sri-nic.ARPA Subject: subdomain sizes Surely limits (like 100) should ONLY apply to top level domains. Otherwise anybody who wants to be a subdomain should be one. After all, A host is a subdomain. Even mark's "d.osg.cb" is not so bad. It's only two characters more than cbosgd and much more clear in meaning. Especially when there are machines "a.osg.cb" etc. In fact, I would suggest that any organization with more than ONE machine be encouraged to make a subdomain. After all, what's better? watmath, wateng, watcgl .... (as we have now) or math.wat, eng.wat, cgl.wat .... (as we should have) or even math.waterloo, eng.waterloo These are much clearer, and they let local users refer to their local machines as just "math" and "eng" etc. provided the local name server is a good one. I think this is exactly what we want. --------------------------------- Date: 15 May 1984 23:40-EDT From: Robert Elton Maas Subject: Domain requirements / must country be toplevel domain? To: namedroppers@SRI-NIC In-reply-to:ESTEFFERUD@USC-ECL I don't see any reason why several countries can't get together and form a consortium for the purpose of naming authority. For example, several small nations in a compact geographic area (Caribbean islands, or west African republics) might not be able to afford a toplevel naming authority in each nation and a nameserver, so might want to pool their resources. Or several nations allowing open trans-national data flow (USA & Canada & England for example) might establish a joint naming authority to allow multi-national companies in those countries to conduct internal business without regard to national borders and to allow names within the single company to avoid the pain of having to factor all names according to country of location (which would prohibit any subdomain such as a company-department from being in more than one country). Thus perhaps the default should be that each nation is granted a toplevel domain which it is solely responsible for, but consortiums of nations may merge their name domains into new consortium-toplevel domains if they all agree to it. --------------------------------- Date: Wed 16 May 84 09:58:40-PDT From: Peter Karp Subject: Implementation status and thoughts on server distribution To: namedroppers@SRI-NIC.ARPA Cc: KARP@SUMEX-AIM.ARPA I have a Unix implementation working on small databases. This afternoon I hope to get it to read in a significant part of the entire NIC database and start testing the servers robustness. I offer the following thoughts on the recent topic of how many sites should actually be running name servers. Consider that: (a) All sites will have to run some subset of the name server software anyway because they will need resolvers and a cache system. For my implementation this would essentially mean that they will run my entire system but simply without authoritative entries in the database. (b) Will it really be acceptable to various small organizations to have another larger organization running a name server for them? People tend to dislike relying on other people to provide essential services for them. System administrators might like to have tight control over their local host tables so they can experiment with different network configurations. And in general it seems unlikely that people will want to be in the situation where they are unable to talk to a new machine they've just installed because another organization has not enterred them in their name server which is authoritative for the first organizations hosts. Of course there are ways to hack around this, but my suggestion is that we look upon running a name server as being a bit less of a big deal, and that most sites will be running a significant subset of most name server software anyway. (After all if a site provides unreliable name service this should affect their local users as well). Peter ------- --------------------------------- Date: 16 May 84 14:36:25 EDT From: Charles Hedrick Subject: Re: Implementation status and thoughts on server distribution To: KARP@SUMEX-AIM.ARPA Cc: namedroppers@SRI-NIC.ARPA In-Reply-To: Message from "Peter Karp " of 16 May 84 12:58:40 EDT Yikes! You are certainly right. But let me try to point out some implications of your message that just struck me. They are so obvious that I am sure others must have thought about them. But this should still be said: It seems fairly clear that every site with a local area network will run a local name server. It is clearly impractical (and probably a violation of DCA guidelines) for our local hosts to send packets to NIC when they want to address another local host on our local area network. Given that situation, the protocol designers might want to think very carefully about the requirements necessary to run a domain server. While I have supported the idea that there should be a minimum size to have a domain server, I now see that such a requirement poses obvious dangers. Suppose I am in the position of being a small organization, so that I don't have an Arpanet-sanctioned domain server. Presumably NIC acts as my server, or I commission someone else to do it for me. However I still have my own domain server, which I use on my local area network. Unless I do something unusual, this server will also respond to packets coming in from the Arpanet. Here are the dangers: - there are now two different authoritative lists of my hosts: the one in the sanctioned Arpanet domain server, and the one in my local domain server. Anybody who thinks those two lists will always be the same is dreaming. - anyone who communicates with my site a significant amount will be very tempted to put a special entry in his database to cause him to access my "real" domain server, rather than the sanctioned one. This will happen the first time one of his users wants to talk to one of my hosts that is not yet listed by the sanctioned domain server. - even if this doesn't happen, local mail will be generated using the local name server. So it seems inevitable that there will be "skew" between the name servers, and that headers in messages on the Arpanet will be generated using both servers. If we are careful, we will attempt to update the sanctioned name server and the local name server at the same time, and this skew will be minimal. However the point of establishing size bounds on sanctioned name servers was because we were afraid that some sites would not be able to provide sufficient reliability. It seems that managing the coordination of two name servers under different management is in fact a more serious problem than just trying to keep my own reliable. ------- --------------------------------- Date: Wed, 16 May 84 15:25 EDT From: "Benson I. Margulies" Subject: What can we expect people to type? To: namedroppers@SRI-NIC.ARPA The most strilking difference between the Postal service and the domain names is ambiguity. There are 47 3/4 different valid ways to type any given postal address. Could it be that small, dumb, nodes are just not practical? The whole thrust of the Domain system is to deal with a name space that is big, decentralized, and volatile. To offer service as a user agent in such an environment you are going to have to communicate quickly, or risk being out of date. Perhaps we should make two seperate optimizations: one for people in the fast lane, and one for everyone else. I confes that I don't see what a dumb node is going to do except to demand that its users type a lot of characters, quite precisely. As for 12 characters: Sillyness, eh? Like R2D2? Forcing people so use procrustean techniques to stuff a real-world name into a computer name is a recipe for sillyness and confusion. --------------------------------- Date: Thursday, 17 May 1984 08:53-PDT To: namedroppers@SRI-NIC Subject: Re: Multiple names, short names, simplicity From: imagen!geof Postal-Address: IMAGEN, 2660 Marine Way, Mountain View, CA 94043 Sorry for the delay, I've been letting mail batch up for a week or so. I believe this message is still current, though. Title: A plea for simplicity Let us not lose sight of the original goals of domain names, which were very simple: some new way was needed of mapping host names to addresses, because the Internet was getting too big and the NIC overloaded. Domain names suggest a way to decentralize the administrative and day-to-day aspects of the NIC's HOST.TXT file. It has been suggested that they might do much more: .CA.westUS.US.NAmer.Whemi.Terra.InnerSol.Sol.Spiral2.MWay..... = .94043.... = .CompSci.ACMMember.... = ..male.human.... I don't see what this has to do with making the NIC's tables more manageable. I do see what the idea is (so don't try to convince me of it), and I like the idea, but I don't think that this is the forum or time for it to be worked out. There is an IFIP committee working on this, and they have good ideas. Let them worry about the semantics of names, while we figure out how to get an Internet address from a string (because that's what we need today). UUCP is not going to go away, but they aren't going to use RFCXXX name servers either. If standard relay machines exist, one could envision a top or lower level UUCP domain. I haven't heard anyone say there would never be such a thing. Obviously politics are involved. But the UUCP connections, such as they exist do not appear to be in jeapordy. The domain name scheme is based on globally unique names for hosts. Host managers are given more latitude in choosing the end part of this name, because the beginning part decreases the subset of the name space into which they must fit. Multiple paths are not really manageable: [1] you can't ask a host at an internet address what its name is because it doesn't necessarily know all its names (there is no clear administrative function for it to use to find them out). [2] when you choose a host name you have to make it as unique as possible, so that it can be added to many subdomains. you're not going to see something like UNIX.IMAGEN.COR, even if there is only one machine at imagen that fits the more specified description. And how does the host manager know when his name is unique enough? By making it be imagen-unix? The 12-character limit: it is silly, and limiting. It is also probably a good idea as an administrative technique for making domain names shorter. Look at Multics and Unix - the top level of the hierarchy is usually given as short a name as possible to limit the length of the entire path. I would prefer to see this limit more clearly stated as an administrative limit, rather than a technical limit on the length of all components of domain names, to avoid things like "char name[13]" in code. If a top level domain really has 1000 hosts in it, then there shouldn't be too many of them, and a short abbreviation shouldn't be too hard to remember. Example: Give me the USP abbrevs for California, Massachusetts, New York, and Texas. For Arkansas? well, it's a small table to look it up in. - Geof Cooper Imagen --------------------------------- From: Christopher A Kent Date: 18 May 1984 1516-EST (Friday) To: Charles Hedrick Cc: namedroppers@SRI-NIC.ARPA, KARP@SUMEX-AIM.ARPA Subject: Re: Domain servers for local nets In-Reply-To: Your message of 16 May 84 14:36:25 EDT. <8405161852.AA08446> By the same token, we have a number of hosts that are not registered with the NIC, though they have Arpa access. While our conversation has dealt largely with mail, we must also consider the other services that we use that require name to address translation, e.g. TELNET and FTP. I have always been under the impression that these services will also need to use the domain based naming to resolve host addresses, since there will no longer be centrally administered host tables. I certainly don't want to have to register my print/file/graphics servers with the NIC -- I don't want someone from MIT printing on my printer, just as I'm sure they don't want me printing on their Dover, besides the fact that this information is only of local interest, and presents nothing but overhead if someone outside the organization must maintain it. Yet local users need to be able to find out those addresses; hence I need my own server. Recent experiences with high delays in getting the NIC to do host table updates lead me to react strongly against something that takes local information out of my control. Cheers, chris ---------- --------------------------------- Date: Mon, 21 May 84 15:40 EDT From: Barry Margolin Subject: Aliases To: namedroppers@SRI-NIC.ARPA Thank you, Jon, for a very complete response to all the recent issues. I have only one bone to pick, regarding section 11 on Aliases. I feel that local names for systems are a bad idea. While names in headers and user interfaces can always be canonicalized, these are tno the only places where domain names exist. People often include host names in the text of messages. Users don't know which names are local nicknames, so they will tell someone across the country something like "my friend's address is jones@e" where "e" is a local alias. barmar --------------------------------- Date: Mon, 21 May 84 12:10:11 EDT From: John R Ellis Subject: re: comments on Domain Requirements To: namedroppers@SRI-NIC.ARPA In-Reply-To: POSTEL@USC-ISIF.ARPA, 20 May 1984 21:46:49 PDT 8) Second Level Domains 100 Hosts. ... We are open for suggestions for other criteria. A naive proposal: Why not allow any legitimate higher-educational institution as a second-level domain under EDU? The only requirements should be that the institution actually has access to the domain system (i.e. it has it's own computers) and that it has a responsible administrator. For exmaple: MIT.EDU YALE.EDU RUTGERS.EDU CMU.EDU This will put a reasonable limit on the number of subdomains under EDU. How many universities could possibly want to register in the next 5 years? A thousand? Two thousand? Given the generally unique names of universities, that seems entirely resonable. And the EDU domain will be fairly stable: universities don't change their names very often. Each institution will still be required to provide name service for its subdomain. The larger institutions (MIT, CMU) will probably run their own name servers. The smaller ones will have to find someone else willing to service their small domains. How does this not meet Postel's general requirments for subdomains? The disadvantage of any EDU requirement proposal based on domain size is that it will produce an artificial asymmetry in naming universities. Some will be second-level domains: MIT.EDU and some will be third-level: YALE.SMALL.EDU This asymmetry in addressing universities is just as bad as naming hosts by network or route. ------- --------------------------------- Date: Mon, 21 May 84 23:16:21 EDT From: Mike Muuss To: NameDroppers@sri-nic.ARPA Cc: Steve@BRL-TGR.ARPA, PHD@BRL-TGR.ARPA Subject: Offer: .UUCP Domain Server Benson Margulies writes: "An administration has to administer. For UUCP to be a domain, someone someplace has to be responsable for handing out reasonable names. Somehow, this all reminds me of Xerox and Ethernet Numbers. Won't anyone stand up and volunteer to be a UUCP name coordinator?" The U. S. Army Ballistic Research Laboratory will (when we get a domain server running) take on the task of being a UUCP name coordinator for the InterNet, and would be willing to keep appropriate entries for a .UUCP domain in the domain server. BRL will *not* actually forward any mail for a .UUCP domain, but we will gladly resolve names to addresses if some other site(s) will do the forwarding (I know who they are). There are several reasons we are willing to do this (in no particular order): 1) We have to do it already. Our mail system will already accept mail of the form and re-route it correctly. 2) Doing it with a domain server will give us a somewhat heavy loading for the domain server, so it will break early, and become reliable. 3) Being the Army's "lead lab" for computer research, it is consistent with our mission. (Actually forwarding all the UUCP traffic, on the other hand, is NOT). 4) BRL has a heavy committment to UNIX, and wishes to help bring the UNIX community into the network world (kicking and screaming, if necessary). 5) As DARPA's ADDCOMP program is taking the InterNet into the battlefield, it is important that Army elements have the opportunity to become well acquainted with this technology, rather than getting taken by surprise. BRL offers a testbed for such technology. I believe that we will be well qualified to operate such a domain, on all except the 100-count metric. (We go for moderate numbers of substantial hosts, rather than hordes of shrimps). (Of course, if we get to count all the UUCP hosts, we certainly made it!). *) We presently operate 2 InterNet gateways, in separate buildings, on separate power supplies. The primary gateway is in Room 100, as will be one of the domain servers. (Room 100 is a computer room in a bomb shelter, located in a restricted access area.) Our first 2 gateways share a single MILNET IMP as the only common point. *) We have in place a 56 Kbps microwave link to another part of our facility (20 miles away), where we will be installing another InterNet gateway. A MILNET IMP will also be located there, pushing the common point of failure back to C&P Telephone's DDS trunking. *) Being physically well located, our MILNET IMP is well trunked (currently 5 circuits operating). If somebody else (Berkeley, perhaps?) has a burning desire to operate the domain server for UUCP, they may do so with my gratitude. Best, -Mike Muuss Leader, Advanced Computer Systems Team U. S. Army BRL --------------------------------- Date: Wed, 23 May 84 02:20:26 edt From: cbosgd!mark (Mark Horton) To: mike@BRL-TGR.ARPA Subject: Re: Offer: .UUCP Domain Server Cc: ksh@Berkeley, namedroppers@sri-nic.ARPA We appreciate the offer for BRL to manage the UUCP domain. There is already an organization formed to administer this domain. It's called the UUCP Project, and it's being funded by Usenix. The administrative contact is Karen Summers-Horton, cbosgd!ksh@Berkeley.ARPA (actually ksh@cbosgd.UUCP). If BRL would like to join with us and help out, their cooperation would be very much appreciaated. Mark Horton --------------------------------- Date: Wed 23 May 84 11:46:14-PDT From: Peter Karp Subject: The UUCP domain To: namedroppers@SRI-NIC.ARPA Cc: KARP@SUMEX-AIM.ARPA I think it's great that we have volunteers to administer the UUCP domain, however it's not clear to me what information the UUCP domain will actually contain. a) Will it contain an A (address) RR for each host? For a UUCP host this would consist of a phone number. However, this would make little sense since (1) this information would be totally useless to a non-Unix host (2) this information would be largely useless to most Unix hosts because the phone number would probably be long distance. Also, presumably sites do not wish to give out the passwords of their UUCP directories (or is this in fact common practice?) b) Will it contain MF (mail forwarding) RRs? This would also make little sense since it takes more than one hop to reach a given UUCP site. But presumably the relay, being one hop closer to the site, would be able to figure out how to reach the site itself. So it would be conceivable to include a routing specification to each host. But in fact this also makes little sense since the route TO a given destination host depends on where the SOURCE host is. The point I am making is that to properly administer the UUCP world one must know the topology of the UUCP network. The domain name system is not designed to represent network topology. Thus unless the administrators plan to hack a representation of the topology of the UUCP netork into a domain server, or have some other clever idea about how to provide information about UUCP hosts, I'm confused about what their plans are. Peter ------- --------------------------------- From: (Mike O'Dell[x-csam]) mo@lbl-csam Date: 23 May 1984 1228-PDT (Wednesday) To: Peter Karp Cc: namedroppers@SRI-NIC.ARPA Subject: Re: The UUCP domain In-Reply-To: Your message of Wed 23 May 84 11:46:14-PDT. Nope, the name server will do what is required, ie, provide an Internet- palitable address for UUCP hosts to Internet clients. The address will probably be a forwarder since you cannot directly contact a UUCP host from a TCP host. How the UUCP domain in managed internally is not and should not be visible from the outside. Yours for less nosey software, -Mike