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

JINMEI Tatuya / 神明達哉 <> Wed, 01 September 2004 17:01 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id NAA10611; Wed, 1 Sep 2004 13:01:45 -0400 (EDT)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1C2XTU-0002iP-FR; Wed, 01 Sep 2004 11:56:40 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1C2VxY-0004YZ-Si for; Wed, 01 Sep 2004 10:19:37 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id KAA17436 for <>; Wed, 1 Sep 2004 10:19:34 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1C2Vzk-0002An-1o for; Wed, 01 Sep 2004 10:21:53 -0400
Received: from (unknown [2001:200:0:8002:9d66:8cbb:c45e:52c1]) by (Postfix) with ESMTP id A1BFD15265; Wed, 1 Sep 2004 23:19:26 +0900 (JST)
Date: Wed, 01 Sep 2004 23:19:27 +0900
Message-ID: <>
From: JINMEI Tatuya / 神明達哉 <>
To: Ted Lemon <>
Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt
In-Reply-To: <>
References: <000e01c486b3$66af02b0$> <6493.1093586912@munnari.OZ.AU> <> <>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
X-Mailman-Version: 2.1.5
Precedence: list
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

>>>>> On Tue, 31 Aug 2004 09:33:46 -0700, 
>>>>> Ted Lemon <> said:

>> I don't know what people think, I have no strong feelings myself, but
>> we could relax things a bit perhaps. But there is some added complexity
>> and it isn't essential. It could also be extended later if necessary.
>> We could tweak the spec to allow what you say, if there's agreement on
>> that. But most of all, I want to come to some conclusion really soon.

> I think using the IRT option in a context where there is a lifetime 
> already doesn't make sense, and should not be allowed.   I don't mean 
> the client should drop the packet if it gets both - just that the 
> option has no meaning in the context of a stateful DHCP message.

I basically agree with this.

Regarding complexity, different people may have different image on it,
so I suspect we can easily get a consensus.

But I think we all at least agreed on the following points:

  it isn't not that useful to have a separate lifetime when we already
  have lifetimes (or lease times) for addresses in the stateful case.
  (almost the same thing what Ted said above)

In addition to that, as an implementor, if we explicitly allow this
case, it means we'll need to implement it anyway to be compliant to
the RFC(-to-be), even though we know we have no practical case where
it is useful.  Opinions on whether the implementation will be
complicated or not may differ among people (see above), but it's a
real issue for me as an implementor.

If we need a compromise for future possibility, we could explicitly
say this case is beyond the scope of the document as I mentioned

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.

dhcwg mailing list