Re: [tcpm] Éric Vyncke's Discuss on draft-ietf-tcpm-converters-17: (with DISCUSS and COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

Mirja,

Your explanation about my first discuss makes sense. I will downgrade this DISCUSS to a COMMENT (see below) when clearing the 2nd DISCUSS.

The old discuss becomes the following non-blocking COMMENT. Same issue, but, with a text change suggestion:

OLD TEXT
   This document specifies an application proxy, called Transport
   Converter, to assist the deployment of TCP extensions such as
   Multipath TCP.  A Transport Converter may provide conversion service
   for one or more TCP extensions.  The conversion service is provided
   by means of the TCP Convert Protocol (Convert).

NEW TEXT
   This document specifies an application proxy, called Transport
   Converter, to assist the deployment of TCP.
   A Transport Converter may provide conversion service
   for one or more TCP extensions.  The conversion service is provided
   by means of the TCP Convert Protocol (Convert). This document focuses on Multipath TCP as an example of this generic mechanism.


Hope this helps

-éric
-----Original Message-----
From: iesg <[e-mail]> on behalf of Mirja Kuehlewind <[e-mail]>
Date: Monday, 2 March 2020 at 16:19
To: Eric Vyncke <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, The IESG <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-tcpm-converters-17: (with DISCUSS and COMMENT)

    Hi Eric,
    
    Just on your first discuss comment. This document was initial proposed in MPTCP and then moved to tcpm as a generic mechanism. Use of a converter does not make sense for all TCP options but in other cases than MPTCP it is also often quite straight forward. I would prefer to keep it generic in the abstract and especially title because that the intention.
    
    Mirja
    
    
    
    > On 2. Mar 2020, at 15:58, Éric Vyncke via Datatracker <[e-mail]> wrote:
    > 
    > É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 ?
    > 
    > 
    > 
    >