Subject: machine readable subnet table in AI:SYSHST;HSTNET >: clarification
From: Rob Austein <[email-masked]>
To: [email-masked], [email-masked]
Date: Fri, 8 Jul 1988 12:48 EDT

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".

Date: Fri, 8 Jul 1988  12:41 EDT
From: Rob Austein <[email-masked]>
To:   [email-masked], [email-masked]
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

Date: Tue, 24 Nov 87 23:36:00 EST
From: David Vinayak Wallace <[email-masked]>
Subject:  ai.mit.edu
To: [email-masked]
cc: [email-masked], [email-masked]

    Date: Tue, 24 Nov 1987  18:45 EST
    From: Rob Austein <SRA at XX.LCS.MIT.EDU>

        Date: Friday, 20 November 1987  11:45-EST
        From: Chris Lindblad <[email-masked]>

            Date: Fri, 20 Nov 87 10:25:23 EST
            From: David Vinayak Wallace <[email-masked]>

            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 [email-masked]).  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.")

Date: Tue, 24 Nov 1987  18:45 EST
From: Rob Austein <[email-masked]>
To:   Chris Lindblad <[email-masked]>
Cc:   [email-masked], [email-masked]
Subject: ai.mit.edu

    Date: Friday, 20 November 1987  11:45-EST
    From: Chris Lindblad <[email-masked]>
    To:   [email-masked]
    cc:   [email-masked]
    Re:   ai.mit.edu

        Date: Fri, 20 Nov 87 10:25:23 EST
        From: David Vinayak Wallace <[email-masked]>

        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).

Date: Fri, 20 Nov 87 11:45 EST
From: Chris Lindblad <[email-masked]>
Subject: ai.mit.edu
To: [email-masked]
cc: [email-masked]

    Date: Fri, 20 Nov 87 10:25:23 EST
    From: David Vinayak Wallace <[email-masked]>

    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.

Date: Fri, 20 Nov 87 10:25:23 EST
From: David Vinayak Wallace <[email-masked]>
Subject:   ai.mit.edu
To: [email-masked]
cc: [email-masked]

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.

Date: Mon, 3 Aug 87 09:36 EDT
From: Chris Lindblad <[email-masked]>
Subject: Minor deficiences in MIT.EDU zone and children
To: [email-masked]
cc: [email-masked]

    Date: Sun, 2 Aug 1987  18:08 EDT
    From: Rob Austein <[email-masked]>

    ...

	    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.

Date: Sun, 2 Aug 1987  18:08 EDT
From: Rob Austein <[email-masked]>
To:   [email-masked]
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

Date: Thu, 21 May 87 23:31:28 EDT
From: "Philip A. Prindeville" <[email-masked]>
Subject:  Re: Nameservice for foreign domain
To: [email-masked]

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

Date: Wed, 6 May 1987  22:50 EDT
From: Rob Austein <[email-masked]>
To:   "Philip A. Prindeville" <[email-masked]>
cc:   [email-masked]
Subject: Nameservice for foreign domain

    Date: Wednesday, 6 May 1987  22:22-EDT
    From: "Philip A. Prindeville" <[email-masked]>

    	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" <[email-masked]>
        To: [email-masked]
        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			[email-masked]
	AI.MIT.EDU		[email-masked]
	MEDIA.MIT.EDU		[email-masked]
	NS.ATHENA.MIT.EDU	[email-masked]
	LL.MIT.EDU		[email-masked]

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

Date: Wed, 8 Apr 1987  16:48 EDT
From: Rob Austein <[email-masked]>
To:   [email-masked], [email-masked]
Subject: Maybe we need a Mailer-Error-of-Tomorow list?

Date: Wednesday, 8 April 1987  12:24-EDT
From: [email-masked] (Jon Postel)
To:   [email-masked]
cc:   [email-masked]
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.

Date: Thu, 22 Jan 1987  14:35 EST
From: Rob Austein <[email-masked]>
To:   [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked]
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 "[email-masked]" 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 <[email-masked]>
To:   MGT: ;
cc:   [email-masked]
Re:   DDN MGT Bulletin # 32

