0-RTT TCP Convert Protocol
draft-ietf-tcpm-converters-19

Thank you for addressing my DISCUSS and COMMENT points.

Med and other authors,

Thank you for addressing my previous DISCUSS (kept below for archival purpose), they are now cleared. Most of my COMMENTs were also addressed.

BUT, the new version has a couple of typos in the changed text, e.g., 'relam' rather than 'realm'. It also uses 'Unassigned' rather than the usual 'Reserved', is there any reason?

Finally, I wonder why the 'magic number' has been introduced and while using the RFC number if 'fun' the entropy is not that high.

Anyway, the document can be published in my opinion

Thank you for all the work and the fast reaction

-éric

== OLD DISCUSS ==

-- Section 1.2 --
A trivial one: while the title and the abstract of this document appear as quite generic, the document focus is reduced later in section 1.2 to MPTCP: 
  "this
   document specifies how the Convert Protocol applies for Multipath
   TCP.  It is out of scope of this document to provide a comprehensive
   list of all potential conversion services. "
While I do not mind having a focus on MPTCP only, I would strongly suggest to reflect this focus in the title and in the abstract (the current filename is correct).

-- Section 6.2.8 --
I appreciate that this is an experimental document, but, having only 2 occurrences of ICMP in the whole document and no real "how to process" TLV "Destination Unreachable"... and the payload of this TLV having only the code without the offending packet will probably make Path MTU discovery (and other mechanisms) impossible.

While I am not a transport expert, I believe that this aspect needs to be described in this document.

== COMMENTS ==

-- Section 1.2 --
Is the benefit of a transport proxy only for the clients as written in the 1st paragraph? It was probably the case for the original MPTCP proxy but what about other TCP extensions?


-- Section 4.1 --
While the difference "(Internet-facing interface, customer-facing interface)" will probably represent the vast majority of use cases, I wonder whether there will always be a single Internet-facing ? Could probably be 0 or 2 in some use cases... Suggest to remove this part of the text.

-- Section 6.1 --
Please state the usual wording about "unassigned" field: it must be ignored by the receiver.

Adding some explanations on why version 0 is reserved but cannot be used would be welcome.

-- Section 6.2.5 --
Can the "remote peer IP address" be a link-local address ?

== NITS ==

-- Section 1.1 (and possibly others) --
Please use a consistent means of introducing acronyms, cfr URLLC and ATSSS ;-)

-- Section 4.2 ---
The use of "regular TCP packets" makes me wonder whether the authors think that MPTCP uses "irregular TCP packets"... The use of 'regular' seems a little weird here but I am not a native English speaker.

-- Section 4.3 --
The caption below figure 7 ends with "(TCP)" that is not the acronym of "Transport Session Entry". Is it expected ?

It is not very clear whether the WG expects many future version of this protocol. Version compatibility story is not very clear in this document, so the WG should think about it.

Thank you for adding the applicability statement; it removes the main sense
of having disparate deployment scenarios one of which is well-defined and the
other of which requires some under-specified actions in order to be secure.

I'm still pretty uneasy about giving such emphasis to the "0-RTT" nature
of this service, and feel that achieving the "0-RTT" nature relies on some
strong assumptions on the nature of the network in which the protocol is
being deployed, so that the 0-RTT nature is not as much an attribute of
the protocol itself as the combination of the protocol and the deployment
scenario.  That said, the document is not describing an internally inconsistent
state, so I cannot justify making this a Discuss-level point any more.

I had a similar question as Éric on the handling of ICMP messages and related troubleshooting (specifically I was concerned about the non-Type 1 (Destination Unreachable) messages. I saw the authors responded and I will keep track of the discussion.