Draft: draft-ietf-taps-arch

Commentary: Closed 
 I just read  and have the following NiTs which I think we should address : /Listeners by default register with multiple paths/ ought this to be : /Listeners , by default , register with multiple paths/ /A Framer is a data translation layer that can be to a Connection to define how application - level Messages are transmitted over a transport protocol . / I think this should be ( because I do n’t think they are protocol specific ) /A Framer is a data translation layer that can be to a Connection to define how application - level Messages are transmitted over the transport service . / /to retransmit in the event of packet loss,/ better to avoid event here :-) /to retransmit when there is packet loss,/ 
 I am just gon na add a few more nits here : The  object in figure 4 is a bit awkward , it appears as if the Listen ( ) call appears out of thin air while per the API it gets called on the preconnection object like Initiate ( ) and  ( ) . In section 4.1.1 , there are 5 references to section 4.1.2 , is it really necessary to have that many ? Point 2 in section 4.2.3 only talks about required transport services , the same should probably be said about prohibited services , i.e. " both protocol stacks MUST NOT offer transport services prohibited by the application " 
 Let me add to this : Section 1 : print send ( ) and recv ( ) in fixed - with font [ HTML / XML issue only ] Section 2 - Figure 1 : socket ( ) [ with the brackets ] looks odd in the figure title 
 I fear framers may be specific to the underlaying protocol , e.g. , for SIP slicing messages out of TCP stream whereby doing nothing for SCTP and UDP 
 In relation to frames I think I only asked to add /service/ instead of protocol ... I do n't understand how  's comment reacts to that 
 I think protocol is correct here and would not change the sentence . 
 OK - so I think you are saying the framer depends only on the specific next protocol , rather than upon the transport service that was offered ? - It is still not clear to me that this is correct . 
 that is a fairly good question … The behaviour of the framer defiantly depends on the transport service provided ( which may be a subset or superset of the transport service requested ) . A framer needs to support all possible outcomes of the transport services requested It may optimize based on the protocols it actually finds , e.g. , turn into a no - op with the transport preserves message boundaries . Whether the next protocol is a sufficient representation of this is unclear to me . Maybe not , if one thinks of supporting arbitrarily large messages and UDP over IPv6 with and without fragmentation … 
 LGTM , thanks !
Paragraph (version A):
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 naming of
objects and functions across these APIs is not consistent, and varies
depending on the protocol being used.  For example, sending and
receiving streams of data is conceptually the same for both an
unencrypted Transmission Control Protocol (TCP) stream and operating
on an encrypted Transport Layer Security (TLS) RFC8446 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 transport protocols varies based on the
context of the protocols themselves: terms such as "flow", "stream",
"message", and "connection" can take on many different meanings.
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 naming of objects
and functions across these APIs is not consistent, and varies
depending on the protocol being used.  For example, sending and
receiving streams of data is conceptually the same for both an
unencrypted Transmission Control Protocol (TCP) stream and operating
on an encrypted Transport Layer Security (TLS) RFC8446 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 transport protocols varies
based on the context of the protocols themselves: terms such as
"flow", "stream", "message", and "connection" can take on many
different meanings.  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):
Both stacks MUST offer the transport services that are required by
the application.  For example, if an application specifies that it
requires reliable transmission of data, then a Protocol Stack
using UDP without any reliability layer on top would not be
allowed to replace a Protocol Stack using TCP.  However, if the
application does not require reliability, then a Protocol Stack
that adds reliability could be regarded as an equivalent Protocol
Stack as long as providing this would not conflict with any other
application-requested properties.
Paragraph (version B):
Both stacks MUST offer the transport services that are requested
by the application.  For example, if an application specifies that
it requires reliable transmission of data, then a Protocol Stack
using UDP without any reliability layer on top would not be
allowed to replace a Protocol Stack using TCP.  However, if the
application does not require reliability, then a Protocol Stack
that adds reliability could be regarded as an equivalent Protocol
Stack as long as providing this would not conflict with any other
application-requested properties.