Re: [dhcwg] some comments and questions on dhcpv6-24

>>>>> On Mon, 13 May 2002 10:37:09 -0400, 
>>>>> Ralph Droms <rdroms@cisco.com> said:

>> 17.2.2. Creation and transmission of Advertise messages
>> 
>> ... The Advertise message MUST
>> be unicast through the interface on which the Solicit message was
>> received.
>> 
>> It seems to me the requirement is too strong.  Is this really
>> necessary?

> It's necessary if the server received the Solicit directly from the client; 
> i.e., if the server and the client are on the same link and the server is 
> sending the Advertise to the client's link-local address.

I understand that, but as I said in the succeeding message, I think
the "link" (not "interface") is more accurate.  Requiring to send a
particular "interface" is overspecification from a strict
scope-architecture point of view.  Also, using the word "link" is
consistent with the wording in Section 16.

>> 18.2.5. Receipt of Information-request messages
>> 
>> The server contructs a Reply message by setting the "msg-type" field
>> ^^^^^^^^^this should be "constructs".  There are many
>> other "contructs" in the draft.

> This problem was fixed between preliminary publication of the -24
> rev and the final version published at the IETF.

>> to REPLY, copying the transaction ID from the Rebind message into the
>> ^^^^^^
>> transaction-ID field.
>> 
>> Should the "Rebind" message be "Information-request"?  This sentence
>> seems to be just copied from the previous section...

> This problem was fixed between preliminary publication of the -24
> rev and the final version published at the IETF.

Okay, but where can I get the "final version"?  The -24 draft at
ftp://ftp.ietf.org/internet-drafts has the same problems.

					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