Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!GIPSI.GIPSI.FR!philipp
From: philipp@GIPSI.GIPSI.FR (Philippe Prindeville)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: Network names via DNS
Message-ID: <9003152010.AA14482@Gipsi.Gipsi.Fr>
Date: 15 Mar 90 22:10:23 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 39


	The point is that the code will have nothing to look up unless
	somebody puts the data there.

Yes, I understand.  By utilizing it (via the 4.4BSD getnetent() function)
one creates a demand for it (perhaps), and hopefully people will put
the data where they ought to.
	
	My view of what RFC1101 should have done was to have a NIC-created
	database which served as either a backstop or an initial database
	which would be delegated away a la IN-ADDR.ARPA.

And yes, you can prep IN-ADDR.ARPA with data from the hosttable, but
it will become out of data unless people get into the habit of
maintaining it (and even though gethostbyaddr() uses the IN-ADDR.ARPA
domain, that in itself has not assured that everyone maintains their
domain space).

Part of the problem is that when most people register a domain, they
are not compelled (by their top-level domain's authority or even by
disgruntled users) to maintain this information.  Even if the process
of registration required that the database be set-up, that would still
not guarrantee that it was keep up-to-date.  The name of the game is
"entropy".

Perhaps inverse queries (despite the computational burden) would
have been the "right" way to go.

Once network management takes off (ie. SNMP is as widespread as RIP
unfortunately is), then perhaps we will start seeing RFC-1101 in use.

	The folks at the meeting were adamant that the data be in the already
	allocated IN-ADDR.ARPA name space so that no new domains need be
	created.  Of course, the NIC wasn't thrilled by a new job to do.

Yes, it's funny how these distributed databases increase the burden
on the NIC...

-Philip