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

[Stig Venaas <[e-mail]>]

On Mon, Aug 23, 2004 at 10:45:02AM -0400, Joe Quanaim wrote:
> 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?).

Yes, the term lifetime is a bit misleading. I'm open for
suggestions for other names.

> > 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:

I don't see why you would want that.

> > - 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.

Yes, that is no good.

> 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.

I don't like this, sounds more complex than we need.
> 
> 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.

I feel strongly that it should only tell the client when it should
try to update the info (like t1 I guess). But the client should
keep the info while it keeps trying to update the info. As I
understand the DHCP spec, it will keep retransmitting the
Information-Request indefinitely if necessary, which means that
the config data also might be kept indefinitely.

Of course there could be other reasons for the client to remove
configuration, the lifetime spec shouldn't prevent that either.
But that would be completely independent of the lifetime option.

The reason we want the option, is to have some control of when a
client tries to update its info. We're trying to solve problem
stated in the problem statement. The point is not to ensure
stateless info is removed at the host. Why would you want that?

I agree the name is misleading. The draft should make clear what
it is, but another name might help.

Stig

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