Change:
identifying the interfaces between these protocols and both transport protocols and applications.  It examines Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), IETF QUIC, Google <del> QUIC (gQUIC), tcpcrypt, Internet Protocol Security (IPsec), SRTP (with DTLS), WireGuard, CurveCP, and MinimaLT.  For each protocol, this document provides a brief description.  Then, it describes the interfaces between these protocols and transports in transport- interface and the interfaces between these protocols and applications in application-interface. Selected protocols represent a superset of functionality and features a Transport Services system may need to support, both internally and externally (via an API) for applications I-D.ietf-taps-arch. Ubiquitous IETF protocols such as (D)TLS, as well as non-standard protocols such as gQUIC, are both included despite overlapping features.  As such, this survey is not limited to protocols developed within the scope or context of the IETF.  Outside of this candidate set, protocols that do not offer new features are omitted.  For example, newer protocols such as WireGuard make unique design choices that have implications and limitations on application usage.  In contrast, protocols such as ALTS ALTS are omitted since they do not provide interfaces deemed unique. </del> <ins> QUIC (gQUIC), tcpcrypt, Internet Protocol Security (IPsec), Secure Real-time Transport Protocol (SRTP) with DTLS, WireGuard, CurveCP, and MinimaLT.  For each protocol, this document provides a brief description.  Then, it describes the interfaces between these protocols and transports in transport-interface and the interfaces between these protocols and applications in application-interface. A Transport Services system exposes an interface for applications to access various (secure) transport protocol features.  The security protocols included in this survey represent a superset of functionality and features a Transport Services system may need to support, both internally and externally (via an API) for applications I-D.ietf-taps-arch.  Ubiquitous IETF protocols such as (D)TLS, as well as non-standard protocols such as gQUIC, are included despite overlapping features.  As such, this survey is not limited to protocols developed within the scope or context of the IETF.  Outside of this candidate set, protocols that do not offer new features are omitted.  For example, newer protocols such as WireGuard make unique design choices that have implications and limitations on application usage.  In contrast, protocols such as ALTS ALTS are omitted since they do not provide interfaces deemed unique. </ins> Authentication-only protocols such as TCP-AO RFC5925 and IPsec AH RFC4302 are excluded from this survey.  TCP-AO adds authenticity

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?