TCP Extensions for Multipath Operation with Multiple Addresses
draft-ietf-mptcp-multiaddressed-12

I have several Comments that don't really merit a Discuss, but which you should really think about a little.

---

The description of Figure 13 could be clearer about the meaning of the 
value n. I.e., there are n Address IDs present.

You should probably say whether n=0 is allowed. 

Lastly, you should mark the unused bits on the figure as reserved.

---

In Figure 17, shouldn't the transition out of M_LAST-ACK (right-hand
side) be into M_TIME WAIT? Otherwise, the MPTCP PCB seems to not get
deleted.

---

Are you really happy with "RFC Required" as the allocation policy for
the new MPTCP Option Subtypes registry? You understand that one person
could write an Independent Stream RFC and take all of the available 
code points in one go? Although you might hope that the IESG would spot
this and request the ISE to not publish the RFC, this seems like a risk.

Since the plan is to move to the Standards Track, why don't you change
this to "Standards Action"?

The authors have completely cleared up the description of the MP_CAPABLE flags, and the registry for them.  Thanks very much for working with me on this.

This appears to me to be great work, and as an applications guy, I cannot wait for this to be deployed. The only thing that prevented me from balloting "Yes" instead of "No objection" is simply because much of the detailed technical work is beyond my knowledge base and I can't vouch for it personally. But what I do understand I'm very pleased by.

One addition that might serve folks well: You might add a section at the beginning or end of the document on open experimental issues that need to be addressed before going to standards track. In particular, 3.3.6, 3.3.7, and 3.8.2 point out such issues. I'm sure there are more. If you could summarize them in one section, it might be helpful.

Would it be difficult to add a short summary to this document calling out what information the mptcp implementation is expecting to get from the API?

  This paragraph:
  >
  > MPTCP's interpretation of, and effect on, regular single-path TCP
  > semantics are discussed in Section 4.
  >
  seems to be out of place in the Terminology section.

I've cleared.  Thanks for working with me on this draft.

- Something wrong with this just before the start of 3.2, might need
an RFC editor note:

   "the IDSN of a MUST be the least significant 64 bits of the SHA-1 hash"

- Change on page 38, new text says;

  "Further security considerations around the issue of	
   accidental or maliciously misdirecting ADD_ADDR messages are	
   discussed in Section 5."

I think that'd be better as:

   "Further security considerations around the issue of	
   accidentally mis-directed or maliciously directed ADD_ADDR 
   messages are	discussed in Section 5.

- This was a discuss point and I don't see a change for it, but
I'll let it go as a comment since its probably implied really.

Don't you need to say that a host MUST drop the
connection if it had set C=1 but receives a packet with a
missing checksum?

- And one old comment that also was once a discuss
and I guess you just don't wanna take on board;-)

What is the actual probability of a token collision in
3.1? I'm concerned it is not "very small" and most
especially for a server with many connections. Have you
done the math on this? According to [1] the probability is
about 10% of there being one collision with 25k
connections and hits 50% with 77163 connections. That is
not really "very small." And that ignores implemention
and/or RNG problems which are arguably more important. 

Maybe just s/very/usually/

   [1] http://preshing.com/20110504/hash-collision-probabilities