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

[<[e-mail]>]

Re-,

Focusing on this part of the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : tcpm [mailto:[e-mail]] De la part de
> [e-mail]
> Envoyé : jeudi 27 juin 2019 17:58
> À : [e-mail]; [e-mail]
> Cc : [e-mail]
> Objet : Re: [tcpm] WGLC for draft-ietf-tcpm-converters-08
> 
> I support this document. Thanks to the authors for the nice work.
> 
> 
> --------------
> Suggested clarifications - significant:-
> 
> I think it would be great if Section 3 was expanded into a "protocol
> model" https://tools.ietf.org/html/rfc4101 in particular to expand on

[Med] Section 3 is purposely edited "to quickly grasp the essence of" the convert protocol. It focuses on the main design rationale that is use one single SYN to supply data to a converter. That supplied data is unambiguously distinguished by means of TLVs and location within the payload.  

> <<   2. What messages are being transmitted and what do they mean?>> -
> figures show the basic msg exchanges (info, connect, extended, supported,
> cookie and error)

[Med] There is a risk to be redundant with Section 4 (4.2.2, in particular) + discuss messages that are not defined yet. We may consider adding figures to section 4, though. 

> <<   3. What are the important, but unobvious, features of the protocol?>>
> eg use of assigned port# ; use of first bytes of bytestream ;etc.

[Med] Again, there is a risk to be redundant here. Will think about this further. 

> 
> I think you could distinguish more carefully between: the initiator of the
> TCP convert protocol and the other 'legacy' end point versus the end
> device downstream on a broadband line and the server upstream in the
> internet. The language of the doc basically assumes that a "Client"
> fulfils both the first roles and a "Server" fulfils both the last roles,
> but this needs not always be the case. I realised this reading Section
> 4.2.8, but I suspect it's true in many other places.

[Med] I agree with the comment. 

The assumption are as follows:
* The default communication direction is assumed to be from a host (Client role) to a remote host (Server role): denoted as "outgoing"
* A host (which is used to be a client for outgoing connections) may accept incoming connections because it embeds an application server. We called that "client" too for simplification reasons. 

Point taken, we will need to figure out how to make this better. 

> 
>