Re: musings

stev knowles <stev@precision.guesswork.com> Fri, 17 May 1996 16:20 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17451; 17 May 96 12:20 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17447; 17 May 96 12:20 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa10613; 17 May 96 12:20 EDT
Received: by zephyr.isi.edu (5.65c/5.61+local-23) id <AA24994>; Fri, 17 May 1996 09:01:05 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id <AA24975>; Fri, 17 May 1996 09:01:03 -0700
Received: from Precision.Guesswork.Com ([204.17.152.100]) by venera.isi.edu (5.65c/5.61+local-23) id <AA00820>; Fri, 17 May 1996 09:00:39 -0700
Received: from Precision.Guesswork.Com by Precision.Guesswork.Com ; Fri, 17 May 96 11:59:22 EDT
Received: from woburn ([206.34.72.126]) by Precision.Guesswork.Com ; Fri, 17 May 96 11:59:22 EDT
Message-Id: <2.2.32.19960517120136.002de000@mail.guesswork.com>
X-Sender: stev@mail.guesswork.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 17 May 1996 12:01:36 +0000
To: Mike O'Dell <mo@uunet.uu.net>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: stev knowles <stev@precision.guesswork.com>
Subject: Re: musings
Cc: Mike O'Dell <mo@uunet.uu.net>, Fred Baker <fred@cisco.com>, braden@isi.edu, rreq@isi.edu
X-Orig-Sender: owner-rreq@isi.edu
Precedence: bulk

sometime around 11:20 AM 5/17/1996 -0400, Mike O'Dell wrote us a message
containing:

>in complex environments, however, you don't want boxes deciding
>things on their own because you have no way of knowing what
>all it decided. and if it decides to listen to and repeat RIP,
>or pick its own address, or any of a few dozen other terrifying things
>I've *seen* boxes try to do to "help" you, you can be very truly
>screwed in a BIG way and it can take many hundred hours to locate.

while i agree with you about it helping with routing protocols (RIP is not
the only one, i probably dont want it peering with anyone else, either. on
the other hand, i would like it to tell me about what it sees)

>the example you cite could be because one end of the line is
>actually mis-configured, but yet it would still start working
>and the error would not be discovered for some time. that is 
>very bad.

hey, if you assume everything is OK just because the line comes up, you
deserve to lose. the line coming up at least lets you see what is going on,
and then you can go in and decide that you actually wanted the CISCO
protocol rather than PPP.

when UUNET is installing routers, i imagine that they are first unpacked,
and then configured, before being deployed. if uunet is connecting other
people's routers, i would *imagine* that getting the line up *at all* would
be a big win. it has got to be easier to fix problems when you can talk to
the remote end directly, rather than having to *believe* what that voice on
the other end is telling you.

>so there *does* need to be ONE switch with two positions on the
>outside:
>
>	"Zealous Mode" and "Obedient Mode"
>
>you can even ship it with the switch clearly in Zealous Mode, but
>I will change it to "Obedient Mode" when I install it.

so, since you are going over the boxes before anyway, i am sure you will get
all the configuration set correctly before it ever sees a production wire,
so why the flame?

>As Rob Pike once said,
>
>	"Most (terminals) which are described as *intellegent*
>	 are actually just smartass."
>
>same goes for network elements in my book.


well, i believe that the network should be as self configuring as possible .
. . i suppose that is just something we will have to disagree on forever. . . .