Skip to main content

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