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.

I believe this document is READY WITH a minor ISSUE addressed below. The Security Considerations section of this document, along with its companion draft-ietf-pce-stateful-pce-18, appears to do a thorough job of enumerating the ways in which the newly-introduced message types can contribute to the ability of misbehaving PCCs and PCEs to disrupt each other, with consequences that generally strike me as acceptable. It duly recommends that PCEP be run over an authenticated channel to prevent these messages from being spoofed by a third party.

I am unsure how this final recommendation is going to be implemented in practice. RFC 5440 characterizes channel security for PCEP as a work-in-progress as of 2009, and I lack sufficient familiarity with this area to know if the status quo has improved since then in practice. The TCP authentication option, cited in RFC 5440 as WIP, is now RFC 5925, but I don't know whether anyone actually uses it for this application. TLS is mentioned as another alternative, but existing standards documents give insufficient instruction on how to implement this interoperably, since there is no mention of port allocations, a STARTTLS scheme, an ALPN identification sequence, or anything else that would explain how to go about initiating the TLS session. It looks like draft-ietf-pce-pceps intends to rectify this.

Addressing whatever deficiencies exist in PCEP security mechanisms obviously falls well outside the scope of this particular document to address. Even if the administrator fails to provide channel security for PCEP as recommended, adding support for stateful sync optimizations will not leave the network meaningfully worse-off than it was already. However -- and here's the ISSUE -- as Alvaro Retana already sort of touched on, the introduction of the Speaker Entity ID TLV means that implementation of stateful sync optimizations can't be entirely agnostic with respect to the choice of channel security mechanism. Implementations need to verify that the Speaker Entity ID is consistent with the cryptographic identity of the channel peer in order to prevent one PCC from spoofing the identity of another. Until PCEP channel security matures a bit I'm not how much concrete advice we can give implementers on how to do this properly, but somewhere in the document there should at least be an observation that this check should be present.

I also second Retana's desire for greater consistency between this document, draft-ietf-pce-stateful-pce, and RFC 5440 as to which channel security mechanisms are recommended and/or required.

PS - sorry about the last minute review.