Subject: [dhcwg] one more comment about the lifetime option

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 04 Aug 2004 02:03:04 +0900

I forgot to mention this one:

Is it possible to specify different lifetimes for different instances
of stateless information?  For example, people may want to specify
different lifetimes for recursive DNS server addresses and for SIP
server addresses.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

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

---

From: Stig Venaas <[email-masked]>
Date: Tue, 3 Aug 2004 19:14:47 +0200

> different lifetimes for recursive DNS server addresses and for SIP

We should keep this simple. If e.g. recursive server data needs to be
updated more frequently than SIP data, I would simply say that lifetime
should be the shortest. When you contact server to update DNS data, you
can at the same time update other data like SIP server address.

Note that the draft says:

   If client has received a lifetime with this option, and contacts
   server to receive new or update any existing data prior to its
   expiration, it SHOULD also update data covered by this option.  If no
   new lifetime is received, it MUST behave as if no value was ever
   provided.

In line with that SHOULD, there's no good reason to have multiple
lifetimes.

Stig

---

From: Ralph Droms <[email-masked]>
Date: Tue, 03 Aug 2004 13:59:10 -0400

I agree with Stig - we've discussed this issue before and come to the 
conclusion that there is little extra overhead in delivering information 
that has not changed, so there should be a single lifetime - chosen to be 
the shortest lifetome of any of the client's parameters.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Aug 2004 15:07:02 -0700

> different lifetimes for recursive DNS server addresses and for SIP

I think the amount of work the server has to do to make this happen is 
more than the amount of work that is saved.   That is, you're going to 
have to process an Information Request packet every time anything on 
the client expires.   And figuring out that you only need to send 
certain options, and not certain others, is more work than just sending 
what you have.   So I think that not only is it not necessary to have 
different lifetimes for different options, it's actually harmful to 
have them.

---

From: Joe Quanaim <[email-masked]>
Date: Wed, 4 Aug 2004 08:21:23 -0400

> different lifetimes for different options, it's actually harmful to

Per option lifetimes also make client implementations more complicated.  
Furthermore, they have the potential to cause more dhcpv6 traffic for 
everyone.

Joe Quanaim.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 05 Aug 2004 02:03:03 +0900

>>>>> On Tue, 03 Aug 2004 13:59:10 -0400, 
>>>>> Ralph Droms <[email-masked]> said:

> the shortest lifetome of any of the client's parameters.

Okay, I'm fine with the "singe lifetime for all option parameters"
approach.  In fact, I was just wondering without any particular
preference.

But I want the document to be more specific on this point because
other readers might wonder the same point.

					JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Aug 2004 10:29:09 -0700

> other readers might wonder the same point.

Yes, if there was a question for you, there will be questions for 
others, and this needs to be clarified.   I think we're just debating 
(well, for once, resoundingly agreeing on) what the clarification 
should be.   :')

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 23 Aug 2004 18:27:37 +0900

>>>>> On Thu, 05 Aug 2004 02:03:03 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> other readers might wonder the same point.

We should also restrict the position where the lifetime option can
appear: it should only be able to appear at the "top level" of option
hierarchy.  In other wise, it must not appear as a sub-option of
another option.

					JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 Aug 2004 10:30:03 -0400

On Aug 23, 2004, at 5:27 AM, JINMEI Tatuya / 神明達哉 wrote:
> hierarchy.

I think this is a good idea.

---

From: "Bernie Volz" <[email-masked]>
Date: Tue, 24 Aug 2004 20:55:14 -0400

If it is restricted to a REPLY to an INFORMATION-REQUEST, there is no need for this explicit statement as that's all that is currently possible - there are no IA_NA, IA_TA, or IA_PD options for these messages.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Ted Lemon
> Sent: Monday, August 23, 2004 10:30 AM
> To: JINMEI Tatuya / _–¾’BÆ
> Cc: [email-masked]
> Subject: Re: [dhcwg] Re: one more comment about the lifetime option
> 
>