Peter Memishian writes: > > > The scope of what the daemon controls seems to be dependent on > > implementation artifact rather than anything inherent about the > > operation of the protocol, so that doesn't sound like the right answer > > to me. > > It is intended to be inherent -- the only thing that's supposed to be > configured is IP address (and its prefix length). The route thing is a > mistake. (I suppose there could be cases where one didn't want the IP > address, but that seems a bit strange -- DHCPINFORM seems a better fit > there.)
I'm afraid I just don't get it. From an administrator's point of view, what's more obvious about (say) the subnet mask versus a print server address? Aren't they configured in roughly the same way as far as the protocol is concerned? I don't get why an administrator would or should expect that DHCP shuts itself down when some server-supplied parameters are overridden, but doesn't do so when others are overridden. You've given a definition -- ones that the client configures -- that depends on the implementation of the client. Is there a definition that doesn't depend on the implementation? > > There's an argument (albeit a weak one, I think) to be made that the > > IP address is "special" because it's associated with a lease, unlike > > all the other parameters, and thus touching that value has "special" > > consequences. Maybe. > > Yes, that's basically my argument. Is the mask part of the lease? > > A similar thing doesn't happen with ~IFF_UP change? Wouldn't the > > acquisition of a new lease possibly change the address in that case, > > and probably also cause IFF_UP to be reinstated? > > In order to acquire the new lease, at least one address on the interface > would have to be IFF_UP (which wouldn't happen in the if_mpadm(1M) case, > but could happen in the more general case). Also, in the IFF_UP case, at > worst the machine will end up another IFF_UP IP address -- no existing > IFF_UP IP address will get clobbered. Either way, you end up with a possibly unexpected situation, which was my point. > > [This is where NWAM could insert an alternative based on > > setting the desired override parameter as part of some > > profile.] > > Yes, we could document it -- or we could leave the current behavior. > Personally, I find the IFF_UP change easier to justify. I can live with it. It just seems incomplete. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
