Operational Neighbor Discovery Problems
draft-ietf-v6ops-v6nd-problems-05
Yes
(Ron Bonica)
No Objection
(Gonzalo Camarillo)
(Ralph Droms)
(Robert Sparks)
(Russ Housley)
(Stephen Farrell)
(Wesley Eddy)
Note: This ballot was opened for revision 04 and is now closed.
Jari Arkko Former IESG member
Yes
Yes
(2012-03-01 for -04)
Unknown
Thanks for writing this document.
Ron Bonica Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2012-02-28 for -04)
Unknown
I have no objeciton to the publication of this document, but I noticed a few small points I hope you will look at before publication. --- While appreciating the desire to use RFCs to force vendors to provide specific function to the operators, I don't think that the use of RFC 2119 language in this Informational document adds very much (the language is intended to add clarity to protocol specifiations, and is sometimes used to make requirements documents clearer). In fact, I cold only find two uses of such language (both are "SHOULD") in this document so I suggest you change them to normal lower case, and drop the boilerplate from Section 1. --- Section 4 During testing it was concluded that 4 simultaneous nmap sessions from a low-end computer was sufficient to make a router's neighbor discovery process unusable and therefore forwarding became unavailable to the destination subnets. Without casting aspertions on the authors, is it possible to provide some qualification of this statement? For example, a reference to the test description and results, or a simple note as to by whom the testing was carried out. Similarly... The failure to maintain proper NDP behavior whilst under attack has been observed across multiple platforms and implementations, including the largest modern router platforms available (at the inception of work on this document). ... would benefit from a reference. --- Section 6 s/stipulated/suggested/ or s/stipulated/stated/ --- Section 7 might benefit from more detail on the management interfaces that operators would like to see provided by vendors both for the control of the optional mechanisms discussed in this document and for the notification about and analysis of attacks. --- It might have been nice to add a note about the interaction with mobility (such as of VMs in a data center).
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -04)
Unknown
Peter Saint-Andre Former IESG member
No Objection
No Objection
(2012-02-28 for -04)
Unknown
This document sure feels like a standards-track Applicability Statement to me. Did the WG consider requesting a status of Proposed Standard? Please consider citing RFC 4732 at the first use of the term Denial of Service.
Ralph Droms Former IESG member
No Objection
No Objection
(for -04)
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
(for -04)
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(for -04)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(for -04)
Unknown
Stewart Bryant Former IESG member
No Objection
No Objection
(2012-02-29 for -04)
Unknown
I have no objection to the publication of this document. It discusses a problem that is very close to the problem that we have chartered the ARMD to address and I am wondering whether there needs to be a reference to that work.
Wesley Eddy Former IESG member
No Objection
No Objection
(for -04)
Unknown