Re: [dhcwg] unresolved comments in dhcpv6-25

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