[11] in Hesiod
Re: question about HS class
daemon@ATHENA.MIT.EDU (Jerome H. Saltzer)
Thu Oct 27 12:12:21 1988
Date: Thu, 27 Oct 88 11:26:26 EDT
To: pma%hpcndm@hplabs.HP.COM
Cc: Win Treese <treese@ATHENA.MIT.EDU>,
In-Reply-To: pma%hpcndm@hplabs.HP.COM's message of Thu, 27 Oct 88 08:04:18 MST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> I would expect it to be more common that the name server
> administrators maintain TXT data (password entries for instance) than
> separate groups maintain TXT data. Since our administrators are
> handling more and more machines without more manpower, we have to make
> maintenance and set up as simple as possible. I expect it will be hard to
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.
The thing we discovered, as our site grew in size, is that there is a
natural division of responsibilities that leads to groups with very
different goals and reporting structure. The people who manage the
communications substrate (which includes assigning names for network
nodes) work with a set of procedures, attitudes, and response times
that are somewhat telephone-company-like in approach, while those who
manage remote network services (allocation and naming of disk space
in the NFS servers for example) work with a set of procedures,
attitudes, and response times that are more like those of a computing
center. If the authoritative data base used for managing both areas
is combined physically into a single structure that both must have
the ability to update, the stage is set for administrative disaster.
But if you design the system so that the two groups have distinct
data bases then the collision of values simply goes away.
I regard this separation as fairly fundamental, much like the
separation of responsibility that we went through when we stopped
having every host named in the root domain.
Jerry Saltzer
