Skip to main content

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

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 steering group member) Yes

Yes (for -08)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (for -08)

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (for -08)

                            

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

No Objection (2014-09-28)
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)

                            

(Pete Resnick; former steering group member) No Objection

No Objection (for -08)

                            

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -08)

                            

(Stephen Farrell; former steering group member) No Objection

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