Browse Prior Art Database

Suggestions for improved host table distribution (RFC0849)

IP.com Disclosure Number: IPCOM000003896D
Original Publication Date: 1983-May-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 2 page(s) / 5K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

M.R. Crispin: AUTHOR

Abstract

This RFC may be something unique among modern-day RFC's, an RFC that actually is a request for comments. The issue dealt with is that of a naming registry update procedure, both as exists currently and what could exist in the future. None of the proposed solutions are intended as standards at this time; rather it is hoped that a general consensus will emerge as the appropriate solution, leaving eventually to the adoption of standards.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 59% of the total text.

Network Working Group Mark Crispin

Request for Comments: 849 Stanford

May 1983

SUGGESTIONS FOR IMPROVED HOST TABLE DISTRIBUTION

This RFC may be something unique among modern-day RFC's, an RFC

that actually is a request for comments. The issue dealt with is that

of a naming registry update procedure, both as exists currently and what

could exist in the future. None of the proposed solutions are intended

as standards at this time; rather it is hoped that a general consensus

will emerge as the appropriate solution, leaving eventually to the

adoption of standards.

THE PROBLEM

I am somewhat dissatisfied with the current level of Internet name

service and name registry updating. Each site is expected to

individually maintain a copy of the [SRI-NIC]HOSTS.TXT file,

and in fact has to, since SRI-NIC is simply not reliable enough to

depend upon as a name server. Neither the Tenex operating system nor

the Foonly computer are known for exceptional reliability or

performance. Probably they serve the NIC's internal operations well;

that is not at issue. What is needed is a name service that is

available at all times. Only then could a site sacrifice maintaining

its own local copy of "the host table".

The NIC indirectly acknowledges this, by providing a service by

which the entire Internet name registry can be dumped, as well as

ANONYMOUS FTP access to the HOSTS.TXT file. The problem is,

some individual has to know to retrieve the latest version of the file

from the NIC. The NIC has not always been careful to announce updates

to the name registry. My experience with maintaining an independent

name registry from the NIC's in the past leads me to appreciate the

NIC's problems.

There also seems to be no good automated way to cross-check the

version at the local site with the NIC's. It is clearly inefficient to

go to the effort of retrieving the same version of the host table that

already has been installed on site.

SOME SOLUTIONS

One could argue that a solution is to replace or augment the

present SRI-NIC system with VAX Unix system(s) dedicated to name service

and network information. A reliable and highly-responsive name service

would ultimately lead to the elimination of the necessity to maintain

copies of the registry locally. This solution requires money, time, and

effort, which may or may not be immediately available; it must therefore

be considered a longer-term solution.

A more short-term solution is to make possible faster and more

thorough updating of the various local copies of the name tables. I

have several suggestions in this area, and would like to hear comments

(I said this was an RFC that requested comments!):

(1) a new protocol by which the NIC could ship updated name

registries to the hosts itself. This would take t...