Draft: draft-ietf-taps-interface

Commentary: Reconsider words like " atop " and " underneath " when talking about interface boundaries . ( Also , I do n't know what it means to be atop an architecture . ) 
 There are several places where the language in this document , once published as an RFC , will not age well . Search for occurrences of the word " modern " and consider writing less to motivate and more to define . Reconsider the use of terms like " traditional " . 
 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 
 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 . 
 Small fix for  's comment suggested .
Paragraph (version A):
This document describes an abstract application programming
interface, API, to the transport layer that enables the selection of
transport protocols and network paths dynamically at runtime.  This
API enables faster deployment of new protocols and protocol features
without requiring changes to the applications.  The specified API
follows the Transport Services Architecture by providing
asynchronous, atomic transmission of messages.  It is intended to
replace the traditional BSD sockets API as the common interface to
the transport layer, in an environment where endpoints could select
from multiple interfaces and potential transport protocols.
Paragraph (version A):
This document specifies a modern abstract application programming
interface (API) atop the high-level architecture for transport
services defined in I-D.ietf-taps-arch.  The Transport Services
Architecture supports asynchronous, atomic transmission of messages
over transport protocols and network paths dynamically selected at
runtime, in environments where an endpoint selects from multiple
interfaces and potential transport protocols.
Paragraph (version B):
This document describes an abstract application programming
interface, API, to the transport layer that enables the selection of
transport protocols and network paths dynamically at runtime.  This
API enables faster deployment of new protocols and protocol features
without requiring changes to the applications.  The specified API
follows the Transport Services Architecture by providing
asynchronous, atomic transmission of messages.  It is intended to
replace the BSD sockets API as the common interface to the transport
layer, in an environment where endpoints could select from multiple
interfaces and potential transport protocols.
Paragraph (version B):
This document specifies an abstract application programming interface
(API) that specifies the interface component of the high-level
architecture for transport services defined in I-D.ietf-taps-arch.
The Transport Services Architecture supports asynchronous, atomic
transmission of messages over transport protocols and network paths
dynamically selected at runtime, in environments where an endpoint
selects from multiple interfaces and potential transport protocols.
Paragraph (version A):
This API derives specific path and protocol selection properties and
supported transport features from the analysis provided in RFC8095,
RFC8923, and RFC8922.  The design encourages implementations
underneath the interface to dynamically choose a transport protocol
depending on an application's choices rather than statically binding
applications to a protocol at compile time.  Nevertheless, the
Transport Services API also provides applications with a way to
override transport selection and instantiate a specific stack, e.g.,
to support servers wishing to listen to a specific protocol.
However, forcing a specific transport stack choice is discouraged for
general use, because it can reduce portability.
Paragraph (version B):
This API derives specific path and protocol selection properties and
supported transport features from the analysis provided in RFC8095,
RFC8923, and RFC8922.  The design encourages implementations that
provide the interface to dynamically choose a transport protocol
rather than statically binding applications to a protocol at compile
time.  Nevertheless, the Transport Services API also provides
applications with a way to override transport selection and
instantiate a specific stack, e.g., to support servers wishing to
listen to a specific protocol.  However, forcing a specific transport
stack choice is discouraged for general use, because it can reduce
portability.