> 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.) > 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. > > My concern is that after the renew fails, the client will obtain a new > > lease and clobber the statically configured address. Given that the lease > > might be days or even weeks long, that's a long time between cause and > > effect -- and likely to be seriously inconvenient when it does occur. > > 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. > Anyway, yes, I agree that'd be a bit annoying. The documentation > should be clear: > > If you change a DHCP-configured parameter manually, your > change will remain in effect as long as the DHCP server > doesn't provide a different value for that parameter. > However, if the server changes the parameter on a subsequent > lease renewal -- which may well be days or weeks after you > last modified the value. > > If you want your manually-configured values to remain in > force, you should use an infinite lease time, change the > server to provide the desired values, or terminate DHCP > service for that interface. > > [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. -- meem
