We originally wanted to make changes to 2462bis I-D, but since it's in AUTH state, that may not be possible anymore.
If you want, we can let 2462bis I-D not make our proposed change, but our security case and solution needs to be addressed in an I-D to highlight the problem with older implementations that can skip DAD. It would be preferable if the security problem and its solution is presented in 2462bis, but if that's not possible, then we'll discuss it in our I-D. We have other issues we want to address in our I-D, and we don't want to have this issue prevent other issues from being discussed. - Hemant and Wes -----Original Message----- From: JINMEI Tatuya / ???? [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 26, 2007 10:42 AM To: Hemant Singh (shemant) Cc: Brian E Carpenter; Fred Baker (fred); [email protected] Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 At Tue, 26 Jun 2007 10:10:19 -0400, "Hemant Singh (shemant)" <[EMAIL PROTECTED]> wrote: > Let's focus on the problems at hand and solutions - forget delay of > 2462bis I-D or what have you. Why are we referring to text in 2462bis > as an admittance that accident cases can exist when we have a solution > for such cases? I'm afraid I'm now a little confused, so please let me be sure about one thing first: are you still requiring us to incorporate your proposed change in the coming 2462bis RFC? Or are you now starting a discussion as a separate thread from the publication of 2462bis? 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 --------------------------------------------------------------------
