My apologies for the tardiness of this review. The tracker says
it's on the agenda for the next telechat so maybe this isn't completely
useless.

  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 draft describes a simple request/response protocol to create
and manage mappings on upstream devices (like NATs) to control how
incoming packets get forwarded. It defines two threat models (a simple
one and an advanced one) that seem reasonable for the different use
cases. The Security Considerations are well-written and address all
attacks I could think of. The draft is very well-written and complete.

  PCP has a THIRD_PARTY option in which a PCP client can create a
mapping on a PCP server for a different device. This has the potential
for abuse. The implications of this option are mentioned somewhat in
passing in the section that describes the option ("Determining which PCP
clients are authorized to use the THIRD_PARTY Option for which other
hosts is deployment-dependent....A cryptographic authentication and
authorization model is outside the scope of this specification") but
it would be nice if they were addressed a bit more in the Security
Considerations section. It would be nice to see mention of:

  a) what capabilities should a PCP server have to properly address
     authorization of requests that include the THIRD_PARTY option; and,
  b) what are the implications of enabling the THIRD_PARTY option on a
     PCP server? In other words, what does a user need to understand
     before he enables it?

I understand that this is a very tardy request, my apologies again, so I
understand if this comment is not resolved.

  regards,

  Dan.