Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!sun-barr!ames!cincsac.arc.nasa.gov!medin From: medin@cincsac.arc.nasa.gov (Milo S. Medin) Newsgroups: comp.protocols.appletalk Subject: Re: Appletalk Phase II Message-ID: <27296@ames.arc.nasa.gov> Date: 20 Jun 89 19:45:10 GMT References: Sender: usenet@ames.arc.nasa.gov Lines: 75 In article , REWING@TRINCC.BITNET writes: > Milo's comments regarding Appletalk may have had some valid points in > phase I Appletalk, but I thin he's missing the point regarding Appletalk's > functionality. There are those in this world that believe that TCP/IP is the > end all, be all network that everyone should adopt, bar none. While > IP has its definite advantages, have you ever tried to set up an IP network? Actually, I design IP networks for a living. I'm the lead engineer on the NASA Science Internet Project, building international networks for NASA Science. So yes, I do it all the time. So do naive users who install SUN's out of the box... > Ever try to add new users? Does anyone really know what "192.32.2.0" means? Actually, it's not that hard. You can use a number of tools like rarp for address assignment. Ever wonder how a diskless workstation gets it's address? Same sort of problem... > Do you really want to do that kind of support? Oh sure, setting up your > favorite Sun, Apollo, Vax or Cray on time might be okay. But most > Mac sites are hardly static, as people come and go, students come and go, > and devices and added and removed from the net more frequently. Appletalk > was built with ease of use in mind. Sure its not the most efficient > protocol in the world. But that's hardly a reason to pick-up IP just because > of throughput benchmarks. Again, it's not that hard, you could modify the tools to do much of this dynamically, much as Kboxes assign IP addresses dynamically to Mac's now... Ease of use eh? What happens when you have 50-100 appletalk nets all trying to interoperate with each other? How easy is it to make that work? A lot harder than the equivalent IP or DECNET networks... > The old Appletalk was admittedly a "renegade" protocol on Ethernet, forcing > every non Macintosh to listen to everything it broadcasted. The new > Appletalk is IEEE accepted, as the structure of its new packets indicates, > just like IP and Decnet. Now your Suns, Cray, or other machines no > longer have to listen to Mac packets, unless they want to. > That wasn't the point. The point is you guys are trying to kludge appletalk into being an real Internet protocol, and ignoring real internet protocols that exist today and are widely used. It's not just IP, there's DECNET and even some CLNP. The new Appletalk may be IEEE accepted, but do you use 802.2 LLC underneath? No. Just because it's documented doesn't mean it's a good thing. You are now standard in the ethernet MAC header. I'll grant that. > (continued in next message) > > -_Rick Ewing > Apple Atlanta > REWING@APPLE.COM The bottom line is not that IP or DECNET or OSI networks are easier to install and manage than ATP. The point is that they could easily be made that way using existing tools. It's a user interface issue, not a protocol architecture issue. It would have taken a lot less effort to build simple tools for IP to look as friendly as ATP compared to the amount of work put into building an inferior protocol from scratch. Instead, Apple built something completely different. And all those management tools and routing protocols and other things we use to solve problems in the IP world can't be leveraged in the Apple world. Sure, maybe it's not so bad when dealing with tiny networks. But one thing they certainly should have realized from networking experience is that sucessful small systems all turn into large systems. If you design with limited expectations, you outstrip the architecture when users try and build larger systems. And all of us have to suffer with the consequences. Thanks, Milo