Original text:
changes to the application. requirements explains the fundamental requirements for a Transport <del> Services API.  These principles are intended to make sure that </del>  transport protocols can continue to be enhanced and evolve without requiring significant changes by application developers. <del> concepts presents the Transport Services architecture diagram and defines the concepts that are used by both the API I-D.ietf-taps- interface and implementation guidelines I-D.ietf-taps-impl.  The Preconnection allows applications to configure Connection Properties. </del>  concepts also presents how an abstract Connection is used to select a transport protocol instance such as TCP, UDP, or another transport.  The Connection represents an object that can be used <del> to send and receive Messages. </del>  1.3. the implementation below the API. The Transport Services API I-D.ietf-taps-interface defines the <del> interface for an application to create network connections and transfer data.  It combines interfaces for multiple interaction patterns into a unified whole.  By combining name resolution with connection establishment and data transfer in a single API, it allows for more flexible implementations to provide path and transport protocol agility on the application's behalf. </del>  The Transport Services implementation I-D.ietf-taps-impl implements the transport layer protocols and other functions needed to send and 2.2. The Socket API provides a message interface for datagram protocols <del> like UDP, but provide an unstructured stream abstraction for TCP. While TCP does indeed provide the ability to send and receive data as streams, most applications need to interpret structure within these streams.  For example, HTTP/1.1 uses character delimiters to segment messages over a stream RFC7230; TLS record headers carry a version, content type, and length RFC8446; and HTTP/2 uses frames to segment its headers and bodies RFC7540. </del>  The Transport Services API represents data as messages, so that it more closely matches the way applications use the network.  Providing the ability to associate deadlines with messages, for applications that care about timing; <del> the ability to provide control of reliability, choosing which messages to retransmit when there is packet loss, and how best to make use of the data that arrived; the ability to manage dependencies between messages, when a Transport Services implementation could decide to not deliver a message, either following packet loss or because it has missed a deadline.  In particular, this can avoid (re-)sending data that relies on a previous transmission that was never received. </del>  the ability to automatically assign messages and connections to underlying transport connections to utilize multi-streaming and inform how transport protocols use a network path or interface. There are several ways the Transport Services system can offer <del> flexibility to an application: it can provide access to multiple sets of protocols and protocol features; it can use these protocols across </del>  multiple paths that could have different performance and functional characteristics; and it can communicate with different remote systems to optimize performance, robustness to failure, or some other metric. not. A Transport Services system makes decisions that select protocols and <del> interfaces.  In normal use, a Transport Services system SHOULD result in consistent protocol and interface selection decisions for the same network conditions given the same set of Properties.  This is intended to provide predictable outcomes to the application using the API. </del>  4. information about the received Message, such as metadata generated at the receiver and information signalled by the Remote Endpoint. For example, a Message can be marked with a Message Property <del> indicating that it is the final message on a connection if the peer sent a TCP FIN. </del>  Send: The action to transmit a Message over a Connection to the Remote Endpoint.  The interface to Send can accept Message phase (racing). Candidate Protocol Stack: One Protocol Stack that can be used by <del> an application for a connection, of which there can be several. Candidate Protocol Stacks are identified during the gathering phase (gathering) and are started during the racing phase (racing). </del>  System Policy: Represents the input from an operating system or other global preferences that can constrain or influence how an 4.2.2. Connection establishment attempts for a set of candidates may be <del> performed simultaneously, synchronously, serially, or some </del>  combination of all of these.  We refer to this process as racing, borrowing terminology from Happy Eyeballs RFC8305. protocol state, cached path state, and heuristics, may be shared (e.g. across multiple connections in an application).  This provides efficiency and convenience for the application, since the Transport <del> Services implementation can automatically optimize behavior. </del>  There are several reasons, however, that an application might want to explicitly isolate some Connections.  These reasons include:

