Draft: draft-ietf-taps-interface

Commentary: Make items in list consistent style . This has many suggested edits , sorry ; - (
Paragraph (version A):
A Transport Services system can offer a variety of transport
protocols, independent of the Protocol Stacks that will be used at
runtime.  All common features of these protocol stacks are made
available to the application in a transport-independent way to the
degree possible.  This enables applications written to a single
API to make use of transport protocols in terms of the features
they provide.
Paragraph (version B):
A Transport Services system that can offer a variety of transport
protocols, independent of the Protocol Stacks that will be used at
runtime.  To the degree possible, all common features of these
protocol stacks are made available to the application in a
transport-independent way.  This enables applications written to a
single API to make use of transport protocols in terms of the
features they provide.
Paragraph (version B):
Asynchronous Connection establishment, transmission, and
reception.  This allows concurrent operations during establishment
and event-driven application interactions with the transport
layer.
Paragraph (version A):
Each Transport Property has a one of the basic types described in
notation.
Paragraph (version B):
Each Transport Property has one of the basic types described in
notation.
Paragraph (version A):
When additional information (such as Provisioning Domain (PvD)
information RFC7556) is available about the networks over which an
endpoint can operate, this can inform the selection between alternate
network paths.  Path information can include network segment PMTU,
set of supported DSCPs, expected usage, cost, etc.  The usage of this
information by the Transport Services System is generally independent
of the specific mechanism/protocol used to receive the information
(e.g. zero-conf, DHCP, or IPv6 RA).
Paragraph (version B):
When additional information (such as Provisioning Domain (PvD)
information RFC7556) is available about the networks over which an
endpoint can operate, this can inform the selection between alternate
network paths.  Path information can include PMTU, set of supported
DSCPs, expected usage, cost, etc.  The usage of this information by
the Transport Services System is generally independent of the
specific mechanism/protocol used to receive the information (e.g.
zero-conf, DHCP, or IPv6 RA).
Paragraph (version A):
The implementation MUST ensure an outcome that is consistent with all
application requirements expressed using Require and Prohibit.  While
preferences expressed using Prefer and Avoid influence protocol and
path selection as well, outcomes can vary given the same Selection
Properties, because the available protocols and paths can differ
across systems and contexts.  However, implementations are
RECOMMENDED to seek to provide a consistent outcome to an
application, given the same set of Selection Properties.
Paragraph (version B):
The implementation MUST ensure an outcome that is consistent with all
application requirements expressed using Require and Prohibit.  While
preferences expressed using Prefer and Avoid influence protocol and
path selection as well, outcomes can vary given the same Selection
Properties, because the available protocols and paths can differ
across systems and contexts.  However, implementations are
RECOMMENDED to seek to provide a consistent outcome to an
application, when provided with the same set of Selection Properties.
Paragraph (version A):
An implementation of the Transport Services API must provide sensible
defaults for Selection Properties.  The default values for each
property below represent a configuration that can be implemented over
TCP.  If these default values are used and TCP is not supported by a
Transport Services system, then an application using the default set
of Properties might not succeed in establishing a connection.  Using
the same default values for independent Transport Services
implementations can be beneficial when applications are ported
between different implementations/platforms, even if this default
could lead to a connection failure when TCP is not available.  If
default values other than those suggested below are used, it is
RECOMMENDED to clearly document any differences.
Paragraph (version B):
An implementation of the Transport Services API needs to provide
sensible defaults for Selection Properties.  The default values for
each property below represent a configuration that can be implemented
over TCP.  If these default values are used and TCP is not supported
by a Transport Services system, then an application using the default
set of Properties might not succeed in establishing a connection.
Using the same default values for independent Transport Services
implementations can be beneficial when applications are ported
between different implementations/platforms, even if this default
could lead to a connection failure when TCP is not available.  If
default values other than those suggested below are used, it is
RECOMMENDED to clearly document any differences.
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.
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 at the Remote Endpoint in the same order as it was sent.
Paragraph (version A):
The set of valid interface types is implementation- and system-
specific.  For example, on a mobile device, there may be "Wi-Fi" and
"Cellular" interface types available; whereas on a desktop computer,
"Wi-Fi" and "Wired Ethernet" interface types might be available.  An
implementation should provide all types that are supported on the
local system, to allow applications to be written generically.  For
example, if a single implementation is used on both mobile devices
and desktop devices, it should define the "Cellular" interface type
for both systems, since an application might wish to always prohibit
cellular.
Paragraph (version B):
The set of valid interface types is implementation- and system-
specific.  For example, on a mobile device, there may be "Wi-Fi" and
"Cellular" interface types available; whereas on a desktop computer,
"Wi-Fi" and "Wired Ethernet" interface types might be available.  An
implementation should provide all types that are supported on the
local system, to allow applications to be written generically.  For
example, if a single implementation is used on both mobile devices
and desktop devices, it ought to define the "Cellular" interface type
for both systems, since an application might wish to always prohibit
cellular.
Paragraph (version A):
Note that the set of LocalEndpoints returned by Resolve() might or
might not contain information about all possible local interfaces; it
is valid only for a Rendezvous happening at the same time as the
resolution.  Care should be taken in using these values in any other
context.
Paragraph (version B):
Note that the set of Local Endpoints returned by Resolve() might or
might not contain information about all possible local interfaces; it
is valid only for a Rendezvous happening at the same time as the
resolution.  Care should be taken in using these values in any other
context.
Paragraph (version A):
For Connections that are Established: information concerning the
path(s) used by the Protocol Stack.  This can be derived from
local PVD information, measurements by the Protocol Stack, or
other sources.  For example, a TAPS system that is configured to
receive and process PVD information RFC7556 could also provide
network configuration information for the chosen path(s).
Paragraph (version B):
For Connections that are Established: information concerning the
path(s) used by the Protocol Stack.  This can be derived from
local PVD information, measurements by the Protocol Stack, or
other sources.  For example, a Transport System that is configured
to receive and process PVD information RFC7556 could also provide
network configuration information for the chosen path(s).