********************************************************************** 
DDN MGT Bulletin 32              DCA DDN Defense Communications System   
22 Jan 87                        Published by: DDN Network Info Center
                                    ([email-masked])  (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 ([email-masked]), or via AUTODIN message, and the NIC
Hostmaster ([email-masked]) 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.

Date: Fri, 16 Jan 1987  01:58 EST
From: Rob Austein <[email-masked]>
To:   Ramin Zabih <[email-masked]>
Cc:   [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked]
Subject: AI -> SUSHI mail, again.

    Date: Friday, 16 January 1987  01:34-EST
    From: Ramin Zabih <[email-masked]>

    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

Date: Sat, 12 Jul 1986  05:20 EDT
From: Rob Austein <[email-masked]>
To:   [email-masked], [email-masked]
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:<HOSTS> will continue to
be updated, but ones in XX:<SYSTEM> 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

Date: Wed, 4 Jun 1986  17:56 EDT
From: Rob Austein <[email-masked]>
To:   [email-masked], [email-masked],
      [email-masked]
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

<service>.<domain-name>	 IN	SERV	<ip-address> <port>
<service>.<domain-name>	 CH	SERV	<chaos-address>

<Service> is the service name (contact name analog).  Domain name is
the name of the host supporting it.  <Ip-address> and <chaos-address>
are as in A RRs (note that <chaos-address is two fields, see
NAMEDROPPERS archives).  <port> 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 <ip-protocol-number> 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

Date: Thu, 15 May 1986  14:44 EDT
From: Rob Austein <[email-masked]>
To:   Robert Scott Lenoil <[email-masked]>
Cc:   [email-masked]
Subject: Athena's student center cluster

    Date: Wednesday, 14 May 1986  22:13-EDT
    From: Robert Scott Lenoil <[email-masked]>
    To:   [email-masked]
    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.

Date: Wed, 14 May 86 22:13:51 EDT
From: Robert Scott Lenoil <[email-masked]>
Subject: Athena's student center cluster
To: [email-masked]

I was just wondering why Athena's student center machines are in
syshst;hstg instead of syshst;hstath.

-Robert

Date: Mon, 27 Jan 1986  17:56 EST
From: Rob Austein <[email-masked]>
To:   [email-masked] (Jeffrey I. Schiller)
Cc:   [email-masked]
Subject: Ooops... I forgot to add LCS.MIT.EDU

    Date: Thursday, 16 January 1986  23:20-EST
    From: [email-masked] (Jeffrey I. Schiller)
    To:   Rob Austein <[email-masked]>
    cc:   [email-masked]
    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: <[email-masked]>
From: Rob Austein <[email-masked]>
To:   [email-masked]
cc:   [email-masked]
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

Date: Thu, 16 Jan 86 23:20:42 EST
From: [email-masked] (Jeffrey I. Schiller)
To: Rob Austein <[email-masked]>
Cc: [email-masked]
Subject: Ooops... I forgot to add LCS.MIT.EDU

I will get that next update (sometime tomorrow I would think).

			-Jeff

Date: Thu, 16 Jan 86 23:19:56 EST
From: [email-masked] (Jeffrey I. Schiller)
To: Rob Austein <[email-masked]>
Cc: [email-masked]
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 <[email-masked]>
Subject:  MC binary host table
To: [email-masked], [email-masked]
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:<SYSTEM>HOSTS3.BIN and the text form of
HSTMIT from XX:<HOSTS>HSTMIT.TXT.

Sorry for the short (one might even say negative) notice, but this was
an emergency fix.

--Rob

Date: Wed, 15 Jan 1986  15:37 EST
From: Rob Austein <[email-masked]>
To:   [email-masked] (Jeffrey I. Schiller)
Cc:   [email-masked]
Subject: Earth to Jeff, come in Jeff....

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

Date: Wed, 15 Jan 86 15:32:13 EST
From: [email-masked] (Jeffrey I. Schiller)
To: Rob Austein <[email-masked]>
Cc: [email-masked]
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: <[email-masked]>
From: Rob Austein <[email-masked]>
To:   [email-masked]
cc:   [email-masked]
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: <[email-masked]>
From: Rob Austein <[email-masked]>
To:   [email-masked]
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:<HOSTS>MAKDOM.C, as usual.

Date: Fri 10 Jan 86 02:32:42-EST
From: "J. Noel Chiappa" <[email-masked]>
Subject: Re: Delegation of LCS subnets
To: [email-masked], [email-masked]
cc: [email-masked], [email-masked]

	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: <[email-masked]>
From: Rob Austein <[email-masked]>
To:   [email-masked]
cc:   [email-masked]
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

Date: Tue, 7 Jan 86 08:00:00 est
From: [email-masked] (John Romkey)
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked],
        [email-masked]
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

