Draft: draft-ietf-taps-impl

Commentary: These are the ones that probably do n't need much discussion . See the email to the list . 
 All changes make sense and are legitimate , I just annotated some findings while reviewing them that could improve consistency and readability .
Paragraph (version A):
Once the Connection is established, Transport Services implementation
maps actions and events to the details of the chosen Protocol Stack.
For example, the same Connection object may ultimately represent a
single transport protocol instance (e.g., a TCP connection, a TLS
session over TCP, a UDP flow with fully-specified Local and Remote
Endpoints, a DTLS session, a SCTP stream, a QUIC stream, or an HTTP/2
stream).  The properties held by a Connection or Listener is
independent of other connections that are not part of the same
Connection Group.
Paragraph (version B):
Once the Connection is established, the Transport Services
implementation maps actions and events to the details of the chosen
Protocol Stack.  For example, the same Connection object may
ultimately represent a single transport protocol instance (e.g., a
TCP connection, a TLS session over TCP, a UDP flow with fully-
specified Local and Remote Endpoints, a DTLS session, a SCTP stream,
a QUIC stream, or an HTTP/2 stream).  The properties held by a
Connection or Listener are independent of other connections that are
not part of the same Connection Group.
Paragraph (version A):
A request by an application for Protocol Properties that cannot be
satisfied by any of the available protocols.  For example, if an
application requires "Configure Reliability per Message", but no
such feature is available in any protocol on the host running the
transport system this should result in an error, e.g., when SCTP
is not supported by the operating system.
Paragraph (version A):
A request by an application for Protocol Properties that are in
conflict with each other, i.e., the required and prohibited
properties cannot be satisfied by the same protocol.  For example,
if an application prohibits "Reliable Data Transfer" but then
requires "Configure Reliability per Message", this mismatch should
result in an error.
Paragraph (version B):
A request by an application for Protocol Properties that cannot be
satisfied by any of the available protocols.  For example, if an
application requires "perMsgReliability", but no such feature is
available in any protocol on the host running the transport system
this should result in an error, e.g., when SCTP is not supported
by the operating system.
Paragraph (version B):
A request by an application for Protocol Properties that are in
conflict with each other, i.e., the required and prohibited
properties cannot be satisfied by the same protocol.  For example,
if an application prohibits "reliability" but then requires
"perMsgReliability", this mismatch should result in an error.
Paragraph (version A):
As a terminological convention, this document structures the
candidates for racing as a tree.  While a tree structure is not the
only way in which racing can be implemented, it does ease the
illustration of how racing works.
Paragraph (version B):
For ease of illustration, this document structures the candidates for
racing as a tree.  This is not meant to restrict implementations from
structuring racing candidates differently.
Paragraph (version A):
"Interface Instance or Type": If the application specifies an
interface type to be preferred or avoided, implementations should
accordingly rank the paths.  If the application specifies an
interface type to be required or prohibited, an implementation is
expeceted to not include the non-conforming paths.
Paragraph (version B):
"Interface Instance or Type": If the application specifies an
interface type to be preferred or avoided, implementations should
accordingly rank the paths.  If the application specifies an
interface type to be required or prohibited, an implementation is
expected to exclude the non-conforming paths.
Paragraph (version A):
The timing algorithms for racing should remain independent across
branches of the tree.  Any timers or racing logic is isolated to a
given parent node, and is not ordered precisely with regards to other
children of other nodes.
Paragraph (version B):
The timing algorithms for racing should remain independent across
branches of the tree.  Any timer or racing logic is isolated to a
given parent node, and is not ordered precisely with regards to other
children of other nodes.
Paragraph (version A):
Connectionless protocols such as UDP and UDP-lite generally do not
provide the same mechanisms that connected protocols do to offer
Connection objects.  Implementations should wait for incoming packets
for connectionless protocols on a listening port and should perform
four-tuple matching of packets to either existing Connection objects
or the creation of new Connection objects.  On platforms with
facilities to create a "virtual connection" for connectionless
protocols implementations should use these mechanisms to minimise the
handling of datagrams intended for already created Connection
objects.
Paragraph (version B):
Connectionless protocols such as UDP and UDP-lite generally do not
provide the same mechanisms that connected protocols do to offer
Connection objects.  Implementations should wait for incoming packets
for connectionless protocols on a listening port and should perform
four-tuple matching of packets to existing Connection objects if
possible.  If a matching Connection object does not exist, an
incoming packet from a connectionless protocol should cause a new
Connection object to be created.
Paragraph (version A):
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):
Ordered: when this is false, this disables the requirement of in-
order-delivery for protocols that support configurable ordering.
When the Protocol Stack does not support configurable ordering,
this property may be ignored.
Paragraph (version A):
Safely Replayable: when this is true, this means that the Message
can be used by a transport mechanism 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 (when used directly,
without a protocol layered atop), can only be used with Messages
that are Safely Replayable.  When a transport system is permitted
to replay messages, replay protection could be provided by the
application.
Paragraph (version B):
"msgPriority": 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 B):
"msgOrdered": when this is false, this disables the requirement of
in-order-delivery for protocols that support configurable
ordering.  When the Protocol Stack does not support configurable
ordering, this property may be ignored.
Paragraph (version B):
"safelyReplayable": when this is true, this means that the Message
can be used by a transport mechanism 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 (when used directly,
without a protocol layered atop), can only be used with Messages
that are Safely Replayable.  When a transport system is permitted
to replay messages, replay protection could be provided by the
application.
Paragraph (version A):
Final: when this is true, this means that the sender will not send
any further messages.  The Connection need not be closed (in case
the Protocol Stack supports half-close operation, like TCP).  Any
messages sent after a Final message will result in a SendError.
Paragraph (version A):
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).  If the
Protocol Stack does not support checksum length limitation, this
property may be ignored.
Paragraph (version A):
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 A):
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 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 A):
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).
Paragraph (version B):
"final": when this is true, this means that the sender will not
send any further messages.  The Connection need not be closed (in
case the Protocol Stack supports half-close operation, like TCP).
Any messages sent after a Final message will result in a
SendError.
Paragraph (version B):
"msgChecksumLen": 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).  If the Protocol
Stack does not support checksum length limitation, this property
may be ignored.
Paragraph (version B):
"msgReliable": 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):
"msgCapacityProfile": 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 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):
"noFragmentation": Setting this avoids network-layer
fragmentation.  Messages exceeding the transport's current
estimate of its maximum packet size (the
singularTransmissionMsgMaxLen Connection Property) can result in
transport segmentation when permitted, or generate an error.  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):
"noSegmentation": When set, this property limits the message size
to the transport's current estimate of its maximum packet size
(the singularTransmissionMsgMaxLen Connection Property).  Messages
larger than this size generate an error.  Setting this avoids
transport-layer segmentation and 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 A):
The amount of data that can be sent as 0-RTT data varies by protocol
and can be queried by the application using the "Maximum Message Size
Concurrent with Connection Establishment" Connection Property.  An
implementation can set this property according to the protocols that
it will race based on the given Selection Properties when the
application requests to establish a connection.
Paragraph (version B):
The amount of data that can be sent as 0-RTT data varies by protocol
and can be queried by the application using the "zeroRttMsgMaxLen"
Connection Property.  An implementation can set this property
according to the protocols that it will race based on the given
Selection Properties when the application requests to establish a
connection.
Paragraph (version A):
Calling "Clone" on a TCP Connection creates a new Connection with
equivalent parameters.  These Connections, and Connections
generated via later calls to "Clone" on an Establied Connection,
form a Connection Group.  To realize entanglement for these
Connections, with the exception of "Connection Priority", changing
a Connection Property on one of them must affect the Connection
Properties of the others too.  No guarantees of honoring the
Connection Property "Connection Priority" are given, and thus it
is safe for an implementation of a transport system to ignore this
property.  When it is reasonable to assume that Connections
traverse the same path (e.g., when they share the same
encapsulation), support for it can also experimentally be
implemented using a congestion control coupling mechanism (see for
example TCP-COUPLING or RFC3124).
Paragraph (version B):
Calling "Clone" on a TCP Connection creates a new Connection with
equivalent parameters.  These Connections, and Connections
generated via later calls to "Clone" on an Establied Connection,
form a Connection Group.  To realize entanglement for these
Connections, with the exception of "connPriority", changing a
Connection Property on one of them must affect the Connection
Properties of the others too.  No guarantees of honoring the
Connection Property "connPriority" are given, and thus it is safe
for an implementation of a transport system to ignore this
property.  When it is reasonable to assume that Connections
traverse the same path (e.g., when they share the same
encapsulation), support for it can also experimentally be
implemented using a congestion control coupling mechanism (see for
example TCP-COUPLING or RFC3124).
Paragraph (version A):
the Transport Services API mappings for MPTCP are identical to TCP.
MPTCP adds support for multipath properties, such as "Multipath
Transport" and "Policy for using Multipath Transports".
Paragraph (version B):
the Transport Services API mappings for MPTCP are identical to TCP.
MPTCP adds support for multipath properties, such as "multipath" and
"multipath-policy".
Paragraph (version A):
The Transport Services API mappings for UDP-Lite are identical to
UDP.  Properties that require checksum coverage are not supported by
UDP-Lite, such as "Corruption Protection Length", "Full Checksum
Coverage on Sending", "Required Minimum Corruption Protection
Coverage for Receiving", and "Full Checksum Coverage on Receiving".
Paragraph (version B):
The Transport Services API mappings for UDP-Lite are identical to
UDP.  Properties that require checksum coverage are not supported by
UDP-Lite, such as "msgChecksumLen", "fullChecksumSend",
"recvChecksumLen", and "fullChecksumRecv".
Paragraph (version A):
Established UDP Multicast Receive connections represent a pair of
specific IP addresses and ports.  The "unidirectional receive"
transport property is required, and the Local Endpoint must be
configured with a group IP address and a port.
Paragraph (version B):
Established UDP Multicast Receive connections represent a pair of
specific IP addresses and ports.  The "direction" Selection
Property must be set to "unidirectional receive", and the Local
Endpoint must be configured with a group IP address and a port.
Paragraph (version A):
When this value is changed, or a Message with Message Property
"Priority" is sent, and there are multiple Connection objects
assigned to the same SCTP association,
CONFIGURE_STREAM_SCHEDULER.SCTP is called to adjust the priorities
of streams in the SCTP association.
Paragraph (version A):
SEND.SCTP.  Message Properties such as "Lifetime" and "Ordered"
map to parameters of this primitive.
Paragraph (version B):
When this value is changed, or a Message with Message Property
"msgPriority" is sent, and there are multiple Connection objects
assigned to the same SCTP association,
CONFIGURE_STREAM_SCHEDULER.SCTP is called to adjust the priorities
of streams in the SCTP association.
Paragraph (version B):
SEND.SCTP.  Message Properties such as "msgLifetime" and
"msgOrdered" map to parameters of this primitive.