>>>>> On Wed, 18 May 2005 17:14:46 -0700, >>>>> Bob Hinden <[EMAIL PROTECTED]> said:
>> - our implementation currently does NOT delay the response to an >> anycasted or multicasted query. > The question here is the delay useful. To me this would seem useful for > multicast queries, but I don't see the need for ones for anycast. I don't see the need (for anycast), either. In fact, in the case of anycast, the query packet should be delivered to a single responder only, and there should be no possibility of response collision which the delay would try to avoid. It should be noted that in the case of Neighbor Discovery (referred from the name-lookups draft in this context) a neighbor solicitation to an anycast address may be delivered to multiple nodes and there may be multiple neighbor advertisements. This scenario is very special and totally different from the name-lookups (or any other normal use of anycast) case. >> 1. In section 2, this document is too specific about particular >> implementations: >> >> [...] An example of a IPv6 debugging tool using IPv6 Node >> Information Queries is the ping6 program in the KAME, USAGI, and >> other IPv6 implementations <http://www.kame.net>. >> >> I'm afraid this is not very appropriate for a general specification >> document. Instead, we might say: > This was there purposely. At one point there was a lot of push back on > moving this forward and it was useful to be very specific about where this > was implemented and being used. Hmm, I do not necessarily oppose to keeping the specific implementation names (actually, I'd be honoured with that:-), if others (especially the IESG) accept this. >> 4. I'm afraid the reference to the MD5 spec (RFC1321) in Section 5 >> should be a normative reference in this context. (If >> icmp-name-lookups is expected to be published as a PS, this may >> cause a problem since RFC1321 is informational.) > I don't think that would be a problem. Do you mean it's okay to keep the reference informational? In any cast, I was actually just wondering, and I'd not oppose to the decision. >> 5. I don't see why we need the TTL field for Node Name, Node >> Addresses, and IPv4 Addresses if it MUST be always 0. Perhaps this >> is just for backward compatibility to existing implementations, >> though...(if so, I believe we should explicitly note that, since >> otherwise future readers will have the same question) > It is left for backward compatibility. I agree it would be good to explain > this. Okay. >> 7. Should we still need the "S" and "C" flags for the Node Addresses >> Query even though site-local unicast addresses and IPv4-compatible >> IPv6 addresses are now deprecated? > I think it is useful to leave them for backwards comparability. We might > want to add some text explaining this. Would it cause compatibility problem if we "reserved" those flag bits as "unused"? If we reserve the bits and specify the responder to ignore those bits, then the responder's behavior will be the same regardless of the semantics of the flags, since new responders wouldn't use these "deprecated" addresses in any event. So I personally think it's clearer to not include the now-deprecated notion in a new specification. But this is not a strong opinion. Unless others have particular opinions or preferences, I'll accept the editor's decision. 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 --------------------------------------------------------------------
