Skip to main content

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

Yes

(Ralph Droms)

No Objection

(Adrian Farrel)
(Barry Leiba)
(Brian Haberman)
(Martin Stiemerling)
(Pete Resnick)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Sean Turner)
(Wesley Eddy)

Note: This ballot was opened for revision 00 and is now closed.

Ballot question: "Is this the correct conflict review response?"

(Ralph Droms; former steering group member) Yes

Yes ()

                            

(Adrian Farrel; former steering group member) No Objection

No Objection ()

                            

(Barry Leiba; former steering group member) No Objection

No Objection ()

                            

(Benoît Claise; former steering group member) No Objection

No Objection (2013-01-22)
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.

(Brian Haberman; former steering group member) No Objection

No Objection ()

                            

(Martin Stiemerling; former steering group member) No Objection

No Objection ()

                            

(Pete Resnick; former steering group member) No Objection

No Objection ()

                            

(Robert Sparks; former steering group member) No Objection

No Objection ()

                            

(Ron Bonica; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection ()

                            

(Sean Turner; former steering group member) No Objection

No Objection ()

                            

(Stephen Farrell; former steering group member) No Objection

No Objection (2013-01-22)
- 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.)

(Stewart Bryant; former steering group member) No Objection

No Objection (2013-01-24)
I hope the authors take Benoit's advice.

(Wesley Eddy; former steering group member) No Objection

No Objection ()