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

[Stig Venaas <[e-mail]>]

On Thu, Aug 12, 2004 at 08:43:27AM -0400, Bernie Volz wrote:
> If a server sets the T1/T2 times to infinity, it gets what it asked for -
> the configuration is static FOREVER. This is one reason it would be an
> extremely bad idea to ever use these values. We added them for clarity in
> the RFC, though never really figured they would be used in practice.
> 
> The no address issue is an interested one.
> 
> On a SOLICIT, the server is ONLY to return the Status Message response with
> NoAddrAvail status. It is *NOT* supposed to return any configuration
> information!!!
> 
> Though it is always possible that a subsequent REQUEST or RENEW/REBIND would
> result in no addresses. However, in those cases the IA_NA is still returned
> with T1 and T2 times and those would, IMHO, apply. (In these cases, the
> NoAddrAvail status is embedded *INSIDE* the IA_* options so these options
> are still returned.)
> 
> I suppose there is the case when a SOLICIT/REQUEST/RENEW/REBIND for an IA_NA
> and IA_TA results in no addresses for a IA_NA and one or more addresses for
> a IA_TA, in which case no T1/T2 times are provided - thought the IA_TA does
> have lifetimes.
> 
> But, all of this gets very messy fairly quickly.
> 
> So, perhaps the easiest thing to do is to *ALWAYS* allow the LIFETIME option
> - for stateful and stateless. A client *SHOULD* renew (etc) its information
> whenver the shortest time expires - LIFETIME, T1, or lifetime on an address
> (and the client needs a replacement address). If the client is stateful, is
> uses RENEW (whether the client includes on or more IA_NAs if no T1 time has
> expired is a matter of local policy - though it would seem reasonable for me
> if it did since there's no harm in doing so). If a client is stateless, it
> uses INFORMATION-REQUEST.
> 
> This also makes server implementations easier since the T1/T2 times and
> "other-configuration-parameters" lifetime can be configured independently
> and a server need not assure that no T1 time is greater than
> "other-configuration-parameters".

This is more in line with my original idea for lifetime. I've started
improving the draft, and I now have these paragraphs:

   The lifetime option specifies a lifetime for all configuration data
   contained in other options in an advertise or reply message that have
   no associated lifetime.  If any of the options have an associated
   lifetime of their own which is shorter than the lifetime option value,
   then that should take precedence.

   Or in other words, the lifetime option specifies an upper bound for
   how long the client should wait before attempting to renew the data.
   If there are options with a shorter lifetime or the client has other
   reasons for requesting data from the DHCP server, then it should also
   update the data covered by the lifetime option.

I think this should pretty much cover what you say and is in line with
my own thinking.

After that I have the 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.

Personally I'm happy to remove that again. I guess we should try to
come to some consensus before I do more writing.

Stig

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