Draft: draft-ietf-taps-interface

Commentary: … establishment timeout into a parameter of init calls ( it stood out strangely in the list of selection properties because it really is n't one ) ; updated defaults for selection properties . 
 Looks good to me now . Fixed the merge conflict with . 
 With the updated definitions I think the defaults for " Notification of excessive retransmissions " and " Notification of ICMP soft error message arrival " should probably be  ? If you are not interested in these properties they should not affect the selection . 
 I completely agree ; done . thanks a lot for fixing the conflict ! I was worried about this :) Now waiting for an ok from and before this lands . 
 Just realized that during  's Presentation 
 not clear this is necessary for the Bangkok rev , unless someone has cycles to send a PR , so dropping milestone . 
 Agree with changing the definition of Ignore , but keeping the name "  " . Then , all preference levels are verbs , that makes sense . :) Well done . I 'd like to have a preference " Default " that restores the System default and another round of going through properties and discuss whether we need to fix the default at all or make it implementation specific , but that is a separate PR
Paragraph (version B):
An Action takes a set of Parameters; an Event contains a set of
Parameters.  Action parameters whose names are suffixed with a
question mark are optional.
Paragraph (version A):
This property specifies whether the application needs to use a
transport protocol that ensures that all data is received on the
other side without corruption.  This also entails being notified when
a Connection is closed or aborted.  The recommended default is to
enable Reliable Data Transfer.
Paragraph (version A):
This property specifies whether an application considers it useful to
indicate its reliability requirements on a per-Message basis.  This
property applies to Connections and Connection Groups.  The
recommended default is to not have this option.
Paragraph (version A):
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
recommended default is to preserve data ordering.
Paragraph (version A):
This property specifies whether an application would like to supply a
Message to the transport protocol before Connection establishment,
which will then be reliably transferred to the other side before or
during Connection establishment, potentially multiple times.  See
also msg-idempotent.  The recommended default is to not have this
option.
Paragraph (version A):
This property specifies that the application would prefer multiple
Connections within a Connection Group to be provided by streams of a
single underlying transport connection where possible.  The
recommended default is to not have this option.
Paragraph (version A):
This property specifies whether the application considers it useful
to enable, disable, or configure a checksum when sending a Message,
or configure whether to require a checksum or not when receiving.
The recommended default is full checksum coverage without the option
to configure it, and requiring a checksum when receiving.
Paragraph (version B):
This property specifies whether the application needs to use a
transport protocol that ensures that all data is received on the
other side without corruption.  This also entails being notified when
a Connection is closed or aborted.  The recommended default is to
Require Reliable Data Transfer.
Paragraph (version B):
This property specifies whether the application needs or prefers to
use a transport protocol that preserves message boundaries.  The
recommended default is to Prefer Preservation of Message Boundaries.
Paragraph (version B):
This property specifies whether an application considers it useful to
indicate its reliability requirements on a per-Message basis.  This
property applies to Connections and Connection Groups.  The
recommended default is to Ignore this option.
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
recommended default is to Require Preservation of data ordering.
Paragraph (version A):
This property specifies whether the application would like the
Connection to be congestion controlled or not.  Note that if a
Connection is not congestion controlled, an application using such a
Connection should itself perform congestion control in accordance
with RFC2914.  Also note that reliability is usually combined with
congestion control in protocol implementations, rendering "reliable
but not congestion controlled" a request that is unlikely to succeed.
The recommended default is that the Connection is congestion
controlled.
Paragraph (version A):
In contrast to other Selection Properties, this property is tuple of
an (Enumerated) interface identifier and a preference, and can either
be implemented directly as such, or for making one preference
available for each interface and interface type available on the
system.
Paragraph (version B):
In contrast to other Selection Properties, this property is a tuple
of an (Enumerated) interface identifier and a preference, and can
either be implemented directly as such, or for making one preference
available for each interface and interface type available on the
system.
Paragraph (version A):
As with interface instances and types, this property is tuple of an
(Enumerated) PvD identifier and a preference, and can either be
implemented directly as such, or for making one preference available
for each interface and interface type available on the system.
Paragraph (version B):
As with interface instances and types, this property is a tuple of an
(Enumerated) PvD identifier and a preference, and can either be
implemented directly as such, or for making one preference available
for each interface and interface type available on the system.
Paragraph (version A):
This property specifies whether an application considers it useful to
transfer data across multiple paths between the same end hosts.
Generally, in most cases, this will improve performance (e.g.,
achieve greater throughput).  One possible side-effect is increased
jitter, which may be problematic for delay-sensitive applications.
Paragraph (version B):
This property specifies whether an application considers it useful to
transfer data across multiple paths between the same end hosts.
Generally, in most cases, this will improve performance (e.g.,
achieve greater throughput).  One possible side-effect is increased
jitter, which may be problematic for delay-sensitive applications.
The recommended default is to Prefer this option.
Paragraph (version A):
This property specifies whether an application considers it useful to
be informed in case sent data was retransmitted more often than a
certain threshold.  The recommended default is to have this option.
Paragraph (version B):
This property specifies whether an application considers it useful to
be informed in case sent data was retransmitted more often than a
certain threshold.  The recommended default is to Ignore this option.
Paragraph (version A):
This property specifies whether an application considers it useful to
be informed when an ICMP error message arrives that does not force
termination of a connection.  When set to true, received ICMP errors
will be available as SoftErrors.  Note that even if a protocol
supporting this property is selected, not all ICMP errors will
necessarily be delivered, so applications cannot rely on receiving
them.  The recommended default is not to have this option.
Paragraph (version A):
This property specifies how long to wait before aborting a Connection
during establishment.
Paragraph (version B):
This property specifies whether an application considers it useful to
be informed when an ICMP error message arrives that does not force
termination of a connection.  When set to true, received ICMP errors
will be available as SoftErrors.  Note that even if a protocol
supporting this property is selected, not all ICMP errors will
necessarily be delivered, so applications cannot rely on receiving
them.  The recommended default is to Ignore this option.
Paragraph (version A):
Before calling Initiate, the caller must have populated a
Preconnection Object with a Remote Endpoint specifier, optionally a
Local Endpoint specifier (if not specified, the system will attempt
to determine a suitable Local Endpoint), as well as all properties
necessary for candidate selection.
Paragraph (version B):
The timeout parameter specifies how long to wait before aborting
Active open.  Before calling Initiate, the caller must have populated
a Preconnection Object with a Remote Endpoint specifier, optionally a
Local Endpoint specifier (if not specified, the system will attempt
to determine a suitable Local Endpoint), as well as all properties
necessary for candidate selection.
Paragraph (version A):
An InitiateError occurs either when the set of transport properties
and security parameters cannot be fulfilled on a Connection for
initiation (e.g. the set of available Paths and/or Protocol Stacks
meeting the constraints is empty) or reconciled with the local and/or
remote endpoints; when the remote specifier cannot be resolved; or
when no transport-layer connection can be established to the remote
endpoint (e.g. because the remote endpoint is not accepting
connections, or the application is prohibited from opening a
Connection by the operating system).
Paragraph (version B):
An InitiateError occurs either when the set of transport properties
and security parameters cannot be fulfilled on a Connection for
initiation (e.g. the set of available Paths and/or Protocol Stacks
meeting the constraints is empty) or reconciled with the local and/or
remote endpoints; when the remote specifier cannot be resolved; or
when no transport-layer connection can be established to the remote
endpoint (e.g. because the remote endpoint is not accepting
connections, the application is prohibited from opening a Connection
by the operating system, or the establishment attempt has timed out
for any other reason).
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 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 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 A):
This property specifies how long to wait before deciding that a
Connection has failed after establishment.