Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs
RFC 6016

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

(Lars Eggert) (was No Objection) Yes

Magnus Westerlund Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Ralph Droms) No Objection

(Lisa Dusseault) No Objection

(Pasi Eronen) No Objection

(Adrian Farrel) (was Discuss) No Objection

Comment (2010-06-17)
No email
send info
Thanks very much for addressing so much of my Discuss and Comment. We made very substantial progress and improved the document significantly.

I have cleared my Discuss and relegated my issue to a Comment.

My remaining issue is mainly philosophy, and I will probably continue to 
disagree on this point regardless of further discussions.

At least it is now clear to me what the purpose and objectives are. IMHO, there is no need for this feature.  My view is that it is possible to identify the state and RSVP addressing context from the existing RSVP message, the incoming interface, and the IP header. IMHO, no further additions are necessary.

But I see that the proposed extension is not mandatory so people can continue to deploy RSVP over MPLS L3VPN without using it. That is good enough for me.

(Russ Housley) No Objection

(Alexey Melnikov) No Objection

Comment (2009-11-18 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
3.6.  Other RSVP Messages

 Comment: not using RFC 2119 keywords? The same comment probably applies to
 other sections, but this is where I've noticed.

(Tim Polk) No Objection

(Dan Romascanu) No Objection

(Robert Sparks) No Objection

(Sean Turner) No Objection