>>>>> On Sun, 08 Feb 2004 19:38:08 +0200,
>>>>> Jari Arkko <[EMAIL PROTECTED]> said:
>> Regarding option 3:
>> pro: this is a complete solution of the problem, which works with
>> MLD snooping switches
>> con: this can be regarded as spec-violation, and we may have to
>> worry about conflict with MLD updates in the future
> Why do you consider this as a spec violation? Because then 2462bis
> would appear to say something that is different than what MLD specs
> say, or because ND specs should not say anything about MLD?
What I'm worrying about is to make a hidden requirement to MLD in the
address autoconfiguration spec (I admit "spec-violation" is not an
appropriate term - "spec boundary violation" is perhaps better?).
> I think the right engineering solutions should be adopted, without
> too much regard into the documentation boundaries.
In general, I agree.
> Having said that,
> if you worry about the document boundary, you can simply say "delay
> joining to the multicast group by a random delay. Once you have joined,
> send the ND packet."
Hmm, I tend to agree with this wording. Yes, this can still be
considered as boundary violation with wording trick, but I think this
makes it clear that the delay is only for DAD NSs and this minimizes
effects to the MLD spec. And, of course, this is a perfect solution
to the collision problem.
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
--------------------------------------------------------------------
