A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses
RFC 6981

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

(Adrian Farrel) Yes

(Ron Bonica) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (2013-02-07 for -10)
No email
send info
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!

(Ralph Droms) No Objection

Comment (2013-02-07 for -10)
No email
send info
I agree with the question about "why publish this document" and look forward to conversation about it.

(Wesley Eddy) No Objection

Comment (2013-02-06 for -10)
No email
send info
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.

(Stephen Farrell) No Objection

Comment (2013-02-05 for -10)
No email
send info
AAH is cute as is "mild security"

(Brian Haberman) No Objection

(Russ Housley) No Objection

Comment (2013-02-05 for -10)
No email
send info
  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

Barry Leiba No Objection

(Pete Resnick) (was Discuss) No Objection

(Robert Sparks) No Objection

Comment (2013-02-06 for -10)
No email
send info
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.

(Martin Stiemerling) No Objection

Comment (2013-02-07 for -10)
No email
send info
I wonder if Section 10. Encapsulation should mention that all of the tunnel methods might create MTU issues.

(Sean Turner) No Objection

(Stewart Bryant) Recuse