Skip to main content

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