OSPF Stub Router Advertisement
draft-ietf-ospf-rfc3137bis-04
Yes
(Joel Jaeggli)
(Stewart Bryant)
No Objection
(Barry Leiba)
(Brian Haberman)
(Gonzalo Camarillo)
(Richard Barnes)
(Stephen Farrell)
(Ted Lemon)
Note: This ballot was opened for revision 03 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
(2013-03-27 for -03)
Unknown
Thanks for this work which I support. I am balloting Yes, but hope you will address my comments. --- Can we take the oportunity to fix the Abstract since an OSPF implementation is not synonymous with a router? OLD This document describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise unavailability to forward transit traffic or to lower the preference level for the paths through such a router. NEW This document describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise a router's unavailability to forward transit traffic, or to lower the preference level for the paths through such a router. END --- This document needs a section marked "Changes from RFC 3137" so that it is easy for people to find out what has changed. It may be that you intend the Appendix to capture this, and that the -00 version of the I-D was the same as the old RFC. But this is not clear. Additionally, such change logs are usually deleted by the RFC Editor. And, finally, at this stage we don't need to know the sequences of changes from revision to revision: just the summary of all changes from the RFC. --- Section 2.1 OSPFv3 [RFC5340] introduced additional options to provide similar, if not better, control of the forwarding topology; the R-bit provides a more granular indication of whether a router is active and should be used for transit traffic. You have used one of my pet phrases. I have beaten-up about it sufficiently that I am now sensitive to its use and the ambiguity it provides. Does "similar, if not better" mean the solution in 5340 is not better (i.e. <= ) the solution you describe in this document. Or does it mean that the solution in 5340 is at least better (i.e., >= ) the solution you describe. When I use the phrase, I always mean the latter, but I can see why many non-native speakers (such as Americans ;-) get confused. Maybe just spell this out?
Joel Jaeggli Former IESG member
Yes
Yes
(for -03)
Unknown
Stewart Bryant Former IESG member
Yes
Yes
(for -03)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -03)
Unknown
Benoît Claise Former IESG member
(was Discuss)
No Objection
No Objection
(2013-03-27 for -03)
Unknown
Thanks for addressing my DISCUSS-DISCUSS. For the record, I cut/paste it, along with the answer, below. Here is Fred Baker's feedback, from the OPS-directorate review (btw, no OP- related concerns): If I would recommend the IESG do anything in particular with the draft, it would be to promote it to Proposed Standard; RFC 3137 is an Informational document that modifies a Proposed Standard, which seems strange. Operational experience with RFC 3137 has been that it works as advertised, and in IPv6 networks the R-bit approach is superior. Answer from Stewart Bryant: Benoit, I have discussed with the authors and the chairs and they confirm that Information is the appropriate track. The OSPFv3 R-bit is part of the base OSPFv3 specification (RFC 5340) and hence all OSPFv3 routers should support it. The original motivation for making the OSPF Stub Router mechanism, as described in RFC 3137, an informational document is that it can be implemented purely as a local policy with the situations under which the policy is applied and the duration of application out of the scope. In other words, there is no change to the protocol or the behavior of OSPF routers other than the OSPF router temporarily designating itself a stub router. The OSPF WG has consistently applied the policy of documents requiring co-ordinated action being PS and local policy documents being Informational, and this draft conforms to that policy.
Brian Haberman Former IESG member
No Objection
No Objection
(for -03)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -03)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2013-03-27 for -03)
Unknown
I would suggest that the document explain what has changed since the previous RFC. http://tools.ietf.org/rfcdiff?url1=rfc3137.txt&url2=draft-ietf-ospf-rfc3137bis-03.txt
Martin Stiemerling Former IESG member
No Objection
No Objection
(2013-03-26 for -03)
Unknown
I was also wondering why this is informational rather than PS.
Pete Resnick Former IESG member
No Objection
No Objection
(2013-03-27 for -03)
Unknown
Even with Stewart's explanation of why this is Informational, I'm still not convinced why this (or 3137) is not PS (or at this point IS). But I don't think it makes enough difference to change.
Richard Barnes Former IESG member
No Objection
No Objection
(for -03)
Unknown
Sean Turner Former IESG member
No Objection
No Objection
(2013-03-26 for -03)
Unknown
For bis drafts, it's often nice to list the differences between the old and new versions. Appendix A lists the changes from -00 to -03, but it's not clear that it's going to be retained? Is it and if it could they just the changes between 3137 and 3137bis? Should RFC 2178 be referenced as well? Curious why every other version of OSPFv2 is referenced except this one.
Stephen Farrell Former IESG member
No Objection
No Objection
(for -03)
Unknown
Ted Lemon Former IESG member
No Objection
No Objection
(for -03)
Unknown