Draft: draft-ietf-taps-interface

Commentary: I gave the document a very careful back - to - back read . My take - away was that removing the Message Context Parameters from where they are , and just pointing to a later section , would make for a bad reading experience . Basically , it would feel like an empty shell - at some point , the reader wants to see something tangible , and so , reading all these Message properties where they appear is satisfying , in a way . The document would get quite tough to digest if it would just provide the " framework " for sending , receiving etc . , and we have to wait for the " meat " until the end , where it is then offered in a very organized fashion . Hence , I decided to leave all the message properties described where they are ( as Message Context Parameters ) . That was my approach to de - duplication in this PR . Side comment if someone 's surprised by the removal of A.1.9 " Immediate " : that 's because this is already fully covered by the Transmission Profile in Section 7.3.7 . 
 Fixed - thanks ! 
 Sorry for being late with the review , but I dislike some details of this PR as is only one part of what we agreed on in Montreal an adds inconsistencies : Inconsistencies : The list - style labeling of all properties with their data - type has removed for those properties that have been moved up to section 7.3 and replaced by prose . Missing Steps Those Transport Properties which we decided to call " Connection Properties " have not been renamed . Those Transport Properties which we decided to call " Selection Properties " have not been renamed . Moving the other Transport Properties up After the complete thing , Section 12 should contain the following things : Overview what Properties are and when they can be specified Definition of types List / Table of all properties with references to the earlier chapters where there are defined I will start preparing PRs fixing these … 
 Yes , makes sense to me . Just one more minor thing , the per - Connection Niceness below still says " Applicability : Connection , Message " . Otherwise I think this is good to lgtm
