Original text:
protocol features to applications for network communication, the Transport Services architecture.  The Transport Services Application Programming Interface (API) is based on an asynchronous, event-driven <del> interaction pattern.  This uses messages for representing data </del>  transfer to applications, and describes how implementations can use multiple IP addresses, multiple protocols, and multiple paths, and provide multiple application streams.  This document further defines how applications can use them effectively. The goal of the Transport Services architecture is to provide a <del> flexible, and reusable architecture that provides a common interface </del>  for transport protocols.  As applications adopt this interface, they will benefit from a wide set of transport features that can evolve over time, and ensure that the system providing the interface can failure, or some other metric.  Beyond these, if the API for the system remains the same over time, new protocols and features can be added to the system's implementation without requiring changes in <del> applications for adoption.  Similarly this can provide a common basis for utilising information about a a network path or interface, </del>  enabling evolution below the transport layer. The normative requirements described in this section allow Transport An application can specify constraints and preferences for the protocols, features, and network interfaces it will use via <del> Properties.  Properties are used by an applicatioon to declares its </del>  preferences for how the transport service should operate at each <del> stage of the lifetime of a connection.  Transport Properties are </del>  subdivided into Selection Properties, which specify which paths and protocol stacks can be used and are preferred by the application; Connection Properties, which inform decisions made during connection <del> establishment and to fine-tune the established connection and Message Properties, set on indvidual Messages. </del>  It is RECOMMENDED that the Transport Services API offers properties that are common to multiple transport protocols.  This enables the A Transport Services implementation can select Protocol Stacks based on the Selection and Connection Properties communicated by the <del> application and any security parameters.  If two different Protocol Stacks can be safely swapped, or raced in parallel (see racing), then they are considered to be "equivalent".  Equivalent Protocol Stacks are defined as stacks that can provide the same Transport Properties and interface expectations as requested by the application. </del>  The following two examples show non-equivalent Protocol Stacks: 4. <del> This Section and the remainder of this document describe the </del>  architecture non-normatively.  The concepts defined in this document are intended primarily for use in the documents and specifications that describe the Transport Services architecture and API.  While the

