Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages
RFC 5711

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

(Adrian Farrel) Yes

(Jari Arkko) No Objection

Comment (2009-09-09 for -)
No email
send info
I agree with Robert's discuss.

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Ralph Droms) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

(Pasi Eronen) No Objection

Comment (2009-09-10 for -)
No email
send info
I agree that this looks more like Proposed Standard than BCP.

(Russ Housley) (was Discuss) No Objection

(Cullen Jennings) No Objection

Comment (2009-09-09 for -)
No email
send info
agree this should not be BCP

(Alexey Melnikov) No Objection

(Tim Polk) (was No Record, Discuss) No Objection

Comment (2009-09-09)
No email
send info
(a) Section 2.2 seems internally inconsistent: in accordance with 2205, a node receiving a 
PathErr message takes no action; in accordance with 3473, a node receiving a PathErr message
with Path_State_Removed in the ERROR_SPEC should take action, but is not required to.

IMHO the 3473 exception is too important to bury halfway through the paragraph with a mild
sentence beginning with "Note that..."

Perhaps the the Path_State_Removed processing merits a new paragraph beginning with: 
"There is one exception where the receiving node MAY change the state.", or something 
along that line.

(b) It might be good to append the references [RFC3209] [RFC3473] to the first sentence in
the Security Considerations, so the readers don't have to guess where those "security
considerations are already specified."

(Dan Romascanu) No Objection

(Robert Sparks) (was Discuss) No Objection

Magnus Westerlund No Objection