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

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

>>>>> On Tue, 24 Aug 2004 11:08:14 -0400, 
>>>>> Ted Lemon <[e-mail]> said:

> However, let's consider your scenario a little more closely.   You 
> acquire some information from the DHCP server.   Subsequently, for some 
> reason, it becomes impossible for the server to respond to the client.

> I have a couple of observations about this.   First, the time at which 
> it becomes impossible for the server to respond is not the same as the 
> time at which the client attempts to refresh its configuration 
> information.   The two events are unrelated.

Okay, I concur on this.  I also see that the scenario might differ
based on whether the client moves to a new link or it stays in the
same link.

Instead of making further responses point by point, I'll try to
summarize major points throughout the thread, and propose what I
personally would envision based on the points (if you feel this
approach is unfair, please say so).  I'll also call the new option
"refresh timer option" in the followings since that's the closest
notion which we now seem to agree on.

The case of moving clients is probably too difficult to provide
a complete solution, but it would be helpful some considerations along
with the this new option.

Now assuming a still client (i.e., a client that doesn't move), we
seem to be close to the consensus.
  - when the refresh timer expires, the client resends a new
    Information-request message.  (it can do so earlier than the
    expiration time based on its local policy)
  - if the client gets a response, it (MUST) replace the old
    information with the new one.  This also means if the response
    contains an empty set of some particular information, the client
    should stop using the old information.
    (BTW, there are two types of an "empty set".  The first one is a
     response that contains the corresponding DHCPv6 option, e.g., DNS
     recursive name server option, with an empty list.  The second one
     is a response that doesn't contain the DHCPv6 option.  It seems
     to me it makes sense to regard both types as "an empty set").
  - if the client cannot get a response, it (SHOULD?) continue using
    the old information because of the reason Ted provided.

So, what I would expect in this document is as follows:

- we basically concentrate on the case of a still client and
  explicitly say so in the document.
- then we describe the detailed behavior for that type of clients as
  shown above (of course, based on a consensus in the wg).
- we also provide some considerations on moving clients (in an
  appendix?), which would be something like this:
    + we assume we can detect the movement (or simply say it's beyond
      the scope of this work).  I think we can simply refer to the
      beginning of Section 18.1.2 of RFC3315 if necessary.
    + when the client detects the movement, it should start contacting
      the DHCP server immediately, regardless of the remaining time of
      the refresh timer.  In this case, how the client deals with the
      old information is up to the client based on its local policy
     (there can be so many valid scenarios as we've seen in the
      discussion).  This should particularly apply when the client
      receives an "empty set" for some information or when the client
      cannot get any responses at all.  However, if the client gets a
      non empty set of new information, it SHOULD(?) replace the old
      information with the new one.

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

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