Skip to main content

Optimistic Duplicate Address Detection (DAD) for IPv6
draft-ietf-ipv6-optimistic-dad-07

Yes

(Margaret Cullen)

No Objection

(Alex Zinin)
(Allison Mankin)
(Bert Wijnen)
(Bill Fenner)
(David Kessens)
(Jon Peterson)
(Mark Townsley)
(Russ Housley)
(Sam Hartman)

Note: This ballot was opened for revision 07 and is now closed.

Margaret Cullen Former IESG member
Yes
Yes () Unknown

                            
Alex Zinin Former IESG member
No Objection
No Objection () Unknown

                            
Allison Mankin Former IESG member
No Objection
No Objection () Unknown

                            
Bert Wijnen Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Bill Fenner Former IESG member
No Objection
No Objection () Unknown

                            
Brian Carpenter Former IESG member
No Objection
No Objection (2005-05-23) Unknown
Possible clarifications from review by Spencer Dawkins:

... it's confusing to new readers that "standard DAD" isn't defined - there's nothing called DAD except optimistic DAD until Section 4.4). Maybe this is OK. I wish the abbreviation was ODAD, though.

In Section 1.1, I would really like to see explicit numbers here - what is the delay before an address can be used when an IPv6 node uses ND or SLAAC, and what is the corresponding delay using optimistic DAD? I've seen enough IETF discussion of fast handoff, etc. to suspect that some people will be hoping this is the 50-ms fast handoff solution... I think I can figure the numbers out from RFC 2641, but you guys already know what you're thinking!

I'm a little confused by the text in 3.2 - up to this point, Optimistic DAD is described as safe, so why is its use SHOULD NOT "unless the probability of collision is exceedingly small"? Just a sentence or two would be good, but there's no discussion of this point until Section 4.2.

In Section 4.2, "the ON will hopefully know all it needs to know about the router from the initial RA" is really informal text, even for a non-normative section. Could you add a phrase detailing the kind of things the ON hopefully knows?

Appendix A is pretty helpful, but I didn't see any reference to it in the rest of the text. A pointer would be nice, especially somewhere near Section 4.2, which discusses collision probability concerns.
David Kessens Former IESG member
No Objection
No Objection () Unknown

                            
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Mark Townsley Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Sam Hartman Former IESG member
No Objection
No Objection () Unknown

                            
Scott Hollenbeck Former IESG member
No Objection
No Objection (2005-05-24) Unknown
Section 3.2 is titled "Modifications to RFC 2461 Neighbor Discovery".  Shouldn't this document thus be identified as updating RFC 2461?  Similar question for Section 3.3 (RFC 2462).
Ted Hardie Former IESG member
No Objection
No Objection (2005-05-23) Unknown
In 4.3, I found this a bit hard to parse:
 
   Once the Optimistic Address has completed DAD, it acts exactly like a
   normal address, and so interoperation cases only arise while the
   address is Optimistic.

I assume it means that the special rules for Optimistic Addresses aren't
applicable once the Address is marked Preferred or Deprecated.  I think
that is clear enough without saying it again here, but if you do need to,
some other phrasing might be needed.