PathErr Message Triggered MPLS and GMPLS LSP Reroutes
draft-ietf-mpls-gmpls-lsp-reroute-06
Yes
(Adrian Farrel)
No Objection
(Alexey Melnikov)
(Cullen Jennings)
(Dan Romascanu)
(Lars Eggert)
(Lisa Dusseault)
(Magnus Westerlund)
(Ralph Droms)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Tim Polk)
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
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
(was Discuss)
No Objection
No Objection
(2009-09-09)
Unknown
> the ERO received in the LSP's incoming Path message does not preclude Term ERO not yet defined > A transit node MAY act on a reroute request locally when the ERO > received in the LSP's incoming Path message does not precluded the > reroute. ... does not preclude ?
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
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Robert Sparks Former IESG member
(was Discuss)
No Objection
No Objection
(2009-09-21)
Unknown
I'm a little concerned by this language in the Security Considerations section: This document does introduce a new error code value, but this value is functionally equivalent to existing semantics. If the semantics are the same, why have a new error code at all? Is the sentence really trying to say the semantics are similar enough to other things that the security impacts are already well understood?
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
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
No Objection
No Objection
()
Unknown