Return to BSD News archive
Xref: sserve comp.os.linux.development:22853 comp.os.386bsd.development:3078 Newsgroups: comp.os.linux.development,comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msunews!uwm.edu!spool.mu.edu!howland.reston.ans.net!pipex!uunet!easix!news.uni-stuttgart.de!rz.uni-karlsruhe.de!stepsun.uni-kl.de!sun.rhrk.uni-kl.de!weber From: weber@rhrk.uni-kl.de (Christoph Weber-Fahr [KIT]) Subject: Re: SAMBA and NETWARE mounting Message-ID: <1995Jan26.162507.26091@rhrk.uni-kl.de> Organization: University of Kaiserslautern, Germany References: <3eo2j1$l5o@uqcspe.cs.uq.oz.au> <D267uw.Grq@park.uvsc.edu> <D2JnoD.1DD@pe1chl.ampr.org> <D2KG6E.CMp@park.uvsc.edu> <D2LH48.3IF@pe1chl.ampr.org> <D2qACr.A46@park.uvsc.edu> <D2s16r.428@pe1chl.ampr.org> <D2vrE0.D8M@park.uvsc.edu> <D2x440.1J1@pe1chl.ampr.org> <D2z554.K4F@park.uvsc.edu> Date: Thu, 26 Jan 1995 16:25:07 GMT Lines: 133 Terry Lambert <terry@cs.weber.edu> writes: >rob@pe1chl.ampr.org (Rob Janssen) wrote: >] >] In <D2vrE0.D8M@park.uvsc.edu> Terry Lambert <terry@cs.weber.edu> writes: >] >The MAIN advantage of IP is universality. >] > >] >The MAIN advantage of IPX is "well, we already bought into it". >] >] Here you are just proving my point. You are quoting an advantage of >] IP, and for IPX you quote something that could just as well be called >] a disadvantage. >] Why can't you just approach the issue from a neutral standpoint? >OK, neutrally speaking, what would you point to as the main >advantage of IPX? He already said so. Larger address space. I would like to add: Automatic configuration of network and station adresses at ordinary (non routing) systems. >Please be sure to include NetWare/IP (NCP over IP instead of IPX) >in your analysis before you answer. See above. >] Say, you want a network filesystem for your department, and it needs >] to serve a number of DOS/Windows and similar workstations. It needs >] some security (not against sniffers, but against accessing confidential >] data at will), and it should perform reasonably well. Some memory >] should be left in the PC after it has been loaded. >Stuff and nonsense! NCP is a protocol that HAPPENS to be on top of >IPX, and NFS is a protocol that HAPPENS to be on IP, and the point >of view you are defending relies LARGELY on a circumstantial >relationship between the file sharing protocols and the transport >protocols they happen to be using. This is *NOT* a causal >relationship, and you should quit portraying it as such. You simply won't get what you describe here. Netware/IP effectively doubles the system cost, simply for using NCP on top of IP instead of IPX. >You want a technical attack on IPX? OK, how about the lack of >packet checksums? As long as you have them on the media level, one might argue that you don't need them at the protocol level. Moreover, AFAIK they _are_ in the IPX spec anyway, but not implemented on the usual media. > How about the misimplementation of the 802.3 >protocol encapsulation header? You refer to a specific IPX implementation, which is obsolete for a number of years now (though still widely used) ? >That the NCP implementation you have runs over IPX is not a >supporting argument for IPX, unless you are taking me up on the >definition of IPX as a legacy system. As long as IPX is currently the only practical way to get this implementation, I would count that as a good practical point of view. (and don't tell me Netware/IP - there are better ways to burn money). >] Also, there is a MODEM pool which is to be accessed from the PCs, and >] of course there are some printers. >Much of the NetWare print model is a joke. The lpr protocol at >least does not use timeouts to indicate end-of-job! Netware doesn't either, but has a clear well defined print job concept. The mere fact that utilities that try to emulate a locally attached printer port must use timeouts, simply because braindead DOS software insists in using these ports doesn't mean there aren't more clean ways to send data to a Netware printing queue. [...] >] Access to other applications via the network is nice, but not the primary >] reason for deploying the network. >] >] What are you going to select? NFS clients on a UNIX server??? Come on... >How about NCP clients over an IP transport to NetWare for UNIX? >That buys me both the ability to throw away all of the IPX issues >and concentrate on a single network transport protocol framework. This buys you in the first place a nice red box that enables you to use all the things you've already bought before, and nothing more. It buys you, at best, about 20k of free memory in every PC using it, provided you have already used Lan Workplace or PC/TCP before. Else ? Well, in small and medium sized installation using and routing IPX is as painless as it could be. In large installations, you probably already have equipmant that can handle IPX as well as IP, so why bother ? On the downside, you are now the proud owner of a number of hassles you possibly didn't have before - you suddenly start administrating IP numbers for every f* PC you have on the net, you have to worry about subnet numbers, correct (default) router entries, nameserver configurations ect etc. >Admittedly the self-tunneled IPX in the NetWare/IP product is a >kludge, but it's less of a kludge than replacing all of the Cisco >and Kalpana boxes on the planet with Novell Servers running the >multiprotocol router NLM. Why the hell do you want to replace CISCo routers ? They route IPX quite well. (I associate Kalpana primarily with Ethernet switches, so I don't know where the problem should be in this case). >This assumes that you are willing to make the latency trade off >inherent in NCP's request/response architecture ...which is not correct for current implementations... >for your security >issues, which boil down to you either improperly firewalling your >network or you allowing untrustworthy individuals inside your >secure zone. Both of these are administrative failures. Every University is, from this point of view, an administrative failure. Most Companies are - generally spoken, DOS is an administrative failure. Regards Christoph Weber-Fahr -- Christoph Weber-Fahr | E-Mail: weber@rhrk.uni-kl.de Universitaet Kaiserslautern, KIT | S-Mail: Postfach 3049 Tel. 0631/205-3391 | D-67653 Kaiserslautern -------------------------- My personal opinion only ---------------------