Graceful OSPF Restart Implementation Report
RFC 4167

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

(Alex Zinin) Yes

(Harald Alvestrand) No Objection

Comment (2004-05-13)
No email
send info
Reviewed by Brian Carpenter, Gen-ART

(Steven Bellovin) No Objection

(Bill Fenner) No Objection

(Ted Hardie) No Objection

(Scott Hollenbeck) No Objection

Comment (2004-04-30)
No email
send info
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

(Russ Housley) No Objection

Comment (2004-05-11)
No email
send info
  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].

(David Kessens) No Objection

(Allison Mankin) No Objection

Comment (2004-05-13)
No email
send info
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.

(Thomas Narten) No Objection

(Jon Peterson) No Objection

(Bert Wijnen) No Objection