Agenda is to conclude on the remaining open issues on the protocol doc, in particular concluding on the proxy issues: Reminder: the purpose of the audio is to close all remaining issues with the protocol draft (confirmed on the list). We will proceed with WG last call immediately a new version is produced that incorporates the conclusions (and simultaneously last call the API doc).

   1. Proxy. It has previously been agreed that [1] we want to complete the protocol standard without deciding the detailed mechanism for supporting proxy operation, [2] we want to allow future flexibility for extensions to support a proxy. There are several possibilities for how to achieve this, some of which alter the current protocol, see email discussion for the possibilities  http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01569.html Our current impression is that consensus is for Option 5 (Keep the current format and later develop new option for proxy capability, eg ADD_ADDR2)
   2. Keys on various MP_CAPABLE msgs. Email discussion concluded to go back to the approach in the -03 version of the draft, with key in SYN - as well as syn/ack ack (& ack for reliability). (Remember to update S2.1 as well)  http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01549.html
   3. Fallback mode – proposed solution is to keep this simple, "Once MPTCP reverts to TCP, it MUST NOT revert back to MPTCP afterwards".  http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01555.html
   4. Teardown of state when all subflows fail - This is a heuristics issue rather than a protocol issue,  http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01531.html
   5. Add Bulk_transfer_optimisation flag to MP-Capable? Don't add, seems like extra complexity for not much gain  http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01531.html
   6. Support of “Single-path mode” (an ambiguous term...)? No changes to the spec. Could be subject of later work on exact requirements for “single path mode” and potential future work to extend the protocol.  http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01559.html