Subject: RE: [dhcwg] Another RFC 2131/2132 issue?

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Tue, 3 Oct 2006 15:13:25 -0400

Yes, and we wouldn't expect a client to reboot itself on a RENEW if the
boot server and/or boot file changed in the options it got back.

I think the DHCP client *SHOULD* "set" the new configuration settings
(and remove those that might have disappeared) so that when that
configuration value is next needed by the client (ie, an application
running on the client), the newer value is used.

- Bernie

-----Original Message-----
From: David W. Hankins [mailto:[email-masked]] 
Sent: Tuesday, October 03, 2006 2:58 PM
To: [email-masked]
Subject: Re: [dhcwg] Another RFC 2131/2132 issue?

On Tue, Oct 03, 2006 at 10:30:33AM -0700, Ted Lemon wrote:
> Yup, we've talked about this before.   I think the consensus at this 
> point is that the client should use the new parameters.   Definitely 
> something that needs to be added if we do an RFC2131/2132 reissue.

To a certain extent, this can't be helped.  Some applications
consume the configuration value when they start running, and need
to be restarted to fetch the new value from the system.

-- 
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DDNS & DHCP.  Email [email-masked].
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 3 Oct 2006 13:17:48 -0700

> running on the client), the newer value is used.

I think that is the best wisdom that can reasonably be offered.