Change:
surfaces between security protocols and transport protocols, and between security protocols and applications. <del> One of the goals of Transport Services is to define a common interface for using transport protocols that allows software using transport protocols to easily adopt new protocols that provide </del> <ins> One of the goals of the Transport Services effort is to define a common interface for using transport protocols that allows software using transport protocols to easily adopt new protocols that provide </ins> similar feature-sets.  The survey of the dependencies security protocols have upon transport protocols can guide implementations in determining which transport protocols are appropriate to be able to use beneath a given security protocol.  For example, a security protocol that expects to run over a reliable stream of bytes, like <del> TLS, restrict the set of transport protocols that can be used to </del> <ins> TLS, restricts the set of transport protocols that can be used to </ins> those that offer a reliable stream of bytes. Defining the common interfaces that security protocols provide to

Discussion:
This PR has fixes for Barry's and Robers's comments, which are all editorial. However, please double-check and state an opinion on the definition of a Transport Services system and on the attempt to provide more context to make the document easier to understand for readers not yet familiar with TAPS.
COMMENT: As incoming AD I found that document really useful and informative - thank you. As a minor nit, I found the English around the usage of the term "Transport Services", that I wasn't familiar with prior to reading this document, slightly tricky to parse in the introduction, particularly because the term isn't defined until the Terminology in section 3. E.g. in the second paragraph it isn't clear to me what a "Transport Services system" real means. Possibly replace "a Transport Services system may need to support" with "a Transport Service may need to support"? Similarly, perhaps change " One of the goals of Transport Services is to define a common interface for using transport protocols" to " One of the goals of Transport Service definitions is to define a common interface for using transport protocols"?
Addressing this issue, I realized that we do not actually define "Transport Services system" anywhere in -arch, or -interface. I usually take it to just be a synonym of "TAPS implementation". Initial proposal for this draft (which I would add to Section 3): "Transport Services system: a software component that exposes an interface to different Transport Services to an application." Do you agree? I'm also going to provide more context in the introduction to make the document easier to understand for people not yet familiar with TAPS.
COMMENT: Thanks for this helpful document. Just some editorial comments beyond what others have mentioned: — Section 1 — It examines Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), IETF QUIC, Google QUIC (gQUIC), tcpcrypt, Internet Key Exchange with Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard, CurveCP, and MinimalT. It’s funny that this carefully expands every abbreviation except “SRTP”. Please do that one too. Ubiquitous IETF protocols such as (D)TLS, as well as non-standard protocols such as gQUIC, are both included The word “both” doesn’t work here.

I think a reasonable fix is just to remove the single word. Maybe a better fix is to slightly reword, as, “Ubiquitous IETF protocols such as (D)TLS are included, and so are non-standard protocols such as gQUIC, despite...” — Section 1.1 — For example, a security protocol that expects to run over a reliable stream of bytes, like TLS, restrict the set of transport protocols that can be used Number agreement: make it “restricts” to match the singular subject “a security protocol”. — Section 2 — Examples include confidentiality, reliable delivery, ordered delivery, message- versus-stream orientation, etc. You don’t need both “examples include” and “etc.”; I suggest eliminating the latter (and sticking in an “and”). — Section 3.1.1 — to marshal (possibly encrypted) data from one peer to the other. Possibly? I understand you’re covering the handshake there as well, but for a summary as (reasonably) brief as this I think it’s misleading to say “possibly”. — Section 3.2.1 — ZRTP [RFC6189] is an alternative key agreement and identity management protocols for SRTP. Number agreement: “protocol” — Section 3.4.3 — For key establishment, OpenVPN can use TLS as a handshake protocol or pre-shared keys. This reads oddly, as though there are two things OpenVPN can use TLS for. I would make it, “URL it can use pre-shared keys.” — Section 5.1 — Extensions (Application-Layer Protocol Negotiation) (EXT): The application enables or configures extensions that are to be negotiated by the security protocol, such as ALPN [RFC7301]. Isn’t the expansion of “ALPN” misplaced here?