Reviewer comments:
Nicer text throughout to introduce key things consistently; firm-up architecture v interface; introduce properties; resolve some NiTs.
Accepted adjustments from Tommy and merged.
I'll have to read the document yet another time, perhaps, but after the few times I went through it for this review, I'm still not clear on how/whether connections are grouped because of actions from the remote end(s). If so, how does the user learn about the grouping? Does it have to poll Connection.GroupedConnections() every time its told of a new Connection?
I think the answer is that an application may be unaware whether incoming Connections are grouped or not. To get the information, polling Connection.GroupedConnections() every time a new Connection arrives sounds just about right. But grouping can take various forms... the most common that I think is on everyone's mind is multi-streaming, where the arrival of a new stream is clear to the underlying stack. In this case, even when a stream is exposed as a Connection, the application can learn that it's really grouped together with others by polling as you say. Another alternative for grouping is to couple the congestion control of connections ([RFC 8699], or see [1] for how it can be done with TCP) - e.g., when they traverse the same tunnel, or when statistics give us a hint that there is a common bottleneck on the path [RFC 8382], [2]. In this case, the grouping is done one-sided. It's also possible that calling clone() really has no effect in the stack, because neither a multi-streaming capable transport nor such coupling mechanisms are available; the Connections are then still "grouped" in that changing a property of one is expected to affect all the others, but this is irrelevant to the peer when the Connections really are, e.g., separate TCP connections. All in all, I don't think a text change is needed. [1] Safiqul Islam, Michael Welzl, Kristian Hiorth, David Hayes, Grenville Armitage, Stein Gjessing: "ctrlTCP: Reducing Latency through Coupled, Heterogeneous Multi-Flow TCP Congestion Control", IEEE INFOCOM Global Internet Symposium (GI) workshop (GI 2018), Honolulu, HI, April 2018. [2] David Hayes, Michael Welzl, Simone Ferlin, David Ros, Safiqul Islam: "Online Identification of Groups of Flows Sharing a Network Bottleneck", IEEE/ACM Transactions on Networking 28(5), pp. 2229-2242, Print ISSN: 1063-6692, Online ISSN: 1558-2566 October 2020. DOI 10.1109/TNET.2020.3007346.
A Connection Group is only a set of Connections that share properties and caches at the sender. I don't think text is needed.
Where does the document state that a connection group is a concept only known to the sender?
Aha! I think that text may be needed. Thanks!
Yes and "aha" - I am happy to add that a connection group is a concept at the sender to arch, I add in a pending PR to address "cloning". I suggest MW does this for interface.
In 3.1 consider "It is important for applications using a Transport Services system to be robust to the" instead of using REQUIRED. At 3.2, if this were a requirements document for the Transport Services system, the SHOULD in the first paragraph might make sense. But if its an architecture document, or better, an overview and introduction. It would be better to simply say "is" rather than SHOULD. (And in a requirements document, I would argue that this SHOULD should be a MUST).
I think 3.1 probably needs a little more unpacking, this is a little abstarct in what is needed to say required: "Applications using a Transport Services system interface are REQUIRED to be robust to the automated selection provided by the system, where the automated selection is constrained by the requirements and preferences expressed by the application." We could therefore loose the /REQUIRED/. I'll suggest this as a starting point for 3.1 - the topic here is not an interoperability requirement of the protocol on the wire, it is about whether the method needs to have the feature to satisfy the design goals: "It is therefore is RECOMMENDED that a Transport Services system permits more specialized protocol features to be used."
this will be fixed with any reasonable fix to
Make it clearer in 3.1 that you are introducing a concept named Properties. A sentence that starts "Properties are" would really help.
Expected fixed in linked PR
The (arch) document currently says (just before section 3.1) "The rest of this document describes the architecture non-normatively", but then goes on to use a bunch of 2119/8174 language (much of which really shouldn't be - please try eliminating all of them).
this will be fixed with any reasonable fix to
See lined PR first, before discussing please.
Early art-art review of draft-ietf-taps-architecture My first observation and request is that the group rethink the separation of the architecture and interface documents. It is a warning-sign that the interface document is a normative reference for the architecture document. As the documents are currently constructed, a new reader cannot grasp the architecture without inferring some of it through reading the interface. Consider reformulating the architecture document as an overview - introduce principles, concepts, and terminology, but don't attempt to be normative. (There are signs that this may already be, or have been, a path the document was being pushed towards). If nothing else, rename it, and acknowledge that the actual architecture is specified using the interface definition. Note that the first sentence of the Overview in the interface document also highlights the current structural problem.
I don't entirely agree with this ART-ART comment: I think I might well agree with moving more of the description to this Arch document, but as discussed before, I also think it useful here to set the actual requirements for the architecture, and to define the architecture. It may need to be much clearer that this architecture consists of more the API.
For completeness, this is the first statement of the interface document review: This document reads fairly well. I have some structural concerns (see the early review of the architecture document). In particular I think this document contains the actual definition of the architecture and some of that is inferential.
Discussion at September 2021 interim: pass through this document with a view toward making it a high level introduction, not an architecture definition: "An Introduction to the Transport Services Architecture". remove normative language from this document (moving it to API, where necessary). move details not useful in a high level intro to API.
I disagree with this conclusion at first pass—we did a specific analysis and pass on this over a year ago, with PR . The normative language and the standards-track aspect was very intentional and something the WG had consensus on. The point is that the API is a specific incarnation of the TAPS architecture, but there are overarching architectural properties that go beyond a specific abstract API.
I completely agree with Tommy here, and recommend we fix this in . We should also of course check for any stray text or missing concepts. I think it would also be useful to somehow better explain that in figure 3 the API function is ONE part of the system.
See linked PR first please to see if this resolves this?
A PR was merged that addressed important text issues with separation of requirements and overview, and should more clearly set out that the requirements are for the system. The question of whether the overall TAPS systems requirements belong in this ID; the API; or a separate RFC needs some discussion based on the review, before this can be closed.
Many good text improvements in the PR NAME but I noticed two smaller updates in the PR that I think were incorrect. Fixed in
The review comment showed were many places where the wording of architecture can be improved. There are some high level principles that I think should remain in the architecture document. The decision in today's interim is to review the architecture to get this more into a shape that is valuable as a reference, and then check the updated draft.
I now suggest the issues are addressed and we close this issue without moving text between documents
I agree with that; closing.

Revised text:
protocol features to applications for network communication, the Transport Services architecture.  The Transport Services Application Programming Interface (API) is based on an asynchronous, event-driven  <ins> interaction pattern.  This API uses messages for representing data </ins> transfer to applications, and describes how implementations can use multiple IP addresses, multiple protocols, and multiple paths, and provide multiple application streams.  This document further defines how applications can use them effectively. The goal of the Transport Services architecture is to provide a  <ins> flexible and reusable architecture that provides a common interface </ins> for transport protocols.  As applications adopt this interface, they will benefit from a wide set of transport features that can evolve over time, and ensure that the system providing the interface can failure, or some other metric.  Beyond these, if the API for the system remains the same over time, new protocols and features can be added to the system's implementation without requiring changes in  <ins> applications for adoption.  Similarly, this can provide a common basis for utilizing information about a network path or interface, </ins> enabling evolution below the transport layer. The normative requirements described in this section allow Transport An application can specify constraints and preferences for the protocols, features, and network interfaces it will use via  <ins> Properties.  Properties are used by an application to declare its </ins> preferences for how the transport service should operate at each  <ins> stage in the lifetime of a connection.  Transport Properties are </ins> subdivided into Selection Properties, which specify which paths and protocol stacks can be used and are preferred by the application; Connection Properties, which inform decisions made during connection  <ins> establishment and fine-tune the established connection; and Message Properties, set on individual Messages. </ins> It is RECOMMENDED that the Transport Services API offers properties that are common to multiple transport protocols.  This enables the A Transport Services implementation can select Protocol Stacks based on the Selection and Connection Properties communicated by the  <ins> application, along with any security parameters.  If two different Protocol Stacks can be safely swapped, or raced in parallel (see racing), then they are considered to be "equivalent".  Equivalent Protocol Stacks are defined as stacks that can provide the same Transport Properties and interface expectations as requested by the application. </ins> The following two examples show non-equivalent Protocol Stacks: 4.  <ins> This section and the remainder of this document describe the </ins> architecture non-normatively.  The concepts defined in this document are intended primarily for use in the documents and specifications that describe the Transport Services architecture and API.  While the