I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is a requirements document (intended as informational) for a routing protocol. At this level of abstraction, I don’t think there are any interesting security issues. There are some messages in the protocol that need to be communicated securely, and the security considerations section references some other RFCs and says the new messages will “inherit at least the same security properties” as the messages in those other RFCs. I didn’t look up what kind of protection existed there. The interesting routing protocol issue has to do with nesting of routing algorithms and the needed multipliers in timeouts. It would appear that pseudo-wires run over a conventional routed infrastructure and also connect parts of a conventional routed infrastructure. The spec assumes that failures within the inner routed infrastructure will heal themselves quickly enough to not be noticed by the pwe3 redundancy protocol (if they are capable of healing at all), and that pseudo-wire failover (triggered by this inner failure) will happen quickly enough to not disrupt the routing protocol that is running over the pseudo-wires. But that requirement is not explicitly acknowledged in the document, and it intuitively seems like a significant challenge. Micro-level issues: In terminology (section 2), the Primary PW is defined as the one that will be used when any one will do, and that if it goes down and comes back the PW will revert to it. But it also defines non-revertive protection switching as an option where the traffic will not switch back to the primary unless the secondary fails, and in section 4.1 it says that non-revertive protection MUST be supported and revertive is optional. Typos: Section 4.1: besupported -> be supported suported -> supported Section 4.2: Orphaned bullet