Draft: draft-ietf-taps-arch

Commentary: This is a set of proposed editorial changes , following a complete pass through the ID . It also offers a one - word fix for Issue This is mainly minor editorial work - except for a proposal to move the definition of " endpoint " upwards , because I found discussion of endpoints in preconception relied upon the endpoint concept . I also think we should have made our meaning of endpoint more explicit , because it is a term that we use a lot . I also suggested we replaced the word " options " within the selection properties para , because a long time ago I think we changed the use of that word in this context to " properties " . 
 OLD : Among the Functional and Optimizing Features , some were common across all or nearly all transport protocols , while others could be seen as features that , if specified , would only be useful with a subset of protocols , but would not harm the functionality of other protocols . Suggest NEW : Some Functional and Optimizing Features are common across all or nearly all transport protocols . Other features might only be useful with a subset of protocols , but would not harm the functionality of other protocols . 
 Re - reading this in context , I proposed a simpler one - word addition as a part of PR . 
 these LGTM
Paragraph (version A):
One of the key insights to come from identifying the minimal set of
features provided by transport protocols I-D.ietf-taps-minset was
that features either require application interaction and guidance
(referred to in that document as Functional or Optimizing Features),
or else can be handled automatically by a system implementing
Transport Services (referred to as Automatable Features).  Among the
Functional and Optimizing Features, some were common across all or
nearly all transport protocols, while others could be seen as
features that, if specified, would only be useful with a subset of
protocols, but would not harm the functionality of other protocols.
For example, some protocols can deliver messages faster for
applications that do not require messages to arrive in the order in
which they were sent.  However, this functionality needs to be
explicitly allowed by the application, since reordering messages
would be undesirable in many cases.
Paragraph (version B):
One of the key insights to come from identifying the minimal set of
features provided by transport protocols I-D.ietf-taps-minset was
that features either require application interaction and guidance
(referred to in that document as Functional or Optimizing Features),
or else can be handled automatically by a system implementing
Transport Services (referred to as Automatable Features).  Among the
identified Functional and Optimizing Features, some were common
across all or nearly all transport protocols, while others could be
seen as features that, if specified, would only be useful with a
subset of protocols, but would not harm the functionality of other
protocols.  For example, some protocols can deliver messages faster
for applications that do not require messages to arrive in the order
in which they were sent.  However, this functionality needs to be
explicitly allowed by the application, since reordering messages
would be undesirable in many cases.
Paragraph (version A):
Allowing applications to interact with messages is backwards-
compatible with existings protocols and APIs, as it does not change
the wire format of any protocol.  Instead, it gives the protocol
stack additional information to allow it to make better use of modern
transport services, while simplifying the application's role in
parsing data.  For protocols which natively use a streaming
abstraction, framers (datatransfer) bridge the gap between the two
abstractions.
Paragraph (version B):
Allowing applications to interact with messages is backwards-
compatible with existing protocols and APIs because it does not
change the wire format of any protocol.  Instead, it gives the
protocol stack additional information to allow it to make better use
of modern transport services, while simplifying the application's
role in parsing data.  For protocols which natively use a streaming
abstraction, framers (datatransfer) bridge the gap between the two
abstractions.
Paragraph (version A):
An application can specify constraints and preferences for the
protocols, features, and network interfaces it will use via
Properties.  A Transport Services API SHOULD offer Properties that
are common to multiple transport protocols, in order to enable the
system to appropriately select between protocols that offer
equivalent features.  Similarly, a Transport Services API SHOULD
offer Properties that are applicable to a variety of network layer
interfaces and paths, in order to permit racing of different network
paths without affecting the applications using the system.  Each
Property is expected to have a default value.
Paragraph (version B):
An application can specify constraints and preferences for the
protocols, features, and network interfaces it will use via
Properties.  A Transport Services API SHOULD offer Properties that
are common to multiple transport protocols, which enables the system
to appropriately select between protocols that offer equivalent
features.  Similarly, a Transport Services API SHOULD offer
Properties that are applicable to a variety of network layer
interfaces and paths, which permits racing of different network paths
without affecting the applications using the system.  Each Property
is expected to have a default value.
Paragraph (version A):
Selection Properties: The Selection Properties consist of the
options that an application can set to influence the selection of
paths between the local and remote systems, to influence the
selection of transport protocols, or to configure the behavior of
generic transport protocol features.  These options can take the
form of requirements, prohibitions, or preferences.  Examples of
options that influence path selection include the interface type
(such as a Wi-Fi connection, or a Cellular LTE connection),
requirements around the largest Message that can be sent, or
preferences for throughput and latency properties.  Examples of
options that influence protocol selection and configuration of
transport protocol features include reliability, multipath
support, and fast open support.
Paragraph (version B):
Selection Properties: The Selection Properties consist of the
properties that an application can set to influence the selection
of paths between the local and remote systems, to influence the
selection of transport protocols, or to configure the behavior of
generic transport protocol features.  These properties can take
the form of requirements, prohibitions, or preferences.  Examples
of properties that influence path selection include the interface
type (such as a Wi-Fi connection, or a Cellular LTE connection),
requirements around the largest Message that can be sent, or
preferences for throughput and latency.  Examples of properties
that influence protocol selection and configuration of transport
protocol features include reliability, multipath support, and fast
open support.
Paragraph (version A):
Connection Properties: The Connection Properties are used to
configure protocol-specific options and control per-connection
behavior of the Transport Services system; for example, a
protocol-specific Connection Property can express that if TCP is
used, the implementation ought to use the User Timeout Option.
Note that the presence of such a property does not require that a
specific protocol will be used.  In general, these properties do
not explicitly determine the selection of paths or protocols, but
can be used in this way by an implementation during connection
establishment.  Connection Properties are specified on a
Preconnection prior to Connection establishment, and can be
modified on the Connection later.  Changes made to Connection
Properties after Connection establishment take effect on a best-
effort basis.
Paragraph (version B):
Connection Properties: The Connection Properties are used to
configure protocol-specific options and control per-connection
behavior of the Transport Services system; for example, a
protocol-specific Connection Property can express that if TCP is
used, the implementation ought to use the User Timeout Option.
Note that the presence of such a property does not require that a
specific protocol will be used.  In general, these properties do
not explicitly determine the selection of paths or protocols, but
can be used by an implementation during connection establishment.
Connection Properties are specified on a Preconnection prior to
Connection establishment, and can be modified on the Connection
later.  Changes made to Connection Properties after Connection
establishment take effect on a best-effort basis.