Skip to main content

Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages
draft-ietf-mpls-3209-patherr-06

Yes

(Adrian Farrel)

No Objection

(Alexey Melnikov)
(Dan Romascanu)
(Lars Eggert)
(Lisa Dusseault)
(Magnus Westerlund)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Ross Callon)
(Russ Housley)

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

Adrian Farrel Former IESG member
Yes
Yes () Unknown

                            
Alexey Melnikov Former IESG member
No Objection
No Objection () Unknown

                            
Cullen Jennings Former IESG member
No Objection
No Objection (2009-09-09) Unknown
agree this should not be BCP
Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (2009-09-09) Unknown
I agree with Robert's discuss.
Lars Eggert Former IESG member
No Objection
No Objection () Unknown

                            
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Magnus Westerlund Former IESG member
No Objection
No Objection () Unknown

                            
Pasi Eronen Former IESG member
No Objection
No Objection (2009-09-10) Unknown
I agree that this looks more like Proposed Standard than BCP.
Ralph Droms Former IESG member
No Objection
No Objection () Unknown

                            
Robert Sparks Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Tim Polk Former IESG member
(was No Record, Discuss) No Objection
No Objection (2009-09-09) Unknown
(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."