Re: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-02.txt

[JINMEI Tatuya / 神明達哉 <[e-mail]>]

>>>>> On Wed, 22 Sep 2004 09:49:02 -0400, 
>>>>> Brian Haberman <[e-mail]> said:

> All,
>       This starts a 1 week IPv6 Working Group Last Call on advancing:

>           Title           : Optimistic Duplicate Address Detection for 
> IPv6
>           Author(s)  : N. Moore
>           Filename : draft-ietf-ipv6-optimistic-dad-02.txt
>           Pages       : 15
>           Date	         : 2004-9-9

> as a Proposed Standard.  This last call is to ensure that all comments
> raised during the initial last call have been addressed.  Substantive
> comments should be addressed to the IPv6 mailing list.  The last call
> will end on Sept. 29, 2004.

I'm not sure if this version addresses the three points below I made
in the previous last call (*)
(*) http://www1.ietf.org/mail-archive/web/ipv6/current/msg03082.html

>>>>> On Fri, 23 Jul 2004 14:39:16 +0900, 
>>>>> JINMEI Tatuya said:

> 1. overall, this approach depends on reasonably small reachable time
>   (per Section 4.2 of RFC2461).  If this value happens to be set to a
>   large value (say, a few to 10 minutes?) via RA, a duplicate
>   link-layer address of an optimistic node can mistakenly be stored
>   for the unreasonaly large period.  While this is a general issue on
>   the reasonable value of reachable time, I think this draft should
>   explicitly note that since it is going to modify the existing
>   protocol and affect implementations.  Perhaps we even need to define
>   the upper limit of reachable that to allow the optimistic behavior.

> 7. In section 2.2

>    Protocols which do not understand this state should
>    treat it equivalently to 'Deprecated', to indicate that the address
>    is available for use but should not be used if another suitable
>    address is available.

> I don't really understand what "protocols which do not understand this
> state" actually means.

> 13. In section 4

>    The ON will immediately send out a Neighbour Solicitation to
>    determine if its new address is already in use, and a Neighbour
>    Advertisement (with the Override flag cleared) for the address. This
>    NA allows communication with neighbours to begin immediately.

> What does "immediately" mean?  Are you saying a random delay before
> the first NS (in some situation) should be removed?  The same comment
> should apply to NA, while I object to sending such NAs in the first
> place (see comment 5 above).

I also have a couple of additional comments on new changes in version
02, which I think can be substantial.

1. In section 2.4:

   Implementing this behaviour may be difficult and unnecessary, so it
   is left as an option to the implementor.

I don't really understand this sentence...what does "this behaviour"
actually specifies?  (Depending on the answer to the previous
question) why implementing it may be difficult and unnecessary?  Or as
a meta-question, is it really adequate to asses whether implementing
something may be difficult or not in a protocol specification?

2. In section 4.2:

   In the course of establishing connections, the ON may send NAs either
   spontaneously or in response to received NSs.

What do you mean by saying "the ON may send NAs spontaneously"?  If
this means unsolicited NAs to all-nodes multicast group, I believe we
decided to remove that feature from the spec.  In fact, no other parts
of the 02 version talk about the unsolicited NAs.  So, if this is the
intent, we should simply remove this part and rewrite the sentence as:

   In the course of establishing connections, the ON may send NAs in
   response to received NSs.

If the intent is not unsolicited NAs, please clarify that.

Finally, I found some editorial nits.  Those are very minor and aren't
a showstopper.  (i.e., if they need to be addresses, it can be done
later with IESG comments.)

3. It's odd to see that the document sometimes say "Optimistic Node"
   or "Optimistic node" even after the introduction of abbreviation
   "ON".  This level of mixture might be acceptable, but I'd prefer
   consistent usage.

4. In section 2.3

   * clearing the 'Override' flag in Neighbor Advertisements for
        Optimistic addresses, which prevents neighbors from overriding
        their existing NC entries. The 'Override' flag is already
        defined [RFC2461] and used for Proxy Neighbor Advertisement.

s/Optimistic addresses/Optimistic Addresses/?

(This seems to be the only occurrence of "optimistic address" with
"address" being not capitalized.)

5. In section 2.3

   * Never using a Optimistic Address as the source address of a Router
        Solicitation with a SLLAO.  Another address, or the unspecified
	...

s/a Optimistic/an Optimistic/

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[e-mail]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------