Hi, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. The draft introduces a new Port Control Protocol (PCP) option, THIRD_PARTY_ID, which is designed to allow identification of a Third Party where that party’s IP address alone does not provide sufficient information to create required mappings in a PCP-controlled device. A scenario for this would be where a CGN is in use, and private IP address ranges used at different subscribers may overlap. My overall view is that this draft is Not Ready. The main concern I have with the draft is the somewhat obvious potential for privacy-related information to be exposed/leak, especially given the draft hints that the approach may be used more broadly. The need for a way to disambiguate between devices with the same IP address information is, however, well made. If the draft moves forward, I would personally like to see it nail down a very specific use of this option, using a differentiator that minimises privacy implications, which might mean a (non persistent?) tunnel ID (which is available in both scenarios presented in the draft). Using MAC addresses, even with the prospect of these changing over time in the future (due to existing privacy concerns over them), seems inappropriate and unnecessary. Is there a specific justification here? Indeed, if/when they do start changing over time more frequently, any differentiation based on them may then break anyway. I suspect this has been discussed (perhaps at length!) in the WG, but if the authors wish to progress broader usage, this should be very carefully justified in the text. The option as defined has no field defining the property on which the ID is generated. That may be intentional, in that any agreed property could be used. But on the scenarios presented in the draft, a tunnel ID seems commonly available. Regardless, the Security Considerations section is insufficient - it also mentions location or profile information (what type of location information?), but not issues with MAC addresses. Finally, I would assume this draft would not be needed in an IPv6 deployment, as hosts would then have unique IP addresses within the THIRD_PARTY option. Should the draft specifically say this is IPv4-only work (which is quite rare now in the IETF), or is there any scenario in which this would be used with IPv6? Best wishes, Tim