[Teas] Martin Duke's No Objection on draft-ietf-teas-rfc3272bis-26: (with COMMENT)

[Martin Duke via Datatracker <[e-mail]>]

Martin Duke has entered the following ballot position for
draft-ietf-teas-rfc3272bis-26: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-teas-rfc3272bis/



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

Thanks for this clear and well-written document.

Thanks to Bob Briscoe for an especially thorough TSVART review!

I have a few minor points from the Transport perspective:

(S1.4) Unless this is a well-understood alternate meaning of the term in the TE
community, might I suggest "congestion response" instead of "congestion
control"? It is both more descriptive and does not overload a very important
concept in Layer 4.

(S1.4) "Egress node: The device (router) at with traffic" s/with/which?

(S2.4.1) s/if the router supports ECN/if the router and end host support ECN

The last paragraph of (S5.1.1.4) is a sentence fragment.

(S5.1.3.6) IPPM also designs measurement techniques and protocols to obtain
those metrics. Probably worth mentioning?

(S5.1.3.8) As a transport AD, I had never heard of RFC3124. Perhaps I'm not
working in the right cases, or maybe that's an indication that RFC3124 is no
longer relevant. If the latter, I'd observe that the main lessons of that work
ended up in HTTP/2 and later, directly in the transport in QUIC, in the way
that they consolidate streams under a single connection and congestion control
context.

RFC3124 also references TCP control block interdependence (RFC2140, since
replaced by RFC9040), which IIUC is very much alive. So maybe the right
references for this concept are 9000, 9040, and 9113?

(S7) "Layer 4 multipath transport protocols are designed to move traffic
between domains and to allow control of the selection of the paths."

Pedantically, it only allows control of the source and destination IP
addresses. It cannot force any path through the network.