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

[<[e-mail]>]

Med - thanks - no follow-ups
phil


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: 02 July 2019 10:05
To: Eardley,PL,Philip,TUD1 R <[e-mail]>; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: RE: WGLC for draft-ietf-tcpm-converters-08

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