Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt)

[Ted Lemon <[e-mail]>]

On Aug 23, 2004, at 5:23 AM, JINMEI Tatuya / 神明達哉 wrote:
> - even if the clients cannot get a response by the expiration, it
>   should continue sending Information-requests.  However, it can also
>   invalidate the expired information in some way, e.g., by preferring
>   a "last resort" default or by using other means of configuration.

Can you think of a real-world scenario where this would be the right 
thing to do?   I can't come up with one.   For example, if we wanted to 
fall back to some sort of link-local protocol, this wouldn't help us, 
because it would take too long.   I think that in just about any 
scenario where you'd think to benefit by switching to some other 
configuration scheme, the switch would happen much too late, using this 
mechanism, to be of any benefit.

So I think that we'd really be better off, as you suggest, renaming 
this the update timer.   If there's some other configuration mechanism 
to which we should fall back, I think we need another mechanism for 
deciding when to fall back to it, and that should probably be specified 
in the draft that describes the fallback mechanism.


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