home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / protocol / nfs / 2704 < prev    next >
Encoding:
Text File  |  1992-11-06  |  1.9 KB  |  48 lines
  1. Newsgroups: comp.protocols.nfs
  2. Path: sparky!uunet!utcsri!torn!watserv2.uwaterloo.ca!watserv1!sunee.uwaterloo.ca!erick
  3. From: erick@sunee.uwaterloo.ca (Erick Engelke)
  4. Subject: Re: PC-NFS and Bootp
  5. Message-ID: <Bx9IDx.5ss@watserv1.uwaterloo.ca>
  6. Sender: news@watserv1.uwaterloo.ca
  7. Organization: University of Waterloo
  8. References: <Bx7pzE.6DL@willamette.edu> <1db96aINN4b4@seven-up.East.Sun.COM>
  9. Date: Thu, 5 Nov 1992 21:29:56 GMT
  10. Lines: 36
  11.  
  12. geoff@tyger.Eng.Sun.COM writes:
  13. >Quoth dan@willamette.edu (Dan Revel) (in <Bx7pzE.6DL@willamette.edu>):
  14. >#I would like to be able to use BOOTP to provide boot info (ip address,
  15. >#etc.) to our PC-NFS clients.  Right now they are RARPing, but I would
  16. >#like to be able to set up clients on a subnet that does not have a RARP
  17. >#server.  Is this possible?  Is it the 'right' approach?
  18. >
  19. >Our current thinking (*not* committed product plans, please note!) is
  20. >that we'll skip BOOTP and adopt DHCP, which is a much more complete
  21. >solution.
  22.  
  23. I would suggest adopting widely supported standards before
  24. soon-to-be-ratified replacements for standards which may offer
  25. more but are not widely available.  Sure, adopt DHCP, but please
  26. think of BOOTP first.
  27.  
  28. Just remember (ooops, Sun guy, better not mention NeFS)...
  29. all the various transports and alternative mail and file
  30. exchange protocols which we have seen get RFCed and which
  31. never caught on despite their obvious superiority.
  32.  
  33. I know I going to get a few flames from selfconcious OSIers
  34. who think I'm talking about them. Don't bother, this is
  35. honestly a post about IP based protocols.
  36.  
  37.  
  38. >.... Bear in mind
  39. >that DHCP is still not an RFC, though the client-server protocol seems
  40. >essentially stable. 
  41.  
  42. Erick
  43.  
  44. -- 
  45. ----------------------------------------------------------------------------
  46. Erick Engelke                                 WATTCP Architect
  47. erick@development.uwaterloo.ca     TCP/IP was easy but i still can't work VI
  48.