Re: [dhcwg] unresolved comments in dhcpv6-25

JINMEI Tatuya / 神明達哉 <> Mon, 10 June 2002 09:53 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id FAA26797 for <>; Mon, 10 Jun 2002 05:53:37 -0400 (EDT)
Received: (from daemon@localhost) by (8.9.1a/8.9.1) id FAA20404 for; Mon, 10 Jun 2002 05:54:10 -0400 (EDT)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id FAA20210; Mon, 10 Jun 2002 05:51:09 -0400 (EDT)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id BAA05698 for <>; Mon, 10 Jun 2002 01:26:39 -0400 (EDT)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id BAA14039 for <>; Mon, 10 Jun 2002 01:26:02 -0400 (EDT)
Received: from localhost ([3ffe:501:4819:2000:200:39ff:fed9:21d7]) by (8.11.6/8.9.1) with ESMTP id g5A5QT865222; Mon, 10 Jun 2002 14:26:29 +0900 (JST)
Date: Mon, 10 Jun 2002 14:26:30 +0900
Message-ID: <>
From: JINMEI Tatuya / 神明達哉 <>
To: Ralph Droms <>
Subject: Re: [dhcwg] unresolved comments in dhcpv6-25
In-Reply-To: <>
References: <> <> <> <> <> <>
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: 63
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>

Hello, thanks for the response,

>>>>> On Wed, 05 Jun 2002 00:02:18 -0400, 
>>>>> Ralph Droms <> said:

> Thanks for your careful review and helpful comments.  We've
> reviewed your comments and included our responses in line
> below. reflects the changes
> described in this response.

I cannot get, but I'm basically fine with
the responses.  A few points to clarify:

>    8. It is not very clear when a server includes a Server Unicast
>       option.  Section 18.1.1 (and some succeeding sections) says

>          Use of multicast or anycast on a link and relay agents
>          enables the inclusion of relay agent options in all messages
>          sent by the client.  The server should enable the use of
>          unicast only when relay agent options will not be used.

>      But, this only talks about some restrictions of including the
>      option.  Even with the text of section 22.13, I'm still not sure
>      when a server should or can send a Server Unicast option.  It
>      would be better to describe the allowed (or necessary) cases
>      explicitly.

> Added the sentence: "Use of unicast may avoid delays due to forwarding
> of messages by relay agents as well as avoid overhead and duplicate
> responses by servers due to delivery of client messages to multiple
> servers." to each of the DISCUSSION paragraphs explaining the use of
> the Unicast option.

Perhaps the added sentence is okay, but it still seems to talk about
benefits of using unicast, not about when the server should or can use

>    9. (I've once pointed it out, but I'll do it again) Section 17.2.2
>       says

>       If the Solicit message was received directly by the
>       server,...The Advertise message MUST be unicast through the
>       interface on which the Solicit message was received.

>      Technically, the requirement is too strong, since links are larger
>      than interfaces according to the IPv6 scoped address architecture.
>      So, more accurately, it should say "The Advertise message MUST be
>      unicast through the link on which the Solicit message was received."
>      (Also see the last paragraph of Section 16.)

> We used the more specific requirement to avoid the problem of a client
> sending a DHCP message on an incorrect interface because the client
> had incorrect configuration information about two interfaces being on
> the same link.

Sorry, I don't understand the response.  Section 17.2.2 talks about
server's behavior, and I don't get why the restriction on the server
side can solve the client's issue.

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

dhcwg mailing list