Re: [dhcwg] unresolved comments in dhcpv6-25
JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp> Mon, 10 June 2002 09:53 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26797 for <dhcwg-archive@odin.ietf.org>; Mon, 10 Jun 2002 05:53:37 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA20404 for dhcwg-archive@odin.ietf.org; Mon, 10 Jun 2002 05:54:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20210; Mon, 10 Jun 2002 05:51:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA05698 for <dhcwg@optimus.ietf.org>; Mon, 10 Jun 2002 01:26:39 -0400 (EDT)
Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14039 for <dhcwg@ietf.org>; Mon, 10 Jun 2002 01:26:02 -0400 (EDT)
Received: from localhost ([3ffe:501:4819:2000:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (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: <y7vsn3v7lh5.wl@ocean.jinmei.org>
From: JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp>
To: Ralph Droms <rdroms@cisco.com>
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] unresolved comments in dhcpv6-25
In-Reply-To: <4.3.2.7.2.20020604235847.038ade40@funnel.cisco.com>
References: <y7vadrqq348.wl@ocean.jinmei.org> <y7vadr4sf81.wl@ocean.jinmei.org> <y7vk7q5mg3c.wl@ocean.jinmei.org> <y7vadr0myz6.wl@ocean.jinmei.org> <y7vit55ehp5.wl@ocean.jinmei.org> <4.3.2.7.2.20020604235847.038ade40@funnel.cisco.com>
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
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org
Hello, thanks for the response, >>>>> On Wed, 05 Jun 2002 00:02:18 -0400, >>>>> Ralph Droms <rdroms@cisco.com> said: > Thanks for your careful review and helpful comments. We've > reviewed your comments and included our responses in line > below. www.dhcp.org/draft-26.txt reflects the changes > described in this response. I cannot get www.dhcp.org/draft-26.txt, 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 unicast. > 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. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] some comments and questions on dhcpv6-24 JINMEI Tatuya / 神明達哉
- RE: [dhcwg] some comments and questions on dhcpv6… Bernie Volz (EUD)
- Re: [dhcwg] some comments and questions on dhcpv6… Ralph Droms
- [dhcwg] Re: comments and qeustions on dhcpv6-24 JINMEI Tatuya / 神明達哉
- [dhcwg] comments and qeustions on dhcpv6-24 JINMEI Tatuya / 神明達哉
- Re: [dhcwg] some comments and questions on dhcpv6… JINMEI Tatuya / 神明達哉
- Re: [dhcwg] some comments and questions on dhcpv6… Ralph Droms
- [dhcwg] additional comments on dhcpv6-24 JINMEI Tatuya / 神明達哉
- [dhcwg] unresolved comments in dhcpv6-25 JINMEI Tatuya / 神明達哉
- Re: [dhcwg] unresolved comments in dhcpv6-25 Ralph Droms
- Re: [dhcwg] unresolved comments in dhcpv6-25 Ralph Droms
- Re: [dhcwg] unresolved comments in dhcpv6-25 Raymond Jayaraj
- Re: [dhcwg] unresolved comments in dhcpv6-25 JINMEI Tatuya / 神明達哉
- Re: [dhcwg] unresolved comments in dhcpv6-25 JINMEI Tatuya / 神明達哉
- Re: [dhcwg] unresolved comments in dhcpv6-25 Ralph Droms
- Re: [dhcwg] unresolved comments in dhcpv6-25 SHIRASAKI Yasuhiro