Re: [dhcwg] Lifetime draft: refresh time should never be more thanIRT_DEFAULT

On Tue, Nov 09, 2004 at 05:34:09PM -0500, Bernie Volz wrote:
[...]
> Note that the draft says:
> 
>    When the client detects that the refresh time has expired, it SHOULD
>    try to update its configuration data by sending an Information-
>    Request as specified in section 18.1.5 of [RFC 3315], except that the
>    client MUST delay sending the first Information-Request by a random
>    amount of time between 0 and INF_MAX_DELAY.
> 
> So, the value is just *another* trigger, not the only trigger. There is NO
> language that says a client is prohibited from refreshing this information
> sooner.

It also says
   The information refresh time option specifies an upper bound for how
   long a client should wait before refreshing information retrieved
   from DHCPv6.

So I think this should be pretty clear.

> So, while we COULD have an upper bound, I don't see that this is that
> critical.
> 
> I do agree that the security section should point out that the client may
> not want to honor very long values. And, it already has something about
> this: "or with a large or infinite value which would be no worse than a
> client that does not make use of this option."

Yes, I also see problems with large values, and think some recommendation
like this should be sufficient. I'm a bit concerned with infinity perhaps.
If we don't think large values are good, do we want infinity?

I must say though, that I don't think this option changes much. Currently
you can also easily send clients forged responses listing wrong info, and
there's no telling when client will choose to update it. The triggers a
client currently uses, should still be used to refresh info when using
this option.

Stig

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg