jiebi/TextFlow huggingface dataset:
Original text:
may be delivered to the receiving application out of order.  This property is used for protocols that support preservation of data ordering, see prop-ordering, but allow out-of-order delivery for <del> certain messages. </del>  7.4.4.

Reviewer comments:
Just a proposal...
Well, you could do it with streams in SCTP as well so as an example it seems approriate. And good with an example I think.
Yes, we do have actually these kind of examples in many cases in the doc and I just thought when reading one could help here as well.
I don't understand why one would need streams for this in SCTP, but it doesn't matter. As I said I have no strong opinion, I'm fine with adding this example (and I just fixed the nit).
NAME you do not need to, as there are multiple ways to do it in SCTP, but you could.

Revised text:
may be delivered to the receiving application out of order.  This property is used for protocols that support preservation of data ordering, see prop-ordering, but allow out-of-order delivery for  <ins> certain messages, e.g., by multiplexing independent messages onto different streams. </ins> 7.4.4.
Original text:
10.1. <del> The Connection Properties defined as independent of the chosen protocol stack, and available on all Connections are defined in the subsections below. </del>  Note that many Connection Properties have a corresponding Selection <del> Property, which enables applications to express their preference for </del>  protocols providing a supporting transport feature. 10.1.1.

Reviewer comments:
Comma in the first section was wrong but better to rephrase anyway...
nit

Revised text:
10.1.  <ins> Generic Connection Properties are defined independent of the chosen protocol stack and therefore available on all Connections. </ins> Note that many Connection Properties have a corresponding Selection  <ins> Property which enables applications to express their preference for </ins> protocols providing a supporting transport feature. 10.1.1.
Original text:
10.3.  Asynchronous introspection is also possible, via the SoftError Event. This event informs the application about the receipt of an ICMP error message related to the Connection.  This will only happen if the even if the underlying stack supports it, there is no guarantee that a soft error will be signaled. <del> 10.4. </del>  This event notifies the application of excessive retransmissions, based on a configured threshold (see conn-excss-retransmit).  This

