Subject: [tcpm] Éric Vyncke's No Objection on draft-ietf-tcpm-converters-18: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Fri, 06 Mar 2020 06:55:29 -0800

Éric Vyncke has entered the following ballot position for
draft-ietf-tcpm-converters-18: No Objection

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/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Med and other authors,

Thank you for addressing my previous DISCUSS (kept below for archival purpose),
they are now cleared. Most of my COMMENTs were also addressed.

BUT, the new version has a couple of typos in the changed text, e.g., 'relam'
rather than 'realm'. It also uses 'Unassigned' rather than the usual
'Reserved', is there any reason?

Finally, I wonder why the 'magic number' has been introduced and while using
the RFC number if 'fun' the entropy is not that high.

Anyway, the document can be published in my opinion

Thank you for all the work and the fast reaction

-éric

== OLD 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.

== 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 ?

---

From: <[email-masked]>
Date: Fri, 6 Mar 2020 15:05:26 +0000

Hi Eric, 

Thank you. 

We are using 'Unassigned' rather than 'Reserved' because these bits can be assigned. We are following the terminology set in RFC8126:

      Unassigned:  Not currently assigned, and available for assignment
            via documented procedures.  While it's generally clear that
            any values that are not registered are unassigned and
            available for assignment, it is sometimes useful to
            explicitly specify that situation.  Note that this is
            distinctly different from "Reserved".

      Reserved:  Not assigned and not available for assignment.
            Reserved values are held for special uses, such as to extend
            the namespace when it becomes exhausted.  "Reserved" is also
            sometimes used to designate values that had been assigned
            but are no longer in use, keeping them set aside as long as
            other unassigned values are available.  Note that this is
            distinctly different from "Unassigned".

Cheers,
Med

> -----Message d'origine-----
> De : Éric Vyncke via Datatracker [mailto:[email-masked]]
> Envoyé : vendredi 6 mars 2020 15:55
> À : The IESG
> Cc : [email-masked]; [email-masked];
> [email-masked]; Michael Scharf; [email-masked]
> Objet : Éric Vyncke's No Objection on draft-ietf-tcpm-converters-18:
> (with COMMENT)
>