Draft: draft-ietf-taps-interface

Commentary: I also a link to NEATPy in the overview of implementations , and inserted a missing word in interface ( a missing " without " , must have been a nit ) 
 It might be worth to better align the sections on Message Properties in the API and Implementation draft . Note that e.g. " Final " has more implementation details in the API draft than in the implementation draft .
Paragraph (version A):
This property specifies that a message should be sent and received as
a single packet network-layer fragmentation, if possible.  Attempts
to send a message with this property set with a size greater to the
transport's current estimate of its maximum transmission segment size
will result in a "SendError".  When used with transports supporting
this functionality and running over IP version 4, the Don't Fragment
bit will be set.
Paragraph (version B):
This property specifies that a message should be sent and received as
a single packet without network-layer fragmentation, if possible.
Attempts to send a message with this property set with a size greater
to the transport's current estimate of its maximum transmission
segment size will result in a "SendError".  When used with transports
supporting this functionality and running over IP version 4, the
Don't Fragment bit will be set.
Paragraph (version A):
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 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
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):
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 A):
Corruption Protection Length: when this is set to any value other
than -1, it sets the minimum protection in protocols that allow
limiting the checksum length (e.g.  UDP-Lite).
Paragraph (version A):
Singular Transmission: When set, this property limits the message
size to the Maximum Message Size Before Fragmentation or
Segmentation (see Section 10.1.7 of I-D.ietf-taps-interface).
Messages larger than this size generate an error.  Setting this
avoids transport-layer segmentation or network-layer
fragmentation.  When used with transports running over IP version
4 the Don't Fragment bit will be set to avoid on-path IP
fragmentation (RFC8304).
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.  Also, protocols that do not protect against duplicated
messages, such as UDP, can only be used with Messages that are
Safely Replayable.
Paragraph (version B):
Corruption Protection Length: when this is set to any value other
than "Full Coverage", it sets the minimum protection in protocols
that allow limiting the checksum length (e.g.  UDP-Lite).
Paragraph (version B):
Reliable Data Transfer (Message): When true, the property
specifies that the Message must be reliably transmitted.  When
false, and if unreliable transmission is supported by the
underlying protocol, then the Message should be unreliably
transmitted.  If the underlying protocol does not support
unreliable transmission, the Message should be reliably
transmitted.
Paragraph (version B):
Message Capacity Profile Override: When true, this expresses a
wish to override the Generic Connection Property "Capacity
Profile" for this Message.  Depending on the value, this can, for
example, be implemented by changing the DSCP value of the
associated packet (note that the he guidelines in Section 6 of
RFC7657 apply; e.g., the DSCP value should not be changed for
different packets within a reliable transport protocol session or
DCCP connection).
Paragraph (version B):
No Fragmentation: When set, this property limits the message size
to the Maximum Message Size Before Fragmentation or Segmentation
(see Section 10.1.7 of I-D.ietf-taps-interface).  Messages larger
than this size generate an error.  Setting this avoids transport-
layer segmentation or network-layer fragmentation.  When used with
transports running over IP version 4 the Don't Fragment bit will
be set to avoid on-path IP fragmentation (RFC8304).