>>>>> On Wed, 22 Sep 2004 09:49:02 -0400, >>>>> Brian Haberman <[EMAIL PROTECTED]> 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. [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
