Services Provided by IETF Transport Protocols and Congestion Control Mechanisms
draft-ietf-taps-transports-14

In Sec 5, I wondered why only IPv4 was specified for the broadcast?  
"IPv4 broadcast (UDP, UDP-Lite, ICMP)"

Just a few very minor comments:

- 1, 2nd paragraph: Would it make sense to include citations for things like NewReno, TFRC, and LEDBAT?

- 3.5.1, 2nd to last paragraph: Would a citation to WebRTC (perhaps the overview or the transports draft)?

-3.5.2, paragraph starting with "For the following SCTP protocol extensions the BSD Sockets API..."
The paragraph is hard to parse.

Thanks for a useful document. I think this will be quite
informative for many people so please consider my comments
below as just suggestions offered for consideration, and it's
entirely fine if you'd rather not even think about 'em. (I
can well imagine that a document like this could be polished
forever and never finished.)

- abstract: Having finished a first read of this I don't find
the "classifies" and "compares" claims from the abstract to
have really been met.

- end of p11 - seems like a truncated paragraph there or
something.

- 3.5 (and to a lesser extent 3.6): This reads to me as if
the authors regret that the world hasn't adopted the SCTP
(resp. DCCP) as "planned." There's no particular action
following from that, but we might want to consider whether or
not that's the impression we want readers to get. I think it
might be a tiny bit better to do a pass to try make the
language in those bits more neutral.

- 3.7: I agree with Alissa that referring to the TLS1.3 draft
would be good. SSL can also be referred to via RFC6101.  It'd
be a little better to refer to RFC7525 as BCP195 I think.

- 3.7.2: I think it'd be good to consider whether or not this
should describe the so-called 0RTT feature of TLS1.3.  That
is a dangerous implement that could be usefully covered in
this document as informing likely readers of this about how
to properly use (or more importantly, not use) that new
"feature" could be well worth while.

- 3.7.2: The mention of RNGs here is a bit odd. Those aren't
usually an external interface but rather a dependency that
the implementation has on the system/OS.  Similar things
didn't seem to be mentioned in other equivalent sections.
You also don't say that there's no standard API. There was
also a relatively recent paper on how awful TLS cert APIs are
and how those damage security that might be worth a
reference. [1] This section could maybe do with a little more
work. (If you want to, I'm nowhere near trying to insist.)

  [1]
https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html

- 3.9.1: Cookies as "MIME headers"? Huh? Was this text
checked over by some HTTP folks? That sentence makes me think
3.9 might need some more checking.

- 3.10.2: Seems odd to have URLs here for non-maintained
implementations of a rarely used protocol when the same
wasn't provided for very widely used protocols.

- 3.10 and 3.11: It wasn't clear to me why it's useful to
include these.

- 3.12: This seems oddly placed and I'm not clear why it's
worth including ICMP but not DNS or CDNs or load balancing or
issues related to head of line blocking.