🚀 go-pugleaf

In article <Added.8Y=x0ty00UkT4BcE8k@andrew.cmu.edu> morgan@JESSICA.STANFORD.EDU writes:
>[ Glen Marianko comments that AppleTalk's dynamic router discovery
>method leads to inefficient routing. ]
>
>Let's not (once again) bash AppleTalk for not being something it
>wasn't intended to be, and let's not forget you don't get something
>for nothing.
>
>[additional speculation as to Glen's 'problem']
>
>I consider the time I spend explaining to neophyte network
>administrators about default IP router addresses, and fixing
>misconfigured machines, to be the real "inefficiency".  I hope
>AppleTalk 2 doesn't lose too much ease of use in its pursuit of
>performance. 
>
> - RL "Bob" Morgan
>   Networking Systems
>   Stanford

I wholeheartedly agree with Bob.  Appletalk was not designed to be the
network to which the entire world could attach and operate efficiently.
I also sincerely hope that future versions of AppleTalk maintain the
ease of use and configurability that AppleTalk has today.  Not having to
configure addresses, paths, routers, etc., etc., etc., in my mind makes
up for any possible inefficiency.  I would hope that those areas which
may be of concern (e.g., routers) would be addressed WITHOUT mucking up
the existing AppleTalk protocols.  

Having been involved in networking software for over 12 years, I would
like to take this opportunity to thank Apple and the individuals involved
in the design of AppleTalk for bringing us a new (and IMHO, better) way
of doing things.

M. A. Pasek          Switching Software Development         NCR Comten, Inc.
(612) 638-7668              CNG Development               2700 N. Snelling Ave.
pasek@c10sd3.StPaul.NCR.COM                               Roseville, MN  55113