Change:
This PR mainly changes the beginning of Section 3, Transport Security Protocol Descriptions. It substitutes the sentence on how the document is structured (which I moved to the Introduction) with a brief discussion on the classification we use in Section 3. This includes an explanation of the difference between handshake and record protocols as suggested by Ekr. Furthermore, this PR references DTLS-SRTP, renames "QUIC + TLS" to "IETF QUIC", and mentions that OpenVPN can use TLS as a handshake protocol.
Thank you!

Discussion:
Services and features provided by transport protocols have been cataloged in RFC8095.  This document supplements that work by surveying commonly used and notable network security protocols, and <del> identifying the services and features a Transport Services system (a system that provides a transport API) needs to provide in order to add transport security.  It examines Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), QUIC + TLS, tcpcrypt, Internet Key Exchange with Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard, CurveCP, and MinimalT.  For each protocol, this document provides a brief description, the dependencies it has on the underlying transports, and the interfaces provided to applications. </del> <ins> 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 QUIC (gQUIC), tcpcrypt, Internet Key Exchange with Encapsulating Security Protocol (IKEv2 + ESP), 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. </ins> 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 <del> protocols such as Google QUIC, are both included despite overlapping </del> <ins> protocols such as gQUIC, are both included despite overlapping </ins> 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

This section contains brief descriptions of the various security protocols currently used to protect data being sent over a network. <del> The interfaces between these protocols and transports are described in transport-interface; the interfaces between these protocols and applications are described in application-interface. </del> <ins> These protocols are grouped based on where in the protocol stack they are implemented, which influences which parts of a packet they protect: Generic application payload, application payload for specific application-layer protocols, both application payload and transport headers, or entire IP packets. Note that not all security protocols can be easily categorized, e.g., as some protocols can be used in different ways or in combination with other protocols.  One major reason for this is that channel security protocols often consist of two components: A handshake protocol, which is responsible for negotiating parameters, authenticating the endpoints, and establishing shared keys. A record protocol, which is used to encrypt traffic using keys and parameters provided by the handshake protocol. For some protocols, such as tcpcrypt, these two components are tightly integrated.  In contrast, for IPsec, these components are implemented in separate protocols: AH and ESP are record protocols, which can use keys supplied by the handshake protocol IKEv2, by other handshake protocols, or by manual configuration.  Moreover, some protocols can be used in different ways: While the base TLS protocol as defined in RFC8446 has an integrated handshake and record protocol, TLS or DTLS can also be used to negotiate keys for other protocols, as in DTLS-SRTP, or the handshake protocol can be used with a separate record layer, as in QUIC. </ins> 3.1.

Secure RTP (SRTP) is a profile for RTP that provides confidentiality, message authentication, and replay protection for RTP data packets <del> and RTP control protocol (RTCP) packets RFC3711. </del> <ins> and RTP control protocol (RTCP) packets RFC3711.  SRTP can use different handshake protocols, such as DTLS in DTLS-SRTP RFC5764 or ZRTP RFC6189. </ins> 3.2.2.

alternative to IPsec.  A major goal of this protocol is to provide a VPN that is simple to configure and works over a variety of transports.  OpenVPN encapsulates either IP packets or Ethernet <del> frames within a secure tunnel and can run over UDP or TCP. </del> <ins> frames within a secure tunnel and can run over UDP or TCP.  For key establishment, OpenVPN can use TLS as a handshake protocol or pre- shared keys. </ins> 4.