Draft: draft-ietf-taps-interface

Commentary: , , , . Partially addresses . A few comments : :  's comment addressed ( " Connection Properties can be set on Preconnections " fixed to " Connection Properties can be set on Preconnections and Connections " ) : I do n't think the sentence explaining what an application could do upon an establisment error is necessary . I removed it , and now the text should be clearer . : All Connection Properties but " Priority ( Connection ) " are entangled . This is now clearly stated , not mentioned as an example . : Great catch . I now replaced this with an example that talks about ordering ( clearly , requiring ordering from UDP will have to fail ) . : Reworded all the bits you point out , hopefully it 's all clearer now . : first , there was a broken sentence , which seemed to miss " will not occur " , so I this . Then , I removed the last sentence which had the contradictory " ConnectionError < can occur after Closed < , ... " statement . 
 contradicts itself in one paragraph : It seems like Closed < can and should be it : the stack should refuse any further interaction with userspace for this connection after that point . 
 says : The transport system ca n't ensure that : it can ensure that either the message is delivered before clean shutdown or the connection will be broken without a clean shutdown . Later , it says : " Deliver " in the context of transports is a term of art that means " the stack handed the data over to the application " . The local endpoint has no way of knowing when or if this has happened : the remote endpoint will happily ACK packets until the rxbuf is full , without delivering a single byte of data to the application . What is the actual condition under which this will fire ? I think this wants to be more general , because this will happen ( e.g. , in TCP ) even if a MITM sends a RST . Maybe just " the connection is otherwise broken " . 
 Why ? Even an unreliable connection can block forever if congestion control is in place . Maybe a better illustration is : what should the TTL on a UDP message be ? Is there a maximum ? If so , how do you know what it is or specify it ? Maybe a better example is warranted here . 
 " Entangled " appears eight times in the doc and its effect is never precisely defined . The doc should specify in an easily - consumable format ( e.g. , a table , but not necessarily a table ) exactly which properties are shared between cloned connections and which are n't . 
 I am having difficult parsing : 
 : " Although Connection Properties ( see Section 7.1 ) can be set during pre - establishment , they may be changed later . " Four sentences later : " Connection Properties can be set on Preconnections " 
 Unrelated , but about the same text : I notice something weird here , regarding compilation . Looking at https://ietf- I see : ... which is broken at the end . However , looking at I see : They are used to inform decisions made during establishment and to fine - tune the established connection . The behavior of the selected protocol stack(s ) when sending Messages is controlled by Message Properties ( see { { message - props } } ) . ... which is much better . Since the last manual commit is 2 days ago , this must be a strange compilation mistake . 
 PR has addressed  's point - so this is now about something else . Please see my comment above . 
 The file is the correct copy . We can close this .
