Re: [rfc2462bis issue 274] conflict between MLD and NS delay

[JINMEI Tatuya / $B?@L at C#:H(B <jinmei at isl.rdc.toshiba.co.jp>]

>>>>> On Sun, 08 Feb 2004 19:38:08 +0200, 
>>>>> Jari Arkko <jari.arkko@kolumbus.fi> 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.
					jinmei@isl.rdc.toshiba.co.jp

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------