Re: [tcpm] AD review of draft-ietf-tcpm-converters-14

[<[e-mail]>]

Hi Mirja, 

Thank you for detailed review (as usual!).

We will get back to you ASAP. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Mirja Kuehlewind [mailto:[e-mail]]
> Envoyé : vendredi 10 janvier 2020 15:48
> À : [e-mail]
> Cc : tcpm IETF list
> Objet : Re: AD review of draft-ietf-tcpm-converters-14
> 
> Hi again,
> 
> Of course if have more question/comments. However these are easy ones:
> one nit, and two question about why the text is in the appendix :-)
> 
> One more thought: Looking at the SOCKS6 document again, I think what you
> have defined here, can actually be seen as a light-weight SOCKS. I think
> that’s fine but maybe it would be better to acknowledge it this way…?
> There will also be reviews by the INT ADs in IESG Evaluation and I don’t
> think this has been otherwise reviewed by any INT area working group
> yet, right?
> 
> After all thanks for a well-written document and also for the good
> shepherd write-up!
> 
> Mirja
> 
> 
> 
> --------------------
> 1) Appendix B.1:
> "   o  0x4: (client) send data in the opening SYN regardless of cookie
>       availability and without a cookie option.
> 
>    By setting this configuration variable to 0x5, a Linux client using
>    the above code would send data inside the SYN without using a TFO
>    option.”
> 0x4 or 0x5 ?
> 

[Med] 0x5 is correct because these are bitmap values. 

> 2) This is fully editorial, but given appendix C is really short, I
> think this could have also be just be place somewhere in the body of the
> document like e.g. in section 5.2.7 or the intro text in section 5.

[Med] Works for me. 

> 
> 3) Further I also don’t fully see why appendix D is in the appendix. I
> think most of this is mentioned in the body of the document already but
> in less detail which makes it actually harder to understand (in think I
> had at least one question to this below). I think having this text as
> subsections in 3.3. would actually be helpful to understand the usage
> better.
> 

[Med] We put it there because we thought this is getting down into deployment options/considerations. We can move it to the main text if we maintain the same level of details. Hope this is OK with you.