Re: [dhcwg] additional comments on dhcpv6-24

JINMEI Tatuya / 神明達哉 <> Thu, 16 May 2002 16:58 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id MAA02196 for <>; Thu, 16 May 2002 12:58:48 -0400 (EDT)
Received: (from daemon@localhost) by (8.9.1a/8.9.1) id MAA28307 for; Thu, 16 May 2002 12:59:03 -0400 (EDT)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id MAA28088; Thu, 16 May 2002 12:56:08 -0400 (EDT)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id MAA27855 for <>; Thu, 16 May 2002 12:53:40 -0400 (EDT)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id MAA01929 for <>; Thu, 16 May 2002 12:53:24 -0400 (EDT)
Received: from localhost ([3ffe:501:100f:1041::6]) by (8.11.6/8.9.1) with ESMTP id g4GGrX811974; Fri, 17 May 2002 01:53:33 +0900 (JST)
Date: Fri, 17 May 2002 01:51:56 +0900
Message-ID: <>
From: JINMEI Tatuya / 神明達哉 <>
To: "Bernie Volz (EUD)" <>
Subject: Re: [dhcwg] additional comments on dhcpv6-24
In-Reply-To: <66F66129A77AD411B76200508B65AC69B4D428@EAMBUNT705>
References: <66F66129A77AD411B76200508B65AC69B4D428@EAMBUNT705>
User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset="US-ASCII"
X-Dispatcher: imput version 20000228(IM140)
Lines: 36
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>

>>>>> On Wed, 15 May 2002 14:36:37 -0500, 
>>>>> "Bernie Volz (EUD)" <> said:

> Regarding (1), based on -24 the server shouldn't be sending an
> Advertise. And, yes, I think your assumption that the client should
> discard it is correct. Having said that, I would like to see the
> Rapid Commit change to be more of just an option. A server set up to
> respond to Rapid Commit would send the Reply. Other servers could
> send an Advertise. The client would use the Reply if received;
> otherwise simply start using the Advertises as if a Solicit w/o
> Rapid Commit was done.

I'm a bit are you saying the followings?

- the client should discard the unexpected advertise *with the current
- but we should change the spec so that the client will accept an

> Regarding (2), good question ... I would say it should. The logic
> might simply be send a Solicit, wait IRT, check if any Advertises
> received ... if so, go use them otherwise send Solicit again.

Okay.  I don't have a particular opinion on this as long as the
wording is clear.

> Regarding (3), your understanding is correct. I can't see that it
> hurts for us to indicate that RAND be greater than 0.

Okay.  I would simplify the specification so that there will be no
special case, but I don't make an objection to the current spec.

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

dhcwg mailing list