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

<> Fri, 28 June 2019 09:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0EFD11201C5; Fri, 28 Jun 2019 02:27:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v5QQeiBz7_WN; Fri, 28 Jun 2019 02:27:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5F2B7120096; Fri, 28 Jun 2019 02:27:06 -0700 (PDT)
Received: from (unknown [xx.xx.xx.5]) by (ESMTP service) with ESMTP id 45Zry06fs7z8yBS; Fri, 28 Jun 2019 11:27:04 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) by (ESMTP service) with ESMTP id 45Zry05VF8zCqkc; Fri, 28 Jun 2019 11:27:04 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM44.corporate.adroot.infra.ftgroup ([fe80::e8a4:8bb:d7c2:f4e2%21]) with mapi id 14.03.0439.000; Fri, 28 Jun 2019 11:27:04 +0200
To: "" <>, "" <>, "" <>
CC: "" <>
Thread-Topic: WGLC for draft-ietf-tcpm-converters-08
Thread-Index: AdUrckm1sQAV9Sf8TqW1iT6fsU2DwgBZdsDwACyBV3A=
Date: Fri, 28 Jun 2019 09:27:03 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EAAF429@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <> <LNXP123MB258781EFAC897351EDB153E2EBFD0@LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM>
In-Reply-To: <LNXP123MB258781EFAC897351EDB153E2EBFD0@LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-converters-08
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 28 Jun 2019 09:27:08 -0000


Focusing on this part of the review. 

Please see inline. 


> -----Message d'origine-----
> De : tcpm [] De la part de
> Envoyé : jeudi 27 juin 2019 17:58
> À :;
> Cc :
> 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" 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.