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

["Bernie Volz" <[e-mail]>]

I'm OK to restricting the Lifetime Option to replies to
Information-Request's.

The client MUST ignore a Lifetime Option that is in any message other than a
REPLY to an INFORMATION-REQUEST. A client MUST NOT include the Lifetime
Option number in an ORO except when sending an INFORMATION-REQUEST message.

The server MUST NOT include the Lifetime Option in any message other than a
REPLY to an INFORMATION-REQUEST.

- Bernie

> -----Original Message-----
> From: Stig Venaas [mailto:[e-mail]] 
> Sent: Friday, August 20, 2004 7:47 AM
> To: JINMEI Tatuya / ?$B?@L@C#:H
> Cc: [e-mail]; [e-mail]; [e-mail]; Bernie Volz
> Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt
> 
> 
> 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