Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages
RFC 5711
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
Lars Eggert No Objection
(Adrian Farrel; former steering group member) Yes
(Alexey Melnikov; former steering group member) No Objection
(Cullen Jennings; former steering group member) No Objection
agree this should not be BCP
(Dan Romascanu; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
I agree with Robert's discuss.
(Lisa Dusseault; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Pasi Eronen; former steering group member) No Objection
I agree that this looks more like Proposed Standard than BCP.
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) (was Discuss) No Objection
(Ron Bonica; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
(Tim Polk; former steering group member) (was No Record, Discuss) No Objection
(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."