[tcpm] Éric Vyncke's Discuss on draft-ietf-tcpm-converters-17: (with DISCUSS and COMMENT)
Éric Vyncke via Datatracker <noreply@ietf.org> Mon, 02 March 2020 14:58 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: tcpm@ietf.org
Delivered-To: tcpm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B1BD83A0830; Mon, 2 Mar 2020 06:58:47 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Éric Vyncke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-tcpm-converters@ietf.org, tcpm-chairs@ietf.org, tcpm@ietf.org, Michael Scharf <michael.scharf@hs-esslingen.de>, michael.scharf@hs-esslingen.de
X-Test-IDTracker: no
X-IETF-IDTracker: 6.119.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Éric Vyncke <evyncke@cisco.com>
Message-ID: <158316112770.27414.3186724146499309840@ietfa.amsl.com>
Date: Mon, 02 Mar 2020 06:58:47 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/lwZM6psmEdmbCxmXDhdEKjakB8k>
Subject: [tcpm] Éric Vyncke's Discuss on draft-ietf-tcpm-converters-17: (with DISCUSS and COMMENT)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Mar 2020 14:58:48 -0000
Éric Vyncke has entered the following ballot position for draft-ietf-tcpm-converters-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for the work put into this document. It is indeed useful to be able to deploy easily new TCP features. Nevertheless, please find below two DISCUSSes and some non-blocking COMMENTs (and I would appreciate a response from the authors) and NITS. I hope that this helps to improve the document, Regards, -éric == DISCUSS == -- Section 1.2 -- A trivial one: while the title and the abstract of this document appear as quite generic, the document focus is reduced later in section 1.2 to MPTCP: "this document specifies how the Convert Protocol applies for Multipath TCP. It is out of scope of this document to provide a comprehensive list of all potential conversion services. " While I do not mind having a focus on MPTCP only, I would strongly suggest to reflect this focus in the title and in the abstract (the current filename is correct). -- Section 6.2.8 -- I appreciate that this is an experimental document, but, having only 2 occurrences of ICMP in the whole document and no real "how to process" TLV "Destination Unreachable"... and the payload of this TLV having only the code without the offending packet will probably make Path MTU discovery (and other mechanisms) impossible. While I am not a transport expert, I believe that this aspect needs to be described in this document. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Here are some COMMENTs -- Section 1.2 -- Is the benefit of a transport proxy only for the clients as written in the 1st paragraph? It was probably the case for the original MPTCP proxy but what about other TCP extensions? -- Section 4.1 -- While the difference "(Internet-facing interface, customer-facing interface)" will probably represent the vast majority of use cases, I wonder whether there will always be a single Internet-facing ? Could probably be 0 or 2 in some use cases... Suggest to remove this part of the text. -- Section 6.1 -- Please state the usual wording about "unassigned" field: it must be ignored by the receiver. Adding some explanations on why version 0 is reserved but cannot be used would be welcome. -- Section 6.2.5 -- Can the "remote peer IP address" be a link-local address ? == NITS == -- Section 1.1 (and possibly others) -- Please use a consistent means of introducing acronyms, cfr URLLC and ATSSS ;-) -- Section 4.2 --- The use of "regular TCP packets" makes me wonder whether the authors think that MPTCP uses "irregular TCP packets"... The use of 'regular' seems a little weird here but I am not a native English speaker. -- Section 4.3 -- The caption below figure 7 ends with "(TCP)" that is not the acronym of "Transport Session Entry". Is it expected ?
- [tcpm] Éric Vyncke's Discuss on draft-ietf-tcpm-c… Éric Vyncke via Datatracker
- Re: [tcpm] Éric Vyncke's Discuss on draft-ietf-tc… Mirja Kuehlewind
- Re: [tcpm] Éric Vyncke's Discuss on draft-ietf-tc… Eric Vyncke (evyncke)
- Re: [tcpm] Éric Vyncke's Discuss on draft-ietf-tc… mohamed.boucadair
- Re: [tcpm] Éric Vyncke's Discuss on draft-ietf-tc… Eric Vyncke (evyncke)
- Re: [tcpm] Éric Vyncke's Discuss on draft-ietf-tc… mohamed.boucadair
- Re: [tcpm] Éric Vyncke's Discuss on draft-ietf-tc… Eric Vyncke (evyncke)