Re: Optimistic DAD _again!_

2004-02-23 Thread JINMEI Tatuya / 神明達哉
On Thu, 19 Feb 2004 19:52:28 +1100, Nick 'Sharkey' Moore [EMAIL PROTECTED] said: You might recall some time ago I stirred up some interest in my Optimistic DAD draft, which seeks to eliminate DAD delay without significantly increasing the risk involved in address collision. In the

Re: Optimistic DAD _again!_

2004-02-23 Thread Nick 'Sharkey' Moore
On 2004-02-23, Jun-ichiro itojun Hagino wrote: Hi IPv6ers, You might recall some time ago I stirred up some interest in my Optimistic DAD draft, [...] i don't think it necessary to raise this discussion again. IIRC it was not accepted with sane reason. Previously,

Re: Optimistic DAD _again!_

2004-02-23 Thread Nick 'Sharkey' Moore
On 2004-02-23, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote: Nick 'Sharkey' Moore [EMAIL PROTECTED] said: You might recall some time ago I stirred up some interest in my Optimistic DAD draft, [...] Please let me know what you think ... and if there's enough interest maybe we can

comments on draft-moore-ipv6-optimistic-dad-04.txt

2004-02-23 Thread JINMEI Tatuya / 神明達哉
Here are comments on draft-moore-ipv6-optimistic-dad-04.txt. I have one relatively-substantial comment and several editorial ones. The relatively-substantial comment is: I don't see the strong need for the unsolicited neighbor advertisements described in Section 3.1: * (adds to 7.2.6) The

Re: Optimistic DAD _again!_

2004-02-23 Thread S. Daniel Park
Title: Re: Optimistic DAD _again!_ One fundamental question that I remember is whether optimizing DAD really makes much sense while there are other kinds of delays such as random delay (up to 1 second) for the first RS and random delay at routers before responding to an RS. Without

[rfc2462bis issue 275] DAD text inconsistencies

2004-02-23 Thread JINMEI Tatuya / 神明達哉
Since we have a discussion about optimistic DAD, this is probably a good chance to start a related discussion for rfc2462bis. As you know, there have been many discussions on DAD, including - whether omitting/optimizing DAD is a good idea - (if yes) in which case we can omit DAD - DAD vs DIID -

[psg.com #264] Dead code in DoS Algorithm

2004-02-23 Thread rt+ipv6-2462bis
This is almost an editorial fix, and the change was included in the latest I-D. IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6