Change:
3. <del> This section contains brief descriptions of the various security protocols currently used to protect data being sent over a network. 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. </del> <ins> This section contains brief transport and security descriptions of the various security protocols currently used to protect data being sent over a network.  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. </ins> Note that not all security protocols can be easily categorized, e.g., as some protocols can be used in different ways or in combination

Discussion:
Addresses and
== DISCUSS == I question the inclusion of CurveCP in the mix as per URL it does not seem to support IPv6. At the bare minimum, the I-D should mention this restriction in section 3. (and I hope to be corrected about CurveCP IPv6 support). COMMENT: Please respond to the IoT-directorate review by Mohit: URL Please respond to the INT-DIR review by Brian: URL + Gorry Fairhurst's about GRE Generic comment about the intended transport: all protocols analyzed in this document are point to point (no multicast), this should probably be mentioned in the introduction. -- Section 1 -- Is there any reason why the integrity property of IPsec AH is not mentioned ? Same also applies in section 2 when "security protocol" is defined. -- Section 3 -- Use the wording of "record protocol" generically while the term "record protocol" is defined in section 2 as a blocked data transport (like in TLS). Suggest the use of "data transfer protocol" ? An important property of such protocols is to be able to traverse a NAPT box (that I hate)... I suggest to mention whether the analyzed protocols support NAT-traversal in this description section or even in the analysis parts as having a different view (application and network layers seeing possibly different IP addresses so a potential impact on the API).
From Magnus: Eric and I have discussed this and the proposal is a clarifying change to the initial statement in Section 3: OLD: This section contains brief descriptions of the various security protocols currently used to protect data being sent over a network. NEW: This section contains brief transport and security descriptions of the various security protocols currently used to protect data being sent over a network. The purpose of this change to clarify that these descriptions are only concerning relevant aspects of transport and security. Are the WG and authors ok with the above change?
From Gorry: I think GRE (the one I know more) should be mentioned as existing somehow. ... even if the WG doesn't want to add an analysis of GRE! A suggested starting text blob proposal for GRE could be: Generic Routing Encapsulation [RFC2784] specifies a protocol for encapsulation of an arbitrary protocol over another arbitrary network layer protocol. GRE tunnels do not by default provide security features.

[RFC2890] describes enhancements by which two fields, Key and Sequence Number, can be optionally carried in the GRE Header to implement security functions. [RFC8086] specifies a method of encapsulating network protocol packets using GRE in UDP. GRE can be used in combination with IPsec (see RFC2890).
Just a note: We're not addressing his comment on including NAT traversal as a feature, right? I think a good explanation for this is that with TAPS we can do racing, e.g., if a secure transport protocol does not work because of NAT, we might use the same protocol but tunneled over UDP. Thus the problem of NAT traversal can be orthogonal to what we describe in our draft.
Maybe change "of the various" to "of various", since otherwise it can be read as suggesting these are all the security protocols used.
NAME applied your suggested change!
NAME Yes, let's just comment in our email response.
Major issues: The document header says that this document is about interfaces between security protocols and transport services. Yet, later on, I find that the document is also discussing the interfaces between security protocols and applications. Perhaps you could add 'applications' to the title -> 'Interaction Between Applications, Security Protocols, and Transport Services' Editorial issues: Instead of saying 'This protocol obsoletes TCP MD5 "signature" options', can we say 'TCP-AO obsoletes....' to avoid confusion of what is 'this' Please expand 'and IPsec AH [RFC4302]' -> IP Authentication Header Are you talking about cryptographic agility here 'security protocols: confidentiality, privacy protections, and agility.' ? Consider changing 'interface surface exposed '-> interface exposed by'. Otherwise it sounds too similar to attack surface exposed. Expand EAP and reference RFC3748. - Perhaps you could say that Source Address Validation (SAV) to prevent DoS is relevant for protocols that use unreliable transport?
Regarding the title change, I think we can not change this, as "Transport Services" is by definition the interaction between applications and transports; we're adding security to the mix. The first sentence of the abstract already mentions applications.
Should be covered by
Looks good so far, modulo one typo. I was wondering if we want to include "integrity protection" to our definition of Security Protocol, too, as Eric suggested.

But that sentence says "such as", so perhaps it's fine if we don't enumerate all possible features. Also, Eric suggested we change our generic use of the term "record protocol", as our definition in Section 2 clashes with it. Maybe we want to change the definition in Section 2 instead to match our use and remove the "Record" definition? I don't think we actually use "Record" as "Framed protocol messages" in the rest of the document, do we?NAME LGTM with a couple nits! Reviewer: Mohit Sethi Review result: Ready with Nits This document provides a summary of common security protocols. It then discusses the interfaces that exist between applications and security protocols as well as security protocols and transport services. Major issues: The document header says that this document is about interfaces between security protocols and transport services. Yet, later on, I find that the document is also discussing the interfaces between security protocols and applications. Perhaps you could add 'applications' to the title -> 'Interaction Between Applications, Security Protocols, and Transport Services' Editorial issues: Instead of saying 'This protocol obsoletes TCP MD5 "signature" options', can we say 'TCP-AO obsoletes....' to avoid confusion of what is 'this' - Please expand 'and IPsec AH [RFC4302]' -> IP Authentication Header - Are you talking about cryptographic agility here 'security protocols: confidentiality, privacy protections, and agility.' ? - Consider changing 'interface surface exposed '-> interface exposed by'. Otherwise it sounds too similar to attack surface exposed. - Expand EAP and reference RFC3748. - Perhaps you could say that Source Address Validation (SAV) to prevent DoS is relevant for protocols that use unreliable transport?
Reviewer: Brian Haberman Review result: Ready with Issues This document is a survey of network security protocols and their interaction with transport and application protocols. It is clearly written and easy to read. I have a minor comment on the contents of this draft. It is not abundantly clear what the criteria was for selecting the subset of security protocols included in this draft. Some notable omissions include SSH, L2TP, and GRE. These seem like interesting omissions given their popularity in a number of deployment scenarios. Not a showstopper in my opinion, but interesting to note.