>>>>> On Tue, 22 Feb 2005 11:18:24 +0100,
>>>>> Christian Vogt <[EMAIL PROTECTED]> said:
> Ok, your point is the order implied in the text I suggested. I actually
> didn't mean to imply this. But yes, the text could potentially be
> misinterpreted. So maybe you whish to reduce it to the following?
(snip)
> In the above, the first paragraph specifies NC-state creation, and the
> second specifies the additional address-resolution procedure that may be
> required in the case of a unicast RA. This second paragraph is based on
> the corresponding existing paragraph in section 7.2.4. (Note the
> difference between "[unicast] Router Solicitations" and "[unicast]
> Router Advertisements", though.) This is good for conformity.
> We don't need to explicitly address the case of a solicitation without
> SLLAO in the first paragraph, because (a) no NC state is created in case
> of a multicast RA, (b) the second paragraph describes address resolution
> and state creation in case of a unicast RA in conformance with section
> 7.2.4, and (c) the decision of whether to send a multicast or a unicast
> RA is already attended to in the beginning of section 6.2.6.
Okay, the proposed text looks reasonable.
> An aside with respect to the second paragraph: You may also want to
> modify this paragraph through a s/Neighbor Discovery/address resolution/
> in both section 7.2.4 and, as suggested, section 6.2.6.
I tend to agree (although it's not a strong preference).
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