Date: Tue, 7 Jan 1986  01:15 EST
From: Rob Austein <[email-masked]>
To:   "J. Noel Chiappa" <[email-masked]>
Cc:   [email-masked], [email-masked]
Subject: LCS portion of IN-ADDR domain

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.ORIGINAL>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" <[email-masked]>
Subject: Re: LCS portion of IN-ADDR domain
To: [email-masked], [email-masked]
cc: [email-masked], [email-masked]
Message-ID: <[email-masked]>

	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
-------

Date: Mon, 6 Jan 86 22:47:47 EST
From: [email-masked] (Jeffrey I. Schiller)
To: Rob Austein <SRA@MIT-XX>
Cc: [email-masked]
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: <[email-masked]>
From: Rob Austein <[email-masked]>
To:   [email-masked]
cc:   [email-masked]
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:<HOSTS>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

Date: Sun, 5 Jan 1986  12:32 EST
From: Rob Austein <[email-masked]>
To:   Chris Lindblad <[email-masked]>
Cc:   Alan Bawden <[email-masked]>, [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked]
Subject: Ick!

(Oh bleep, let's put this on namecallers and get it over with already).

    From: Chris Lindblad <[email-masked]>

    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 <[email-masked]>
Subject: IN-ADDR stuff for LCS
To: [email-masked]
CC: [email-masked]

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: <[email-masked]>
From: Rob Austein <[email-masked]>
To:   [email-masked], [email-masked]
cc:   [email-masked]
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

Date: Fri, 6 Dec 85 18:07:52 est
From: [email-masked] (John Romkey)
To: [email-masked]
Cc: [email-masked]
Subject: Host number assignment.

   Date: Thu, 5 Dec 1985  06:57 EST
   From: Rob Austein <[email-masked]>

   SUBNET : <subnet address> : <owning domain> :  ;<manditory comment>

   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" <[email-masked]>
Subject: Automatic generation of tables
To: [email-masked]
cc: [email-masked]
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

Date: Thu, 5 Dec 1985  06:57 EST
From: Rob Austein <[email-masked]>
To:   [email-masked]
Subject: Host number assignment.

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 : <subnet address> : <owning domain> :  ;<manditory comment>

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 <[email-masked]>
Subject: Re: Host number assignment.
To: [email-masked], [email-masked]
cc: [email-masked]
In-Reply-To: Message from "Rob Austein <[email-masked]>" 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
-------

Date: Thu, 5 Dec 1985  01:34 EST
From: Rob Austein <[email-masked]>
To:   [email-masked] (Jeffrey I. Schiller)
Cc:   [email-masked]
Subject: Host number assignment.

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:<hosts>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

Date: Thu, 5 Dec 85 00:09:36 est
From: [email-masked] (Jeffrey I. Schiller)
To: Namecallers@MIT-MC
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: <[email-masked]>
From: Rob Austein <[email-masked]>
To:   [email-masked] (Jeffrey I. Schiller)
Cc:   [email-masked]
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 : <address> {,<address>} : ; <comments, I hope>

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

Date: Wed, 4 Dec 85 21:58:36 est
From: [email-masked] (Jeffrey I. Schiller)
To: Namecallers@MC
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

Date: Mon 2 Dec 85 14:49:53-EST
From: "J. Noel Chiappa" <[email-masked]>
Subject: Re: Impending host table format change
To: [email-masked], [email-masked]
cc: [email-masked]

	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: <[email-masked]>
From: Rob Austein <[email-masked]>
To:   [email-masked], [email-masked]
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: <[email-masked]>
From: Rob Austein <[email-masked]>
To:   [email-masked]
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 : <domain> : <class> : <source>: <bug-address> : 
	 <serial> : <refresh> : <retry> : <expire> : <minimum> :
	 <nameserver> {<address>} {,<nameserver> {<address>}} :

The <address> 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 <serial>
field to be zero; in this case the <serial> 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

Date: Wed, 9 Oct 85 16:49 EDT
From: David C. Plummer <[email-masked]>
Subject: domain class for chaos
To: Gail Zacharias <[email-masked]>, [email-masked]
cc: [email-masked], [email-masked],
    [email-masked]

    Date: Wed,  9 Oct 85 15:05:09 EDT
    From: Gail Zacharias <[email-masked]>

	Date: Tue, 8 Oct 85 17:52 EDT
	From: David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
	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 <[email-masked]>
Subject:  domain class for chaos
To: [email-masked]
cc: [email-masked], [email-masked],
    [email-masked]
In-reply-to: Msg of Tue 8 Oct 85 17:52 EDT from David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
Message-ID: <[MIT-MC.ARPA].673861.851009.GZ>

    Date: Tue, 8 Oct 85 17:52 EDT
    From: David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
    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. 

Date: Tue, 8 Oct 85 17:52 EDT
From: David C. Plummer <[email-masked]>
Subject: re: domain class for chaos
To: [email-masked], [email-masked]
cc: [email-masked]

    Date:  7 Oct 1985 10:52:47 PDT
    From: [email-masked]

    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 <class> <class-specific-string>
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.

Date: Mon, 7 Oct 1985  17:48 EDT
From: Chris Lindblad <[email-masked]>
To:   [email-masked]
Cc:   [email-masked], [email-masked], [email-masked]
Subject: Domain class for chaos

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: [email-masked]
Subject: re: domain class for chaos
To:   [email-masked]
cc:   [email-masked]

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.
-------

Date: Mon, 7 Oct 85 10:48 EDT
From: David C. Plummer <[email-masked]>
Subject: Domain class for chaos
To: [email-masked], [email-masked], [email-masked]
cc: [email-masked], [email-masked]

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: [email-masked]
Subject: Domain class for chaos
To:   [email-masked], [email-masked]
cc:   [email-masked], [email-masked]

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:

<host number>.<subnet>.<chaos net id>.<origin>

The <host number> 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 <subnet> field corresponds to the high order 8 bits of a Chaosnet
address.  It will use the same representation as the <host number>.

The <chaos net id> 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 <origin> is a well known domain.  Perhaps 'CH-ADDR.<something>'.  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: <SRA.12141108301.BABYL@MIT-XX>
From: Rob Austein <SRA@MIT-XX>
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 <[email-masked]>
Subject:  [email-masked] -> OZ.AI.MIT.EDU
To: [email-masked]
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: <SRA.12137458798.BABYL@MIT-XX>
From: Rob Austein <SRA@MIT-XX>
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 <[email-masked]>
Subject: Re: Big guys in he top level namespace
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked]
In-Reply-To: Message from "Gail Zacharias <[email-masked]>" 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 <[email-masked]>
Subject:  Big guys in he top level namespace
To: [email-masked]
cc: [email-masked], [email-masked]
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 <[email-masked]>
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
-------

