Operational Neighbor Discovery Problems
RFC 6583

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

(Jari Arkko; former steering group member) Yes

Yes (2012-03-01 for -04)
No email
send info
Thanks for writing this document.

(Ron Bonica; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection (2012-02-28 for -04)
No email
send info
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 steering group member) No Objection

No Objection ( for -04)
No email
send info

(Peter Saint-Andre; former steering group member) No Objection

No Objection (2012-02-28 for -04)
No email
send info
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 steering group member) No Objection

No Objection ( for -04)
No email
send info

(Robert Sparks; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Stephen Farrell; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Stewart Bryant; former steering group member) No Objection

No Objection (2012-02-29 for -04)
No email
send info
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 steering group member) No Objection

No Objection ( for -04)
No email
send info