Draft: draft-ietf-taps-arch

Commentary: Noted two small edits in  's update that I think were incorrect . Properties erroneously removed in " Selection Properties " Connection groups do not only exist at the Sender . 
 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 can not 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 do n'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 do n't entirely agree with this ART - ART comment : I think I might well agree with moving more of the description to this  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  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 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 .
Paragraph (version A):
Selection: The Selection Properties consist of the properties that
an application can set to influence the selection of paths between
the local and remote systems, to influence the selection of
transport protocols, or to configure the behavior of generic
transport protocol features.  These properties can take the form
of requirements, prohibitions, or preferences.  Examples of
properties that influence path selection include the interface
type (such as a Wi-Fi connection, or a Cellular LTE connection),
requirements around the largest Message that can be sent, or
preferences for throughput and latency.  Examples of properties
that influence protocol selection and configuration of transport
protocol features include reliability, multipath support, and fast
open support.
Paragraph (version B):
Selection Properties: The Selection Properties consist of the
properties that an application can set to influence the selection
of paths between the local and remote systems, to influence the
selection of transport protocols, or to configure the behavior of
generic transport protocol features.  These properties can take
the form of requirements, prohibitions, or preferences.  Examples
of properties that influence path selection include the interface
type (such as a Wi-Fi connection, or a Cellular LTE connection),
requirements around the largest Message that can be sent, or
preferences for throughput and latency.  Examples of properties
that influence protocol selection and configuration of transport
protocol features include reliability, multipath support, and fast
open support.
Paragraph (version A):
A Connection Group is a set of Connections at the sender that shares
properties and caches.  For multiplexing transport protocols, only
Connections within the same Connection Group are allowed to be
multiplexed together.
Paragraph (version B):
A Connection Group is a set of Connections that shares properties and
caches.  A Group represents state for managing Connections within a
single application, and does not require end-to-end protocol
signaling.  For multiplexing transport protocols, only Connections
within the same Connection Group are allowed to be multiplexed
together.