I don't like the idea of a random delay in the MLD Reports. As I said in another note, it either adversely affects the logic in the MLD specs or causes application delays for non-LL groups.
Is having a delay in the NS transmission alone sufficient? So that the Report is sent immediately and the NS is delayed.
Regards, Brian
JINMEI wrote:
On Sun, 08 Feb 2004 09:02:54 -0500, Brian Haberman <[EMAIL PROTECTED]> said:
Given my point above, I would argue that we shouldn't add a delay to MLD messages.
So, do you have any opinion among the options I raised in this thread?
1. no change in rfc2462bis (expecting MLDv1 and/or MLDv2 will eventually be updated with a random delay) 2. the original proposal of mine (expecting MLDv1 and/or MLDv2 will eventually be updated with a random delay): impose a random delay even for the first NS after the corresponding MLD when the sending node knows there is no delay for the MLD. 3. Greg's suggestion: require a random delay before the first MLD (in rfc2462bis).
(including "4. none of above").
Apparently you'd reject option 3 from your point. I also know that you are NOT expecting MLDv1/v2 will be updated with a random delay, even if you prefer option 1 or 2 itself.
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 --------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
