Re: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02

[Tim Chown <[e-mail]>]

On Thu, Aug 26, 2004 at 08:10:09AM -0400, Bernie Volz wrote:
> > 
> > Do you think it's ok that client might update information if 
> > a server becomes unreachable? Say you learn DNS or NTP server 
> > address from DHCP, and at some point the resolver or NTP 
> > client determines that it can't reach the server. Would it 
> > then be ok to make the dhcp client request new data? An issue 
> > might be that if a server goes down, thousands of clients may 
> > try to update their DHCP config almost simultaneously... I'm 
> > only trying to give an example though, but is it a good one?
> 
> NO. Like Rich, I think this would be an extremely bad idea. Let's remove it.
> 
> I'd replace the two above paragraphs with:
> 
>   The Information Refresh Time option's time is an upper bound as to when
>   the client SHOULD refresh its configuration information. A client MAY
>   refresh this information before this time, such as if one or more
>   prefixes for addresses in the configuration information expire.

That sounds fine to me.  
 
> > |  Note that this also means that it doesn't make sense to have  
> > | different refresh time options for different data, since when the  
> > | client has reason to refresh some of its data, it should 
> > also  refresh 
> > | the remaining data.
> 
> I'd reword this to simply state that there is ONE time for all configuration
> data.

Also fine by me.  Less is more :)
 
> > |  In some cases the client uses a default refresh time IRT_DEFAULT.  
> > | The recommended value for IRT_DEFAULT is 86400 (24 hours).  The  
> > | client implementation should allow for this value to be configured.
> > 
> > What do you think of 24 hours? I've got suggestions for 1, 
> > 6-12, at least 12 hours and more from you.
> 
> I like 24 hours.

The value will depend on the environment.  I think if the admin knows the
environment is one liable to be changed, they will make active use of this
timer, if not, then it'll be a typical (relatively) static environment in
which case 24 hours would be ample.   In the event of a major change, the
admin can ramp it down.
 
> > Do you agree with a minimum like this? It should make it 
> > harder to do bad things, and I don't see a use for <10 
> > minutes. If <600, would you rather use 600 than IRT_DEFAULT?
> 
> As I suggested it, I like it. Perhaps we should specify IRT_MINIMUM as a
> parameter?

I think this is an interesting suggestion.  Again, it depends on the
environment.  If it's a renumbering event, and a document like Fred Baker's
without-a-flag-day draft is followed, the minimum value can certainly be 
higher than 10 minutes.   One would assume in that type of renumbering
environment the old and new prefixes coexist for some time.   If a DNS
or NTP server is being turned off/phased out, then the replacement should
be made available in advance.   The awkward case is where there is a
sudden transition between (DNS, NTP, etc) servers or networks, but these
are I believe typically user, not administrator, driven.

Tim

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