[12] in Hesiod
Re: question about HS class
daemon@ATHENA.MIT.EDU (pma%hpcndm@hplabs.HP.COM)
Thu Oct 27 12:33:26 1988
To: Jerome H. Saltzer <Saltzer%ATHENA.MIT.EDU%hplabs@hplabs.HP.COM>
Cc: hesiod%ATHENA.MIT.EDU%hplabs@hplabs.HP.COM
In-Reply-To: Your message of Thu, 27 Oct 88 11:26:26 -0400.
Date: Thu, 27 Oct 88 10:03:21 MST
From: pma%hpcndm@hplabs.HP.COM
> That is certainly an important consideration, but there is something
> else quite fundamental going on here. In the same way that the
> domain name system is designed to decentralize and distribute the
> administration of the name space, the use of a new class for Hesiod
> data has as its real purpose the distribution of administration.
Since decentralization has occured in naming already, why decentralize
with another class when the same can be achieved by naming in the IN class?
Suppose you have the system admins managing passwords and home directories
and another group managing data from project A. What will happen is that
both groups will have name servers for their particular data and delegation
for each type of data will occur within the HS class. The same delegation
can happen in the IN class. Admin handles passwd.athena.mit.edu and
filsys.athena.mit.edu and project A handles projecta.athena.mit.edu.
RFC1034 says "The most common reasons for creating a new class are the
necessity for a new data format for existing types or a desire for a
spearately managed version of the existing name space." (page 19) So,
chosing a new class to distribute administration is not against the spirit
of the RFCs. I'm only saying that for general consumption the easier it
use, the more it will be used.
Another thought:
Suppose admins want to put TXT data next to existing data,
which class should they use?
foo IN A 1.1.1.1
IN TXT "LOCATION: room 252 building 3"
IN TXT "PROJECT: graphics development"
or should the TXT data be in the HS tree under foo.generalinfo?
paul
