Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt

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

>>>>> On Thu, 12 Aug 2004 10:18:57 -0400, 
>>>>> Joe Quanaim <[e-mail]> said:

>> The primary motivation for the lifetime option is for situations where
>> no lifetime (or renewal time) is communicated to the client, such as for
>> Stateless DHCP service as specified in [RFC 3736]. However, it applies
>> to both stateful and stateless DHCP clients and is an upper bound for
>> when a client should initiate renewal of at least its non-address based
>> configuration parameters - a stateful client MAY renew its addresses at
>> the same time and SHOULD always get updated configuration data from the
>> server when it renews any addresses.
>> 
>> One difference between Stateful and Stateless clients with regards
>> to this option is that a Stateful client that does not receive this
>> option MUST NOT apply the default lifetime.

> As noted, the motivation of the lifetime option is to ensure stateless clients 
> receive current configuration information.  As such, I think keeping it out 
> of stateful configuration is the simplest approach.  As we have discussed, 
> stateful configuration already has several variables to manipulate client 
> behavior.  I do not see much gain in adding another.

It's not a strong opinion, but I'd also still prefer to restrict the
use of the lifetime option to the stateless case.  The reasons are:

- even if it might be true that the client can use stateful exchanges
  without having addresses or infinite T1/T2 timers for other
  configurations only, it should be a very minor case (I'm pretty sure
  that everyone agrees on this - whether still want to allow such
  usage or not).  In my understanding, the sense of RFC3315 is that
  "if you can get an address, you may get other information.  If you
  cannot get an address, then give up any possible information."  In
  fact, Section 18.1.8 says

    [...]  If the client receives no addresses in
    any of the IAs, it may either try another server (perhaps restarting
    the DHCP server discovery process) or use the Information-request
    message to obtain other configuration information only.

  but the RFC does not (explicitly) allow the client to continue to
  use other information configuration than addresses.  What you are
  going to achieve in the scenario of the lifetime option with the
  stateful case seems to contradict the original sense, IMO.

- recalling that we rejected the idea of multiple lifetime options for
  multiple configuration parameters, it's odd to me that we are now
  going to have T1/T2 as well as the lifetime option (I was happy with
  rejecting the idea of multiple lifetimes, BTW).  If we applied the
  same logic, we could simply use an appropriate T1 value to implement
  controlled update of the other configuration information.  Again,
  it's true that stateful exchanges can provide no finite timers,
  but, as I said in the above bullet, it's very minor or even
  almost-unexpected use case in my understanding.

- as I pointed out in my first message, we'll have to define all the
  details, most of which are boring corner cases (but the implementors
  would be unhappy if we didn't define those).  I know some of you are
  now trying to address those, and trying to minimize the complexity
  of the specification.  However, right now I'm not sure if it really
  makes sense, considering the usage case of stateful+lifetime is
  minor.  I admit this is a tradeoff issue, and perhaps we need to
  end up discussing details to make a clear consensus.

- one thing I'm concerned about which is related to the above point:
  there is already a non-address IA that has a notion of timeout:
  IA_PD.  So, we'll probably have to consider the combination of IA_PD
  and the lifetime option.  Moreover, the lifetime option document may
  need to be generic enough to prepare for any future stateful
  resources that has a notion of timeout.

> Still, it's not that complex a change.  If I am outvoted, so be it.

Same here.  Though I'm still skeptical about the benefit of the use
case of stateful+lifetime, considering the possible complexity, I can
live with that if the specification is crystal clear about all the
details.

					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