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

[Stig Venaas <[e-mail]>]

On Tue, Aug 17, 2004 at 05:45:05PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote:
> >>>>> 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:

I think we should come to a decision and proceed. I've given this some
more thought, and personally I don't mind restricting it to stateless.
I'm not sure I like using the term stateless though.

I suggest saying that the option should only be used in replies to
Information-Request messages. This solves the stateless renumbering
issue we set out to solve.

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

I agree with this. At least it's my understanding that when renewing
the address the client should also update other info.

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

Yes, it might be just corner cases. I guess the scope of the option
could be expanded later if needed. It's better to do that later, than
possibly making the scope too large now.

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

Right.

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

I must say I don't quite understand why it is so difficult. OTOH it
seems I have some problems explaining clearly how I think it should
work, so perhaps it is complex after all (;

Well, are you happy with limiting it to replies to Information-Request
then? Has anyone got big problems with that? If there are no major
objections I'll propose some text to you, to make sure we are in
agreement.

Thanks for all the input. I hope to go through the issues, proposing
text and hopefully have concencus on how to resolve it so that I can
put out a new and hopefully final version soon.

Stig

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