A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses
draft-ietf-rtgwg-ipfrr-notvia-addresses-11
Yes
(Adrian Farrel)
No Objection
(Barry Leiba)
(Brian Haberman)
(Gonzalo Camarillo)
(Pete Resnick)
(Ron Bonica)
(Sean Turner)
Recuse
(Stewart Bryant)
Note: This ballot was opened for revision 10 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
(for -10)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -10)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(2013-02-07 for -10)
Unknown
Some sentences using the RFC 2119 keywords are apparently wrong. - The not-via approach provides complete repair coverage and therefore MAY be used as the sole repair mechanism. - Note that if the path from B to the final destination includes one or more nodes that are included in the repair path, a packet MAY back track after the encapsulation is removed. - etc... My advice is to review the sentences with MAY/SHOULD/MUST See RFC 2119 section 6 Note: I did beat Pete on this one ;-) but I doublechecked a few examples with him!
Brian Haberman Former IESG member
No Objection
No Objection
(for -10)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -10)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(2013-02-07 for -10)
Unknown
I wonder if Section 10. Encapsulation should mention that all of the tunnel methods might create MTU issues.
Pete Resnick Former IESG member
(was Discuss)
No Objection
No Objection
(for -10)
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
(2013-02-07 for -10)
Unknown
I agree with the question about "why publish this document" and look forward to conversation about it.
Robert Sparks Former IESG member
No Objection
No Objection
(2013-02-06 for -10)
Unknown
Please consider adding a sentence noting that this document should not be accepted as a normative downref from a standards track document. Any IETF review this document has received has been shaped by the disclaimer that this is just reference for future work and is not appropriate for implementation. When it becomes appropriate, it would be much better if the the relevant algorithms and ideas were copied forward into a standards track document or that this document were explicitly revised to be on the standards track than to incorporate it into the standards track via a downref.
Ron Bonica Former IESG member
No Objection
No Objection
(for -10)
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2013-02-05 for -10)
Unknown
Please consider the clarifications suggested in the Gen-ART Review by Suresh Krishnan on 4-feb-2013. You can find there review here: http://www.ietf.org/mail-archive/web/gen-art/current/msg08156.html
Sean Turner Former IESG member
No Objection
No Objection
(for -10)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2013-02-05 for -10)
Unknown
AAH is cute as is "mild security"
Wesley Eddy Former IESG member
No Objection
No Objection
(2013-02-06 for -10)
Unknown
I'm not totally clear on the ultimate goal of publishing this as an RFC (rather than just a magazine or journal article), based on the IPR and lack of concrete specification. I think the "Purpose of this Document" could be more clear, despite having a section of that name. Normally we don't just capture a WG's thinking and move on, unless we're maybe declaring open issues and unsolved mysteries that require a bunch of long-term work, and I didn't get that impression from this document.
Stewart Bryant Former IESG member
Recuse
Recuse
(for -10)
Unknown