At Tue, 11 Feb 2003 13:52:08 +0100 (CET), Erik Nordmark wrote:
I think there are some tradeoffs to take into account between e.g.
securing a single channel for configuration information (between the
client and the DHCP server) with the DHCP server being a single point
of failure, and securing N channels to N entities providing
configuration information co-located with the actual service (with fate
sharing between the configuration entity and the sevice itself).
I'm sure there are other tradeoffs as well.
- Configuring vs reconfiguring: in the latter case given an adaquate
caching scheme (and an adaquate implementation, grr), one is probably
in a better position to keep going if the configuration system
(whether monolithic or distributed) is on the blink.
- Single config protocol vs multiple config protocol: not the same
thing as Erik's single point of failure vs co-location tradeoff, one
could use a single protocol with the co-location model, so that
one's toaster would only have to implement one config protocol
(applies both to client toasters and server toasters). Oh, right,
this is supposed to be a tradeoff, well, I suppose that having N
separate protocols to do the same thing is good for the economy :).
in the case where I have a DHCP server controlled by someone-not-me (some
ISPs seem to want to run DHCP for their customers, for some reason), having
a separate mechanism for configuring stuff the DHCP server's owner doesn't
care about seems like a Good Idea.