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

[<[e-mail]>]

Hi Phil,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : tcpm [mailto:[e-mail]] De la part de
> [e-mail]
> Envoyé : lundi 1 juillet 2019 12:04
> À : [e-mail]; [e-mail]; [e-mail]
> Cc : [e-mail]
> Objet : Re: [tcpm] WGLC for draft-ietf-tcpm-converters-08
> 
> Finishing my review...
> 
> Section 4.2.8 Error TLV
> Resource exceeded & Network failure
> " The
>       Transport Converter may indicate in the Value field the suggested
>       delay (in seconds) that the Client SHOULD wait before soliciting
>       the Transport Converter for a new proxied connection.  A Value of
>       zero corresponds to a default delay of at least 30 seconds."
> Are there any circumstances in which a Transport Converter may want to
> suggest that the Client waits less than one second before re-trying?

[Med] The errors we identified so far do not have such requirements. 

> 
> Section 7.5 Multipath TCP-specific Considerations
> " aggregation service" -> multipath TCP converter service?

[Med] OK.

> 
> " This method does not require any interaction
>       with the Transport Converter." [twice]
> You could say interaction of what (since something is interacting with
> it!)

[Med] added "... for authorization matters."

> 
> Section 8 IANA Considerations
> Convert TLVs
> It has a range assigned via IETF review, a range assigned via
> Specification required and a range for Private use. Wouldn't it be simpler
> to choose either IETF review or Specification required (plus private use)?
> I think Specification required would be ok, given the RFC will be
> Experimental.

[Med] We are simplifying the assignment for some code points while allowing for a range to be reserved to key extensions. This is simple compared to "Standards Action" I have seen in some experimental RFCs! 

> 
> Convert Error Messages
> It has a range assigned via IETF review and a range assigned via
> Specification required.
> Same comment as above, except more strongly - for error messages, IETF
> review seems excessive to me.

[Med] Why? The same considerations (interoperability) apply for the error codes and TLVs.  

> Also, would it be useful to have some space for Private use?

[Med] Makes sense. 

> 
> Section 11 Example Socket API Changes to Support the 0-RTT Convert
> Protocol
> " As an example, on Linux, a client can send the 0-RTT Convert message
>    inside a SYN by using sendto with the MSG_FASTOPEN flag as shown in
>    the example below"
> Is this example right?

[Med] Yes. 

 Since Transport Converter now uses TLV messages
> rather than TFO?

[Med] This is about the control flags. 

> 
> Section 12
> " A recently
>    proposed extension to SOCKS also leverages the TFO option"
> I think "also" should be deleted (since Transport Converter now uses TLV
> messages rather than TFO)

[Med] OK.

> 
> Section 13
> [RFC6824]
> Would be good to update to the bis document (which has currently completed
> IESG - I think waiting for AD follow-up)

[Med] Will consider this once the bis is sent to the RFC editor. 

FWIW, the changes to address this review can be seen at: https://github.com/obonaventure/draft-tcp-converters/pull/65/files 

> 
> Thanks - best wishes,
> phil