Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 8 Jul 88 19:42:01 EDT Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 8 Jul 88 18:52:39 EDT Date: Fri, 8 Jul 1988 12:48 EDT Message-ID: From: Rob Austein To: namecallers@MC.LCS.MIT.EDU, info-hosts@ai.AI.MIT.EDU Subject: machine readable subnet table in AI:SYSHST;HSTNET >: clarification I forgot a paragraph in the previous message. The naming authority for a given subnet should not be confused with some kind of limitation on the names of the hosts on that subnet; the naming authority field simply specifies which zone's nameservers have responsibility for providing the IN-ADDR data. Eg, there are a number of AI lab machines on subnet 18.26.0.0, but LCS is responsible for providing the IN-ADDR data for subnet 18.26.0.0. Think of "the naming authority for this subnet is FOO" as meaning "the nameservers that are authoritative for the FOO zone are also authoritative for the IN-ADDR data for this subnet".  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 8 Jul 88 19:39:33 EDT Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 8 Jul 88 18:52:34 EDT Date: Fri, 8 Jul 1988 12:41 EDT Message-ID: From: Rob Austein To: namecallers@MC.LCS.MIT.EDU, info-hosts@ai.AI.MIT.EDU Subject: machine readable subnet table in AI:SYSHST;HSTNET > I finally had sufficient motivation to design (with some help from Mike Patton) a machine readable syntax for the master MIT subnet table that lives on AI. I've placed a copy of the file in the usual place (AI: SYSHST; HSTNET >). Comments and corrections welcome. Please indicate whether your comments/corrections refer to the SYNTAX of the table or the DATA that is presently in the table; Mike and I are well aware that some of the data is horribly out of date. If the comments and the syntax are clear enough that you understand the table, please feel free (nay, encouraged) to update anything you know to be obsolete. If the syntax or comments are too opaque, please say so. The data I'm trying to distribute via this table is the following: 1) Subnet masks for all known MIT networks. 2) Which IP network (one at most) a given subnet is part of. 3) Which portion of MIT is the naming authority for a particular subnet (eg, LCS owns subnet 18.26.0.0); the notation is less general than the domain system itself, but seems sufficient for the way we allocate subnets and domains at MIT. 4) Whether or not this subnet is believed to be allocated properly (ie, whether there is a known conflict with this subnet because somebody didn't follow the rules). 5) A text string indicating physical location and/or a contact. Eventually I hope to have a program that will do some kind of automated consistancy checking of this table against both itself and the combined MIT host tables so that it can notify the appropriate people if somebody does something weird. The proximate cause of all this is that I need to automate the proceedure by which the LCS zone file constructor job figures out which subnets of net 18 LCS currently owns so that it can generate the right IN-ADDR zone files. --Rob  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 24 Nov 87 23:39:53 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 24 Nov 87 23:37:47 EST Date: Tue, 24 Nov 87 23:36:00 EST From: David Vinayak Wallace Subject: ai.mit.edu To: SRA@XX.LCS.MIT.EDU cc: NAMECALLERS@MC.LCS.MIT.EDU, CJL@REAGAN.AI.MIT.EDU In-reply-to: Msg of Tue 24 Nov 1987 18:45 EST from Rob Austein Message-ID: <291043.871124.GUMBY@AI.AI.MIT.EDU> Date: Tue, 24 Nov 1987 18:45 EST From: Rob Austein Date: Friday, 20 November 1987 11:45-EST From: Chris Lindblad Date: Fri, 20 Nov 87 10:25:23 EST From: David Vinayak Wallace Who put in the MX entry for AI.MIT.EDU? It says 1: Reagan.ai.mit.edu, 2: ai.ai.mit.edu. Reagan, at least, barfs when it gets mail for ai.mit.edu. I doubt AI will fare any better. B:>file-server>update-domain.lisp I commented out the code that adds the MX entries. AI.MIT.EDU should really be handled too, if the AI lab can designate a machine to be mail relay. I assume this would be AI.AI.MIT.EDU or Reagan.AI.MIT.EDU. If you guys can pick a machine and CJL can turn the MX stuff back on, I can handle making the HOSTS3 tables and the Lispm Namespace do the right thing (ie, I know what we did for LCS). The problem is that we don't have a machine on which everybody has an account (not to mention which has enough info to heuristicate things like David.Wallace@ai.mit.edu). DCP tells me that Symbolics doesn't support this yet, and the ITSs don't have the user community any more (not to mention the fact that COMSAT would have to be fixed to process mail for which it is not the "host.")  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 24 Nov 87 19:08:20 EST Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 24 Nov 87 18:51:48 EST Date: Tue, 24 Nov 1987 18:45 EST Message-ID: From: Rob Austein To: Chris Lindblad Cc: GUMBY@AI.AI.MIT.EDU, NAMECALLERS@MC.LCS.MIT.EDU Subject: ai.mit.edu In-reply-to: Msg of 20 Nov 1987 11:45-EST from Chris Lindblad Date: Friday, 20 November 1987 11:45-EST From: Chris Lindblad To: GUMBY@AI.AI.MIT.EDU cc: NAMECALLERS@MC.LCS.MIT.EDU Re: ai.mit.edu Date: Fri, 20 Nov 87 10:25:23 EST From: David Vinayak Wallace Who put in the MX entry for AI.MIT.EDU? It says 1: Reagan.ai.mit.edu, 2: ai.ai.mit.edu. Reagan, at least, barfs when it gets mail for ai.mit.edu. I doubt AI will fare any better. B:>file-server>update-domain.lisp I commented out the code that adds the MX entries. Gee, I thought the MX RRs that your code was adding were just fine. Someday I intend to do the same kind of thing for LCS. The only MX RRs that you might want to leave off for now would be ones for the name "AI.MIT.EDU" itself, the rest are fine. AI.MIT.EDU should really be handled too, if the AI lab can designate a machine to be mail relay. I assume this would be AI.AI.MIT.EDU or Reagan.AI.MIT.EDU. If you guys can pick a machine and CJL can turn the MX stuff back on, I can handle making the HOSTS3 tables and the Lispm Namespace do the right thing (ie, I know what we did for LCS).  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Nov 87 11:50:23 EST Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 20 Nov 87 11:50:18 EST Received: from OTIS.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 76130; Fri 20-Nov-87 11:45:35 EST Date: Fri, 20 Nov 87 11:45 EST From: Chris Lindblad Subject: ai.mit.edu To: GUMBY@AI.AI.MIT.EDU cc: NAMECALLERS@MC.LCS.MIT.EDU In-Reply-To: <288830.871120.GUMBY@AI.AI.MIT.EDU> Message-ID: <871120114535.2.CJL@OTIS.AI.MIT.EDU> Date: Fri, 20 Nov 87 10:25:23 EST From: David Vinayak Wallace Who put in the MX entry for AI.MIT.EDU? It says 1: Reagan.ai.mit.edu, 2: ai.ai.mit.edu. Reagan, at least, barfs when it gets mail for ai.mit.edu. I doubt AI will fare any better. B:>file-server>update-domain.lisp I commented out the code that adds the MX entries.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Nov 87 10:27:07 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 20 Nov 87 10:27:06 EST Date: Fri, 20 Nov 87 10:25:23 EST From: David Vinayak Wallace Subject: ai.mit.edu To: CJL@REAGAN.AI.MIT.EDU cc: NAMECALLERS@MC.LCS.MIT.EDU In-reply-to: Msg of Thu 19 Nov 87 19:02 EST from Chris Lindblad Message-ID: <288830.871120.GUMBY@AI.AI.MIT.EDU> Who put in the MX entry for AI.MIT.EDU? It says 1: Reagan.ai.mit.edu, 2: ai.ai.mit.edu. Reagan, at least, barfs when it gets mail for ai.mit.edu. I doubt AI will fare any better.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 3 Aug 87 09:38:52 EDT Received: from REAGAN.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 3 AUG 87 09:38:34 EDT Received: from OTIS.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 51303; Mon 3-Aug-87 09:36:42 EDT Date: Mon, 3 Aug 87 09:36 EDT From: Chris Lindblad Subject: Minor deficiences in MIT.EDU zone and children To: SRA@XX.LCS.MIT.EDU cc: Namecallers@MC.LCS.MIT.EDU In-Reply-To: Message-ID: <870803093640.7.CJL@OTIS.AI.MIT.EDU> Date: Sun, 2 Aug 1987 18:08 EDT From: Rob Austein ... We are missing the so-called network pointers. The following RRs should exist but don't: ... 52.128.IN-ADDR.ARPA. PTR KLUDGE.AI.MIT.EDU. ... This is now fixed.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 2 Aug 87 18:10:19 EDT Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 2 Aug 87 18:10:19 EDT Date: Sun, 2 Aug 1987 18:08 EDT Message-ID: From: Rob Austein To: Namecallers@MC.LCS.MIT.EDU Subject: Minor deficiences in MIT.EDU zone and children I happened to notice (or remember) the following minor bugs in the current setup: According to the NIC, one of the nameservers for MIT.EDU is MIT-STRAWB.ARPA. Shouldn't this be STRAWB.MIT.EDU? I seem to recall problems once before when the address for STRAWB.MIT.EDU changed but the address for MIT-STRAWB.ARPA didn't. We are missing the so-called network pointers. The following RRs should exist but don't: 18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU. 52.128.IN-ADDR.ARPA. PTR KLUDGE.AI.MIT.EDU. The main-campus-spine side addresses of some (most) of the spine gateways aren't in the domain system. I have a program that generates a list of gateways based on name and address comparisons, but it can't spot most of the spine gateways because they don't have all their addresses listed. --Rob  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 21 May 87 23:49:27 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 21 May 87 23:31:08 EDT Date: Thu, 21 May 87 23:31:28 EDT From: "Philip A. Prindeville" Subject: Re: Nameservice for foreign domain To: namecallers@MC.LCS.MIT.EDU Message-ID: <203844.870521.PAP4@AI.AI.MIT.EDU> Hi. I'm following up a message that Rob Austein Cc:'d to Namecallers. I haven't heard anything in response, though I'm not subscribed to this list (it seemed likely I would be an explicit recipient). The problem is that I need to find a back-up name server already on the Internet before I can register the Canadian domain (.CAN). None of the Canadian hosts can really be on the Internet until they have legitimate names (i.e. in a registered domain). This is a bootstrapping problem for us. Is there a nameserver out there that wouldn't mind handling a few more zones? Thanks for any info (and please respond to me directly), -Philip  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 6 May 87 22:56:50 EDT Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 6 May 87 22:54:08 EDT Date: Wed, 6 May 1987 22:50 EDT Message-ID: From: Rob Austein To: "Philip A. Prindeville" cc: Namecallers@MC.LCS.MIT.EDU Subject: Nameservice for foreign domain In-reply-to: Msg of 6 May 1987 22:22-EDT from "Philip A. Prindeville" Date: Wednesday, 6 May 1987 22:22-EDT From: "Philip A. Prindeville" I sent this message before, but to the wrong address I think. Here it is again. Date: Wed, 15 Apr 87 02:35:36 EDT From: "Philip A. Prindeville" To: SRA@AI.AI.MIT.EDU Subject: Nameservice for foreign domain I was wondering if it was plausible for MIT to provide a back-up name server for the Canadian domain (.CA). Please let me know if this is the case. No, it got lost in my BABYL file. You are asking two questions. To answer the question you actually asked, sure, anybody can provide backup service, no reason why MIT shouldn't. To answer the question you presumably meant to ask, I can't do it on XX or MILO at the moment; you'd have to ask somebody else running nameservers at MIT if you want to check further: Domain Contact Email address ------ --------------------- MIT.EDU netreq@Athena.MIT.EDU AI.MIT.EDU BUG-AI-DOMAIN@OZ.AI.MIT.EDU MEDIA.MIT.EDU jwang@ATRP.MEDIA.MIT.EDU NS.ATHENA.MIT.EDU dyer@Athena.MIT.EDU LL.MIT.EDU Glenn@XN.LL.MIT.EDU I doubt that the LL.MIT.EDU or MIT.EDU people will be able to help, but it doesn't hurt to ask, I guess. All of this information is of public record, pulled out of the SOA RRs in the domain system (except in the case of MIT.EDU, since I happen to know that nobody ever updates the SOA RR for that zone, gripe, kvetch), and is subject to change without notice. --Rob  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 8 Apr 87 17:11:06 EDT Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 8 Apr 87 16:54:16 EDT Date: Wed, 8 Apr 1987 16:48 EDT Message-ID: From: Rob Austein To: Mailer-Error-of-the-Day@MC.LCS.MIT.EDU, Namecallers@MC.LCS.MIT.EDU Subject: Maybe we need a Mailer-Error-of-Tomorow list? Date: Wednesday, 8 April 1987 12:24-EDT From: postel@bel.isi.edu (Jon Postel) To: namedroppers@sri-nic.arpa cc: taylor%cs.glasgow.ac.uk@cs.ucl.ac.uk Re: reservered names Posted-Date: Wed, 8 Apr 87 08:24:05 PST I reject the idea of dis-allowing as low level (leaf) names in the Domain name system words that happen to be top level names in some other name system. I am seriously considering naming my machine "UK.ISI.EDU". --jon.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 22 Jan 87 14:43:07 EST Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 22 Jan 87 14:36:27 EST Date: Thu, 22 Jan 1987 14:35 EST Message-ID: From: Rob Austein To: Namecallers@MC.LCS.MIT.EDU, MIT-IP-People@MC.LCS.MIT.EDU, Vax-Wizards@MILO.LCS.MIT.EDU, Postmaster@MC.LCS.MIT.EDU, Info-Hosts@AI.AI.MIT.EDU Subject: WARNING: Non-domain nicknames to be removed from NIC tables! I just received the following. Note that most of the unix machines currently in existance at MIT will be in violation of this directive; very few are cannonicalizing "sra@xx" to "sra@xx.lcs.mit.edu" in mail headers. ITS, TOPS-20, and Lispms should be ok; I don't know about status of other operating systems. Date: Thursday, 22 January 1987 12:35-EST From: DDN Reference To: MGT: ; cc: nic@SRI-NIC.ARPA Re: DDN MGT Bulletin # 32 ********************************************************************** DDN MGT Bulletin 32 DCA DDN Defense Communications System 22 Jan 87 Published by: DDN Network Info Center (NIC@SRI-NIC.ARPA) (800) 235-3155 DEFENSE DATA NETWORK MANAGEMENT BULLETIN The DDN MANAGEMENT BULLETIN is distributed online by the DDN Network Information Center under DCA contract as a means of communicating official policy, procedures and other information of concern to management personnel at DDN facilities. Back issues may be read through the TACNEWS server ("@n" command at the TAC) or may be obtained by FTP (or Kermit) from the SRI-NIC host [26.0.0.73 or 10.0.0.51] using login="anonymous" and password="guest". The pathname for bulletins is DDN-NEWS:DDN-MGT-BULLETIN-nn.TXT (where "nn" is the bulletin number). ********************************************************************** PHASE 1 OF THE DOMAIN NAME IMPLEMENTATION The DDN Network Information Center (NIC) is directed to remove all nondomain-style host names and nicknames from the Official DoD Host Table, NETINFO:HOSTS.TXT, by 31 March 1987. After that time, names which do not conform to domain-style naming conventions, i.e. do not have ".domain" extensions, will not be allowed in either the Official DoD Host Table or the domain name servers. Nicknames, or aliases, will not be permitted in either the servers or the Official Host Table unless authorized. Network mailers are required to use primary host names and to accept host names containing dots (.), as specified in the DDN mail protocols RFC 821 (MILSTD-1781) and RFC 822. If mailers are not now adhering to these protocol requirements, they may experience mail delivery problems when the nondomain-style names are discontinued. Users sending electronic mail should use primary host names in all mail destinations and sources. If nicknames are used, problems may arise in mail delivery. The NIC will notify Host Administrators as to which names or nicknames do not now conform. Host Administrators may change nonconforming data by the usual procedure via Network Change Requests (NCRs) and Network Change Directives (NCDs), if they wish, before the 31 March 1987 deadline. Host Administrators anticipating problems with this plan should notify DCA Code B652 (DCAB652@DDN1.ARPA), or via AUTODIN message, and the NIC Hostmaster (HOSTMASTER@SRI-NIC.ARPA) no later than 2 weeks prior to the scheduled cutover. In March of 1984, the DDN began the transition to domain-style names with the issuance of DDN Management Bulletin 22. In that bulletin, all hosts were required to change their primary host names to contain ".domain" extensions in accordance with RFC 897. At the same time, all of the old-style names (without the ".domain" extensions) were automatically declared to be nicknames in the Official Host Table, NETINFO:HOSTS.TXT. This use of old-style nicknames was allowed on an interim basis to make the transition to domain-style naming easier. Almost three years have passed, and this transition period must now come to a close. The transition to naming domains has progressed to the point where there are many domain name servers implemented and running. In order to maintain interoperability between hosts on the DDN using the host table and hosts using the domain name servers, all hosts must be able to recognize domain-style names. It is imperative that all transition names and nicknames be upgraded to domain-style names or be removed from NETINFO:HOSTS.TXT so that naming is consistent and so that all use of names adheres to the specification for domain names adopted in 1984.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 16 Jan 87 02:05:27 EST Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 16 Jan 87 01:59:59 EST Date: Fri, 16 Jan 1987 01:58 EST Message-ID: From: Rob Austein To: Ramin Zabih Cc: BUG-Mail@MC.LCS.MIT.EDU, JAR@AI.AI.MIT.EDU, ZVONA@AI.AI.MIT.EDU, BillW@SCORE.STANFORD.EDU, Namecallers@MC.LCS.MIT.EDU Subject: AI -> SUSHI mail, again. Date: Friday, 16 January 1987 01:34-EST From: Ramin Zabih I just talked to Bill Westfield, and it may be that AI-SUSHI mail is now working. SUSHI had a cache entry for the AI namespace that directed it to GUTENBERG, which seems to be bogus. I don't know where it came from, but it's gone now, so perhaps things will continue to work. Until last fall, there was no way to give bind special "out of band" data to use to bootstrap itself into knowledge of the database. So a lot of records got added to local machines' initial cache load files with godawful long timeouts (eg, 99999999 which is over three years). Since this was in the cache, anybody who asked bind for that those RRs (which tended to be things like SOA, NS, and A records for each zone) stood some chance of getting the RR with the three year timeout instead of the normal one from the zone load files. GUTENBERG was decommissioned a month or three ago. Bind has been fixed to do the same thing JEEVES does (it has a special list of bootstrap addresses). But there are a lot of old copies of bind around, and the damage has already been done. Keep in mind that the domain system is a distributed database. The only method for invalidating a RR is having the timeout expire. We still have 2.5 years to go before that happens. Short of shutting down EVERY nameserver on the net, AT THE SAME TIME, and flushing this RR if present, there is no way to get rid of the bugger before 1989. Remind you of the giant tapeworm at the end of Shockwave Rider? --Rob  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 12 JUL 86 13:01:00 EDT Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 12 Jul 86 05:22:55 EDT Date: Sat, 12 Jul 1986 05:20 EDT Message-ID: From: Rob Austein To: Info-Hosts@AI.AI.MIT.EDU, Namecallers@MC.LCS.MIT.EDU Subject: Name conflicts, table breakage, inconsistancies, version numbers First the short item. The HOSTS3 compiler has stopped working again (undoubtably somebody on the West Coast added another 200 SUN workstations to the NIC tables). I'll fix as soon as I decide what new class of machines to punt. Files in XX: will continue to be updated, but ones in XX: will freeze until this is fixed. Next. I happened to compare a dump of Jeff's MIT.EDU domain with the host tables on AI. I did a number of minor updates to the AI tables. I also discovered a few questionable items. It doesn't appear that the SOA version number is getting updated for the MIT.EDU domain or the non-delegated subnets. This potentially a serious problem, since it screws anybody who wants to do zone transfers. Is PARIS.MIT.EDU a VAX-11/750 or a VAX-11/785? Is PROMETHEUS.MIT.EDU running UNIX or DOS? Is ATRP.MIT.EDU a VAX-11/785 or a VAX-11/750? Is SAILOR.MIT.EDU a MASSCOMP or a SUN? None of this major, but it'd be nice if it were correct. There are some machines in the MIT.EDU domain with names of the form MIT-foo.MIT.EDU which are also listed in the AI tables (where they get names of the form foo.MIT.EDU): CEZANNE, DEGAS, EMS, GOLDILOCKS, TWEETY-PIE, XEVIOUS, ZAXXON. Not life or death but it'd be nice if we could agree. POLYHYMNIA was listed in both MIT.EDU and LCS.MIT.EDU. I flushed the copy in LCS.MIT.EDU since I have a hard time picturing LCS owning a machine in building 66. Everybody thinks they own the MIT TAC. The NIC calls it MIT-TAC.ARPA and refuses to change it. Jeff calls it TAC.MIT.EDU, I calls it TAC.LCS.MIT.EDU. Who cares. And lastly, we have two full fledged name conflicts: KOALA.MIT.EDU: Chaos 15435, Lispm, RLE (Speech Ethernet) IP 18.72.0.79, Vaxstation, Project Athena (E40) RENOIR.MIT.EDU: Chaos 15415, Lispm, RLE (Speech Ethernet) IP 18.72.0.108, Vaxstation, Project Athena (E40) I'm pretty sure the Lispms have seniority. Good thing they aren't choosing to talk IP this week. Watch this space for further cruft. --Rob  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 4 JUN 86 18:41:06 EDT Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 4 Jun 86 17:52:50 EDT Date: Wed, 4 Jun 1986 17:56 EDT Message-ID: From: Rob Austein To: tcp-ip@SRI-NIC.ARPA, namedroppers@SRI-NIC.ARPA, namecallers@MC.LCS.MIT.EDU Subject: Contact names, WKS RRs, redesigning known universe (This is going to TCP-IP because the discussion started there. Any followup should be conducted on NAMEDROPPERS, I think.) I'd like to (belatedly) second Joe Weening's suggestion that we use the domain system to supply a contact name service. If we were designing the Internet from scratch, I'd say to use Chaosnet style contact names, which are a big win. But we're not designing from scratch. Using the domain system would solve two distinct problems that have arisen lately. One is the contact-names problem under discussion on TCP-IP, the other is the inadaquacy of the current IN WKS RR format (see NAMEDROPPERS archives for details). Here's my proposed RR formats . IN SERV . CH SERV is the service name (contact name analog). Domain name is the name of the host supporting it. and are as in A RRs (note that is a 16 bit port number. Chaosnet doesn't need this, since chaosnet has contact names, but it would be nice to be able to have a WKS analog for Chaosnet. The address fields are there for the same reason as in the WKS RR; some host might offer different services on different network interfaces. I'm not convinced this is reasonable, but it was considered necessary in the original WKS format. We might want to add a field to the IN class format, same logic (the analog for Chaosnet would be another text string) Examples: SMTP.XX.LCS.MIT.EDU IN SERV 10.0.0.44 25 TFTP.XX.LCS.MIT.EDU IN SERV 10.0.0.44 69 FILE.XX.LCS.MIT.EDU CH SERV MIT.EDU 2420 TIME.XX.LCS.MIT.EDU CH SERV MIT.EDU 2420 or (with protocols ids) SMTP.XX.LCS.MIT.EDU IN SERV 10.0.0.44 6 25 TFTP.XX.LCS.MIT.EDU IN SERV 10.0.0.44 17 69 FILE.XX.LCS.MIT.EDU CH SERV MIT.EDU 2420 CHANNEL TIME.XX.LCS.MIT.EDU CH SERV MIT.EDU 2420 SIMPLE We might also want to put RRs for all the standard services (ie, the ones known to the protocol czar) in at the root node. This would be useful for people who want to code with a contact name approach, and shouldn't be too much overhead. Queries like {IN SERV *.XX.LCS.MIT.EDU} should work fine and give a series of RRs listing all funny IP protocols supported by XX. I think this proposal solves serveral problems without creating any new ones. It is not the optimal solution to the contact name problem, but it will work and uses existing technology. Comments? --Rob  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 15 MAY 86 14:48:44 EDT Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 15 May 86 14:45:43 EDT Date: Thu, 15 May 1986 14:44 EDT Message-ID: From: Rob Austein To: Robert Scott Lenoil Cc: namecallers@MC.LCS.MIT.EDU Subject: Athena's student center cluster In-reply-to: Msg of 14 May 1986 22:13-EDT from Robert Scott Lenoil Date: Wednesday, 14 May 1986 22:13-EDT From: Robert Scott Lenoil To: namecallers@MC.LCS.MIT.EDU Re: Athena's student center cluster I was just wondering why Athena's student center machines are in syshst;hstg instead of syshst;hstath. -Robert Because nobody at Athena has shown any sign of caring. Feel free to fix if you know which machines are which.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 14 MAY 86 22:15:30 EDT Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 14 MAY 86 22:12:38 EDT Date: Wed, 14 May 86 22:13:51 EDT From: Robert Scott Lenoil Subject: Athena's student center cluster To: namecallers@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].41110.860514.LENOIL> I was just wondering why Athena's student center machines are in syshst;hstg instead of syshst;hstath. -Robert  Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 27 Jan 86 18:02:04 EST Date: Mon, 27 Jan 1986 17:56 EST Message-ID: From: Rob Austein To: jis@BITSY.MIT.EDU (Jeffrey I. Schiller) Cc: namecallers@MC.LCS.MIT.EDU Subject: Ooops... I forgot to add LCS.MIT.EDU In-reply-to: Msg of 16 Jan 1986 23:20-EST from jis@BITSY.MIT.EDU (Jeffrey I. Schiller) Date: Thursday, 16 January 1986 23:20-EST From: jis@BITSY.MIT.EDU (Jeffrey I. Schiller) To: Rob Austein cc: namecallers@MC.LCS.MIT.EDU Re: Ooops... I forgot to add LCS.MIT.EDU I will get that next update (sometime tomorrow I would think). BITSY doesn't seem to know this one yet.  Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 19 Jan 86 23:55:28 EST Date: Sun, 19 Jan 1986 23:55 EST Message-ID: From: Rob Austein To: jis@BITSY.MIT.EDU cc: namecallers@MC.LCS.MIT.EDU Subject: MILO running ok now (mostly) BIND appears to object to empty zones (some of the LCS subnets don't currently have any names registered). There may also be a limit on the number of RRs it will store. In any case, I now have it running correctly for all the "essential" subnets: 18.2, 18.10, 18.26, 18.48. If anybody has any real problems that they think are caused by this lame fix, tell me. --Rob  Received: from BITSY.MIT.EDU by MC.LCS.MIT.EDU 16 Jan 86 23:20:47 EST Received: by BITSY.MIT.EDU (5.15/4.7) id AA04403; Thu, 16 Jan 86 23:20:42 EST Date: Thu, 16 Jan 86 23:20:42 EST From: jis@BITSY.MIT.EDU (Jeffrey I. Schiller) Message-Id: <8601170420.AA04403@BITSY.MIT.EDU> To: Rob Austein Cc: namecallers@MC.LCS.MIT.EDU In-Reply-To: Rob Austein's message of Wed, 15 Jan 1986 13:32 EST Subject: Ooops... I forgot to add LCS.MIT.EDU I will get that next update (sometime tomorrow I would think). -Jeff  Received: from BITSY.MIT.EDU by MC.LCS.MIT.EDU 16 Jan 86 23:20:03 EST Received: by BITSY.MIT.EDU (5.15/4.7) id AA04398; Thu, 16 Jan 86 23:19:56 EST Date: Thu, 16 Jan 86 23:19:56 EST From: jis@BITSY.MIT.EDU (Jeffrey I. Schiller) Message-Id: <8601170419.AA04398@BITSY.MIT.EDU> To: Rob Austein Cc: namecallers@MC.LCS.MIT.EDU In-Reply-To: Rob Austein's message of Wed, 15 Jan 1986 13:32 EST Subject: Re: Earth to Jeff, come in Jeff.... I have changing the databases for 18.IN-ADDR.ARPA to delegate to XX and MILO the subnets that you requested. I tested out "ns.boot.dont-install-yet" on MILO and it didn't work. I am too tired to figure out why. The nameserver apparently just exists after reading in some of you 18_XX.zone files. I brought up Milo's nameserver with the installed ns.boot file which doesn't attempt to load the LCS inverse zones. It is important that this either get fixed or else I should remove MILO from the delegation list. NOTE: I have removed all AI and LCS hostnames from the MIT.EDU domain. Now we will see who is still dependant on them... -Jeff  Date: Thu, 16 Jan 86 18:52:50 EST From: Rob Austein Subject: MC binary host table To: INFO-HOSTS@MC.LCS.MIT.EDU, NAMECALLERS@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].786028.860116.SRA> I turned off the code that was generating the names like MIT-foo.MIT.EDU and foo.MIT.EDU (for hosts that are in some other domain, ie, AI or LCS). This was necessary because COMSAT was completely out of address space and I needed the few K this freed up just to keep COMSAT running. This means that (1) host tables will be a little smaller, and that (2) it is possible that you will be unable to reply to hosts that are still using these names (nobody should be, but they still linger in some dark corners). If you need a table that has all this cruft, you can get the binary from XX:HOSTS3.BIN and the text form of HSTMIT from XX:HSTMIT.TXT. Sorry for the short (one might even say negative) notice, but this was an emergency fix. --Rob  Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 15 Jan 86 19:56:53 EST Date: Wed, 15 Jan 1986 15:37 EST Message-ID: From: Rob Austein To: jis@BITSY.MIT.EDU (Jeffrey I. Schiller) Cc: namecallers@MC.LCS.MIT.EDU Subject: Earth to Jeff, come in Jeff.... In-reply-to: Msg of 15 Jan 1986 15:32-EST from jis@BITSY.MIT.EDU (Jeffrey I. Schiller) Thanks. That union business sound interesting, wouldn't even have occured to me (the twenex server definitely will not do that). Worth playing with anyway. --Rob  Received: from BITSY.MIT.EDU by MC.LCS.MIT.EDU 15 Jan 86 15:32:26 EST Received: by BITSY.MIT.EDU (5.15/4.7) id AA02132; Wed, 15 Jan 86 15:32:13 EST Date: Wed, 15 Jan 86 15:32:13 EST From: jis@BITSY.MIT.EDU (Jeffrey I. Schiller) Message-Id: <8601152032.AA02132@BITSY.MIT.EDU> To: Rob Austein Cc: namecallers@MC.LCS.MIT.EDU In-Reply-To: Rob Austein's message of Wed, 15 Jan 1986 13:32 EST Subject: Re: Earth to Jeff, come in Jeff.... I will update the namespace tonight. Btw. I believe we can have two "primary" file entries in a boot file that load the same domain (in this case 18.in-addr.arpa) and the data will be unioned. We should check this out. -Jeff  Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 15 Jan 86 14:57:18 EST Date: Wed, 15 Jan 1986 13:32 EST Message-ID: From: Rob Austein To: jis@BITSY.MIT.EDU cc: namecallers@MC.LCS.MIT.EDU Subject: Earth to Jeff, come in Jeff.... Please add the following to your database and punt the appropriate other info: LCS.MIT.EDU. A 18.10.0.81 ;lcs mail drop (kirin) 2.18.IN-ADDR.ARPA. NS XX.LCS.MIT.EDU. ;tech sq 3mb ether NS MILO.LCS.MIT.EDU. 9.18.IN-ADDR.ARPA. NS XX.LCS.MIT.EDU. ;lcs ansync line net NS MILO.LCS.MIT.EDU. 10.18.IN-ADDR.ARPA. NS XX.LCS.MIT.EDU. ;lcs proteon ring NS MILO.LCS.MIT.EDU. 23.18.IN-ADDR.ARPA. NS XX.LCS.MIT.EDU. ;jnc test network A NS MILO.LCS.MIT.EDU. 24.18.IN-ADDR.ARPA. NS XX.LCS.MIT.EDU. ;jnc test network B NS MILO.LCS.MIT.EDU. 26.18.IN-ADDR.ARPA. NS XX.LCS.MIT.EDU. ;lcs 2nd-5th floor ether NS MILO.LCS.MIT.EDU. 45.18.IN-ADDR.ARPA. NS XX.LCS.MIT.EDU. ;yoyodyne subnet NS MILO.LCS.MIT.EDU. 46.18.IN-ADDR.ARPA. NS XX.LCS.MIT.EDU. ;yoyodyne serial link NS MILO.LCS.MIT.EDU. 48.18.IN-ADDR.ARPA. NS XX.LCS.MIT.EDU. ;lcs mef 2nd floor ether NS MILO.LCS.MIT.EDU. 49.18.IN-ADDR.ARPA. NS XX.LCS.MIT.EDU. ;lcs 4th floor ether NS MILO.LCS.MIT.EDU. 104.18.IN-ADDR.ARPA. NS XX.LCS.MIT.EDU. ;lcs cls/iris ether NS MILO.LCS.MIT.EDU. 105.18.IN-ADDR.ARPA. NS XX.LCS.MIT.EDU ;lcs apollo (fla) net NS MILO.LCS.MIT.EDU. XX is already advertising data for anybody who asks it about these subnets. MILO isn't since the combination of your namespace and my namespace with this included is an inconsistant state. --Rob  Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 13 Jan 86 13:20:31 EST Date: Mon, 13 Jan 1986 11:53 EST Message-ID: From: Rob Austein To: namecallers@MC.LCS.MIT.EDU Subject: makdom MF & MD support (for them as care) I just added code so that makdom will (1) generate MD entries for IP live hosts with the TCP/SMTP service, and (2) only generate chaos MF entries (if they are turned on via -c) if the chaos host supports either CHAOS/MAIL or CHAOS/SMTP. Source in XX:MAKDOM.C, as usual.  Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 10 Jan 86 02:30:02 EST Date: Fri 10 Jan 86 02:32:42-EST From: "J. Noel Chiappa" Subject: Re: Delegation of LCS subnets To: SRA@XX.LCS.MIT.EDU, jis@BITSY.MIT.EDU cc: Namecallers@MC.LCS.MIT.EDU, JNC@XX.LCS.MIT.EDU In-Reply-To: Message-ID: <12174049772.17.JNC@XX.LCS.MIT.EDU> Hey! I wasn't complaining, just pointing out what I thought was a purely technical point. -------  Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 9 Jan 86 16:15:16 EST Date: Thu, 9 Jan 1986 16:17 EST Message-ID: From: Rob Austein To: jis@BITSY.MIT.EDU cc: Namecallers@MC.LCS.MIT.EDU Subject: Delegation of LCS subnets Jeff, Well, nobody but Noel has screamed loudly and I am currently holding this gun to his head to keep him quiet, so it appears to be unanimous. Please delegate the subnets I listed before to XX and MILO, and I will stop bugging you (for now, anyway). I still have the list somewhere if you don't have it anymore. And while you are at it please add the entry for LCS.MIT.EDU with KIRIN's address. Thanks. --Rob  Received: from BORAX.LCS.MIT.EDU by MC.LCS.MIT.EDU 7 Jan 86 08:00:21 EST Received: by BORAX.LCS.MIT.EDU (4.12/4.7); Tue, 7 Jan 86 08:00:00 est Date: Tue, 7 Jan 86 08:00:00 est From: romkey@BORAX.LCS.MIT.EDU (John Romkey) Message-Id: <8601071300.AA05196@BORAX.LCS.MIT.EDU> To: JNC@XX.LCS.MIT.EDU Cc: jis@BITSY.MIT.EDU, SRA@XX.LCS.MIT.EDU, namecallers@MC.LCS.MIT.EDU, JNC@XX.LCS.MIT.EDU In-Reply-To: "J. Noel Chiappa"'s message of Tue 7 Jan 86 00:40:28-EST Subject: LCS portion of IN-ADDR domain SEWAGE isn't so bad. You could just name its 18.10 address SEWAGE.LCS.MIT.EDU and its spine address SEWAGE.ATHENA.MIT.EDU. I'm not sure this is a useful idea, though...but it is easier to figure out the names for the various interfaces on sewage in this case than it has been in few occasions in the past when we've given different names to different interfaces on a single gateway. - john  Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 7 Jan 86 01:15:10 EST Date: Tue, 7 Jan 1986 01:15 EST Message-ID: From: Rob Austein To: "J. Noel Chiappa" Cc: jis@BITSY.MIT.EDU, namecallers@MC.LCS.MIT.EDU Subject: LCS portion of IN-ADDR domain In-reply-to: Msg of 7 Jan 1986 00:40-EST from "J. Noel Chiappa" Well, yes, there is that problem. But I think we have already demonstrated that Jeff doesn't have the time to provide the kind of instant service we want over here, so we have to do something. It seems to me that it is not unreasonable to delegate authority for a subnet to the group that owns the physical wire. In cases where more than one group uses a particular wire, presumably the two groups get along reasonably well (they have to) and have some shared table of address assignments. In the case of gateways, it seems you really want CNAME entries, yes? Eg, you have an entry 7.0.10.18.IN-ADDR.ARPA. CNAME SEWAGE.ON.MAIN-CAMPUS.18.IN-ADDR.ARPA. That way I don't even have to know the name of the machine over here, and Jeff can call it whatever he wants. Granted, this entry has to be maintained by hand, but that isn't that hateful, since presumably as the address guru of subnet 10 I know about this gateway hanging off of my subnet. And there aren't *that* many gateways to worry about, nor do they change often. I'm still not completely sold on this idea, but it seems like the easiest one for both me and Jeff, so if you don't like it you'd better come up with something even easier. Now, assuming that we do actually go and delegate subnets, here is what I have been able to come up with for lcs owned subnets, looking at hstlcs and hstnet. If anybody has any corrections/additions, please holler. Otherwise I would like to have these subnets delegated to XX and MILO. 18.2.0.0 ;tech sq 3mb ether 18.9.0.0 ;lcs ansync line net 18.10.0.0 ;lcs proteon ring 18.23.0.0 ;jnc test network A 18.24.0.0 ;jnc test network B 18.26.0.0 ;lcs 2nd-5th floor ether 18.45.0.0 ;yoyodyne subnet 18.46.0.0 ;yoyodyne serial link 18.48.0.0 ;lcs mef 2nd floor ether 18.49.0.0 ;lcs 4th floor ether 18.104.0.0 ;lcs cls/iris ether 18.105.0.0 ;lcs apollo (fla) net Also, Jeff, please add an entry listing KIRIN as LCS.MIT.EDU. I was going to ask for a CNAME entry (LCS.MIT.EDU. CNAME KIRIN.LCS.MIT.EDU.) but that has been declared illegal (see the spec updates from Mockapetris in XX:DOMAIN.CHANGES if that isn't clear). So I think the thing to do is just put in the entry LCS.MIT.EDU. A 18.10.0.81 Please *don't* put in a corresponding IN-ADDR entry (whether we delegate subnets or not) since the primary name of the machine is still KIRIN.LCS.MIT.EDU. I would appreciate getting this one set up soon so that I can start playing around with mailbox data. --Rob  Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 7 Jan 86 00:39:41 EST Date: Tue 7 Jan 86 00:40:28-EST From: "J. Noel Chiappa" Subject: Re: LCS portion of IN-ADDR domain To: jis@BITSY.MIT.EDU, SRA@XX.LCS.MIT.EDU cc: namecallers@MC.LCS.MIT.EDU, JNC@XX.LCS.MIT.EDU Message-ID: <12173242908.28.JNC@XX.LCS.MIT.EDU> Jeff (and everyone), one potential problem with delegating is that domain boundaries may not match wire boundaries. Consider the host SEWAGE (the LCS/Main Campus gateway, which Jeff owns); by rights it ought to be SEWAGE.ATHENA.MIT or some such, since you own it, but it has an address on 18.10, which LCS owns. If you put it in some domain of yours, how are we supposed to find out about it for address stuff? Actually, the problem is worse that that, since it also has an address in 18.main_campus_ring, which you own! So no matter which domain you put it in, you lose. Perhaps you could maintain all of 18.IN-ADDR by querying all the subservers periodically to see if their serial number has incremented; if so, you suck all the info over and build a new 18.IN-ADDR automatically. Noel -------  Received: from BITSY.MIT.EDU by MC.LCS.MIT.EDU 6 Jan 86 22:46:05 EST Received: by BITSY.MIT.EDU (5.15/4.7) id AA01734; Mon, 6 Jan 86 22:47:47 EST Date: Mon, 6 Jan 86 22:47:47 EST From: jis@BITSY.MIT.EDU (Jeffrey I. Schiller) Message-Id: <8601070347.AA01734@BITSY.MIT.EDU> To: Rob Austein Cc: namecallers@MC.LCS.MIT.EDU In-Reply-To: Rob Austein's message of Monday, 6 January 1986 05:02 est Subject: Re: LCS portion of IN-ADDR domain I am still here... it is just that I haven't had time to refrob the programs that generate the inverse query domains. I can delegate to you those networks which are properly LCS's (ie. 18.10, 18.26 and any others that you tell me about). -Jeff  Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 6 Jan 86 05:00:17 EST Date: Mon, 6 Jan 1986 05:02 EST Message-ID: From: Rob Austein To: jis@ATHENA.MIT.EDU cc: namecallers@MC.LCS.MIT.EDU Subject: LCS portion of IN-ADDR domain Jeff, I still haven't heard boo from you on this. Your servers are still running with bogus names for LCS hosts. I set up a frob in my nightly batch job on XX so that a file XX:LCS.INADDR will be generated automaticly. All you have to do is copy it over periodicly (like when you are doing your massive ftp updates to all the nameservers) and use it instead of whatever outdated information you are using for our machines. Please do so. RSVP. --Rob  Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 5 Jan 86 12:34:43 EST Date: Sun, 5 Jan 1986 12:32 EST Message-ID: From: Rob Austein To: Chris Lindblad Cc: Alan Bawden , BUG-HOSTS3@MC.LCS.MIT.EDU, BUG-PEEK@MC.LCS.MIT.EDU, BUG-RANDOM-PROGRAM@MC.LCS.MIT.EDU, GUMBY@MC.LCS.MIT.EDU, namecallers@MC.LCS.MIT.EDU Subject: Ick! In-reply-to: Msg of 2 Jan 1986 14:33-EST from Chris Lindblad (Oh bleep, let's put this on namecallers and get it over with already). From: Chris Lindblad Alan points out that when generating the hosts3 table, you only have to be compatible with people who have been using the hosts3 table. Not quite. Eg, JIS has MIT-OA.MIT.EDU as the IN-ADDR translation for 18.10.0.79, so if anybody out there is still using the old cannonical name algorithm (name->address->name) they will think that is OA's primary name, thus will include it in mail headers, thus people using HOSTS3.BIN should be able to recognize it to avoid barfing on replies. This is probably not as much of a problem for AI as for LCS because of the relative numbers of TCP/IP machines. There are bugs in your algorithm anyway. You are taking the name MITAI and generating MIT-MITAI.ARPA, which was never in any domain. (The arpa domain only contained the primary names of hosts). Mea culpa. I really think it is silly to be genrating all these names. Just because JIS was lazy, and made names like mit-foo.mit.edu shouldn't be a reason for us to clutter our host tables with them. I suggest that as soon as possible, we eliminate references to the mit.edu domain. The longer they're there, the harder it will be to take them out, and there's no better time to make changes like this than during IAP. Agreed. I never intended that all that cruft be there permenantly, just for transition to try to keep the world from falling apart too badly too fast. IAP does seem like a good time to punt it. Over the next year, more than 100 hosts will be added to the host table. We better start making each entry more compact if we expect it to keep working. Alan says that we have only two pages left. Right, but the key point is that HOSTS3 isn't going to work much longer. One of two things will happen: (1) the NIC table will no longer be anything like exhaustive, in which case the table is incomplete, or (2) the NIC table will grow to the point where it is completely unusable. My guess is that we will end up with a HOSTS3.BIN that contains info for MIT, and Chaos-only machines will either have to grok domains or just start blindly sending mail to some forwarder if the address is unrecognized. Eventually HOSTS3 may become identical with HOST3C if/when chaos machines grok domains, but that's not for a while yet. For the AI host table. I would be happy if you didn't generate any names, and I specify all the names I want. Ok. Nag me if you don't hear about this in the next few days.  Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 23 Dec 85 16:47:44 EST Date: Mon 23 Dec 85 16:12-EST From: Rob Austein Subject: IN-ADDR stuff for LCS To: jis@BITSY.MIT.EDU CC: namecallers@MC.LCS.MIT.EDU Jeff, Now that we have been running as LCS.MIT.EDU for a week with no problems (worth mentioning, anyway), could you please update your information for 18.in-addr.arpa to point at the new names? I have asked the NIC to update their info for 10.in-addr.arpa (ie, MC, GW, XX, TSTGW, AI); they promise to do it as soon as the hostmaster gets back from vacation. This will be particularly important once I get around to fixing bind to use in-addr instead of iquery, sometime in early January probably. But XX is already using in-addr, and it really would be nice if I could believe the information that my code is retrieving.... Thanks. --Rob  Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 18 Dec 85 07:16:06 EST Date: Wed, 18 Dec 1985 07:14 EST Message-ID: From: Rob Austein To: info-hosts@MC.LCS.MIT.EDU, namecallers@MC.LCS.MIT.EDU cc: sra@XX.LCS.MIT.EDU Subject: New host tables installed on MC. The new tables that have been running on XX on an experimental basis have now been installed on MC and AI. A few things to note: At CSTACY's request, the tables no longer live in MC: SYSNET; because the directory got too crowded. All the text files have been moved to MC: SYSHST;. The old versions of the host tables are still present in SYSNET; on the off chance that we have to back out of this, but they will be going away soon. The binary host table of course is still in SYSBIN;. There is a little bit of documentation in some of the files in SYSHST; ask me if you need help, I would much rather have to answer a lot of silly questions than have to pick up the pieces if somebody breaks all this. For those who deleted my last warning on this subject, the new host table is significantly larger than the old one. Some programs on your machine will probably barf and need to be recompiled. Sorry. Problems, flames, etc to me and NAMECALLERS. --Rob  Received: from BORAX by MIT-MC.ARPA 6 Dec 85 18:10:51 EST Received: by BORAX.MIT.EDU (4.12/4.7) id AA11328; Fri, 6 Dec 85 18:07:52 est Date: Fri, 6 Dec 85 18:07:52 est From: romkey@BORAX.MIT.EDU (John Romkey) Message-Id: <8512062307.AA11328@BORAX.MIT.EDU> To: SRA@MIT-XX.ARPA Cc: Namecallers@MIT-MC.ARPA In-Reply-To: Rob Austein's message of Thu, 5 Dec 1985 06:57 EST Subject: Host number assignment. Date: Thu, 5 Dec 1985 06:57 EST From: Rob Austein SUBNET : : : ; eg SUBNET : 18.10.0.0 : LCS.MIT.EDU : ;LCS Proteon Ringnet Add one more thing: a contact or owning name for that subnet. Treat it as a comment, but don't put it in the comment field or people will ignore it. - john  Date: Thu, 5 Dec 85 12:59:41 EST From: "J. Noel Chiappa" Subject: Automatic generation of tables To: NAMECALLERS@MIT-MC.ARPA cc: JNC@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].742896.851205.JNC> There's only one bug with this idea, and I found it last night by looking through the table that Shawn currently maintains by hand. There are LOTS of hosts that are in his list, as well as reservations of address ranges for various things which aren't in the host table. He also keeps info on where the machine is (phsyically) as well as who is responsible for it, all very useful info for tracking down net problems. Now, maybe you could fix the former by a massive registration drive, but what about the latter two? I've currently got a hand-produced table that is the union of his hand-maintained table and the stuff in HSTMIT >; I don't know whether installing it is the right thing or not, though. A automatically maintained table would be nice, I admit. The one for the LCS Ether is in JNC;ETH ADDR. Noel  Received: from MIT-XX.ARPA by MIT-MC.ARPA 5 Dec 85 06:58:48 EST Date: Thu, 5 Dec 1985 06:57 EST Message-ID: From: Rob Austein To: Namecallers@MIT-MC.ARPA Subject: Host number assignment. In-reply-to: Msg of 5 Dec 1985 04:28-EST from John Wroclawski You want me to generate the host-by-address lists? Since I am already ftping and reading and parsing every known host table in the entire known universe and at least a dozen output files already, what's another form of output? Just more TECO code or C code or whatever.... I've already got the parser in either case, doing the output is no big deal. I'll have to code in an understanding of the IP <=> Chaos address mapping, but this is presumably static. IN 18.x.0.y maps to UN 7.0.x.y, right? I agree that we eventually need to delegate subnets, my crock is only intended to work while all the tables still live on MC. I like the idea of putting all the delegations into HSTNET; that is more workable than my earlier proposal. There is this one lose though, in that we don't have the DOMAIN: data in the same file anymore, so we either have to duplicate it (bad idea) or kludge around it. So here's a proposed kludge: SUBNET : : : ; eg SUBNET : 18.10.0.0 : LCS.MIT.EDU : ;LCS Proteon Ringnet This is the minimal information with no redundancies. The SOA and NS data are copied from the SOA and NS RRs for the owning domain (work it out, you will see that the right people already have those RRs anyway, although inserting them in all the right places will be a bit of a pain). Since this is a file that will be shared by paranoid people and lassez-faire types (as well as twits, unfortunately), we probably want to specify that if a owning domain isn't recognized it isn't delegated. A null field indicates that the subnet hasn't been allocated at all. --Rob  Received: from MIT-SPEECH by MIT-MC.ARPA via Chaosnet; 5 DEC 85 04:29:38 EST Date: Thu 5 Dec 85 04:28:34-EST From: John Wroclawski Subject: Re: Host number assignment. To: SRA@MIT-XX.ARPA, jis@MIT-BITSY.ARPA cc: Namecallers@MIT-MC.ARPA In-Reply-To: Message from "Rob Austein " of Thu 5 Dec 85 01:41:07-EST Campers, this discussion has diverged. Y'all recall it was started by JNC bringing up the question of keeping better track of host number assignments on a subnet, to make it easier to find new ones and keep numbers consistant across protocols. Problem is getting randoms to keep these list files up to date for non-centrally administered subnets. This suggests keeping the list up to date by generating it as an additional output from whatever you use to convert your host table/namespace/whatever into a domain database file, instead of by hand. Ordered by subnet, then host number within the subnet, I guess. Might also be nice if it pointed out inter-protocol number mismatches. About IN-ADDR.ARPA - Rob's solution may work in the short term, but only if all the subdomains arrange to automatically update their HSTxxx files on MC. But, I don't really think it's reasonable to ask Jeff to build his in-addr database from a central point like that, for the same reasons we decided it wasn't reasonable to keep all the hosts centrally in the first place. To avoid this, we have to delegate. Perhaps we could solve the IN-ADDR and subnet assignment problems at the same time by combining Jeff and Rob's thinking and keeping a HSTNET > file on MC which contains machine-readable delegation information and such-like, and have the 18.IN-ADDR.ARPA servers use that file as the source for delegation information. -john -------  Received: from MIT-XX.ARPA by MIT-MC.ARPA 5 Dec 85 01:35:59 EST Date: Thu, 5 Dec 1985 01:34 EST Message-ID: From: Rob Austein To: jis@MIT-BITSY.ARPA (Jeffrey I. Schiller) Cc: Namecallers@MIT-MC.ARPA Subject: Host number assignment. In-reply-to: Msg of 5 Dec 1985 00:09-EST from jis@BITSY.MIT.EDU (Jeffrey I. Schiller) Oh, you were talking just about hosts. Sorry. So long as the tables all live on MC (or at least have copies on MC), fine, you can be the authority for 18.in-addr.arpa, so long as you are generating the right names. This is extremely important, since it does me no good to be maintaining correct data for OA.LCS.MIT.EDU when you are telling people that 79.0.10.18.IN-ADDR.ARPA is MIT-OA.MIT.EDU. I've been (reasonably) quiet about this because I know what a pain it is to do this right without the split up host tables. Well, the host tables on MC are now split up, and have DOMAIN: keywords in them, and I have this C program that will generate the right thing. If you do cat hstlcs hstai hstath hstee hstg | makdom -dip >18.in-addr.zone you will get a good 18.in-addr.arpa file (now you know why I wanted to keep using stdin and stdout for this). The source code is in xx:makdom.c. You will probably need a new filter anyway when you start using these tables, so you may as well use this one. If there start to be problems with the in-addr data getting out of sync with the MC tables I may ask for delegation of the LCS subnets again, but so long as you keep up to date this shouldn't be necessary. --Rob  Received: from BITSY.MIT.EDU by MIT-MC.ARPA 5 Dec 85 00:11:46 EST Received: by BITSY.MIT.EDU (4.12/4.7) id AA04287; Thu, 5 Dec 85 00:09:36 est Date: Thu, 5 Dec 85 00:09:36 est From: jis@BITSY.MIT.EDU (Jeffrey I. Schiller) Message-Id: <8512050509.AA04287@BITSY.MIT.EDU> To: Namecallers@MIT-MC In-Reply-To: Rob Austein's message of Wednesday, 4 December 1985 23:13 est Subject: Re: Host number assignment. Don't get confused. I delegate host numbers on networks, I DO NOT DELEGATE NETWORK NUMBERS. The in-addr.arpa name server has my name servers as the domain name server for 18.in-addr.arpa but the information I provide is gleaned from the MC tables. (We have to separate in our minds the administrative delegation done here at MIT and the programs that implement the domain system). For now I think we should continue to use a shared file on MC (or some other agreed upon place if the demise of MC should occur). for the human delegation of subnet numbers. I will have to periodically pick up the information about delegated subnets into my database file for the 18.in-addr.arpa domain (ie. I can generate said database file from a source format file kept on MC). Keep in mind that SOMEBODY's nameserver has to provide this function. It might as well be mine. It is just the data itself that has to be shared. -Jeff  Received: from MIT-XX.ARPA by MIT-MC.ARPA 4 Dec 85 23:15:25 EST Date: Wed, 4 Dec 1985 23:13 EST Message-ID: From: Rob Austein To: jis@MIT-BITSY.ARPA (Jeffrey I. Schiller) Cc: Namecallers@MIT-MC.ARPA Subject: Host number assignment. Jeff, if you are now the self proclaimed delegator of subnet numbers for network 18 it is a good thing you got around to telling the rest of us. I thought it was still being resolved by reading the comments at the back of HSTMIT. These comments, along with the NET: keywords out of HSTMIT and HSTNIC, are moving into MC: SYSNET; HSTNET >. We do need to deal with delgation of the IN-ADDR stuff though. Maybe we should add yet another keyword to the RFC810 tables, eg: SUBNET :
{,
} : ; This would go into the HSTLCS, HSTAI, etc tables, and would confer ownership (in the IN-ADDR sense) of the specified nets. Probably this should include both IP and Chaos forms of a given net if it is Chaos live, although the Chaos form will be ignored until/unless we start using Chaosnet nameservers. Not being a big fan of needless duplication, I propose right now that the rest of the SOA record for the IN-ADDR zone generated from this data be the same as that for the normal hosts. Ie, DOMAIN : LCS.MIT.EDU : IN : XX.LCS.MIT.EDU : BUG-LCS-DOMAIN.XX.LCS.MIT.EDU : 0 : 7200 : 600 : 3600000 : 60 : XX.LCS.MIT.EDU, MILO.LCS.MIT.EDU : SUBNET : 18.10.0.0 : ;LCS Ringnet would generate an SOA record for 10.18.IN-ADDR.ARPA that looked the same as the one for LCS.MIT.EDU except for the name. Or maybe we just want to do SUBNET : 10.18.IN-ADDR.ARPA : and have done with it. There should still be an ordered comprehsive list somewhere if possible, for which HSTNET is as good a place as any and better than a file that only Jeff can write. As soon as I get my act together (read, after I finish playing with sendmail.cf files so I can install the new host tables) I will want to become the authority (in the IN-ADDR sense) for the LCS subnets. CJL will probably want to do the same thing for AI, and he and I can split any ones that don't split neatly by flipping a coin. Presumably Athena will stay with Jeff as the IN-ADDR authority. JTW and BCN, tell me what you want done with RLE and EECS and I'll set it up in the tables, assuming that we do go with this SUBNET keyword kludge. --Rob  Received: from BITSY.MIT.EDU by MIT-MC.ARPA 4 Dec 85 22:00:45 EST Received: by BITSY.MIT.EDU (4.12/4.7) id AA04093; Wed, 4 Dec 85 21:58:36 est Date: Wed, 4 Dec 85 21:58:36 est From: jis@BITSY.MIT.EDU (Jeffrey I. Schiller) Message-Id: <8512050258.AA04093@BITSY.MIT.EDU> To: Namecallers@MC In-Reply-To: J. Noel Chiappa's message of Monday, 2 December 1985 14:49 est Subject: Host number assignment. I maintain files on the assignment of numbers to networks hung off the Campus spine. Requests for number assignment should be sent to me (preferably electronically). If you cannot wait for me to give you a number (which may take between 24 and 48 hours) you can ftp the file "/hosttable/hstcamp.txt" from BITSY.MIT.EDU (18.71.0.21) using anonymous FTP. This file is a copy of the authoritative database for the campus network. Assign yourself a number (preferably taking the next available number for the LAN involved) and send me mail telling me what number you took. I will acknowledge your assignment within 24 to 48 hours DON'T CONSIDER YOUR ASSIGNMENT PERMANENT unless you get an acknowledgment (just in case your request gets lost in the mail, you want to make sure it gets into the table before someone else takes the same number). Btw. The same name servers that handle the .MIT.EDU namespace are also delegated the 18.in-addr.arpa domain. I am willing to subdelegate the subnets that aren't directly on the campus net (ie. Tech Square) if someone is willing to provide a server (I am providing the information for these subnets now from files on MIT-MC). -Jeff  Received: from MIT-XX.ARPA by MIT-MC.ARPA 2 Dec 85 20:39:00 EST Date: Mon 2 Dec 85 14:49:53-EST From: "J. Noel Chiappa" Subject: Re: Impending host table format change To: Namecallers@MIT-MC.ARPA, Info-Hosts@MIT-MC.ARPA cc: JNC@MIT-XX.ARPA In-Reply-To: Message-ID: <12163960357.23.JNC@MIT-XX.ARPA> One other thing we should try and tackle in an organised fashion is allocation of host numbers on wires. Right now, it's done by looking through the host tables, which aren't organized in any useful fashion for this; in addition, some people chose a number, look to see if anyone has that number in protocol family X, and don't check to see if anyone is using it in family Y, with the result that a single host number winds up on two machines, with all the attendant hassle. Shawn keeps files for the LCS Ring and Ether, but they aren't publicy known about. It would be good if we had files for all the wires which random people hang new things on somewhere. Any ideas? Noel -------  Received: from MIT-XX.ARPA by MIT-MC.ARPA 28 Nov 85 03:07:47 EST Date: Thu, 28 Nov 1985 03:05 EST Message-ID: From: Rob Austein To: Info-Hosts@MIT-MC.ARPA, Namecallers@MIT-MC.ARPA Reply-To: Namecallers@MC Subject: Impending host table format change I am in the final stages of debugging the various filters, etc to implement the compartmentalization of the MIT host tables. For those who aren't in on this already, HSTMIT is being split up into several smaller files that map one to one with Internet domains (AI.MIT.EDU, LCS.MIT.EDU, ATHENA.MIT.EDU, etc). The new host tables are actually complete right now, and reside in MC: SYSNET;. Don't anybody try to use them yet though (you would have to work very hard to do so anyway). There is even a little documentation for them as wants it, in MC: SYSNET; HSTNEW README. I'll be testing this for a little while on XX before mucking with the MC binaries, but that will happen fairly soon (within two weeks) if nothing major goes wrong. Anyone who uses the MC host tables at all is hereby warned that something is almost certain to break on your machine when this change goes into effect. The most probably cause is the sheer size of the new table. The complete HOSTS3 table (HSTNIC + all the things that used to be in HSTMIT) will be significantly bigger (how much depends on what measure you use; the big change is a lot more nicknames for MIT hosts, some fairly long). A lot of this is temporary; far too many existing programs have assumptions about primary hostnames hardwired into them, so this part of the changeover has to be done in stages. Obviously there are a lot of tradeoffs here; questions or suggestions on this should go to NAMECALLERS@MC rather than all of INFO-HOSTS. For now, anybody who edits MC: SYSNET; HSTMIT > should also edit the appropriate subdomain file. If you aren't sure what to do, just make sure to tell me what changes you made and I'll update the appropriate file. I will send another message to INFO-HOSTS when I start the actual changeover on MC, but I wanted to make sure that people had some advance warning about this. --Rob  Received: from MIT-XX.ARPA by MIT-MC.ARPA 14 Nov 85 18:09:43 EST Date: Thu, 14 Nov 1985 18:11 EST Message-ID: From: Rob Austein To: Namecallers@MIT-MC.ARPA Subject: Host table conversion, yet again Here is the current state of the project of converting host tables. We need something we can use to generate both the Chaosnet namespace and the RFC883 input files for the various domain servers. Sorry to keep blathering about this, but I want to make sure nobody strenuously objects (or has a better idea) before I go off and implement all this cruft. I have a set of tables, current as of September (the point at which this project got dropped because of hurricane related damage to several machines), separated out into LCS, AI, Athena, EECS, and Everybody else. I will bring these up to date sometime in the next week. These files will be in "modified modified RFC810 format". Each files will have a single entry called DOMAIN at the top. This will contain basicly all the information for the SOA and NS record in the RFC883 format files. Format: DOMAIN : : : : : : : : : : {
} {, {
}} : The
fields that go with nameservers are optional (for LCS they are redundant because both nameservers are LCS hosts). One special hack I'd like to put into this is to allow the field to be zero; in this case the value in the SOA record should be the version number of the RFC810 file. Obviously this is only of use to people who keep their master tables on a machine that has version numbers, but this feature can be ignored for domains like Athena and should be useful for domains like LCS and AI. Since this format can't be used directly by any of the network code, we need a pair of filters. One (to convert this gubbish to RFC883) I have basicly written, JIS has another version, CJL has yet another version. The other is just a crock to make a slightly more normal RFC810 file out of this format (basicly just tack the domain name onto the end of all the hostnames) to make something that we can feed into HOSTS3 to generate the Chaosnet namespace. At one point I proposed teaching HOSTS3 itself how to read this format; I'm not so sure that's the right thing to do anymore. Is there anybody out there who isn't a PDP10 and who is reading MC:SYSNET;HSTMIT > directly for Chaosnet names? If so, fixing HOSTS3 won't do these people any good. If there isn't anybody like that and some hero wants to go out and fix HOSTS3, be my guest. I ain't gonna do it. Another thing that will have to happen is we will have to coordinate with the NIC when we actually do the cutover, since mismatches in the primary names of hosts will break HOSTS3 (sigh). Comments anybody? I get the distinct feeling that I've talked about this too much already, but it's getting late and I want to get this stuff rolling before we all die of old age. --Rob  Received: from SCRC-VALLECITO.ARPA by MIT-MC.ARPA 9 Oct 85 16:55:25 EDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-VALLECITO.ARPA via CHAOS with CHAOS-MAIL id 40543; Wed 9-Oct-85 16:49:32-EDT Date: Wed, 9 Oct 85 16:49 EDT From: David C. Plummer Subject: domain class for chaos To: Gail Zacharias , DCP@SCRC-QUABBIN.ARPA cc: NAMECALLERS@MIT-MC.ARPA, namedroppers@SRI-NIC.ARPA, POSTEL@USC-ISIB.ARPA In-Reply-To: <[MIT-MC.ARPA].673861.851009.GZ> Message-ID: <851009164909.5.DCP@NEPONSET.SCRC.Symbolics.COM> Date: Wed, 9 Oct 85 15:05:09 EDT From: Gail Zacharias Date: Tue, 8 Oct 85 17:52 EDT From: David C. Plummer I see. If you want to fork off another discussion, I think there should be a naming scheme for chaos addresses so they can appear in mail headers, just as raw internet address can. (Replace Chaos with DECNet or some other address space for other examples.) Something like "11406.CH-ADDR.MIT.EDU" could appear in mail headers, provided the CH-ADDR.MIT.EDU server says all the right things in response to MAILA queries... Something along the lines of: 11406.CH-ADDR.MIT.EDU CH A MIT.EDU 11406 11406.CH-ADDR.MIT.EDU CH PTR OZ.AI.MIT.EDU 11406.CH-ADDR.MIT.EDU CH MD 11406.CH-ADDR.MIT.EDU 11406.CH-ADDR.MIT.EDU IN MF MAIL-RELAY.MIT.EDU The server should pretend the A/MD/MF records exist even if there is no PTR record, i.e. even if the host is not registered by name. Basically a syntactically correct nnnn.CH-ADDR.MIT.EDU should never get authoritative name errors. I'm obviously not up on things. Why does the CH-ADDR.MIT.EDU server even get asked?? That is, here is how I would 'expect' a mail user to route mail to an unknown "11406.CH-ADDR.MIT.EDU". 'Gee, I don't know what 11406.CH-ADDR.MIT.EDU is. Nor CH-ADDR.MIT.EDU. Nor MIT.EDU But I DO know what EDU is; I'll send it it's a mail bouncer.' The EDU mail bouncer gets it and says 'Gee, I don't know what 11406.CH-ADDR.MIT.EDU is. Nor CH-ADDR.MIT.EDU. But I DO know what MIT.EDU is; I'll send it to it's mail bouncer.' The MIT.EDU mail bouncer gets it and says 'Gee, I don't know what 11406.CH-ADDR.MIT.EDU is. But I DO know what CH-ADDR.MIT.EDU is; I'll send it to it's mail bouncer.' If the CH-ADDR.MIT.EDU doesn't know what's going on, something is wrong. But note that neither the original host nor the next two need know nothing about what 11406.CH-ADDR.MIT.EDU really translates to. I probably have the wrong model of how things really are. I should probably shut up.  Date: Wed, 9 Oct 85 15:05:09 EDT From: Gail Zacharias Subject: domain class for chaos To: DCP@SCRC-QUABBIN.ARPA cc: NAMECALLERS@MIT-MC.ARPA, namedroppers@SRI-NIC.ARPA, POSTEL@USC-ISIB.ARPA In-reply-to: Msg of Tue 8 Oct 85 17:52 EDT from David C. Plummer Message-ID: <[MIT-MC.ARPA].673861.851009.GZ> Date: Tue, 8 Oct 85 17:52 EDT From: David C. Plummer I see. If you want to fork off another discussion, I think there should be a naming scheme for chaos addresses so they can appear in mail headers, just as raw internet address can. (Replace Chaos with DECNet or some other address space for other examples.) Something like "11406.CH-ADDR.MIT.EDU" could appear in mail headers, provided the CH-ADDR.MIT.EDU server says all the right things in response to MAILA queries... Something along the lines of: 11406.CH-ADDR.MIT.EDU CH A MIT.EDU 11406 11406.CH-ADDR.MIT.EDU CH PTR OZ.AI.MIT.EDU 11406.CH-ADDR.MIT.EDU CH MD 11406.CH-ADDR.MIT.EDU 11406.CH-ADDR.MIT.EDU IN MF MAIL-RELAY.MIT.EDU The server should pretend the A/MD/MF records exist even if there is no PTR record, i.e. even if the host is not registered by name. Basically a syntactically correct nnnn.CH-ADDR.MIT.EDU should never get authoritative name errors.  Received: from SCRC-QUABBIN.ARPA by MIT-MC.ARPA 8 Oct 85 17:53:35 EDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 208767; Tue 8-Oct-85 17:53:40-EDT Date: Tue, 8 Oct 85 17:52 EDT From: David C. Plummer Subject: re: domain class for chaos To: POSTEL@USC-ISIB.ARPA, namedroppers@SRI-NIC.ARPA cc: namecallers@MIT-MC.ARPA In-Reply-To: The message of 7 Oct 85 13:52-EDT from POSTEL@USC-ISIB.ARPA Message-ID: <851008175248.7.DCP@NEPONSET.SCRC.Symbolics.COM> Date: 7 Oct 1985 10:52:47 PDT From: POSTEL@USC-ISIB.ARPA David: Wrong. We are not talking about "CHAOS" appearing in an name at any level. We are talking about a kind of data associated with the existing names that is in the chaos class. All the data associated with the names till now has been in the internet class. I see. If you want to fork off another discussion, I think there should be a naming scheme for chaos addresses so they can appear in mail headers, just as raw internet address can. (Replace Chaos with DECNet or some other address space for other examples.) Queries are really (at least) a three argument call (1) name, (2) class, (3) type. Most of the queries are of type address and class internet, that is, get the internet address for this name. The proposal here is to add a class value for chaos so one cam make the query "what is the chaos address of the host with this name". The names would be the same (e.g., OZ.MIT.EDU). I see. The way Symbolics did this was to say "Hey, tell me what you know about OZ.MIT.EDU" and then extract the necessary data from the reponse. In this case, addresses come through as tokens ADDRESS so you can not only get one internet/chaosnet/decnet address, but all of them for all types. I realize this is a bit verbose and may be expensive to packet-charging networks, but it does us rather well. Chris Stacy may know enough about our namespace protocol to describe it. It may be documented; I'm not sure.  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 7 OCT 85 17:51:09 EDT Date: Mon, 7 Oct 1985 17:48 EDT Message-ID: From: Chris Lindblad To: MOCKAPETRIS@USC-ISIC.ARPA Cc: cstacy@MIT-MC.ARPA, namecallers@MIT-MC.ARPA, namedroppers@SRI-NIC.ARPA Subject: Domain class for chaos In-reply-to: Msg of 4 Oct 1985 15:58-EDT from MOCKAPETRIS at USC-ISIC.ARPA I suggest the network identifier in the chaos class Address record be a domain name. This was option 2 in Paul's message. So a chaosnet address record might be: REAGAN.AI.MIT.EDU CH A CH-ADDR.MIT.EDU 13065 For address to name support, instead of composing a domain hierarchy just like IN-ADDR.ARPA as Paul suggested, we take the domain name to which that the address corresponds, and lookup the address in that domain. This is similar to IN-ADDR, but the issue of a root domain and central authority for chaosnet address domains disappears. For my example there might be a record in the CH-ADDR.MIT.EDU domain: 13065.CH-ADDR.MIT.EDU CH PTR REAGAN.AI.MIT.EDU I hesitantly agree with DCP that the chaosnet addresses shouldn't be split up into subnets, and should be expressed in octal. Chaosnets are supposed to be local area nets, and the advantages to splitting the address into host and subnet fields for distributed address translation might not be significant enough to outweigh the confusion the different format of address gives. I could easily be convinced otherwise, though. As a matter of fact, I'm not quite sure which is better. Pointer records like this? 65.26.CH-ADDR.MIT.EDU CH PTR REAGAN.AI.MIT.EDU or like this? 13065.CH-ADDR.MIT.EDU CH PTR REAGAN.AI.MIT.EDU  Received: from USC-ISIB.ARPA by MIT-MC.ARPA 7 Oct 85 13:58:40 EDT Date: 7 Oct 1985 10:52:47 PDT From: POSTEL@USC-ISIB.ARPA Subject: re: domain class for chaos To: namedroppers@SRI-NIC.ARPA cc: namecallers@MIT-MC.ARPA David: Wrong. We are not talking about "CHAOS" appearing in an name at any level. We are talking about a kind of data associated with the existing names that is in the chaos class. All the data associated with the names till now has been in the internet class. Queries are really (at least) a three argument call (1) name, (2) class, (3) type. Most of the queries are of type address and class internet, that is, get the internet address for this name. The proposal here is to add a class value for chaos so one cam make the query "what is the chaos address of the host with this name". The names would be the same (e.g., OZ.MIT.EDU). --jon. -------  Received: from SCRC-QUABBIN.ARPA by MIT-MC.ARPA 7 Oct 85 10:47:56 EDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 208091; Mon 7-Oct-85 10:48:03-EDT Date: Mon, 7 Oct 85 10:48 EDT From: David C. Plummer Subject: Domain class for chaos To: MOCKAPETRIS@USC-ISIC.ARPA, cstacy@MIT-MC.ARPA, cjl@MIT-MC.ARPA cc: namedroppers@SRI-NIC.ARPA, namecallers@MIT-MC.ARPA In-Reply-To: The message of 4 Oct 85 15:58-EDT from MOCKAPETRIS@USC-ISIC.ARPA Message-ID: <851007104842.9.DCP@NEPONSET.SCRC.Symbolics.COM> Chaos address are almost always presented as one octal number and are hardly ever presented as subnet/host, and NEVER NEVER NEVER in decimal. Since you didn't supply a full example, I'm not sure if you are proposing (with my modification), that MIT-OZ can be named as 11406.CHAOS.MIT.EDU or as 11406.MIT.CHAOS I would prefer the former since .MIT.EDU already exists (as would all others) and the burden of mail is ONLY on .MIT.EDU and not on the entire world. Conversely, using .MIT.CHAOS would require a new top level routing entry (.CHAOS) and those gateways would need to know a parallel domain tree.  Received: from USC-ISIC.ARPA by MIT-MC.ARPA 4 Oct 85 16:04:14 EDT Date: 4 Oct 1985 12:58:02 PDT From: MOCKAPETRIS@USC-ISIC.ARPA Subject: Domain class for chaos To: cstacy@MIT-MC.ARPA, cjl@MIT-MC.ARPA cc: namedroppers@SRI-NIC.ARPA, namecallers@MIT-MC.ARPA Some members of the MIT Chaosnet community have suggested that chaos be allocated a domain class. The principal purpose, at least at present, is to map between chaos net addresses and host names. This message describes my perception of the issues in creating this new class, but should not be taken as being an edict or even as a preliminary design; I do hope that it encourages the Chaos community to develop a standard which is compatible with the Internet domain class and the domain protocols in general. In any case, chaos deserves a class regardless of what they do, and I have allocated class 3 and acronym CH (for master file purposes). For those unfamilar with Chaos, the basic idea is that we want to be able to map between domain names for hosts and chaosnet address, which are 16 bit numbers. An additional problem is that there are multiple chaosnet address spaces, which aren't connected, and hence there isn't one space. The general form of the proposed solution is that Chaos class type A RRs include a Chaos system or net identifier of some sort along with the 16 bit address. Note that the Chaos class is using exactly the same name space as the Internet class, although the identical name space doesn't imply that data will be present in both classes. That is, if a host has both a chaos and internet class adddresses it will have the same name in both classes, though some hosts may well have RRs in only one class or the other. (Note that we assume that Chaos will encode types with internet parallels identically with those of the Internet class.) The choices which have been proposed for the Chaos net identifier are: 1) A 16 bit encoded type. 2) A domain name 3) A variable length character string (similar to the HINFO data) Since the Chaos community has a tradition of character strings, the suggestion is the equivalent of a label, represeted using either (2) or (3), where (3) seems to be a marginally better choice. The label restriction says that, by convention, the string will not contain imbedded spaces or blanks, and will be 63 characters or less. The address to name support requires the equivalent of the IN-ADDR.ARPA domain. The suggestion is that the address to name space for the chaos class be of the form: ... The field corresponds to the low order 8 bits of a Chaosnet address. The suggested format is a decimal string similar to that used in the IN-ADDR.ARPA domain. (Some want octal for historical reasons.) The field corresponds to the high order 8 bits of a Chaosnet address. It will use the same representation as the . The is a label corresponding to the character strings in the A RRs for class CH. If the chaos net ID format changes, this too will change. The is a well known domain. Perhaps 'CH-ADDR.'. In any case, I'd rather have someone in the Chaos world pick it / get others to accept it. There are other major issues related to who will be responsible for the chaos zone which effectively allocates the chaos net IDs, implementation of this new zone's servers, etc., and refining the definition of the NS and SOA RRs for this new environmen, but is seems worthwhile to solve the multiple chaos problem first. This first use of multiple classes should provide for interesting times. paul -------  Received: from MIT-XX.ARPA by MIT-MC.ARPA 7 Sep 85 03:15:44 EDT Date: Fri, 6 Sep 1985 11:39 EDT Message-ID: From: Rob Austein To: namecallers@mc Subject: mail forwardings Here's a possible sollution to the problem of changing MF entries in a hurry. Chaos-only hosts should have MF entries pointing to a host called MAIL-RELAY inside of the local subdomain (ie, OZ would use MAIL-RELAY.AI.MIT.EDU, PSZ's vaxen would use MAIL-RELAY.LCS.MIT.EDU, etc). The MAIL-RELAY would be a single CNAME entry pointing at MC or XX or whatever. At the very least this allows a single change to fix all the hosts in a subdomain. If we are clever we may even be able to set it up so that the CNAME RR for MAIL-RELAY would have a short timeout to force outsiders to get frequent updates (I'm not sure this can be done, have to go reread the spec). I'm not particularly attached to this idea, feel free to shoot holes in it if you have a better one.... --Rob  Date: Fri, 30 Aug 85 08:38:18 EDT From: Gail Zacharias Subject: %MIT-OZ@MIT-MC.ARPA -> OZ.AI.MIT.EDU To: NAMECALLERS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].628433.850830.GZ> I'd like to bring up a problem with Chaosnet-only hosts in the domain world, and what it implies about domain server software. Theoretically, there should be no problem, since everybody is supposed to look up MF (Mail Forwarding) records when doing mail, which we will presumably supply for all chaos-only hosts. In practice, I expect everybody is having so much trouble just doing address resolution that they won't get around to handling MF data until later. In and of itself that's no big deal, we could continue to use OZ@MC a little longer, until such time as it seems safe to drop it. However, if, as appears likely, the MF stuff is going to be retrofitted into existing address resolution software, it will most likely use only the first MF record it finds, the way address resolution interfaces tend to give you only one address, "the address", for a host. In fact, MRC says that's exactly what he's expecting and designing for as far as the TOPS-20 mail system is concerned -- the mail system will hand "OZ.AI.MIT.EDU" to a system call and get back an Internet address to connect to. I don't think we can expect most mail software to cycle through all forwarders. This is similar to what we have now, with outgoing headers specifying OZ@MIT-MC so that all mail comes back thru MC. However, the explicitness of the "MIT-MC" means that people are aware of the forwarding going on, and there are many knowledgable users who know (or can easily find out from their mail wizard) to use @MIT-something-else if MC is down. Moreover when MC is going to be down for an extended period of time, we can (and do, on OZ) make outgoing headers say, e.g., @MIT-XX. With all mention of the forwarder removed from the headers, this sort of knowledge is going to disappear. This means that it must be moved to the domain servers. E.g. it must be possible to tell a domain server to move the MF->XX records up ahead of the MF->MC records for all hosts -- having to edit a moby source file and reboot something would not work. In fact, ideally the servers should automatically cycle the returned order of MF records when the first one is dead. We might even want to cycle the order periodically for no reason other than spreading the load. Does any of the existing or planned server software have these sorts of capabilities? Or other ways of addressing the problem?  Received: from MIT-XX.ARPA by MIT-MC.ARPA 23 Aug 85 13:32:16 EDT Date: Fri, 23 Aug 1985 13:32 EDT Message-ID: From: Rob Austein To: namecallers@mc cc: SRA@MIT-XX Subject: Whence host tables? JIS and I have been talking about what we should do with the MIT host tables. Our current theory is that we should keep the primary source of host data for MIT in the extended RFC810 format (whether the files live on MC or not is a seperate issue). There are two reasons for this: (1) as Jeff pointed out to me, it is a bit harder to make an inconsistant RFC810 host table than to make an inconsistant RFC883 table, because in the RFC810 format all the data for a particular host is on a single line, including nicknames, alternate addresses, etcetera. The other reason for keeping the RFC810 format is so that we can keep the Internet and Chaosnet data in the same file. Eventually we may end up with some kind of domain stuff for the Chaosnet, but right now we don't have the technology. Obviously it is easier to keep the data all in one set of tables than have to keep updating the Internet data in one file and the Chaosnet data in another file. Accordingly, I propose that we split HSTMIT back up into subfiles (sorry folks), but this time sorted by domain. For now that means HSTAI, HSTLCS, HSTATH(ena), and HSTOTH(er). Jeff also proposed that we add a new entry type to the RFC810 format, a DOMAIN field. This would occur once per file and would contain all the data associated with the SOA record for this domain (or as much as is practical, we may not want to put initial timeout values here). We already have a program to make RFC883 files from RFC810. I have this enormous grody TECO hack that will handle merging HSTMIT and HSTNIC (since some of the MIT info appears only in the NIC table). I have a couple of reluctant volunteers to go through the tables with me to figure out which host belong to which domain (any other volunteers are welcome). After all this is done I will probably start supplying RFC883 format files on XX for them as wants them, presumably Jeff will do the same somewhere else. Comments, flames, etcetera, anybody? --Rob  Received: from MIT-XX.ARPA by MIT-MC.ARPA 30 Jul 85 16:40:23 EDT Date: Tue 30 Jul 85 15:22:34-EDT From: Rob Austein Subject: Re: Big guys in he top level namespace To: GZ@MIT-MC.ARPA cc: jis@MIT-BITSY.ARPA, NAMECALLERS@MIT-MC.ARPA, jnc@MIT-XX.ARPA In-Reply-To: Message from "Gail Zacharias " of Tue 30 Jul 85 14:45:25-EDT Office: [NE43-503] 545 Technology Square, Cambridge MA 02139; (617) 253-7341 I expect that (at first, anyway) the only domains will be LCS.MIT.EDU, AI.MIT.EDU, ATHENA.MIT.EDU, and G.MIT.EDU (or whatever this last one is called). The business with detailed plans for everybody and her kid brother having a subdomain was to plan in advance what we do if/when people start flaming. The nameservers for the generic types will be run by JIS's office, so long as they don't get too large. Once you have a couple of subdomains (which I and most of the people at the meeting feel is necessary) it doesn't make much difference if you have two or two hundred. -------  Date: Tue, 30 Jul 85 14:47:09 EDT From: Gail Zacharias Subject: Big guys in he top level namespace To: jis@MIT-BITSY.ARPA cc: NAMECALLERS@MIT-MC.ARPA, jnc@MIT-XX.ARPA In-reply-to: Msg of Sat 27 Jul 85 18:10:59 edt from jis at MIT-BITSY.MIT.EDU (Jeffrey I. Schiller) Message-ID: <[MIT-MC.ARPA].593774.850730.GZ> Thanks for the explanation. I guess my gut reaction is that the division into departments seems a bit too fine grained. It seems like most of those `domains' would have but a handful of hosts. While having a domain.MIT.EDU host essentially eliminates mail problems, that still leaves FINGER and FTP and TELNET and ... I am not very familiar with the design of project Athena, but isn't it the case that almost all networked machines at MIT, outside of the labs, will be part of it? (By networked I mean here capable of receiving arpanet mail, directly or indirectly). In that case, all those "Bold Heading" departments would really be subdomains of Athena. Similarly, I don't see AI and LCS requiring separate name spaces and name servers. While we've had our little spats and problems, I think we'd be capable of cooperating to that extent... Was the possibility considered of a less detailed division? Say, as a first approximation, something along the lines of RES(EARCH).MIT.EDU -- the labs and similar semi-independent research entities SCH(OLASTIC).MIT.EDU (trying to avoid EDU.MIT.EDU) -- Departmental and educational machines, etc., essentially project athena at this point. ADMIN.MIT.EDU - admissions, presidents' office, etc... My feeling is that most non-computer science entities would not be interested in (or possibly capable of) running their own name servers, and hence the CS people in each general category would end up running things anyway. (Also, non-CS people tend not to be so religious on details like host names, so if told they can't have a certain name because it's taken, they wouldn't go to war about it, just pick another name). So course 21 can just be told to register their hosts with Athena, a biology lab with Tech Square, etc (I guess Athena would run ADMIN as well). Of course if somebody insists on a domain of their own, they can have one, in an appropriate category. The fact that they'd be more deeply nested would tend to discourage frivolous use of this option...  Received: from MIT-EECS by MIT-MC.ARPA via Chaosnet; 29 JUL 85 13:47:42 EDT Date: Mon 29 Jul 85 13:46:40-EDT From: Clifford Neuman Subject: A few thoughts on both proposals To: NAMECALLERS@MIT-MC I feel that the the conculsion to put everyone in a subdomain of MIT.EDU was partly political. Organizations such as LCS, and the AI lab need to have administrative control over whatever domain they are in so that they can add and remove their own hosts, and change network addresses, etc. whithout having to deal with a central MIT authority. At the same time, they don't want to become second class citizens. If they are forced into a subdomain (for example LCS.MIT.EDU) while other hosts remain in the top level MIT domain, then they fell as if they are second class. This feeling can be backed up by the ability for someone else to come along and put a host name in the top level MIT domain matching a host name in their subdomain, thus "eclipsing" their entry. One solution to this problem (the one decided at the meeting) is to place everyone in subdomains (with strict rules on who can appear in the top level domain). This way, everyone is equal. Problems with this approach are that, outside MIT, people don't know MIT's internal structure, and might have a harder time synthesizing domain names for a host they want to get to. This isn't as much of a problem as it seems since most host names are arbitrary anyway, and one can be told the full host name as easily as the local part. As far as non-arbitrary names go (e.g. AI, LCS, EE, Athena), the proposal calls for one host in the topl-level domain for each of these anyway. The other proposal was the flat namespace proposal. This could work if there were some mechanism for each organization to modify the MIT.EDU domain without having to go though a central authority. To the outside, everyone would appear as .MIT.EDU. Another advantage is that name conflicts would be seen immediately instead of being "hidden" by placing the hosts in different subdomains. The disadvantage of this approach is that it doesn't scale up well. It is fine for the number of hosts we have now, but as the number of hosts grows, we will have more and more name conflicts. I think that whichever approach is finally chosen should be based on the number of hosts we expect to see at MIT. With MIT, at least, there is a reasonable upper bound on the number of hosts (e.g. 2 times the number of people in the MIT community). We can use this upper bound in planning our addressing structure. ~ Cliff -------  Received: from MIT-BITSY by MIT-MC.ARPA 27 Jul 85 18:11:30 EDT Received: by MIT-BITSY.MIT.EDU (4.12/4.7) id AA04245; Sat, 27 Jul 85 18:10:59 edt Date: Sat, 27 Jul 85 18:10:59 edt From: jis@MIT-BITSY.MIT.EDU (Jeffrey I. Schiller) Message-Id: <8507272210.AA04245@MIT-BITSY.MIT.EDU> To: GZ@MIT-MC.ARPA Cc: JNC@MIT-XX.ARPA, NAMECALLERS@MIT-MC.ARPA In-Reply-To: Gail Zacharias's message of Fri, 26 Jul 85 23:31:21 EDT Subject: Big guys in he top level namespace I will attempt to answer your question... First what was decided: We decided NOT to put arbitrary hosts directly in the MIT.EDU domain but to instead create subdomains for administrative entities at MIT (for example all departments and independent laboratories... If you had a "Bold Heading" in the MIT directory was given out as an ad hoc criterion). Each subdomain would either have its own set of name servers (as probably AI and LCS would desire) or could have their domain requests resolved by the same nameservers as handle MIT.EDU. Each domain would also be able to put ONE host in the MIT.EDU domain which would have the same name as the domain itself. For example LCS may have the "LCS.MIT.EDU" domain and also have a host named "LCS.MIT.EDU" registered in the MIT.EDU domain. It would be expected that this host would be able to handle mail for any person affiliated with the department or lab. Therefore a person (lets call them "person" for discussion) would get mail as person@LCS.MIT.EDU. Other proposals: The major competing proposal was to put all MIT machines directly in the MIT.EDU domain and also let those groups that wanted their own domain to have a subdomain created. Presumably a group would want to administer its own subdomain (with it own set of name servers) so that they would have administrative control over the domain without having to interact with the administration of the MIT.EDU domain. This proposal lost out mostly because it was viewed as one which would create name conflicts in the MIT.EDU domain (the whole NIC host table problem all over again, just at a smaller level). There have already been battles over who owns names in the HSTMIT > file on MC. I personally don't believe that this would happen but the majority at the meeting did, or to be more accurate the general consensus was to try the first proposal and see if we could make it work. The only major drawback of the first proposal is that there IS NOT a one to one mapping between old host names in the .ARPA domain and the new MIT.EDU domain. Ie. If I knew what the name of a host in the ARPA domain was I cannot merely strip off the .ARPA and append a .MIT.EDU and have the right thing happen. Instead a user in the outside world has to know what organization at MIT a machine belongs to in order to divine which of the various subdomains the host is in. The current situation: For now there is only one subdomain in existence, that is the "ATHENA" subdomain of MIT.EDU. For now until I get some information about which hosts go in which (as yet to be created) subdomains I have taken all hosts in the NIC host table that begin with a "MIT-" and put them in the MIT.EDU domain for now (as well as hosts found in HSTMIB on MC). Being as most of the hosts now placed in the MIT.EDU domain belong to either LCS or AI I can create the LCS and AI domains (and administer them until someone tells me addresses for nameservers) as soon as someone give me a list of AI owned hosts and a list of LCS owned hosts (I don't need their addresses and other information, I can fetch that from HSTNIC and HSTMIB). -Jeff  Date: Fri, 26 Jul 85 23:31:21 EDT From: Gail Zacharias Subject: Big guys in he top level namespace To: JNC@MIT-XX.ARPA cc: NAMECALLERS@MIT-MC.ARPA In-reply-to: Msg of Wed 24 Jul 85 00:40:17-EDT from J. Noel Chiappa Message-ID: <[MIT-MC.ARPA].589905.850726.GZ> I don't think the EDU administrators would allow this, there are guidelines for the minimum sizes of second level domains and single hosts just don't make it. On the other hand, there is nothing preventing larger administrative entities at MIT from trying to register themselves in EDU directly. This would presumably be discouraged by the NIC but accepted if insisted upon. If such a thing were to happen, it would be highly confusing to users, and for this reason I think it's important that the administration of the MIT domain be sufficiently flexible and open so as to be acceptable to any group at MIT. For the benefit of those of us who weren't at the meeting, could somebody please outline what the current plans are for the MIT domain, what was discussed, what was decided, etc.  Received: from MIT-XX.ARPA by MIT-MC.ARPA 24 Jul 85 22:18:02 EDT Date: Wed 24 Jul 85 22:16:03-EDT From: Rob Austein Subject: Re: Big guys in he top level namespace To: JNC@MIT-XX.ARPA cc: DCP@SCRC-QUABBIN.ARPA, namecallers@MIT-MC.ARPA In-Reply-To: Message from ""J. Noel Chiappa" " of Wed 24 Jul 85 20:56:31-EDT Office: [NE43-503] 545 Technology Square, Cambridge MA 02139; (617) 253-7341 Doesn't seem to me to be an issue. If Joe random wants his LSI-11 to be FOO.EDU, well, fine by me. But he'd better not expect any support or recognition (as part of MIT, that is) from the rest of us. It seems to break down into two cases. Case one is where Joe wants to be a seperate administrative entity from MIT; if he can get the NIC to approve this, fine, no skin off my nose, see above. Case two is where Joe just wants his *name* to be in .EDU so that he doesn't have to type as much; in this case he is just plain confused and should be told so in a slightly more diplomatic fashion. Or do you have a specific case in mind that doesn't fall into one of these catagories? --Rob -------  Received: from MIT-XX.ARPA by MIT-MC.ARPA 24 Jul 85 20:45:42 EDT Date: Wed 24 Jul 85 17:28:18-EDT From: "J. Noel Chiappa" Subject: Re: Big guys in he top level namespace To: DCP@SCRC-QUABBIN.ARPA, namecallers@MIT-MC.ARPA cc: JNC@MIT-XX.ARPA In-Reply-To: Message from "David C. Plummer in disguise " of Wed 24 Jul 85 15:44:04-EDT You weren't at the meeting which discussed the MIT domain management (which is what this mailing list is about). There was this big discussion on which hosts to allow in the top level MIT namespace (political issues). I was pointing out to people that the problem exists at one level up; i.e. do we allow the *host* MC.EDU to exist (as well as MC.MIT.EDU and MC.LCS.MIT.EDU). Also, can we control Joe Random at MIT who wants to register his host in the EDU domain directly? Noel -------  Received: from SCRC-QUABBIN.ARPA by MIT-MC.ARPA 24 Jul 85 19:20:52 EDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 185484; Wed 24-Jul-85 11:50:12-EDT Date: Wed, 24 Jul 85 11:52 EDT From: David C. Plummer in disguise Subject: Big guys in he top level namespace To: J. Noel Chiappa , namecallers@MIT-MC.ARPA In-Reply-To: The message of 24 Jul 85 00:40-EDT from J. Noel Chiappa Message-ID: <850724115211.4.NFEP@NEPONSET.SCRC.Symbolics.COM> Date: Wed 24 Jul 85 00:40:17-EDT From: "J. Noel Chiappa" I had a though about this issue of "who do we allow to be a host in the top level MIT namespace". What's to stop people going to the NIC and asking to have their hosts registered at the top level in the EDU domain (e.g. MC.EDU)? Hmm.... I don't see any reason not to allow this. MC.EDU would mean the educational entity called MC, which has nothing (necessarily) to do tiwh MC.MIT.EDU. Maybe I missed something? How is this different than SCRC.SYMBOLICS.COM and SCRC.SCRC.SYMBOLICS.COM? I think both of those work. They happen to mean the same machine, but they don't have to.  Received: from MIT-XX.ARPA by MIT-MC.ARPA 24 Jul 85 00:42:19 EDT Date: Wed 24 Jul 85 00:40:17-EDT From: "J. Noel Chiappa" Subject: Big guys in he top level namespace To: namecallers@MIT-MC.ARPA cc: JNC@MIT-XX.ARPA I had a though about this issue of "who do we allow to be a host in the top level MIT namespace". What's to stop people going to the NIC and asking to have their hosts registered at the top level in the EDU domain (e.g. MC.EDU)? Hmm.... -------  Received: from SCRC-QUABBIN.ARPA by MIT-MC.ARPA 23 Jul 85 07:02:17 EDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 185008; Tue 23-Jul-85 07:00:05-EDT Date: Tue, 23 Jul 85 07:01 EDT From: David C. Plummer in disguise Subject: Yow, are we ad-hoc yet? To: Christopher C. Stacy cc: NAMECALLERS@MIT-MC.ARPA In-Reply-To: <[MIT-MC.ARPA].584627.850722.CSTACY> Message-ID: <850723070144.8.NFEP@NEPONSET.SCRC.Symbolics.COM> Date: Mon, 22 Jul 85 17:51:26 EDT From: Christopher C. Stacy (NAMECALLERS (EQV-LIST (FILE [DSK:NETDOC;NAMCAL MAIL]) (jis BITSY.MIT.EDU) CSTACY CJL JTW (SAR XX) GZ DCP (romkey BORAX) (DClark MULTICS) (BCN EECS) (Sollins XX) (dgg ATHENA) (JPRESTIVO XX))) We are certainly ad hoc since I have no idea what this list is for. Am I supposed to call you a good name or a bad name, or does that depend on my mood? I imagine this is network related, but in what capacity I have no idea.  Date: Mon, 22 Jul 85 17:51:26 EDT From: Christopher C. Stacy Subject: Yow, are we ad-hoc yet? To: NAMECALLERS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].584627.850722.CSTACY> (NAMECALLERS (EQV-LIST (FILE [DSK:NETDOC;NAMCAL MAIL]) (jis BITSY.MIT.EDU) CSTACY CJL JTW (SAR XX) GZ DCP (romkey BORAX) (DClark MULTICS) (BCN EECS) (Sollins XX) (dgg ATHENA) (JPRESTIVO XX)))