IETF conflict review for draft-cheshire-nat-pmp
conflict-review-cheshire-nat-pmp-00

No objection to the conflict review.

One piece of advice to the authors. 
While reading the draft, I found difficult to understand the connection between this draft and the PCP work.
The abstract mentions
    In 2012 NAT-PMP was superseded by the IETF Standards-Track
   Port Control Protocol, which builds on NAT-PMP and uses a compatible
   packet format, but adds a number of significant enhancements [PCP].

And then, it's only in the section 8 that I understood:
   In 2012 NAT-PMP was superseded by the IETF Standards-Track Port
   Control Protocol [PCP]. PCP builds on NAT-PMP and uses a compatible
   packet format, and adds a number of significant enhancements,
   including IPv6 support, management of outbound mappings, management
   of firewall rules, full compatibility with large-scale NATs with a
   pool of external addresses, error lifetimes, and an extension
   mechanism to enable future enhancements.

The intro should contain this text, with some information about the timing of draft-cheshire-nat-pmp-06 and draft-ietf-pcp-base-26. What confused me was that those two documents are being worked in parallel. So competing solutions? not really!. It's just that draft-cheshire-nat-pmp-06 should have ideally be published years ago, so that PCP could build on top of it. Note: I had to call Ralph Droms to get this history.

- The authors note that PCP is the IETF standards-track way to do
this stuff. But I wasn't clear if they're saying that it'd be good
for clients of this protocol to upgrade to PCP or that clients of
NAT-PMP are just fine to keep using it as they do today and
needn't bother updating to PCP even if a NAT box has. (I'm not
saying that one is better than the other, nor that the authors are
wrong to not say, but I was left wondering.)

- This refers to rfc 1918. I'm not sure when it'd be good to start
referring instead to the new IANA registries, or if that'd be
better here or not, but you might want to think about it.

- I wondered (but didn't check) if there's any way to confuse the
messages here with PCP messages since the same ports are to be
used for both. If so, might be no harm to note that or to explain
how to disambiguate the two protocols. (If its entirely obvious
when you read both then I guess its fine not to say.)

I hope the authors take Benoit's advice.