Requirements for MPLS Transport Profile (MPLS-TP) Shared Mesh Protection
RFC 7412

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

(Adrian Farrel; former steering group member) Yes

Yes ( for -08)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Joel Jaeggli; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Kathleen Moriarty; former steering group member) (was Discuss) No Objection

No Objection (2014-09-28)
No email
send info
Thanks very much for addressing my discuss from the SecDir review and comments in the updated version.

(Martin Stiemerling; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Pete Resnick; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Spencer Dawkins; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Stephen Farrell; former steering group member) No Objection

No Objection (2014-08-07 for -08)
No email
send info
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.)