Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!NSIPO.NASA.GOV!medin
From: medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: %-Hack .vs. Route Address
Message-ID: <9001100241.AA02167@cincsac.arc.nasa.gov>
Date: 10 Jan 90 02:41:35 GMT
References: <1988@uvaarpa.virginia.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 51


>There are special cases that won't be covered, but this solution DOES
>handle the case of PCs on an internal network or any other  such situation.
>The main case it won't (legally) handle is gatewaying to a network whose
>machines aren't under your theoretical administrative control.
>NASA's SPAN DECnet is circumventing this by having *.SPAN.NASA.GOV and
>I heartily approve of NASA's solution even though many nodes on that
>DECnet aren't owned or operated by NASA.

This was/is a hack to enable reasonable functionality for mail
relay to SPAN systems.  It's not the right thing to do, but was
expedient.  The reason it's not right is that SPAN is not run by
a single organizational unit (to use OSIspeak).  The right way
of skinning the cat would be to use individual MX records for
machines at sites to map them into the local domain name space
of the facility.

For example, a DECNET node named SAT located at Ames, should not
be addressed at user@sat.span.nasa.gov, but user @sat.arc.nasa.gov.  This
way, if the machine happens to speak IP (as it does), it could be
considered a CNAME for it's full hostname, or an MX record could
be used that points mail at an Ames local MAIL-11 relay system.  If
you use an MX record for *.span.nasa.gov, then all of it has to
go through a single mail relay.  You can get into the case of a JPL host
sending internet mail to a JPL DECNET host via a relay at ARC or GSFC.
If the JPL DECNET host had an MX record in the jpl.nasa.gov subdomain,
a more optimal path could be taken.  I think JPL actually does this,
but the point is the obvious.

The problem with this is that it means having all the individual
system administrators interacting with all the site domain managers
and whoever runs a relay at the site to fix things so they work
right, which is harder than fixing it once using the span.nasa.gov 
pseudodomain.

The same reason holds why a .BIT.NET or .CS.NET (or maybe .ONE.NET
these days I guess) is a bad idea.  Those systems really should reside
in a site's name local namespace.  If people obeyed these rules, Internet
mail delivery would be much more transparent, and the fact that a 
particular network (SPAN,BITNET,CSNET, etc...) was being used as
transport would be hidden from the users.  And that makes life easier
on them.  Why should 3 different forms of different address 
specifications be used to talk to 3 machines connected in different
ways at one site?


					Thanks,
					   Milo

PS All the usual disclaimers about the government not being responsible
for anything I say apply of course...