home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 800s / rfc849.txt < prev    next >
Text File  |  1992-09-22  |  5KB  |  113 lines
  1. Network Working Group                                       Mark Crispin
  2. Request for Comments: 849                                       Stanford
  3.                                                                 May 1983
  4.  
  5.  
  6.             SUGGESTIONS FOR IMPROVED HOST TABLE DISTRIBUTION
  7.  
  8.      This RFC may be something unique among modern-day RFC's, an RFC
  9. that actually is a request for comments.  The issue dealt with is that
  10. of a naming registry update procedure, both as exists currently and what
  11. could exist in the future.  None of the proposed solutions are intended
  12. as standards at this time; rather it is hoped that a general consensus
  13. will emerge as the appropriate solution, leaving eventually to the
  14. adoption of standards.
  15.  
  16.                                 THE PROBLEM
  17.  
  18.      I am somewhat dissatisfied with the current level of Internet name
  19. service and name registry updating.  Each site is expected to
  20. individually maintain a copy of the [SRI-NIC]<NETINFO>HOSTS.TXT file,
  21. and in fact has to, since SRI-NIC is simply not reliable enough to
  22. depend upon as a name server.  Neither the Tenex operating system nor
  23. the Foonly computer are known for exceptional reliability or
  24. performance.  Probably they serve the NIC's internal operations well;
  25. that is not at issue.  What is needed is a name service that is
  26. available at all times.  Only then could a site sacrifice maintaining
  27. its own local copy of "the host table".
  28.  
  29.      The NIC indirectly acknowledges this, by providing a service by
  30. which the entire Internet name registry can be dumped, as well as
  31. ANONYMOUS FTP access to the <NETINFO>HOSTS.TXT file.  The problem is,
  32. some individual has to know to retrieve the latest version of the file
  33. from the NIC.  The NIC has not always been careful to announce updates
  34. to the name registry.  My experience with maintaining an independent
  35. name registry from the NIC's in the past leads me to appreciate the
  36. NIC's problems.
  37.  
  38.      There also seems to be no good automated way to cross-check the
  39. version at the local site with the NIC's.  It is clearly inefficient to
  40. go to the effort of retrieving the same version of the host table that
  41. already has been installed on site.
  42.  
  43.                              SOME SOLUTIONS
  44.  
  45.      One could argue that a solution is to replace or augment the
  46. present SRI-NIC system with VAX Unix system(s) dedicated to name service
  47. and network information.  A reliable and highly-responsive name service
  48. would ultimately lead to the elimination of the necessity to maintain
  49. copies of the registry locally.  This solution requires money, time, and
  50. effort, which may or may not be immediately available; it must therefore
  51. be considered a longer-term solution.
  52.  
  53.  
  54.  
  55. Crispin                                                         [Page 1]
  56.  
  57.      A more short-term solution is to make possible faster and more
  58. thorough updating of the various local copies of the name tables.  I
  59. have several suggestions in this area, and would like to hear comments
  60. (I said this was an RFC that requested comments!):
  61.  
  62.      (1) a new protocol by which the NIC could ship updated name
  63. registries to the hosts itself.  This would take the form of a server
  64. process on each site listening on a registered port for updates from
  65. certain "trusted" sites (specifically SRI-NIC but possibly other sites
  66. as well).  This would allow for nearly immediate updates for cooperating
  67. sites, provided that the hosts in question are up.  There should be some
  68. sort of checksum applied to the updated name registry, to make sure it
  69. arrived complete and intact.
  70.  
  71.      (2) a new protocol by which the NIC will report the current
  72. "version" of the host table.  Tenex and TOPS-20 sites would find the use
  73. of the file generation number natural.  I presently maintain a
  74. SYSTEM:HOSTS.TXT with the same generation as it existed on the NIC, and
  75. just check at the NIC from time to time to see if the generation number
  76. changed there.  I would like to automate this.
  77.  
  78.      (3) A variation on (1), whereby the NIC would mail the updated host
  79. table to a mailing list of "host table update" recepients and each site
  80. would establish its own update procedures.  This is the simplest to
  81. implement for the NIC, but is fraught with all sorts of problems.  Mail
  82. is not a good means for bulk-shipping files to many recepients,
  83. especially when the files are likely to become hugh.
  84.  
  85.      I like (1) best of these three, because that would guarantee
  86. immediate updating without a local necessity to periodically poll the
  87. NIC.  That does place the burden on the NIC to make sure all sites
  88. receive the update, and also requires that the NIC remember which sites
  89. are dead to retry the update later.  This leads me to what I think is
  90. the best solution, which is:
  91.  
  92.      (4) A combination of (1) and (2).  The NIC will ship updates to all
  93. hosts which are registered with it to receive the updates, and will try
  94. only once.  Each site, as part of its system startup procedure, will run
  95. a program to poll the NIC for a possible update and if one is available
  96. retrieve it.  As a backup, there could also be a periodic poll on, say,
  97. a daily basis.
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111. Crispin                                                         [Page 2]
  112.  
  113.