Reviewer comments:
Btw. does this cover all events? There is an issue where I also ask if we e.g. need an event that sending failed due to lifetime expiry. is there a way to double-check if we considered all needed events? Should we also mention ConnectionErrors here? Maybe we anyway need to say more about error?
These are not all events (just search for the word "event" in the document), and generally they are not all lumped together - e.g. sending related events such as "Sent" appear in the "Sending Data" section - which, in fact, has its own subsection called "Send Events". So, this would be a subsection just related to connection management... but then, you state: "During the lifetime of a connection there are events that can occur when configured." which gives the (wrong) impression that this would be the list of all events that can happen during a connection's lifetime. So, I wouldn't add this subsection heading and not include that statement. Or maybe add the subsection heading (which is ok but doesn't help much - as you see, there are only very few events in there), but remove that statement.
+1 to calling this "connection lifecycle events" or similar (do we refer to a connection lifecycle?)
Changed the heading and fixed the nit. I'm open to have another sentence there if people have proposals. We could even have no text but we usually say something after each heading.
Given the new heading, I'm fine with the sentence as it is - because the context is clear now, it's no longer misleading (i.e., giving the wrong impression that these would be ALL events).

Revised text:
10.3. <ins> During the lifetime of a connection there are events that can occur when configured. 10.3.1. </ins> Asynchronous introspection is also possible, via the SoftError Event. This event informs the application about the receipt of an ICMP error message related to the Connection.  This will only happen if the even if the underlying stack supports it, there is no guarantee that a soft error will be signaled.  <ins> 10.3.2. </ins> This event notifies the application of excessive retransmissions, based on a configured threshold (see conn-excss-retransmit).  This
Original text:
D.ietf-taps-transport-security. As described above in equivalence, if a Transport Services system <del> races between two different Protocol Stacks, both MUST use the same security protocols and options. </del>  Applications need to ensure that they use security APIs appropriately.  In cases where applications use an interface to Moreover, Transport Services systems MUST NOT automatically fall back from secure protocols to insecure protocols, or to weaker versions of <del> secure protocols.  For example, if an application requests TLS, but the desired version of TLS is not available, its connection will fail.  Applications are thus responsible for implementing security protocol fallback or version fallback by creating multiple Transport Services Connections, if so desired. </del> 

Reviewer comments:
Following , Section 4.2.3 of the Architecture document now says that fallback between different security protocol versions might be allowed. The Security Considerations section was out of sync. This PR fixes that.

Revised text:
D.ietf-taps-transport-security. As described above in equivalence, if a Transport Services system  <ins> races between two different Protocol Stacks, both SHOULD use the same security protocols and options.  However, a Transport Services system MAY race different security protocols, e.g., if the application explicitly specifies that it considers them equivalent. </ins> Applications need to ensure that they use security APIs appropriately.  In cases where applications use an interface to Moreover, Transport Services systems MUST NOT automatically fall back from secure protocols to insecure protocols, or to weaker versions of  <ins> secure protocols.  For example, if an application requests a specific version of TLS, but the desired version of TLS is not available, its connection will fail.  Applications are thus responsible for implementing security protocol fallback or version fallback by creating multiple Transport Services Connections, if so desired. Alternatively, a Transport Services system MAY allow applications to specify that fallback to a specific other version of a protocol is allowed. </ins>
Original text:
model describes how the API model of Transport Services differs from traditional socket-based APIs.  Specifically, it offers asynchronous event-driven interaction, the use of messages for <del> data transfer, and the ability to easily adopt different transport protocols. </del>  design explains the design principles behind the Transport Services API.  These principles are intended to make sure that

Reviewer comments:
Proposed some text for - I think this summarizes the "flexibility" advantage of TAPS that we elaborate on in Section 2.3.
In Section 1.2, Overview, the architecture draft says that TAPS offers "the ability to easily adopt different transport protocols". What does "adopt" mean here? I guess this relates to Section 2.3 (maybe say that explicitly here), but even after reading this Section, I don't quite understand why "adopt". Is the point here that a flexible interface makes it easier to add support for new protocols? Then perhaps we should say this here.
It means that applications don't need to rewrite a ton of code or adopt a new library to access a new transport protocol. In how I read it, "adopt" captures that, but if there's some other text you would like to suggest, that's fine.
For me "adopt" is fine as it should be clear from the rest of the doc. However, if we want to be more clear we could say "make use of different protocols without the need to change the interface" or something...?
Looks good, merged!

Revised text:
model describes how the API model of Transport Services differs from traditional socket-based APIs.  Specifically, it offers asynchronous event-driven interaction, the use of messages for  <ins> data transfer, and the flexibility to use different transport protocols and paths without requiring major changes to the application. </ins> design explains the design principles behind the Transport Services API.  These principles are intended to make sure that
Original text:
is intended for immediate termination of a connection, without cleaning up state.  4.2. This section defines the set of objects used internally to a system transport service across a network, as required by the abstract interface. <del> Connection Group: A set of Connections that share properties and caches.  For multiplexing transport protocols, only Connections within the same Connection Group are allowed to be multiplexed together.  An application can explicitly define Connection Groups to control caching boundaries, as discussed in groups. </del> Path: Represents an available set of properties that a local system can use to communicate with a remote system, such as routes, addresses, and physical and virtual network interfaces.

Reviewer comments:
This is fully editorial: I'm not sure if the term "Connection Group" is introduced in the right section. There might be no perfect fit but maybe section 2.2 is a bit better? Also I note that the terms "Connection Group" and "Path" do not not show up in any of the figures...
Make this a new subsection, i.e. 4.1.7.
Works - Thank you!

Revised text:
is intended for immediate termination of a connection, without cleaning up state. <ins> 4.1.7. A Connection Group is a set of Connections that share properties and caches.  For multiplexing transport protocols, only Connections within the same Connection Group are allowed to be multiplexed together.  An application can explicitly define Connection Groups to control caching boundaries, as discussed in groups. </ins> 4.2. This section defines the set of objects used internally to a system transport service across a network, as required by the abstract interface.  Path: Represents an available set of properties that a local system can use to communicate with a remote system, such as routes, addresses, and physical and virtual network interfaces.
Original text:
5.2.12. <del> local-address-preference </del>  <del> Enumeration Default: For Listeners and Rendezvous Connections: Stable.  For other Connections: Temporary This property specifies whether Listeners and Connections should prefer the use of temporary addresses when possible.  This is generally used to prevent linking connections over time when a stable address is not needed.  Possible values are: </del>  <del> Prefer the use of stable (sometimes called "permanent") local addresses </del>  <del> Prefer the use of temporary (sometimes called "privacy") addresses </del>  5.2.13.

Reviewer comments:
Following the suggestion in , made Local Address Preference a Set(Preference, Enumeration), so an application can now also Require or Prohibit stable addresses. Added a sentence warning that, e.g., preferring stable AND temporary addresses does not make sense - but there are less obvious ways to produce a conflicting set of Selection Properties, too, and we know how to deal with them.
Interim discussion: let's use prohibit/avoid/prefer/require temporary addresses. Default connections to prefer temporary. Default listeners to avoid temporary.
Note that it fails without temporary addresses if you require temporary; which makes IPv4 fail.
Simplified this as discussed in the interim. Please take another look.
Looks good to me – But I am unsure whether we should replace the temporary address with a stable address with Preference. Rational: For IPv6 with outgoing connections, temporary is default anyway, so requiring the special case instead of avoid/prohibit the default looks much more straight forward.
I've read this a few times but I'm still not sure: What alternative solution are you proposing here?
I am proposing to Invert the whole name and meaning of the property – instead of requesting a temporary address, request a stable address.
Thanks for clarifying. I think this Property is straightforward enough as is, no need to invert.
For Local Address Preference we only have the option to prefer stable or temporary. However, I guess we would also need a way to e.g. specify that stable is required, no?
Is this addressed by PR ?
I don't think so.
lgtm

Revised text:
5.2.12.  <ins> use-temporary-local-address </ins>  <ins> Preference </ins>  <ins> Avoid for Listeners and Rendezvous Connections.  Prefer for other Connections. </ins>  <ins> This property allows the application to express a preference for the use of temporary local addresses, sometimes called "privacy" addresses RFC4941.  Temporary addresses are generally used to prevent linking connections over time when a stable address, sometimes called "permanent" address, is not needed.  Note that if an application Requires the use of temporary addresses, the resulting Connection cannot use IPv4, as temporary addresses do not exist in IPv4. </ins> 5.2.13.
Original text:
with RFC2914.  Also note that reliability is usually combined with congestion control in protocol implementations, rendering "reliable but not congestion controlled" a request that is unlikely to succeed. <del> The recommended default is to Require that the Connection is congestion controlled. </del>  5.2.10. specified via Provisioning Domain attributes (see prop-pvd) or another specific property.  5.2.11. pvd specific PvD instances or interface instances, and should be preferred over these options.  5.2.12. local-address-preference

Reviewer comments:
Added defaults for interface and PvD following . Also, I caught one leftover "recommended default".
We require implementations to have default but we don't provide any recommendation for interface and PvD.
For Interface, this would the default be to set "Ignore" on all available interfaces, right? This indicates that the application has no preferences of its own, so the implementation can apply some default system policy. Also, if the application specified some local endpoint, this might constrain the actual interfaces used (related to ). If we try to phrase this as (Preference, Enumeration), it reads a bit weird though: ("Ignore", "Cellular") and ("Ignore", "WiFi"), for example. So perhaps we should just write text saying that the default is to set no application preference.
I think text is fine as well but we need to say something.
Thanks!

Revised text:
with RFC2914.  Also note that reliability is usually combined with congestion control in protocol implementations, rendering "reliable but not congestion controlled" a request that is unlikely to succeed.  <ins> The default is to Require that the Connection is congestion controlled. </ins> 5.2.10. specified via Provisioning Domain attributes (see prop-pvd) or another specific property. <ins> The default is to not set a preference for any interface. </ins> 5.2.11. pvd specific PvD instances or interface instances, and should be preferred over these options. <ins> The default is to not set a preference for any PvD. </ins> 5.2.12. local-address-preference
Original text:
Endpoint.  When receiving Messages, Message Properties can contain information about the received Message, such as metadata generated at the receiver and information signalled by the remote endpoint.  Send: The action to transmit a Message over a Connection to the remote system.  The interface to Send MAY include Message

Reviewer comments:
arch doc sec 4.1.4: "When receiving Messages, Message Properties can contain information about the received Message, such as metadata generated at the receiver and information signalled by the remote endpoint." Maybe provide an example here...?
Suggestion: ECN, which is information given from UDP in the form of such metadata.
QUIC stream identifier example works
Final message is in API, just use that
LGTM modulo one nit - but see if you agree with my suggestion. If you don't, I'm ok with this anyway.

Revised text:
Endpoint.  When receiving Messages, Message Properties can contain information about the received Message, such as metadata generated at the receiver and information signalled by the remote endpoint. <ins> 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. </ins> Send: The action to transmit a Message over a Connection to the remote system.  The interface to Send MAY include Message
Original text:
Properties after Connection establishment take effect on a best- effort basis.  4.1.3. Initiate: The primary action that an application can take to

Reviewer comments:
Addresses
I wondering if we should to talk a bit more about authentication in the the arch doc. The API doc has the concept of security parameters, however there is no discussion about this in the arch document. Also, just double-checking: private keys and certificates/identify can be set as a security parameter of a pre-connection. However, is that really a connection parameter or rather a local endpoint property?
To match the API, add Security Properties to Section 4.1.2.
Try to associate with the endpoint?
Add to figure 4 too
I think?

Revised text:
Properties after Connection establishment take effect on a best- effort basis. <ins> Security Parameters: Security Parameters define an application's requirements for authentication and encryption on a Connection. They are used by Transport Security protocols (such as those described in I-D.ietf-taps-transport-security) to establish secure Connections.  Examples of parameters that can be set include local identities, private keys, supported cryptographic algorithms, and requirements for validating trust of remote identities.  Security Parameters are primarily associated with a Preconnection object, but properties related to identities can be associated directly with Endpoints. </ins> 4.1.3. Initiate: The primary action that an application can take to
Original text:
Abstract <del> The Transport Services architecture I-D.ietf-taps-arch defines a system that allows applications to use transport networking protocols flexibly.  This document serves as a guide to implementation on how to build such a system. </del>  1.

Reviewer comments:
You cannot have references in the abstract. Initially I only wanted to remove that reference but then I also took the opportunity to rewrite the abstract a bit to not only talk about the architecture but an TAPS system and the interface that this guide helps with its implementation.
LGTM (I fixed a tiny nit directly with a commit)Thanks looks good.

Revised text:
Abstract  <ins> The Transport Services (TAPS) system enables applications to use transport protocols flexibly for network communication and defines a protocol-independent TAPS Application Programming Interface (API) that is based on an asynchronous, event-driven interaction pattern. This document serves as a guide to implementation on how to build such a system. </ins> 1.
Original text:
4.1.1. Both Local and Remote Endpoint Candidates must be discovered during <del> connection establishment.  To support ICE, or similar protocols, that involve out-of-band indirect signalling to exchange candidates with the Remote Endpoint, it's important to be able to query the set of candidate Local Endpoints, and give the protocol stack a set of candidate Remote Endpoints, before it attempts to establish connections. </del>  4.1.1.1. If NAT traversal is required, the process of gathering Local Endpoints becomes broadly equivalent to the ICE candidate gathering <del> phase RFC5245.  The endpoint determines its server reflexive Local Endpoints (i.e., the translated address of a local, on the other side of a NAT) and relayed locals (e.g., via a TURN server or other relay), for each interface and network protocol.  These are added to the set of candidate Local Endpoints for this connection. </del>  Gathering Local Endpoints is primarily a local operation, although it might involve exchanges with a STUN server to derive server reflexive locals, or with a TURN server or other relay to derive relayed <del> locals.  It does not involve communication with the Remote Endpoint. </del>  4.1.1.2.

Reviewer comments:
and spell out ICE.
I also updated a later reference and added references for STUN and TURN in this same PR now.

Revised text:
4.1.1. Both Local and Remote Endpoint Candidates must be discovered during  <ins> connection establishment.  To support Interactive Connectivity Establishment (ICE) RFC8445, or similar protocols, that involve out- of-band indirect signalling to exchange candidates with the Remote Endpoint, it's important to be able to query the set of candidate Local Endpoints, and give the protocol stack a set of candidate Remote Endpoints, before it attempts to establish connections. </ins> 4.1.1.1. If NAT traversal is required, the process of gathering Local Endpoints becomes broadly equivalent to the ICE candidate gathering  <ins> phase (see Section 5.1.1. of RFC8445).  The endpoint determines its server reflexive Local Endpoints (i.e., the translated address of a local, on the other side of a NAT, e.g via a STUN sever RFC5389) and relayed locals (e.g., via a TURN server RFC5766 or other relay), for each interface and network protocol.  These are added to the set of candidate Local Endpoints for this connection. </ins> Gathering Local Endpoints is primarily a local operation, although it might involve exchanges with a STUN server to derive server reflexive locals, or with a TURN server or other relay to derive relayed  <ins> locals.  However, it does not involve communication with the Remote Endpoint. </ins> 4.1.1.2.