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

My impression is that people want it for stateful as well - or at least not
to restrict it from being used there.

I was where you are - keeping it for stateless only. But there are some edge
cases where stateful clients might not receive any times or might receive
extremely long times (though I think these are really exceptional cases).

I also think it is easier configuration wise to just allow an administrator
on a server to configure this option and not have code in the server not to
send this for a stateful REPLY (or on a client to ignore it). Though I guess
we could place the responsibility on the client not to include it in the ORO
when stateful.

So, I've changed my mind - allow it for stateful as well.

BTW, shouldn't we improve the langauge in the draft regarding the ORO? It is
currently:

3.1. Client behaviour

   A client supporting this option MAY include it in the Option Request
   Option (ORO) when sending messages to the DHCP server that allows ORO
   to be included.

I would suggest we change it to:

3.1. Client behaviour

   A client supporting this option MUST include it in the Option Request
   Option (ORO) when sending SOLICIT, REQUEST, RENEW, REBIND, and
   INFORMATION-REQUEST messages to the DHCP server.

If the consenus is to keep this for stateless only, then it would read:

3.1. Client behaviour

   A client supporting this option MUST include it in the Option Request
   Option (ORO) when sending INFORMATION-REQUEST messages to the DHCP
server.
   A client MUST NOT include this option in an ORO option in any other
   messages.

- Bernie

> -----Original Message-----
> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] 
> On Behalf Of Joe Quanaim
> Sent: Thursday, August 12, 2004 10:19 AM
> To: Bernie Volz; 'Stig Venaas'
> Cc: dhcwg@ietf.org; tjc@ecs.soton.ac.uk
> Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt
> 
> 
> Bernie Volz wrote:
> > I do think you should remove that last paragraph:
> >
> > >    The lifetime option is mainly intended for Stateless 
> DHCP service as
> > >    specified in [RFC 3736].  If the client receives IA 
> Address options
> > >    containing lifetimes, the lifetime option should be 
> ignored.  The
> > >    client should get updated configuration data from the 
> server when it
> > >    renews the addresses.
> 
> I would prefer leaving the paragraph.
> 
> > It confuses the issue.
> >
> > Perhaps something like:
> >
> >   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.
> 
> Still, it's not that complex a change.  If I am outvoted, so be it.
> 
> Joe Quanaim.
> 
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg