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

[JINMEI Tatuya / 神明達哉 <[e-mail]>]

(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?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[e-mail]

>>>>> On Tue, 3 Aug 2004 05:33:57 +0200, 
>>>>> Stig Venaas <[e-mail]> said:

>> Hoping it's not too late, here a couple of comments (or questions,
>> actually) on the draft.
>> 
>> 1. I'm still not really sure what the client should do for information
>> when a lifetime expires.
>> 
>> For example, the draft says in Section 3.1 that
>> 
>> If client has received a lifetime with this option, and contacts
>> server to receive new or update any existing data prior to its
>> expiration, it SHOULD also update data covered by this option.  If no
>> new lifetime is received, it MUST behave as if no value was ever
>> provided.
>> 
>> I don't understand the scenario.  Does this mean the following case?
>> 
>> - The client sends an Information-request message, and gets a reply
>> with a DNS server address (call it X) with lifetime of 1 hour.
>> - 30 minutes later, the client happens to resend an
>> Information-request message.  This time, it gets a response, but
>> the response does not contain either DNS server address X or a new
>> lifetime.
>> 
>> If this is an intended scenario, then what does "behave as if no
>> value was ever provided"?  Does it mean the client MUST treat
>> address X as if it had infinite lifetime?  Or does this mean the
>> client MUST regard address X expired immediately?  Or something
>> else?

> I'm open for anything. But my intention is that client behaves as if
> it didn't get a lifetime in the first place. That is, just like it would
> behave if it doesn't know a specific lifetime. Whether it's infinite or
> not, depends on the client.

> I don't think this scenario will be common anyway, but we should say
> something. My thinking is that the last response is the authoritative
> one, so new lifetime value overrides the old, and no lifetime means
> ignore the old and behave like you haven't ever seen one.

> Another option would be to keep using the last seen lifetime until
> expiry, but I'm not sure that's better.

> Very happy to see suggestions for alternative behaviour, or for text
> changes that makes it more clear.

>> Also, I don't understand what the client should do with DNS server
>> address X when the lifetime expires and the client does not get any
>> reply for the try to update the information.  Should the client
>> invalidate address X?  Can/should it continue to use it?

> I think it can be left to the client. The client will retry for a long
> period of time, and would usually get updated info; the lifetime simply
> says when to start this process. So you're talking about a rare failure
> case. I think it's sensible to keep using the info, at least if there
> is nothing to fall back to.

> I'm thinking of the option as a hint to the client when it should try
> to update the info. I'm not sure if we need to specify the failure
> modes in detail.

>> Even if the client can update the information of address X with a
>> new lifetime, how can we regard the period from the time when the
>> previous lifetime expires and the time when the client gets the new
>> information?  Should we temporarily invalidate the address during
>> the update period?  Or Can we continue to use it?  Probably the
>> latter makes sense when the client can update the information, but
>> it does not really match my intuition of "expiration"...

> My intention is definitely that you should continue using it. I guess
> that should be made clear.

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