[tcpm] Benjamin Kaduk's No Objection on draft-ietf-tcpm-2140bis-10: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-tcpm-2140bis-10: 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-2140bis/



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

Thanks to the shepherd for the very helpful writeup!

Section 3

   +RTTVAR - variance of round-trip times of a TCP packet exchange
   [RFC6298]

nit: in RFC 6298 this is "round-trip time variation", which to me is a more
useful description, since it is not a standard statistical averaged
squared deviation.

Section 6.2

A forward reference to where the "merge()" operation is discussed would
be helpful.

   During the connection, the associated TCB can be updated based on
   particular events, as shown below:

nit(?): should we s/associated TCB/assoicated TCB cache/?  (Likewise for
§6.2.)

Section 9

   confirmation, etc.) [RFC3124]. By dealing exclusively with
   transients, TCB interdependence is more likely to exhibit the same
   behavior as unmodified, independent TCP connections.

Is this the "same behavior" in the steady-state?  There seem to be
obvious (intentional) differences in behavior at startup.

Section 10

   The observation that some TCB state is host-pair specific rather
   than application-pair dependent is not new and is a common
   engineering decision in layered protocol implementations. Although
   now deprecated, T/TCP [RFC1644] was the first to propose using
   caches in order to maintain TCB states (see 0).

"see 0" feels like a broken automation for referencing Appendix A.
(Also occurs in Section 11 for the same T/TCP topic.)

Section 11

(nit) this feels more like a "changes from RFC 2140" section than an
"updates to RFC 2140" section, to me.

Appendix B

A reference to the IANA registry might help the reader make sense of
some of these option names.

Appendix C

   Temporal sharing, as described earlier in this document, builds on
   the assumption that multiple consecutive connections between the
   same host pair are somewhat likely to be exposed to similar
   environment characteristics. The stored information can therefore
   become invalid over time, and suitable precautions should be taken

nit: I don't think the preceding sentence justifies the use of
"therefore" here.

Appendix C.2

   environment, can always use a different value. In specific,
   information from previous connections, or sets of connections with a
   similar path, can already be used as context for such decisions (as
   noted in the core of this document).

nit: it feels like there might be a missing word here, perhaps
"situations" after "specific"?  Or perhaps just s/specific/particular/?

Appendix C.3

   1. On boot:

      IW = MaxIW; # assume this is in bytes, and an even number of MSS

nit: is "even number" intended to mean "integral multiple"?

   A number of additional constraints need to be imposed if this
   mechanism is implemented to ensure that it defaults values that

nit: singular/plural mismatch (maybe "it defaults to values"?)

Appendix C.4

   reasons (e.g., the ISN is used in TCP-AO [RFC5925]). The mechanism
   also benefits from persistent state kept across reboots, as would be
   other state sharing mechanisms (e.g., TCP Control Block Sharing
   [RFC2140]). The mechanism is inspired by RFC 2140's use of
   information across connections.

It feels strange for some reason to reference RFC 2140 here when this
document obsoletes RFC 2140.