Requirements for MPLS Transport Profile (MPLS-TP) Shared Mesh Protection
draft-ietf-mpls-smp-requirements-09
Yes
(Adrian Farrel)
No Objection
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Pete Resnick)
(Spencer Dawkins)
Note: This ballot was opened for revision 08 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
(for -08)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -08)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -08)
Unknown
Kathleen Moriarty Former IESG member
(was Discuss)
No Objection
No Objection
(2014-09-28)
Unknown
Thanks very much for addressing my discuss from the SecDir review and comments in the updated version.
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -08)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -08)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -08)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2014-08-07 for -08)
Unknown
I'm not sure I agree that there are no new security considerations here. Say if the path ABCDE has some security property (e.g. encrypted) then won't that also be a requirement that APQRE will also need to be able to meet? And doesn't that then impose some requirements on solutions? So wouldn't it be a good plan to add a requirement that solutions MUST be able to ensure/manage commensurate security for protection paths? (This is not a discuss because I'd be fine to raise such a discuss ballot for a solution document, and also because it overlaps with Kathleen's discuss with which I agree.)