Draft: draft-ietf-taps-impl

Commentary: Changes to address Issue 
 Properties This is n’t really about /removing/ we need to express this differently , not sure what you wish to say : For example , TCP can not remove bytes from its send buffer , while in case of SCTP , such control over the SCTP send buffer can be exercised using the partial reliability extension [ RFC8303 ] . and : /Final : when this is true , it means that a transport connection can be closed immediately after its transmission./ I think this is : /Final : when this is true , it means that a transport connection can be closed immediately after transmission of the message./ 
 See PR Update draft - ietf - taps- 
 Looks good , just some more nits on top
Paragraph (version A):
Lifetime: this should be implemented by removing the Message from
its queue of pending Messages after the Lifetime has expired.  A
queue of pending Messages within the transport system
implementation that have yet to be handed to the Protocol Stack
can always support this property, but once a Message has been sent
into the send buffer of a protocol, only certain protocols may
support de-queueing a message.  For example, TCP cannot remove
bytes from its send buffer, while in case of SCTP, such control
over the SCTP send buffer can be exercised using the partial
reliability extension RFC8303.  When there is no standing queue of
Messages within the system, and the Protocol Stack does not
support removing a Message from its buffer, this property may be
ignored.
Paragraph (version B):
Lifetime: this should be implemented by removing the Message from
the queue of pending Messages after the Lifetime has expired.  A
queue of pending Messages within the transport system
implementation that have yet to be handed to the Protocol Stack
can always support this property, but once a Message has been sent
into the send buffer of a protocol, only certain protocols may
support removing a message.  For example, an implementation cannot
cannot remove bytes from a TCP send buffer, while it can remove
data from a SCTP send buffer using the partial reliability
extension RFC8303.  When there is no standing queue of Messages
within the system, and the Protocol Stack does not support the
removal of a Message from the stack's send buffer, this property
may be ignored.
Paragraph (version A):
Ordered: when this is false, it disables the requirement of in-
order-delivery for protocols that support configurable ordering.
Paragraph (version A):
Safely Replayable: when this is true, it means that the Message
can be used by mechanisms that might transfer it multiple times -
e.g., as a result of racing multiple transports or as part of TCP
Fast Open.
Paragraph (version A):
Final: when this is true, it means that a transport connection can
be closed immediately after its transmission.
Paragraph (version B):
Ordered: when this is false, this disables the requirement of in-
order-delivery for protocols that support configurable ordering.
Paragraph (version B):
Safely Replayable: when this is true, this means that the Message
can be used by mechanisms that might transfer it multiple times -
e.g., as a result of racing multiple transports or as part of TCP
Fast Open.
Paragraph (version B):
Final: when this is true, this means that a transport connection
can be closed immediately after transmission of the message.