Jinmei,
> 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.
I agree.
> 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.
Yes, I think it will help.
>> 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.
Sorry I wasn't clear. I don't think referencing MD5 will be a problem even if it is Informational.
>> 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.
I have a slight leaning for keeping it as is because of the existing implementations, but am happy to leave to the editor's discretion.
Thanks, Bob
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
