Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-lifetime-00.txt

From: [email-masked]
Date: Tue, 16 Mar 2004 15:03:48 +0200

Heya,

I read through the draft and I have to say this really is something that is needed or will be needed soon. However, while reading the draft one issue in it caught my attention.

Proposed Lifetime option is defined in the draft...

3. Lifetime option definition

   	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.  This means that it does not effect e.g. the
   	IA Address option which contains a lifetime.

My comment and question is: What is the reason to limit usage of this option to 1/message? Doesn't this (unnecessarily?) limit the use of the option, especially in the server?  

If existence of more than 1 lifetime option would be allowed, server could group options according to their lifetimes in the Reply message. This would not just optimize traffic between clients and servers in certain cases, but also make the option more versatile in general. At least in the future DHCPv6 option space assumable will contain options that prefer different lifetimes and still server would like to put them all into same message.

Modified definition for the option that would allow 1+ lifetime options would be:

   	The lifetime option specifies a lifetime for all configuration data
   	contained in other options following the lifetime option in an advertise or       	reply message that have no associated lifetime.  This means that it does not 	effect e.g. the IA Address option which contains a lifetime.

This definition would also enable possibility to have options in the message that are not affected by any lifetime option (put them before any lifetime option in the message).

Semantics for using several lifetime options in the same message could be 

a) Sequential, where lifetime option defines lifetime for DHCPv6 options (not having associated lifetime) following it in the message until the next lifetime option. 

or 

b) Structured (encapsulated) use similar semantics as Vendor-specific Information option aka encapsulate those options inside the Lifetime option that are wanted to be affected by certain lifetime.    

Regards,
Janne Tuononen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of ext
> [email-masked]
> Sent: 09 March, 2004 22:55
> Cc: [email-masked]
> Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-lifetime-00.txt

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Mar 2004 09:01:04 -0600

On Mar 16, 2004, at 7:03 AM, [email-masked] wrote:
> If existence of more than 1 lifetime option would be allowed, server 
> could group options according to their lifetimes in the Reply message. 
> This would not just optimize traffic between clients and servers in 
> certain cases, but also make the option more versatile in general. At 
> least in the future DHCPv6 option space assumable will contain options 
> that prefer different lifetimes and still server would like to put 
> them all into same message.

We talked about this and rejected it as unnecessary.   Consider if you 
have two groups of options, one with a lifetime of 30 seconds and one 
with a lifetime of a day.   How is the server going to know, when it 
gets an information request from the client, that the client already 
has the values that are good for a day?   It's not, so it has to send 
them anyway.  So there's no benefit to this added complexity.