Date: Sat, 27 Jul 85 18:10:59 edt
From: [email-masked] (Jeffrey I. Schiller)
To: [email-masked]
Cc: [email-masked], [email-masked]
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 [email-masked].

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 <[email-masked]>
Subject:  Big guys in he top level namespace
To: [email-masked]
cc: [email-masked]
In-reply-to: Msg of Wed 24 Jul 85 00:40:17-EDT from J. Noel Chiappa <JNC at MIT-XX.ARPA>
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 <[email-masked]>
Subject: Re: Big guys in he top level namespace
To: [email-masked]
cc: [email-masked], [email-masked]
In-Reply-To: Message from ""J. Noel Chiappa" <[email-masked]>" 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" <[email-masked]>
Subject: Re: Big guys in he top level namespace
To: [email-masked], [email-masked]
cc: [email-masked]
In-Reply-To: Message from "David C. Plummer in disguise <[email-masked]>" 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
-------

Date: Wed, 24 Jul 85 11:52 EDT
From: David C. Plummer in disguise <[email-masked]>
Subject: Big guys in he top level namespace
To: J. Noel Chiappa <[email-masked]>, [email-masked]

    Date: Wed 24 Jul 85 00:40:17-EDT
    From: "J. Noel Chiappa" <[email-masked]>

	    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" <[email-masked]>
Subject: Big guys in he top level namespace
To: [email-masked]
cc: [email-masked]

	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....
-------

Date: Tue, 23 Jul 85 07:01 EDT
From: David C. Plummer in disguise <[email-masked]>
Subject: Yow, are we ad-hoc yet?
To: Christopher C. Stacy <[email-masked]>
cc: [email-masked]

    Date: Mon, 22 Jul 85 17:51:26 EDT
    From: Christopher C. Stacy <[email-masked]>

    (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 <[email-masked]>
Subject:  Yow, are we ad-hoc yet?
To: [email-masked]
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)))