OSPF Stub Router Advertisement
RFC 6987

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

(Stewart Bryant) Yes

(Adrian Farrel) Yes

Comment (2013-03-27 for -03)
No email
send info
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) Yes

(Jari Arkko) No Objection

Comment (2013-03-27 for -03)
No email
send info
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

(Richard Barnes) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) (was Discuss) No Objection

Comment (2013-03-27 for -03)
No email
send info
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.

(Stephen Farrell) No Objection

(Brian Haberman) No Objection

Barry Leiba No Objection

(Ted Lemon) No Objection

(Pete Resnick) No Objection

Comment (2013-03-27 for -03)
No email
send info
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.

(Martin Stiemerling) No Objection

Comment (2013-03-26 for -03)
No email
send info
I was also wondering why this is informational rather than PS.

(Sean Turner) No Objection

Comment (2013-03-26 for -03)
No email
send info
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.