[1171] in Commercialization & Privatization of the Internet
Re: Who wasn't at IETF.
daemon@ATHENA.MIT.EDU (Erik E. Fair" (Your Friendly Postm)
Tue Aug 13 07:08:22 1991
From: "Erik E. Fair" (Your Friendly Postmaster) <fair@apple.com>
In-Reply-To: <9108130831.AA09423@garuda.sics.se>
To: Craig Partridge <craig@sics.se>
Cc: com-priv@psi.com
Date: Tue, 13 Aug 91 03:35:18 -0700
I think that the Router Requirements document will be more successful
than Host Requirements. There are fewer router vendors probably by an
order of magnitude, and their stuff mostly works the same whether its
in an isolated LAN or not. Also, my impression is that all of the
serious router vendors are heavily involved in the IETF. This is a good
thing, to the extent that they are there to cooperate, rather than to
gain commercial advantage by FUDding the process.
To give you an idea of how badly off we are in getting the hosts done
right, let's take an area that I am familiar with: E-mail configuration.
We all are supposed to use fully qualified domain names on E-mail
addresses. The rules have said that for something like six years. And
yet, every day there is at least one, usually a dozen, letters with
unqualified return addresses on 'em, passing though apple.com to
internal destinations.
I have a script that scans my mail logs every night looking for this
sort of thing, and E-mailing the postmaster at the site that handed us
the letter (which may or may not be the source of the problem), a nice,
polite note explaining what the problem is, and what RFCs they ought to
check out, and so on. It is effective, but I have the feeling that I'm
raking the ocean (sometimes, however, people just moan at me for
having informed them of a problem (stev, this means you)).
I have helped several Fortune 500 corporations on a strictly informal
basis set up or fix their E-mail systems. Some of them had been
amazingly screwed up before I tried to help and, worse, in some of
them, finding someone who has even the vaguest clue of how this stuff
all is supposed to work is akin to Diogenes' search for an honest man.
Often, they didn't even know they had a problem.
Shall I talk about how often I get asked about the IP address of
AppleLink.Apple.COM by administrators who can't understand why it isn't
in their host table? (AppleLink is our so-called corporate E-mail
system; the answer is that it has no IP address, E-mail to it is done
with MX records and smoke and mirrors, and if you can't MX, you lose).
These days, this is mostly MILNET, but not always...
I'd love to see the DNS RoboDoc back. I heard it was politically
terminated with extreme prejudice, because It Knew Too Much, and Was
Gonna Name Names (and some high muckety mucks didn't think this was
appropriate). Given the time to write such a beast, I would have no
problems dedicating a macintosh to walk the DNS tree indefinitely,
looking for inconsistency, bad configuration, etc, and notifying
responsible parties with appropriately worded E-mail.
DNS consistency is a very big problem, and there are no tools or
operational procedures that I know of (aside from the RoboDoc) that
attempt to insure consistency throughout the system. I'm sure that
there are at least a dozen other hostmasters who feel as I do (and I'm
sure that they have just as much free time for such a project as I do -
that is, zero). Maybe there's a thesis in it, hey?
Slight shift of subject: Telephones are nice. There are a bunch of
standards that say how they should operate, none of which I've ever
read. I don't have to worry about it - they just work, out of the box,
when I hook it up to the jack on the wall. I can buy interconnection
parts at Radio Shack, etc.
What we'd like, I think, is to have potential Internet hosts operate
like a telephone. Ya hook 'em up to the wire, and they just work.
Trouble is, there are levels, and levels, and levels to this thing, and
it all has to work (up and down the protocol stack), and we haven't
beaten the system vendors senseless enough yet (need a bigger hammer).
However, it isn't all their fault. We haven't managed to get the word
out to the random system administrators about certain "phone numbers"
that everyone needs to know in order to use their "telephones" to best
advantage. Like 411 or 555-1212 (DNS), or 911 (your NOC emergency
phone), or that they have to ask the service provider for their own
phone number (the NIC for network numbers (!!)). And this metaphor
already looks like a balloon with too much air in it, but I think you
get the point.
There was a meeting of the "host configuration" working group at the
first IETF meeting that I attended (Stanford, 1989 I think). It was a
two hour debate over a rather serious chicken and egg problem (how to
get enough information to get started, well, that's a hard problem,
because you have to be partly started to get information). Sometimes
you just have to bite the bullet and decide certain things (that is,
REQUIRE certain things, and make assumptions) rather than leave every
variable open to fill-in-the-blank (Rob Pike has some things to say
about this in the context of window systems - ask him about X sometime).
This is one thing that AppleTalk has over IP - it puts configuration
hair in the routers, which administrators set up, rather than on the
hosts, which ordinary users set up. I think that we can all agree that
single-user-as-admin of a host is much more common these days than it
was in ye olde days of ARPANET, and that perhaps we should take away
some or all of the configurability of the hosts... (not, mind you, that
I'm advocating that we all switch to AppleTalk tomorrow - quite the
contrary; it has scaling problems which its designers are only now
coming to grips with. However, I think that some of the design
decisions in AppleTalk have merit when your goal is easy host
configuration (or no host configuration), and the Internet community
ought to take a close look at AppleTalk for possible mechanisms to
attack the host configuration problem).
Maybe now is the time to require that all routers implement a resource
location service which will tell a newfie host where to find an IP
number, DNS server, etc. If we had done it two years ago... Of course,
we don't want to put too much hair in the routers. Aside from
bankrupting the router companies by forcing them to hire too many
software people to implement all this stuff, with all that
configuration stuff in there, we might just force network admins back
into the arms of the bridge vendors (shudder). The horror of that
scenario isn't obvious to most until they're in it. Ask LLNL about
their Open LabNet sometime.
Just to make the tie-in to com-priv obvious, IP is not going to be a
"telephone" service until the "instrument" can mostly just plug in and
work (granting some minimum information on the part of the user about
its basic workings and use). The only close equivalent we can talk
about is the X.25 public data networks, but all they really do is
terminal service (and look how much trouble they have with just doing
*that*). We're trying to make a whole pile of distributed systems work
together in a cooperative fashion (E-mail, DNS, national filesystems,
etc), some on top of the others, often seat-of-the-pants. If you want
to talk to me, not only do you have to do your job right, I have to do
my job right, and the IP service vendor(s) have to do their jobs right.
The amazing part is not that the bear dances the waltz, but that the
bear dances at all.
There is a large market for a book that would explain the Internet top
to bottom, and How To Operate. If you doubt, ask O'Reilly & Associates
how well their Nutshell Handbooks are selling. Maybe the NIC should
give a copy of such a book away with every network number. UUNET does
a similar thing with the Nutshell handbook on the care and feeding of
UUCP, for their new UUCP subscribers. Rick Adams claims that it cut
their telephone support load a lot.
I wonder how much you had to know to successfully operate a car before
Henry Ford?
I hope that operating an Internet host doesn't always require the
equivalent of pilot's training (and have you noticed that a lot more
configuration errors are being described as "pilot" or "cockpit"
error these days? I hear that phrase a lot more lately).
The question is, how can the IETF change TCP/IP to require less
information on the part of the user and the administrator for
successful operation? Further, for the information that remains (i.e.
that which a potential operator *must* have), how do we effectively
disseminate it? I don't think that we've made a very good effort to get
the word out about documents like Host Requirements (but I recall that
Bob Braden didn't want people to be specifying the HR document in their
RFP/RFQ's, either. If I'm misremembering that, apologies).
Erik E. Fair apple!fair fair@apple.com
