Draft: draft-ietf-taps-interface

Commentary: Not many text fixes needed - quite a bit of text reflected the old choice of Priority anyway and was n't correctly updated for Niceness :-) 
 At 8.1.2 you say lower values have higher priorities for connPrio . But later , at msgPrio , higher values have higher priority , and in the examples where you speak of the interaction of connPrio and msgPrio , you imply that higher means higher for both properties . Please check for consistency and clarify . 
 Lower values having higher priorities for connPrio is a remnant that we must have missed when we flipped this , e.g. PR which I do n't know ... too many iterations have mangled the text . 
 Aha , now I see what happened : following some more PRs , also , in PR , re - introduced some text saying that sends on Connections with lower - priority values will be prioritized over sends on Connections with a higher - priority value . This reverses the logic for some part of the text - I suspect that ( very understandably ! ) forgot what happened and this created this mix . We have been editing these documents for way too long ! 
 Fine with me . The max_prio problem can be addressed separately .
Paragraph (version A):
The Protocol Property "Niceness" operates on entangled Connections as
in msg-niceness: when allocating available network capacity among
Connections in a Connection Group, sends on Connections with higher
Niceness values will be prioritized over sends on Connections with
lower Niceness values.  An ideal transport system implementation
would assign each Connection the capacity share (M-N) x C / M, where
N is the Connection's Niceness value, M is the maximum Niceness value
used by all Connections in the group and C is the total available
capacity.  However, the Niceness setting is purely advisory, and no
guarantees are given about the way capacity is shared.  Each
implementation is free to implement a way to share capacity that it
sees fit.
Paragraph (version B):
The Protocol Property "Priority" operates on entangled Connections as
in msg-priority: when allocating available network capacity among
Connections in a Connection Group, sends on Connections with higher
Priority values will be prioritized over sends on Connections with
lower Priority values.  An ideal transport system implementation
would assign each Connection the capacity share (M-N) x C / M, where
N is the Connection's Priority value, M is the maximum Priority value
used by all Connections in the group and C is the total available
capacity.  However, the Priority setting is purely advisory, and no
guarantees are given about the way capacity is shared.  Each
implementation is free to implement a way to share capacity that it
sees fit.
Paragraph (version A):
This property 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):
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 A):
Note that this property is not a per-message override of the
connection Niceness - see conn-niceness.  Both Niceness properties
may interact, but can be used independently and be realized by
different mechanisms.
Paragraph (version B):
This property represents a hierarchy of priorities.  It can specify
the priority of a Message, relative to other Messages sent over the
same Connection.
Paragraph (version B):
A Message with Priority 0 will yield to a Message with Priority 1,
which will yield to a Message with Priority 2, and so on.  Priorities
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):
Note that this property is not a per-message override of the
connection Priority - see conn-priority.  Both Priority properties
may interact, but can be used independently and be realized by
different mechanisms.
Paragraph (version A):
Note that a Final Message must always be sorted to the end of a list
of Messages.  The Final property overrides Niceness and any other
property that would re-order Messages.  If another Message is sent
after a Message marked as Final has already been sent on a
Connection, the Send Action for the new Message will cause a
SendError Event.
Paragraph (version B):
Note that a Final Message must always be sorted to the end of a list
of Messages.  The Final property overrides Priority and any other
property that would re-order Messages.  If another Message is sent
after a Message marked as Final has already been sent on a
Connection, the Send Action for the new Message will cause a
SendError Event.
Paragraph (version A):
Niceness: this represents the ability to de-prioritize a Message
in favor of other Messages.  This can be implemented by the system
re-ordering Messages that have yet to be handed to the Protocol
Stack, or by giving relative priority hints to protocols that
support priorities per Message.  For example, an implementation of
HTTP/2 could choose to send Messages of different niceness on
streams of different priority.
Paragraph (version B):
Priority: this represents the ability to prioritize a Message over
other Messages.  This can be implemented by the system re-ordering
Messages that have yet to be handed to the Protocol Stack, or by
giving relative priority hints to protocols that support
priorities per Message.  For example, an implementation of HTTP/2
could choose to send Messages of different Priority on streams of
different priority.
Paragraph (version A):
Relative niceness: for SCTP, this can be done using the primitive
CONFIGURE_STREAM_SCHEDULER.SCTP described in section 4 of RFC8303.
Paragraph (version B):
Priority (Connection): for SCTP, this can be done using the
primitive CONFIGURE_STREAM_SCHEDULER.SCTP described in section 4
of RFC8303.