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

JINMEI Tatuya / 神明達哉 wrote:
> (Sorry for the delay in response)
>
> I've changed the title since I'm concentrating on this particular
> issue.
>
> Instead of making a response to each sub-issue (attached below), let
> me raise a more fundamental concern.
>
> Perhaps I'm just pedantic, but the current behavior of the lifetime
> option, however clearly it is defined, does not sound like a
> "lifetime" that I would envision.  To me, if a lifetime of some
> information expires, the information should be invalid (in some
> sense).  But the current behavior described in dhc-lifetime-01 does
> not seem to invalidate the information in any way; the "lifetime"
> would rather seem like an "update timer" or something.
>
> One obvious "fix" to this is to change the option name to something
> like "Information Update Timer" option (too long?).
>
> However, I personally would like to leave the possibility of
> invalidating the information on lifetime expiry.  With this sense I'd
> imagine something like this:
>
> - the option name ("lifetime option") is the same
> - the client starts re-sending Information-Requests at some point in
>   time to the expiration.  (e.g. a half of the lifetime)
> - 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.
>
> What do others think?

I also noticed the difference in semantics for this option versus address 
lifetimes.

If the lifetime option means that any option associated with it is no longer 
valid at expiration, then a client needs to start the message exchange before 
the lifetime expires.  Otherwise, normal processing will leave a client 
system without critical information (probably dns) for a second or two under 
normal processing.

For example, when the lifetime expires, the options associated with it will be 
removed from system configuration by the client.  The client then restarts 
the message exchange including a delay for sending.  If all goes well, the 
client receives a response and updates the system.  During the exchange, most 
applications will have problems even if there have been no network changes.

If the lifetime option simply represents a timer to update the associated 
options, this problem goes away.  The previously configured values can remain 
in place while an exchange takes places.  After the exchange the system can 
be updated, if necessary.

I read the lifetime option as a timer.  I did it this way defensively, since 
it does not introduce (short lived) breakage.

Perhaps, as you suggested,  the better fix is to use half the lifetime option 
as a sort of t1 value.  This brings it inline with address lifetime 
semantics.  This would require some rewording of the draft.

Also, if this change is made, it is probably more important to specify a 
minimum lifetime value so that half the configured lifetime does not cause a 
significant change in network usage.  Bernie Volz has mentioned this already.

Thanks for bringing up this issue.

Joe. 

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