Paragraph (version A):
Niceness is a numeric (non-negative) value that represents an
unbounded hierarchy of priorities of Messages, relative to other
Messages sent over the same Connection and/or Connection Group (see
groups).  A Message with Niceness 0 will yield to a Message with
Niceness 1, which will yield to a Message with Niceness 2, and so on.
Niceness may be used as a sender-side scheduling construct only, or
be used to specify priorities on the wire for Protocol Stacks
supporting prioritization.
Paragraph (version B):
This property is a numeric (non-negative) value that represents an
unbounded hierarchy of priorities.  It can specify the priority of a
Message, relative to other Messages sent over the same Connection.
Paragraph (version A):
Ordered is a boolean property.  If true, this Message should be
delivered after the last Message passed to the same Connection via
the Send Action; if false, this Message may be delivered out of
order.
Paragraph (version A):
Idempotent is a boolean property.  If true, the application-layer
entity in the Message is safe to send to the remote endpoint more
than once for a single Send Action.  It is used to mark data safe for
certain 0-RTT establishment techniques, where retransmission of the
0-RTT data may cause the remote application to receive the Message
multiple times.
Paragraph (version B):
Ordered is a boolean property.  If true, it specifies that a Message
should be delivered to the other side after the previous Message
which was passed to the same Connection via the Send Action.  If
false, the Message may be delivered out of order.  This property is
used for protocols that support preservation of data ordering, see
prop-ordering, but allow out-of-order delivery for certain messages.
Paragraph (version B):
Idempotent is a boolean property.  If true, it specifies that a
Message is safe to send to the remote endpoint more than once for a
single Send Action.  It is used to mark data safe for certain 0-RTT
establishment techniques, where retransmission of the 0-RTT data may
cause the remote application to receive the Message multiple times.
Paragraph (version A):
This numeric property specifies the length of the section of the
Message, starting from byte 0, that the application requires to be
delivered without corruption due to lower layer errors.  It is used
to specify options for simple integrity protection via checksums.  By
default, the entire Message is protected by checksum.  A value of 0
means that no checksum is required, and a special value (e.g. -1) can
be used to indicate the default.  Only full coverage is guaranteed,
any other requests are advisory.
Paragraph (version B):
This numeric property specifies the length of the section of the
Message, starting from byte 0, that the application requires to be
delivered without corruption due to lower layer errors.  It is used
to specify options for simple integrity protection via checksums.  By
default, the entire Message is protected by a checksum.  A value of 0
means that no checksum is required, and a special value (e.g. -1) can
be used to indicate the default.  Only full coverage is guaranteed,
any other requests are advisory.
Paragraph (version A):
Transport Properties allow an application to control and introspect
most aspects of the transport system and transport protocols.
Paragraph (version B):
Having discussed Transport Properties in connection-props and listed
a number of Message Properties ("Ordered", "Idempotent" etc.) in
message-props, we now provide a complete overview of a transport
system's defined Transport Properties.
Paragraph (version A):
Note that it is possible for a set of specified Transport Properties
to be internally inconsistent, or to be inconsistent with the later
use of the API by the application.  Application developers can reduce
inconsistency by only using the most stringent preference levels when
failure to meet the property would break the application's
functionality.  For example, they can set the Selection Property
"Reliable Data Transfer", which is a core assumption of many
application protocols, as Required.  Implementations of this
interface should also raise any detected errors in configuration as
early as possible, to help ensure that inconsistencies are caught
early in the development process.
Paragraph (version B):
Note that it is possible for a set of specified Transport Properties
to be internally inconsistent, or to be inconsistent with the later
use of the API by the application.  Application developers can reduce
inconsistency by only using the most stringent preference levels when
failure to meet the property would break the application's
functionality.  For example, they can set the Selection Property
"Reliable Data Transfer", which is a core assumption of many
application protocols, as Required.  However, since this comes at the
cost of flexibility of the transport system, such strict choices
should be made with care.  Implementations of this interface should
also raise any detected errors in configuration as early as possible,
to help ensure that inconsistencies are caught early in the
development process.
Paragraph (version A):
This section is subject to WG discussion on IETF-102.
Paragraph (version A):
in I-D.ietf-taps-interface-00, we had a classification into
Connection Properties and Message Properties, whereby Connection
Properties where itself were sub-classified in Protocol-Selection,
Path-Selection and Protocol properties.
Paragraph (version A):
The classification in this version of the draft emphasizes the way
the property affects the transport system and protocols.  It
treats the aspect of whether properties are used on a connection,
preconnection or message as an orthogonal dimension of
classification.
Paragraph (version A):
The "Message Properties" from I-D.ietf-taps-interface-00 therefore
have been split into "Protocol Properties" - emphasizing that they
affect the protocol configurations - and "Control Properties" -
emphasizing that they control the local transport system itself.
Paragraph (version A):
This property specifies whether the application wishes to use a
transport protocol that ensures that data is received by the
application on the other end in the same order as it was sent.  The
default is to preserve data ordering.
Paragraph (version B):
This property specifies whether the application wishes to use a
transport protocol that can ensure that data is received by the
application on the other end in the same order as it was sent.  The
default is to preserve data ordering.
Paragraph (version A):
This property specifies that a Message should be delivered to the
other side after the previous Message which was passed to the same
Connection via the Send Action.  It us used for protocols that
support preservation of data ordering, see prop-ordering, but allow
out-of-order delivery for certain messages.
Paragraph (version B):
See msg-ordered.
Paragraph (version A):
This property specifies that a Message is safe to send to the remote
endpoint more than once for a single Send Action.  It is used to mark
data safe for certain 0-RTT establishment techniques, where
retransmission of the 0-RTT data may cause the remote application to
receive the Message multiple times.
Paragraph (version A):
The application can query the maximum size of a message that can be
sent idempotent, see size-idempotent.
Paragraph (version B):
See msg-idempotent.  The application can query the maximum size of a
message that can be sent idempotent, see size-idempotent.
Paragraph (version A):
This numeric property specifies the length of the section of the
Message, starting from byte 0, that the application assumes will be
received without corruption due to lower layer errors.  It is used to
specify options for simple integrity protection via checksums.  By
default, the entire Message is protected by the checksum.  A value of
0 means that no checksum is required, and a special value (e.g. -1)
can be used to indicate the default.  Only full coverage is
guaranteed, any other requests are advisory.
Paragraph (version B):
See msg-checksum.
Paragraph (version A):
This property is a numeric (non-negative) value that represents an
unbounded hierarchy of priorities.  It can specify the priority of a
Message, relative to other Messages sent over the same Connection or
Connection Group (see groups), or the priority of a Connection,
relative to other Connections in the same Connection Group.
Paragraph (version A):
This encoding of the priority has a convenient property that the
priority increases as both Niceness and Lifetime decrease.
Paragraph (version A):
As an exception from the per-Connection behavior described in groups,
even when set on a Connection, this property is not entangled when
Connections are cloned.
Paragraph (version B):
This Property is a non-negative integer representing the relative
inverse priority of this Connection relative to other Connections in
the same Connection Group.  It has no effect on Connections not part
of a Connection Group.  As noted in groups, this property is not
entangled when Connections are cloned.
Paragraph (version B):
See msg-lifetime.