Graceful OSPF Restart Implementation Report
RFC 4167
Yes
No Objection
Note: This ballot was opened for revision 05 and is now closed.
(Alex Zinin; former steering group member) Yes
(Allison Mankin; former steering group member) No Objection
The use of RFC 1264 to work through OSPF Graceful Restart looks like a very valuable activity. It's seems it was elective for the WG to do it - RFC 1264 is aimed for whole routing protocols, not for new capabilities, however major. (What I'm saying is that this is does not seem to be a process requirement). One value of not testing the whole protocol was that arguably the testers did not have to pursue this point from RFC 1264 (because OSPF authentication is general): This must include that all of the security features have been demonstrated to operate, and that the mechanisms defined in the protocol actually provide the intended protection.
(Bert Wijnen; former steering group member) No Objection
(Bill Fenner; former steering group member) No Objection
(David Kessens; former steering group member) No Objection
(Harald Alvestrand; former steering group member) No Objection
Reviewed by Brian Carpenter, Gen-ART
(Jon Peterson; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
I do not understand the first sentence of the Security Considerations. I propose: This document does not address any security issues associated with implementing Graceful OSPF Restart. Security considerations for the OSPF protocol are included in RFC2328 [OSPF]. Security considerations for Graceful OSPF Restart are included in [GRACE].
(Scott Hollenbeck; former steering group member) No Objection
I would also suggest sending the implementation report text to the Secretariat for posting on the IETF web site at: http://www.ietf.org/IESG/implementation.html
(Steven Bellovin; former steering group member) No Objection
(Ted Hardie; former steering group member) No Objection
(Thomas Narten; former steering group member) No Objection