Paragraph (version A):
An implementation of this interface must provide sensible defaults
for Selection Properties.  The recommended default values for each
property below represent a configuration that can be implemented over
TCP.  If these default values are used and TCP is not supported by a
Transport Services implementation, then an application using the
default set of Properties might not succeed in establishing a
connection.  Using the same default values for independent Transport
Services implementations can be beneficial when applications are
ported between different implementations/platforms, even if this
default could lead to a connection failure, as, for example, an
application needs to be explicitly designed to support a
connectionless mode.  In this case, the application can recognize the
failure and explicitly specify a different set of Protocol Selection
Properties that result in a usable protocol.  If default values other
than those recommended below are used, it is recommended to clearly
document any differences.
Paragraph (version B):
An implementation of this interface must provide sensible defaults
for Selection Properties.  The recommended default values for each
property below represent a configuration that can be implemented over
TCP.  If these default values are used and TCP is not supported by a
Transport Services implementation, then an application using the
default set of Properties might not succeed in establishing a
connection.  Using the same default values for independent Transport
Services implementations can be beneficial when applications are
ported between different implementations/platforms, even if this
default could lead to a connection failure when TCP is not available.
If default values other than those recommended below are used, it is
recommended to clearly document any differences.
Paragraph (version A):
Calling Clone on a Connection yields a group of Connections: the
parent Connection on which Clone was called, and a resulting cloned
Connection.  The connections within a group are "entangled" with each
other, and become part of a Connection Group.  Calling Clone on any
of these Connections adds another Connection to the Connection Group,
and so on.  Connections in a Connection Group generally share
Connection Properties.  However, there may be exceptions, such as
"Priority (Connection)", see conn-priority.  Like all other
Properties, Priority is copied to the new Connection when calling
Clone(), but it is not entangled: Changing Priority on one Connection
does not change it on the other Connections in the same Connection
Group.
Paragraph (version B):
Calling Clone on a Connection yields a group of Connections: the
parent Connection on which Clone was called, and a resulting cloned
Connection.  The connections within a group are "entangled" with each
other, and become part of a Connection Group.  Calling Clone on any
of these Connections adds another Connection to the Connection Group,
and so on.  "Entangled" Connections share all Connection Properties
except "Priority (Connection)", see conn-priority.  Like all other
Properties, Priority is copied to the new Connection when calling
Clone(), but it is not entangled: Changing Priority on one Connection
does not change it on the other Connections in the same Connection
Group.
Paragraph (version A):
The Message Properties could be inconsistent with the properties of
the Protocol Stacks underlying the Connection on which a given
Message is sent.  For example, a Connection must provide reliability
to allow setting an infinite value for the lifetime property of a
Message.  Sending a Message with Message Properties inconsistent with
the Selection Properties of the Connection yields an error.
Paragraph (version B):
The Message Properties could be inconsistent with the properties of
the Protocol Stacks underlying the Connection on which a given
Message is sent.  For example, a Protocol Stack must be able to
provide ordering if the msgOrdered property of a Message is enabled.
Sending a Message with Message Properties inconsistent with the
Selection Properties of the Connection yields an error.
Paragraph (version A):
Close terminates a Connection after satisfying all the requirements
that were specified regarding the delivery of Messages that the
application has already given to the transport system.  For example,
if reliable delivery was requested for a Message handed over before
calling Close, the transport system will ensure that this Message is
indeed delivered.  If the Remote Endpoint still has data to send, it
cannot be received after this call.
Paragraph (version B):
Close terminates a Connection after satisfying all the requirements
that were specified regarding the delivery of Messages that the
application has already given to the transport system.  For example,
if reliable delivery was requested for a Message handed over before
calling Close, the Closed Event will signify that this Message has
indeed been delivered.  If the Remote Endpoint still has data to
send, it cannot be received after this call.
Paragraph (version A):
A ConnectionError informs the application that: 1) data could not be
delivered after a timeout, or 2) the other side has aborted the
Connection.  There is no guarantee that an Abort will indeed be
signaled.
Paragraph (version B):
A ConnectionError informs the application that: 1) data could not be
delivered to the peer after a timeout, or 2) the Connection has been
aborted (e.g., because the peer has called Abort).  There is no
guarantee that an Abort will indeed be signaled.
Paragraph (version A):
No events will occur on a Connection after it is Closed; i.e.,
after a Closed<> event, an InitiateError<> or ConnectionError<> on
that connection.  To ensure this ordering, Closed<> will not occur
on a Connection while other events on the Connection are still
locally outstanding (i.e., known to the interface and waiting to
be dealt with by the application).  ConnectionError<> can occur
after Closed<>, but the interface must gracefully handle all cases
where the application ignores these errors.
Paragraph (version B):
No events will occur on a Connection after it is Closed; i.e.,
after a Closed<> event, an InitiateError<> or ConnectionError<>
will not occur on that connection.  To ensure this ordering,
Closed<> will not occur on a Connection while other events on the
Connection are still locally outstanding (i.e., known to the
interface and waiting to be dealt with by the application).