Skip to main content

Port Control Protocol (PCP) Proxy Function
draft-ietf-pcp-proxy-09

Yes

(Brian Haberman)

No Objection

(Alia Atlas)
(Alissa Cooper)
(Alvaro Retana)
(Barry Leiba)
(Ben Campbell)
(Benoît Claise)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Kathleen Moriarty)
(Terry Manderson)

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

Brian Haberman Former IESG member
Yes
Yes (for -08) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Ben Campbell Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (2015-07-09 for -08) Unknown
I have these comments and questions:

1) There is no clear definition of what a PCP proxy really is. Section 1. shows it as a pure signalling entity only w/o any NAT functionality (no mapping functionality) but the document body itself talks about PCP proxies having a mapping table (and also the possibility of not -- Section 3.4.1). Adding such a statement about the PCP proxy is or can be to the intro or the terminology section is a good thing.

2) Section 3.1 talks about hairpinning:
There is a potential noteable issue in terms of network management: If the PCP proxy is performing the hair pinning for the Assigned External Address, the byte counters on the PCP server and the proxy will differ for the Assigned External Address. This might be worth to note in a network managment section (or elsewhere in the document).
Spencer Dawkins Former IESG member
(was Discuss) No Objection
No Objection (2015-07-09 for -08) Unknown
I share Stephen's curiosity in his Discuss, but I'll follow along there (I saw Med responded 15 minutes ago).

Thanks for addressing my Discuss, which was:

This should be an easy Discuss to resolve.

I was surprised to see 

   In addition, this goes against the spirit of NAT gateways.  The main
   purpose of a NAT gateway is to make multiple downstream client
   devices making outgoing TCP connections to appear, from the point of
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   view of everything upstream of the NAT gateway, to be a single client
   device making outgoing TCP connections.  In the same spirit, it makes
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   sense for a PCP-capable NAT gateway to make multiple downstream
   client devices requesting port mappings to appear, from the point of
   view of everything upstream of the NAT gateway, to be a single client
   device requesting port mappings.
   
limited to TCP connections. Is this intentional? https://tools.ietf.org/html/rfc6887#section-2.2 certainly lists other transport protocols.

Is it correct to say 

   In addition, this goes against the spirit of NAT gateways.  The main
   purpose of a NAT gateway is to make multiple downstream client
   devices to appear, from the point of
   view of everything upstream of the NAT gateway, to be a single client
   device.  
   
?

Please note that I'm not objecting to the focus on TCP in this text:

   Where this document uses the terms "upstream" and "downstream", the
   term "upstream" refers to the direction outbound packets travel
   towards the public Internet, and the term "downstream" refers to the
   direction inbound packets travel from the public Internet towards
   client systems.  Typically when a home user views a web site, their
   computer sends an outbound TCP SYN packet upstream towards the public
   Internet, and an inbound downstream TCP SYN ACK reply comes back from
   the public Internet.
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2015-07-16) Unknown
Thanks for handling my discuss
Terry Manderson Former IESG member
No Objection
No Objection (for -08) Unknown