Re: [tcpm] WGLC for draft-ietf-tcpm-converters-08

[<[e-mail]>]

Hi Phil,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : [e-mail] [mailto:[e-mail]]
> Envoyé : mardi 9 juillet 2019 12:08
> À : BOUCADAIR Mohamed TGI/OLN; [e-mail];
> [e-mail]
> Cc : [e-mail]
> Objet : RE: WGLC for draft-ietf-tcpm-converters-08
> 
> Med,
> Thanks, just following up a couple of points.
> >
> > S4.1 title
> > "fixed header" - is "fixed" needed?
> 
> [Med] It is fixed because it is present in all convert messages. Do you
> prefer "common" ?
> 
> [phil] I'd prefer if you explicitly stated that all Convert messages have
> this header.
> In fact, I think you could start Section 4 with text to capture the key
> points:
> "This section describes the messages that are exchanged between a Client
> and a Transport Converter. All Convert protocol messages MUST be sent on a
> SYN, ACK or SYN-ACK, to port [tba]. All Convert protocol messages MUST be
> sent as the first bytes of the bytestream and MUST use the header shown in
> Figure 9 and described in Section 4.1, followed by the message itself
> using the generic TLV format shown in Figure 10 and described in Section
> 4.2. "

[Med] Thanks. Some of this proposed text is redundant with existing text, e.g.,

   The Client and the Transport Converter MUST send the fixed-sized
   header, shown in Figure 9, as the first four bytes of the bytestream.

While other part of the text may not be accurate for incoming connections (MUST be sent ...to port (TBA)).

Now that I see more your point, I made some tweaking to address your comment as shown in:
https://github.com/obonaventure/draft-tcp-converters/pull/63/files 

> 
> >
> > " Transport Converter SHOULD include in this
> >    list the TCP options that it accepts from Clients and that it
> >    includes the SYN packets that it sends to initiate connections."
> > I couldn't parse the second part of the sentence ("and that it...")
> >
> 
> [Med] Changed to:
> 
> " A Transport Converter SHOULD include in
> this list the TCP options that it accepts from Clients; these options are
> included by the Transport Converter in the SYN packets that it sends to
> initiate connections."
> 
> Better?
> 
> [phil] Yes. Instead of "are included" you could say MUST /SHOULD /MAY

[Med] This would be redundant with the "SHOULD" in that text. 

> 
> 
> > Section 6
> > This section actually only discusses one type of middlebox (removes
> SYN).
> > Can the discussion be widened slightly
> 
> [Med] This section only focuses on SYN/SYN-ACK because these are used by
> the Convert protocol.
> 
> Do you have in mind a particular case (specific to the Convert protocol)
> that may be problematic?
> 
> [phil] the section only discusses removal of SYN, and not other ways a
> middlebox could interfere with the SYN/ACK.

[Med] The following cases can be considered for SYN/ACKs: 

(1) a middlebox that drops SYN/ACKs having a payload is straightforward. The client won't naturally be able to establish the connection via the converter.  

(2) a middlebox that removes the payload of SYN/ACKs:
 2-a. If that middlebox removes also the payload of SYNs (which is likely), this would have been detected by the client as per the text already in the draft. 
 2-b. If that middlebox lets pass SYNs with their payload but removes the payload of SYN/ACKs (for some mysterious reasons): This can be easily handled by the client because it expects an Error or Extended TCP Header TLV in the response. If an Error TLV was included, a message to terminate the connection would be sent by the Converter. Otherwise, there is no reason to close the connection.  

Do you think that "2-b" is likely and is worth to be documented in the text? Thank you.  

> 
> Thanks
> phil