Reviewer comments:
Thought to address all listed (and related) issues
These are bunched together, and likely could be addressed by one PR: Section 2, right below Figure 2: "The Transport Services API [I-D.ietf-taps-interface] defines the interface for an application to create network connections and transfer data." => Should this be "Connections" instead of "network connections" ? Section 2.1, paragraph 2, last line: "... made explicit in sockets." seems strange. Should this be "in the sockets API." ? Section 2.2 paragraph 1, this sentence: "While TCP does indeed provide the ability to send and receive data as streams, most applications need to interpret structure within these streams." Two issues here. First, I would switch to singular because TCP is not a multi-streaming protocol. I.e., change this to: "While TCP does indeed provide the ability to send and receive data as a stream, most applications need to interpret structure within this stream." Second, is "stream" a known concept? I don't think it's defined in this document, and I'm a little unsure because, even when using singular, someone might read "stream" and think of "one stream out of several, in a multi-streaming protocol". Maybe this is nit-picking, but if you agree, I would prefer to replace "stream" with "data stream", or having a definition of "stream" and capitalizing it (but then the definition would have to appear before the first use of this term...) GF: Data Stream Seems good. Next paragraph: double "provide" in: "Providing a message-based abstraction provides many benefits, such as:" - I suggest to replace the second with "has". In the following item list, I would remove the third item: "the ability to manage dependencies between messages, ..." While it is true that a message-based abstraction enables this, a reader of this document might get the impression that the TAPS system defined in the interface draft offers this specific functionality. It really doesn't, it would still have to be implemented on top of it. For this reason, this item strikes me as a bit misleading, and I think it should be removed. Section 3, paragraph 2: "it can provide access to multiple sets of protocols and protocol features" - remove "sets of", this adds an unnecessary level of indirection here. I guess the transport property profiles in interface, section B.2 would be such sets, but still... Last paragraph before section 3.2: "Applications using a Transport Services system interface are REQUIRED to be robust to the automated selection provided by the system." - why say "system interface" here all of a sudden? This gives an impression as if there were two things: the API, and then perhaps also a separate "system interface". I'd rather replace this with "API". Last paragraph of section 3.4: "In normal use, a Transport Services system SHOULD result in consistent protocol and interface selection decisions for the same network conditions given the same set of Properties." Isn't this too restrictive? It prohibits a Transport Services system from improving. I would change this to: "In normal use, a given version of a Transport Services system SHOULD result in consistent protocol and interface selection decisions for the same network conditions given the same set of Properties." Section 4.1.5: "For example, a Message can be marked with a Message Property indicating that it is the final message on a connection if the peer sent a TCP FIN." I would stop this sentence after "on a connection." - or is it just me misunderstanding something? I thought (and -interface section 9.1.3.5 seems to agree with me) that the idea of "final message for TCP" really is that setting the property means that THIS message that I'm sending gets a FIN flag. Why would a FIN from the peer make me set this property? FWIW I could go on sending more data, and use this property much later? Section 4.1.7, item 1: "end of stream in the ..." - see above for a discussion of the word "stream". Section 4.2, item 5: "One Protocol Stack that can be used by an application for a connection, of which there can be several." => I believe it should be "Connection" here, not "connection". Section 4.2.2, first sentence: "or some combination of all of these" - should this be "or using some combination of all of these" ? This is mentioned in another Issue: Section 1.2, item 4: About the last sentence in item 4, see: URL One other review comment might need discussion prior to resolving... and will be in the next issue

Revised text:
changes to the application. requirements explains the fundamental requirements for a Transport  <ins> Services system.  These principles are intended to make sure that </ins> transport protocols can continue to be enhanced and evolve without requiring significant changes by application developers.  <ins> concepts presents a diagram showing the Transport Services architecture and defines the concepts that are used by both the API I-D.ietf-taps-interface and implementation guidelines I- D.ietf-taps-impl.  The Preconnection allows applications to configure Connection Properties. </ins> concepts also presents how an abstract Connection is used to select a transport protocol instance such as TCP, UDP, or another transport.  The Connection represents an object that can be used  <ins> to send and receive messages. </ins> 1.3. the implementation below the API. The Transport Services API I-D.ietf-taps-interface defines the  <ins> interface for an application to create Connections and transfer data. It combines interfaces for multiple interaction patterns into a unified whole.  By combining name resolution with connection establishment and data transfer in a single API, it allows for more flexible implementations to provide path and transport protocol agility on the application's behalf. </ins> The Transport Services implementation I-D.ietf-taps-impl implements the transport layer protocols and other functions needed to send and 2.2. The Socket API provides a message interface for datagram protocols  <ins> like UDP, but provides an unstructured stream abstraction for TCP. While TCP has the ability to send and receive data as a byte-stream, most applications need to interpret structure within this byte- stream.  For example, HTTP/1.1 uses character delimiters to segment messages over a byte-stream RFC7230; TLS record headers carry a version, content type, and length RFC8446; and HTTP/2 uses frames to segment its headers and bodies RFC7540. </ins> The Transport Services API represents data as messages, so that it more closely matches the way applications use the network.  Providing the ability to associate deadlines with messages, for applications that care about timing;  <ins> the ability control reliability, which messages to retransmit when there is packet loss, and how best to make use of the data that arrived; </ins> the ability to automatically assign messages and connections to underlying transport connections to utilize multi-streaming and inform how transport protocols use a network path or interface. There are several ways the Transport Services system can offer  <ins> flexibility to an application: it can provide access to transport protocols and protocol features; it can use these protocols across </ins> multiple paths that could have different performance and functional characteristics; and it can communicate with different remote systems to optimize performance, robustness to failure, or some other metric. not. A Transport Services system makes decisions that select protocols and  <ins> interfaces.  In normal use, a given version of a Transport Services system SHOULD result in consistent protocol and interface selection decisions for the same network conditions given the same set of Properties.  This is intended to provide predictable outcomes to the application using the API. </ins> 4. information about the received Message, such as metadata generated at the receiver and information signalled by the Remote Endpoint. For example, a Message can be marked with a Message Property  <ins> indicating that it is the final message on a connection. </ins> Send: The action to transmit a Message over a Connection to the Remote Endpoint.  The interface to Send can accept Message phase (racing). Candidate Protocol Stack: One Protocol Stack that can be used by  <ins> an application for a Connection, which there can be several candidates.  Candidate Protocol Stacks are identified during the gathering phase (gathering) and are started during the racing phase (racing). </ins> System Policy: Represents the input from an operating system or other global preferences that can constrain or influence how an 4.2.2. Connection establishment attempts for a set of candidates may be  <ins> performed simultaneously, synchronously, serially, or using some </ins> combination of all of these.  We refer to this process as racing, borrowing terminology from Happy Eyeballs RFC8305. protocol state, cached path state, and heuristics, may be shared (e.g. across multiple connections in an application).  This provides efficiency and convenience for the application, since the Transport  <ins> Services system can automatically optimize behavior. </ins> There are several reasons, however, that an application might want to explicitly isolate some Connections.  These reasons include: