PCP Friday 2013-11-08, 0900-1100
Chairs: Reinaldo Penno, Dave Thaler
Notes: Paul Selkirk
Jabber log: http://www.ietf.org/jabber/logs/pcp/2013-11-08.html

pcp-dhcp - no objections

>> PCP Port Set                                  (Simon Perreault, 10)
>> draft-ietf-pcp-port-set

Dave Thaler suggested that if port-set capability is added (or removed),
the PCP server can reset its Epoch to zero, which causes PCP client to 
re-try using PORT_SET. New text is needed in the document for those things.
[See also discussion in the Jabber log.]

Dave: What if I have two PCP clients on the same host?
Simon: These are internal ports, so the clients need to have control
       over these ports.
Marcus: Not happy with this, want to allocate range of ports, but
       other app has allocated port from the middle of the range.
Dan: Some earlier app grabbed a single port with 24 hour binding, some
     later app tries to map a range of ports that overlaps it.
Marcus: Apps do crash sometimes.
Dave: Either (a) refresh port 2 but not 3, or (b) extend the range 1-3.
Simon: Don't extend.
Dave: If any objections, please send text.

Simon: Possible to get multiple responses to a single request.
Dan: Add to Security Considerations.
Dan: If I'm missing one response out of the set, have to re-send request.
Dave: Need to know nonce, so this can still be an on-path attack.
Reinaldo: Will have to re-read the document.

Dan: Server can be upgraded/changed to support/not support PORT_SET.
     Is there any harm to always request PORT_SET?
Dave: If I get an indication that the server doesn't currently support
      PORT_SET, I'll send multiple requests in parallel.

Dave: May need another WGLC.

Reinaldo will review and advise whether another WGLC is needed.

>> PCP Auth Protocol Details                        (Zhangdacheng, 20)
>> draft-ietf-pcp-authentication

Dave: Wondering if the word "request" in a PCP response will cause confusion.
Dan: Change to "challenge" or "needed" or something else.

Dan: Better to have only one way to do things.
Also don't understand retransmission - seems to be an optimization.
Dave: If there's some security need for this, add to the spec.

>> PCP Anycast                                    (Reinaldo Penno, 10)
>> draft-ietf-pcp-anycast

Marcus: Not just asymmetric routing that's a problem, but also
        multiple exits from your network.
Dave: Punting this to Dan, next preso.

>> PCP Server Selection                               (Dan Wing, 15)
>> draft-ietf-pcp-server-selection-01

Marcus: Exit path is affected by host's source address selection.
Dan: Choose the PCP server that's on the normal traffic path.
Dave: Consensus for solution A.

>> PCP Proxy                                              (Chairs, 15)
>> draft-ietf-pcp-proxy

Dave: Would be far easier to specify as back-to-back server+client.

>> Using PCP for signaling feedback information (Hassnaa Moustafa, 15)
>> draft-mou-pcp-application-network-feedback-00

Dan: Battery and location have nothing to do with the 5-tuple.
     Some of this feels like it should be a new opcode, but then I wonder
     if PCP is the best way to report things like this.

Dave: Continue discussion on the list.

>> PCP server discovery in the 3GPP SIPTO architecture (Gang Chen, 10)
>> draft-chen-pcp-sipto-serv-discovery-00

Dan: UE has no idea which path the traffic will take, unless it
     somehow gets the routing table from the provider.

Ted: Read RFC 6422 (Relay-Supplied DHCP Options).

Dan: Stick a PCP proxy in the box that makes the routing decision.

>> Apple PCP Implementation Report               (Stuart Cheshire, 10)

Dave: Suggest interop testing