Original text:
acknowledged at the connection level with a DATA_ACK.  Further details are in sec_close. <del> There is an additional method of connecton closure, referred to as </del>  "Fast Close", which is analogous to closing a single-path TCP connection with a RST signal.  The MP_FASTCLOSE signal is used to indicate to the peer that the connection will be abruptly closed and the MPTCP connection would continue to provide a regular TCP service. Since key generation is implementation-specific, there is no <del> requirement that they be simply random numbers.  An implemention is </del>  free to exchange cryptographic material out-of-band and generate these keys from this, in order to provide additional mechanisms by which to verify the identity of the communicating entities.  For numbers is not required, then an implementation MAY include just the lower 32 bits of the data sequence number in the data sequence mapping and/or Data ACK as an optimization, and an implementation can <del> make this choice independently for each packet.  An implementaton </del>  MUST be able to receive and process both 64-bit or 32-bit sequence number values, but it is not required that an implementation is able to send both. can be altered by a middlebox without affecting MPTCP, as the data stream is equivalent to a regular, legacy TCP session.  The MP_FAIL signal affects only one direction of traffic.  It is not mandatory <del> for the reciever of an MP_FAIL to also respond with an MP_FAIL, since </del>  the paths may only be damaged in one direction.  However, implementations MAY choose to send a MP_FAIL in the reverse direction and entirely revert to a regular TCP session. that can be applied here.  Furthermore, an on-path attacker would have access to the raw data, negating any other TCP-level security mechanisms.  Also a change from RFC6824 has removed the subflow <del> identifer from the MP_PRIO option (sec_policy), to remove the </del>  theoretical attack where a subflow could be placed in "backup" mode by an attacker.

Reviewer comments:
Reading through the draft I noticed a few typos so I wanted to propose a small change to fix.

Revised text:
acknowledged at the connection level with a DATA_ACK.  Further details are in sec_close.  <ins> There is an additional method of connection closure, referred to as </ins> "Fast Close", which is analogous to closing a single-path TCP connection with a RST signal.  The MP_FASTCLOSE signal is used to indicate to the peer that the connection will be abruptly closed and the MPTCP connection would continue to provide a regular TCP service. Since key generation is implementation-specific, there is no  <ins> requirement that they be simply random numbers.  An implementation is </ins> free to exchange cryptographic material out-of-band and generate these keys from this, in order to provide additional mechanisms by which to verify the identity of the communicating entities.  For numbers is not required, then an implementation MAY include just the lower 32 bits of the data sequence number in the data sequence mapping and/or Data ACK as an optimization, and an implementation can  <ins> make this choice independently for each packet.  An implementation </ins> MUST be able to receive and process both 64-bit or 32-bit sequence number values, but it is not required that an implementation is able to send both. can be altered by a middlebox without affecting MPTCP, as the data stream is equivalent to a regular, legacy TCP session.  The MP_FAIL signal affects only one direction of traffic.  It is not mandatory  <ins> for the receiver of an MP_FAIL to also respond with an MP_FAIL, since </ins> the paths may only be damaged in one direction.  However, implementations MAY choose to send a MP_FAIL in the reverse direction and entirely revert to a regular TCP session. that can be applied here.  Furthermore, an on-path attacker would have access to the raw data, negating any other TCP-level security mechanisms.  Also a change from RFC6824 has removed the subflow  <ins> identifier from the MP_PRIO option (sec_policy), to remove the </ins> theoretical attack where a subflow could be placed in "backup" mode by an attacker.