Draft: draft-ietf-taps-arch

Commentary: From /Introudction/ Please define / API/ in /Many APIs to perform/. First Para mentions TCP , but not UDP - some people could draw conclusions ( very silly perhaps ) that this is about TCP . It would be super nice to include an e.g. with Datagrams mentioning QUIC and UDP . ... From /Design principles/ Curent text : /and it can communicate with different Remote Endpoints to optimize performance./ My new proposed text : /and it can communicate with different   to optimize performance , robustness to failure , or some other metric/. From /Access to Specialized Features/ This says : /Since applications will often need to control fine - grained details of transport protocols to optimize their behavior and ensure compatibility with remote peers , a Transport Services system also needs to allow more specialized protocol features to be used./ I quibble . I do n’t believe this is /often/ , and anyway I do not think this is the most prevalent case , just and important usage , so I would suggest we write something : /There are applications that will need to control fine - grained details of transport protocols to optimize their behavior and ensure compatibility with remote peers , . A Transport Services system will therefore also needsto allow more specialized protocol features to be used./ From /Access to Specialized Features/ This says : /A specialized feature may be required by an application only when using a specific protocol , / I suggest : /A specialized feature could be required by an application only when it uses a specific transport protocol , / and change : /For example , if an application is using UDP , it may require/ to : /For example , if an application is using UDP , it could require/ Please remove /In order to preserve flexibility and compatibility ... / Suggest : /To preserve flexibility and compatibility ... / Please change : /Mappings of these API features in the Implementation document , on the other hand , must explain the ramifications of each feature on existing protocols . It is expected that the Implementation document will be updated and supplemented as new protocols and protocol features are developed./ to this : /The mappings of these API features is explained in the TAPS Implementation [ REF ] , which also explain the implications of the feature provided by existing protocols . It is expected that this documentation will be updated and supplemented as new protocols and protocol features are developed./ Please change : /require any changes on remote hosts./ suggest : /require any changes to a remote host./ Please change : /Transport protocols such as SCTP provide/ add commas : /Transport protocols , such as SCTP , provide/ 
 lgtm with one nit
Paragraph (version A):
Many APIs to perform transport networking have been deployed, perhaps
the most widely known and imitated being the BSD socket() POSIX
interface.  The names and functions between these APIs are not
consistent, and vary depending on the protocol being used.  For
example, sending and receiving on a stream of data is conceptually
the same between operating on an unencrypted Transmission Control
Protocol (TCP) stream and operating on an encrypted Transport Layer
Security (TLS) I-D.ietf-tls-tls13 stream over TCP, but applications
cannot use the same socket send() and recv() calls on top of both
kinds of connections.  Similarly, terminology for the implementation
of protocols offering transport services vary based on the context of
the protocols themselves.  This variety can lead to confusion when
trying to understand the similarities and differences between
protocols, and how applications can use them effectively.
Paragraph (version B):
Many application programming interfaces (APIs) to perform transport
networking have been deployed, perhaps the most widely known and
imitated being the BSD socket() POSIX interface.  The names and
functions between these APIs are not consistent, and vary depending
on the protocol being used.  For example, sending and receiving on a
stream of data is conceptually the same between operating on an
unencrypted Transmission Control Protocol (TCP) stream and operating
on an encrypted Transport Layer Security (TLS) I-D.ietf-tls-tls13
stream over TCP, but applications cannot use the same socket send()
and recv() calls on top of both kinds of connections.  Similarly,
terminology for the implementation of protocols offering transport
services vary based on the context of the protocols themselves.  This
variety can lead to confusion when trying to understand the
similarities and differences between protocols, and how applications
can use them effectively.
Paragraph (version A):
There are several degrees in which a Transport Services system can
offer flexibility to an application: it can provide access to
multiple sets of protocols and protocol features, it can use these
protocols across multiple paths that may have different performance
and functional characteristics, and it can communicate with different
Remote Endpoints to optimize performance.  Beyond these, if the API
for the system remains the same over time, new protocols and features
may be added to the system's implementation without requiring changes
in applications for adoption.
Paragraph (version B):
There are several degrees in which a Transport Services system can
offer flexibility to an application: it can provide access to
multiple sets of protocols and protocol features, it can use these
protocols across multiple paths that may have different performance
and functional characteristics, and it can communicate with different
Remote Endpoints to optimize performance, robustness to failure, or
some other metric.  Beyond these, if the API for the system remains
the same over time, new protocols and features may be added to the
system's implementation without requiring changes in applications for
adoption.
Paragraph (version A):
Since applications will often need to control fine-grained details of
transport protocols to optimize their behavior and ensure
compatibility with remote peers, a Transport Services system also
needs to allow more specialized protocol features to be used.  The
interface for these specialized options should be exposed differently
from the common options to ensure flexibility.
Paragraph (version A):
A specialized feature may be required by an application only when
using a specific protocol, and not when using others.  For example,
if an application is using UDP, it may require control over the
checksum or fragmentation behavior for UDP; if it used a protocol to
frame its data over a byte stream like TCP, it would not need these
options.  In such cases, the API should expose the features in such a
way that they take effect when a particular protocol is selected, but
do not imply that only that protocol may be used if there are
equivalent options.
Paragraph (version B):
There are applications that will need to control fine-grained details
of transport protocols to optimize their behavior and ensure
compatibility with remote peers,. A Transport Services system will
therefore also needs to allow more specialized protocol features to
be used.  The interface for these specialized options should be
exposed differently from the common options to ensure flexibility.
Paragraph (version B):
A specialized feature could be required by an application only when
using a specific protocol, and not when using others.  For example,
if an application is using UDP, it could require control over the
checksum or fragmentation behavior for UDP; if it used a protocol to
frame its data over a byte stream like TCP, it would not need these
options.  In such cases, the API should expose the features in such a
way that they take effect when a particular protocol is selected, but
do not imply that only that protocol could be used if there are
equivalent options.
Paragraph (version A):
In order to preserve flexibility and compatibility with future
protocols, top-level features in the Transport Services API should
avoid referencing particular transport protocols.  Mappings of these
API features in the Implementation document, on the other hand, must
explain the ramifications of each feature on existing protocols.  It
is expected that the Implementation document will be updated and
supplemented as new protocols and protocol features are developed.
Paragraph (version A):
It is important to note that neither the Transport Services API nor
the Implementation document defines new protocols that require any
changes on remote hosts.  The Transport Services system must be
deployable on one side only, as a way to allow an application to make
better use of available capabilities on a system and protocol
features that may be supported by peers across the network.
Paragraph (version B):
To preserve flexibility and compatibility with future protocols, top-
level features in the Transport Services API should avoid referencing
particular transport protocols.  The mappings of these API features
to specific implementations of each feature is explained in the TAPS-
IMPL, which also explain the implications of the feature provided by
existing protocols.  It is expected that this document will be
updated and supplemented as new protocols and protocol features are
developed.
Paragraph (version B):
It is important to note that neither the Transport Services API nor
the Implementation document defines new protocols that require any
changes to a remote host.  The Transport Services system must be
deployable on one side only, as a way to allow an application to make
better use of available capabilities on a system and protocol
features that may be supported by peers across the network.