Draft: draft-ietf-taps-arch

Commentary: This PR contains the architecture revisions  and I went through at IETF 103 . The main change is adding official 2119 language and cleaning up all other uses of should / may / must . This does not contain the necessary rework of the framing section , which will come in a future PR . 
 Looks good to me .
Paragraph (version A):
Originally, sockets presented a blocking interface for establishing
connections and transferring data.  However, most modern applications
interact with the network asynchronously.  When sockets are presented
as an asynchronous interface, they generally use a try-and-fail
model.  If the application wants to read, but data has not yet been
received from the peer, the call to read will fail.  The application
then waits for a notification that it should try again.
Paragraph (version B):
Originally, sockets presented a blocking interface for establishing
connections and transferring data.  However, most modern applications
interact with the network asynchronously.  When sockets are presented
as an asynchronous interface, they generally use a try-and-fail
model.  If the application wants to read, but data has not yet been
received from the peer, the call to read will fail.  The application
then waits for a notification to indicate when it can try again.
Paragraph (version A):
In order to more closely match the way applications use the network,
the Transport Services API respresents data as messages.  Messages
seamlessly work with transport protocols that support datagrams or
records, but can also be used over a stream by defining the
application-layer framing being used framing.
Paragraph (version B):
The Transport Services API respresents data as messages, so that it
more closely matches the way applications use the network.  Messages
seamlessly work with transport protocols that support datagrams or
records, but can also be used over a stream by defining the
application-layer framing being used framing.
Paragraph (version A):
they were sent.  However, this functionality must be explicitly
allowed by the application, since reordering messages would be
undesirable in many cases.
Paragraph (version B):
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):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC2119 RFC8174 when, and only when, they appear in all capitals,
as shown here.
Paragraph (version A):
There are several degrees in which a Transport Services system can
offer flexibility to an application: it can provide access to
multiple sets of protocols and protocol features, it can use these
protocols across multiple paths that may have different performance
and functional characteristics, and it can communicate with different
Remote Endpoints to optimize performance, robustness to failure, or
some other metric.  Beyond these, if the API for the system remains
the same over time, new protocols and features may be added to the
system's implementation without requiring changes in applications for
adoption.
Paragraph (version B):
There are several degrees in which a Transport Services system can
offer flexibility to an application: it can provide access to
multiple sets of protocols and protocol features, it can use these
protocols across multiple paths that could have different performance
and functional characteristics, and it can communicate with different
remote systems to optimize performance, robustness to failure, or
some other metric.  Beyond these, if the API for the system remains
the same over time, new protocols and features could be added to the
system's implementation without requiring changes in applications for
adoption.
Paragraph (version A):
Functionality that is common across multiple transport protocols
should be accessible through a unified set of API calls.  An
application should be able to implement logic for its basic use of
transport networking (establishing the transport, and sending and
receiving data) once, and expect that implementation to continue to
function as the transports change.
Paragraph (version A):
Any Transport Services API must allow access to the distilled minimal
set of features offered by transport protocols I-D.ietf-taps-minset.
Paragraph (version A):
There are applications that will need to control fine-grained details
of transport protocols to optimize their behavior and ensure
compatibility with remote peers.  A Transport Services system will
therefore also needs to allow more specialized protocol features to
be used.  The interface for these specialized options should be
exposed differently from the common options to ensure flexibility.
Paragraph (version A):
A specialized feature could be required by an application only when
using a specific protocol, and not when using others.  For example,
if an application is using UDP, it could require control over the
checksum or fragmentation behavior for UDP; if it used a protocol to
frame its data over a byte stream like TCP, it would not need these
options.  In such cases, the API should expose the features in such a
way that they take effect when a particular protocol is selected, but
do not imply that only that protocol could be used if there are
equivalent options.
Paragraph (version A):
Other specialized features, however, may be strictly required by an
application and thus constrain the set of protocols that can be used.
For example, if an application requires encryption of its transport
data, only protocol stacks that include some transport security
protocol are eligible to be used.  A Transport Services API must
allow applications to define such requirements and constrain the
system's options.  Since such options are not part of the core/common
features, it should be simple for an application to modify its set of
constraints and change the set of allowable protocol features without
changing the core implementation.
Paragraph (version B):
Functionality that is common across multiple transport protocols
SHOULD be accessible through a unified set of API calls.  An
application ought to be able to implement logic for its basic use of
transport networking (establishing the transport, and sending and
receiving data) once, and expect that implementation to continue to
function as the transports change.
Paragraph (version B):
Any Transport Services API is REQUIRED to allow access to the
distilled minimal set of features offered by transport protocols I-
D.ietf-taps-minset.
Paragraph (version B):
There are applications that will need to control fine-grained details
of transport protocols to optimize their behavior and ensure
compatibility with remote systems.  A Transport Services system
therefore SHOULD also permit more specialized protocol features to be
used.  The interface for these specialized options should be exposed
differently from the common options to ensure flexibility.
Paragraph (version B):
A specialized feature could be required by an application only when
using a specific protocol, and not when using others.  For example,
if an application is using UDP, it could require control over the
checksum or fragmentation behavior for UDP; if it used a protocol to
frame its data over a byte stream like TCP, it would not need these
options.  In such cases, the API ought to expose the features in such
a way that they take effect when a particular protocol is selected,
but do not imply that only that protocol could be used.  For example,
if the API allows an application to specify a preference for
constrained checksum usage, communication would not fail when a
protocol such as TCP is selected, which uses a checksum covering the
entire payload.
Paragraph (version B):
Other specialized features, however, could be strictly required by an
application and thus constrain the set of protocols that can be used.
For example, if an application requires encryption of its transport
data, only protocol stacks that include some transport security
protocol are eligible to be used.  A Transport Services API MUST
allow applications to define such requirements and constrain the
system's options.  Since such options are not part of the core/common
features, it will generally be simple for an application to modify
its set of constraints and change the set of allowable protocol
features without changing the core implementation.
Paragraph (version A):
Implementations that provide the Transport Services API I-D.ietf-
taps-impl will vary due to system-specific support and the needs of
the deployment scenario.  It is expected that all implementations of
Transport Services will offer the entire mandatory API, but that some
features will not be functional in certain implementations.  All
implementations must offer sufficient APIs to use the distilled
minimal set of features offered by transport protocols I-D.ietf-taps-
minset, including API support for TCP and UDP transport, but it is
possible that some very constrained devices might not have, for
example, a full TCP implementation.
Paragraph (version A):
To preserve flexibility and compatibility with future protocols, top-
level features in the Transport Services API should avoid referencing
particular transport protocols.  The mappings of these API features
to specific implementations of each feature is explained in the TAPS-
IMPL, which also explain the implications of the feature provided by
existing protocols.  It is expected that this document will be
updated and supplemented as new protocols and protocol features are
developed.
Paragraph (version A):
It is important to note that neither the Transport Services API nor
the Implementation document defines new protocols that require any
changes to a remote host.  The Transport Services system must be
deployable on one side only, as a way to allow an application to make
better use of available capabilities on a system and protocol
features that may be supported by peers across the network.
Paragraph (version A):
The concepts defined in this document are intended primarily for use
in the documents and specifications that describe the Transport
Services architecture and API.  While the specific terminology may be
used in some implementations, it is expected that there will remain a
variety of terms used by running code.
Paragraph (version A):
System-implementation concepts, which are meant to be internally
used when building systems that implement Transport Services.
Paragraph (version B):
Implementations that provide the Transport Services API I-D.ietf-
taps-impl will vary due to system-specific support and the needs of
the deployment scenario.  It is expected that all implementations of
Transport Services will offer the entire mandatory API, but that some
features will not be functional in certain implementations.  All
implementations are REQUIRED to offer sufficient APIs to use the
distilled minimal set of features offered by transport protocols I-
D.ietf-taps-minset, including API support for TCP and UDP transport,
but it is possible that some very constrained devices might not have,
for example, a full TCP implementation beneath the API.
Paragraph (version B):
To preserve flexibility and compatibility with future protocols, top-
level features in the Transport Services API SHOULD avoid referencing
particular transport protocols.  The mappings of these API features
to specific implementations of each feature is explained in the I-
D.ietf-taps-impl which also explain the implications of the feature
provided by existing protocols.  It is expected that this document
will be updated and supplemented as new protocols and protocol
features are developed.
Paragraph (version B):
It is important to note that neither the Transport Services API I-
D.ietf-taps-interface nor the Implementation document I-D.ietf-taps-
impl defines new protocols that require any changes to a remote
system.  The Transport Services system MUST be deployable on one side
only, as a way to allow an application to make better use of
available capabilities on a system and protocol features that may be
supported by peers across the network.
Paragraph (version B):
The concepts defined in this document are intended primarily for use
in the documents and specifications that describe the Transport
Services architecture and API.  While the specific terminology can be
used in some implementations, it is expected that there will remain a
variety of terms used by running code.
Paragraph (version B):
System-implementation concepts, which are intended to be
internally used when building systems that implement Transport
Services.
Paragraph (version A):
Fundamentally, a Transport Services API needs to provide basic
objects (objects) that allow applications to establish communication
and send and receive data.  These may be exposed as handles or
referenced objects, depending on the language.
Paragraph (version A):
Pre-Establishment (preestablishment) encompasses the properties
that an application can pass to describe its intent, requirements,
prohibitions, and preferences for its networking operations.  For
any system that provides generic Transport Services, these
properties should primarily be defined to apply to multiple
transports.  Properties may have a large impact on the rest of the
aspects of the interface: they can modify how establishment
occurs, they can influence the expectations around data transfer,
and they determine the set of events that will be supported.
Paragraph (version A):
Data Transfer (datatransfer) consists of how an application
represents data to be sent and received, the functions required to
send and receive that data, and how the application is notified of
the status of its data transfer.
Paragraph (version A):
Event Handling (events) defines the set of properties about which
an application can receive notifications during the lifetime of
transport objects.  Events can also provide opportunities for the
application to interact with the underlying transport by querying
state or updating maintenance options.
Paragraph (version B):
Fundamentally, a Transport Services API needs to provide basic
objects (objects) that allow applications to establish communication
and send and receive data.  These could be exposed as handles or
referenced objects, depending on the language.
Paragraph (version B):
Pre-Establishment (preestablishment) encompasses the properties
that an application can pass to describe its intent, requirements,
prohibitions, and preferences for its networking operations.  For
any system that provides generic Transport Services, these
properties SHOULD be defined to apply to multiple transport
protocols.  Some properties are specific to a single transport
protocol, and these are be exposed as non-generic interfaces (see
Specific Protocol Properties preestablishment).  Properties can
have a large impact on the rest of the aspects of the interface:
they modify how establishment occurs, they influence the
expectations around data transfer, and they determine the set of
events that will be supported.
Paragraph (version B):
Data Transfer (datatransfer) consists of how an application
represents the data to be sent and received, the functions
required to send and receive that data, and how the application is
notified of the status of its data transfer.
Paragraph (version B):
Event Handling (events) defines the set of properties about which
an application can receive notifications during the lifetime of
transport objects.  Events MAY also provide opportunities for the
application to interact with the underlying transport by querying
state or updating maintenance options.
Paragraph (version A):
Preconnection: A Preconnection object is a representation of a
potential connection.  It has state that describes parameters of a
Connection that might exist in the future: the Local Endpoint from
which that Connection will be established, the Remote Endpoint to
which it will connect, and Path Selection Properties, Protocol
Selection Properties, and Specific Protocol Properties that
influence the choice of transport that a Connection will use.  A
Preconnection can be fully specified and represent a single
possible Connection, or it can be partially specified such that it
represents a family of possible Connections.  The Local Endpoint
must be specified if the Preconnection is used to Listen for
incoming connections, but is optional if it is used to Initiate
connections.  The Remote Endpoint must be specified in the
Preconnection is used to Initiate connections, but is optional if
it is used to Listen for incoming connections.  The Local Endpoint
and the Remote Endpoint must both be specified if a peer-to-peer
Rendezvous is to occur based on the Preconnection.
Paragraph (version A):
Connection: A Connection object represents an active transport
protocol instance that can send and/or receive Messages between a
Local Endpoint and a Remote Endpoint.  It holds state pertaining
to the underlying transport protocol instance and any ongoing data
transfer.  This represents, for example, an active connection in a
connection-oriented protocol such as TCP, or a fully-specified
5-tuple for a connectionless protocol such as UDP.
Paragraph (version A):
Listener: A Listener object accepts incoming transport protocol
connections from Remote Endpoints and generates corresponding
Connection objects.  It is created from a Preconnection object
that specifies the type of incoming connections it will accept.
Paragraph (version A):
Endpoint: An Endpoint represents one side of a transport
connection.  Endpoints can be Local Endpoints or Remote Endpoints,
and respectively represent an identity that the application uses
for the source or destination of a connection.  An Endpoint may be
specified at various levels, and an Endpoint with wider scope
(such as a hostname) can be resolved to more concrete identities
(such as IP addresses).
Paragraph (version A):
Remote Endpoint: The Remote Endpoint represents the application's
name for a peer that can participate in a transport connection.
For example, the combination of a DNS name for the peer and a
service name/port.
Paragraph (version A):
Local Endpoint: The Local Endpoint represents the application's
name for itself that it uses for transport connections.  For
example, a local IP address and port.
Paragraph (version A):
Path Selection Properties: The Path Selection Properties consist
of the options that an application may set to influence the
selection of paths between the Local Endpoint and the Remote
Endpoint.  These options can take the form of requirements,
prohibitions, or preferences.  Examples of options that may
influence path selection include the interface type (such as a Wi-
Fi Ethernet connection, or a Cellular LTE connection),
characteristics of the path that are locally known like Maximum
Transmission Unit (MTU) or discovered like Path MTU (PMTU), or
predicted based on cached information like expected throughput or
latency.
Paragraph (version A):
Protocol Selection Properties: The Protocol Selection Properties
consist of the options that an application may set to influence
the selection of transport protocol, or to configure the behavior
of generic transport protocol features.  These options can take
the form of requirements, prohibitions, and preferences.  Examples
include reliability, service class, multipath support, and fast
open support.
Paragraph (version B):
Preconnection: A Preconnection object is a representation of a
potential connection.  It has state that describes parameters of a
Connection that might exist in the future: the Local Endpoint from
which that Connection will be established, the Remote Endpoint
(preestablishment) to which it will connect, and Path Selection
Properties, Protocol Selection Properties, and Specific Protocol
Properties that influence the choice of transport that a
Connection will use.  A Preconnection can be fully specified and
represent a single possible Connection, or it can be partially
specified such that it represents a family of possible
Connections.  The Local Endpoint (preestablishment) MUST be
specified if the Preconnection is used to Listen for incoming
connections.  The Local Endpoint is OPTIONAL if it is used to
Initiate connections.  The Remote Endpoint MUST be specified in
the Preconnection is used to Initiate connections.  The Remote
Endpoint is OPTIONAL if it is used to Listen for incoming
connections.  The Local Endpoint and the Remote Endpoint MUST both
be specified if a peer-to-peer Rendezvous is to occur based on the
Preconnection.
Paragraph (version B):
Connection: A Connection object represents an active transport
protocol instance that can send and/or receive Messages between
local and remote systems.  It holds state pertaining to the
underlying transport protocol instance and any ongoing data
transfer.  This represents, for example, an active connection in a
connection-oriented protocol such as TCP, or a fully-specified
5-tuple for a connectionless protocol such as UDP.
Paragraph (version B):
Listener: A Listener object accepts incoming transport protocol
connections from remote systems and generates corresponding
Connection objects.  It is created from a Preconnection object
that specifies the type of incoming connections it will accept.
Paragraph (version B):
Endpoint: An Endpoint represents an identifier for one side of a
transport connection.  Endpoints can be Local Endpoints or Remote
Endpoints, and respectively represent an identity that the
application uses for the source or destination of a connection.
An Endpoint can be specified at various levels, and an Endpoint
with wider scope (such as a hostname) can be resolved to more
concrete identities (such as IP addresses).
Paragraph (version B):
Remote Endpoint: The Remote Endpoint represents the application's
identifier for a peer that can participate in a transport
connection.  For example, the combination of a DNS name for the
peer and a service name/port.
Paragraph (version B):
Local Endpoint: The Local Endpoint represents the application's
identifier for itself that it uses for transport connections.  For
example, a local IP address and port.
Paragraph (version B):
Path Selection Properties: The Path Selection Properties consist
of the options that an application can set to influence the
selection of paths between the local and remote systems.  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 Ethernet connection,
or a Cellular LTE connection), characteristics of the path that
are locally known like the Maximum Transmission Unit (MTU) or
discovered like the Path MTU (PMTU), or predicted based on cached
information like expected throughput or latency.
Paragraph (version B):
Protocol Selection Properties: The Protocol Selection Properties
consist of the options that an application can set to influence
the selection of transport protocol, or to configure the behavior
of generic transport protocol features.  These options can take
the form of requirements, prohibitions, and preferences.  Examples
include reliability, service class, multipath support, and fast
open support.
Paragraph (version A):
Specific Protocol Properties: The Specific Protocol Properties
refer to the subset of Protocol Properties options that apply to a
single protocol (transport protocol, IP, or security protocol).
The presence of such Properties does not necessarily require that
a specific protocol must be used when a Connection is established,
but that if this protocol is employed, a particular set of options
should then be used..
Paragraph (version A):
Initiate: The primary action that an application can take to
create a Connection to a Remote Endpoint, and prepare any required
local or remote state to be able to send and/or receive Messages.
For some protocols, this may initiate a client-to-server style
handshake; for other protocols, this may just establish local
state.  The process of identifying options for connecting, such as
resolution of the Remote Endpoint, occurs in response the Initiate
call.
Paragraph (version B):
Specific Protocol Properties: The Specific Protocol Properties
refer to the subset of Protocol Properties options that apply to a
single protocol (transport protocol, IP, or security protocol).
The presence of such Properties does not require that a specific
protocol will be used when a Connection is established, but that
if this protocol is employed, a particular set of options is to be
used.
Paragraph (version B):
Initiate: The primary action that an application can take to
create a Connection to a Remote Endpoint, and prepare any required
local or remote state to be able to send and/or receive Messages.
For some protocols, this will initiate a client-to-server style
handshake; for other protocols, this will just establish local
state.  The process of identifying options for connecting, such as
resolution of the Remote Endpoint, occurs in response the Initiate
call.
Paragraph (version A):
Message: A Message object is a unit of data that can be
represented as bytes that can be transferred between two endpoints
over a transport connection.  The bytes within a Message are
assumed to be ordered within the Message.  If an application does
not care about the order in which a peer receives two distinct
spans of bytes, those spans of bytes are considered independent
Messages.  If a received Message is incomplete or corrupted, it
may or may not be usable by certain applications.  Boundaries of a
Message may or may not be understood or transmitted by transport
protocols.  Specifically, what one application considers to be two
Messages sent on a stream-based transport may be treated as a
single Message by the application on the other side.
Paragraph (version A):
Send: The action to transmit a Message or partial Message over a
Connection to a Remote Endpoint.  The interface to Send may
include options specific to how the Message's content is to be
sent.  Status of the Send operation may be delivered back to the
application in an event (events).
Paragraph (version A):
Receive: An action that indicates that the application is ready to
asynchronously accept a Message over a Connection from a Remote
Endpoint, while the Message content itself will be delivered in an
event (events).  The interface to Receive may include options
specific to the Message that is to be delivered to the
application.
Paragraph (version B):
Message: A Message object is a unit of data that can be
represented as bytes that can be transferred between two systems
over a transport connection.  The bytes within a Message are
assumed to be ordered within the Message.  If an application does
not care about the order in which a peer receives two distinct
spans of bytes, those spans of bytes are considered independent
Messages.  If a received Message is incomplete or corrupted, it
might or might not be usable by certain applications.  Boundaries
of a Message might or might not be understood or transmitted by
transport protocols.  Specifically, what one application considers
to be two Messages sent on a stream-based transport can be treated
as a single Message by the application on the other side.
Paragraph (version B):
Send: The action to transmit a Message or partial Message over a
Connection to the remote system.  The interface to Send MAY
include options specific to how the Message's content is to be
sent.  Status of the Send operation can be delivered back to the
application in an event (events).
Paragraph (version B):
Receive: An action that indicates that the application is ready to
asynchronously accept a Message over a Connection from a remote
system, while the Message content itself will be delivered in an
event (events).  The interface to Receive MAY include options
specific to the Message that is to be delivered to the
application.
Paragraph (version A):
Connection Finished: Signals to an application that a given
Connection is no longer usable for sending or receiving Messages.
This should deliver an error to the application that describes the
nature of the termination.
Paragraph (version A):
Message Sent: Notifies the application of the status of its Send
action.  This may be an error if the Message cannot be sent, or an
indication that Message has been processed by the protocol stack.
Paragraph (version A):
Path Properties Changed: Notifies the application that some
property of the Connection has changed that may influence how and
where data is sent and/or received.
Paragraph (version A):
Close: The action an application may take on a Connection to
indicate that it no longer intends to send data, is no longer
willing to receive data, and that the protocol should signal this
state to the remote endpoint if applicable.
Paragraph (version A):
Abort: The action the application may take on a Connection to
indicate a Close, but with the additional indication that the
transport system should not attempt to deliver any outstanding
data.
Paragraph (version A):
The Transport System Implementation Concepts define the set of
objects used internally to a system or library to provide the
functionality required to provide a transport service across a
network, as required by the abstract interface.
Paragraph (version A):
Path: Represents an available set of properties that a Local
Endpoint may use to send or receive packets with a Remote
Endpoint.
Paragraph (version B):
Connection Finished: Signals to an application that a given
Connection is no longer usable for sending or receiving Messages.
The event SHOULD deliver a reason or error to the application that
describes the nature of the termination.
Paragraph (version B):
Message Sent: Notifies the application of the status of its Send
action.  This might indicate a failure if the Message cannot be
sent, or an indication that Message has been processed by the
protocol stack.
Paragraph (version B):
Path Properties Changed: Notifies the application that some
property of the Connection has changed that might influence how
and where data is sent and/or received.
Paragraph (version B):
Close: The action an application takes on a Connection to indicate
that it no longer intends to send data, is no longer willing to
receive data, and that the protocol SHOULD signal this state to
the remote system if the transport protocol allows this.
Paragraph (version B):
Abort: The action the application takes on a Connection to
indicate a Close and also indicate that the transport system
SHOULD NOT attempt to deliver any outstanding data.
Paragraph (version B):
The Transport System Implementation Concepts define the set of
objects used internally to a system or library to implement the
functionality needed to provide a transport service across a network,
as required by the abstract interface.
Paragraph (version B):
Path: Represents an available set of properties that a local
system can use to communicate with a remote system, such as
routes, addresses, and physical and virtual network interfaces.
Paragraph (version A):
Protocol Stack: A set of Protocol Instances (including relevant
application, security, transport, or Internet protocols) that are
used together to establish connectivity or send and receive
Messages.  A single stack may be simple (a single transport
protocol instance over IP), or complex (multiple application
protocol streams going through a single security and transport
protocol, over IP; or, a multi-path transport protocol over
multiple transport sub-flows).
Paragraph (version B):
Protocol Stack: A set of Protocol Instances (including relevant
application, security, transport, or Internet protocols) that are
used together to establish connectivity or send and receive
Messages.  A single stack can be simple (a single transport
protocol instance over IP), or complex (multiple application
protocol streams going through a single security and transport
protocol, over IP; or, a multi-path transport protocol over
multiple transport sub-flows).
Paragraph (version A):
Candidate Path: One path that is available to an application and
conforms to the Path Selection Properties and System Policy.
Candidate Paths are identified during the gathering phase
(gathering) and may be used during the racing phase (racing).
Paragraph (version A):
Candidate Protocol Stack: One protocol stack that may be used by
an application for a connection, of which there may be several.
Candidate Protocol Stacks are identified during the gathering
phase (gathering) and may be started during the racing phase
(racing).
Paragraph (version A):
System Policy: Represents the input from an operating system or
other global preferences that can constrain or influence how an
implementation will gather candidate paths and protocol stacks
(gathering) and race the candidates during establishment (racing).
Specific aspects of the System Policy may apply to all
Connections, or only certain ones depending on the runtime context
and properties of the Connection.
Paragraph (version B):
Candidate Path: One path that is available to an application and
conforms to the Path Selection Properties and System Policy.
Candidate Paths are identified during the gathering phase
(gathering) and can be used during the racing phase (racing).
Paragraph (version B):
Candidate Protocol Stack: One protocol stack that can be used by
an application for a connection, of which there can be several.
Candidate Protocol Stacks are identified during the gathering
phase (gathering) and are started during the racing phase
(racing).
Paragraph (version B):
System Policy: Represents the input from an operating system or
other global preferences that can constrain or influence how an
implementation will gather candidate paths and protocol stacks
(gathering) and race the candidates during establishment (racing).
Specific aspects of the System Policy either apply to all
Connections or only certain ones, depending on the runtime context
and properties of the Connection.
Paragraph (version A):
Path Selection: Path Selection represents the act of choosing one
or more paths that are available to use based on the Path
Selection Properties provided by the application, and a Transport
Services system's policies and heuristics.
Paragraph (version B):
Path Selection: Path Selection represents the act of choosing one
or more paths that are available to use based on the Path
Selection Properties provided by the application, the policies and
heuristics of a Transport Services system.
Paragraph (version A):
The Transport Services architecture defines a mechanism that allows
applications to easily use different network paths and Protocol
Stacks.  Transitioning between different Protocol Stacks may in some
cases be controlled by properties that only change when application
code is updated.  For example, an application may enable the use of a
multipath or multistreaming transport protocol by modifying the
properties in its Pre-Connection configuration.  In some cases,
however, the Transport Services system will be able to automatically
change Protocol Stacks without an update to the application, either
by selecting a new stack entirely, or racing multiple candidate
Protocol Stacks during connection establishment.  This functionality
can be a powerful driver of new protocol adoption, but must be
constrained carefully to avoid unexpected behavior that can lead to
functional or security problems.
Paragraph (version A):
Both stacks must offer the same interface to the application for
connection establishment and data transmission.  For example, if
one Protocol Stack has UDP as the top-level interface to the
application, then it is not equivalent to a Protocol Stack that
runs TCP as the top-level interface.  Among other differences, the
UDP stack would allow an application to read out message
boundaries based on datagrams sent from the Remote Endpoint,
whereas TCP does not preserve message boundaries on its own.
Paragraph (version B):
The Transport Services architecture defines a mechanism that allows
applications to easily use different network paths and Protocol
Stacks.  Transitioning between different Protocol Stacks is in some
cases controlled by properties that only change when application code
is updated.  For example, an application can enable the use of a
multipath or multistreaming transport protocol by modifying the
properties in its Pre-Connection configuration.  In some cases,
however, the Transport Services system will be able to automatically
change Protocol Stacks without an update to the application, either
by selecting a new stack entirely, or by racing multiple candidate
Protocol Stacks during connection establishment.  This functionality
can be a powerful driver of new protocol adoption, but needs to be
constrained carefully to avoid unexpected behavior that can lead to
functional or security problems.
Paragraph (version B):
Both stacks MUST offer the same interface to the application for
connection establishment and data transmission.  For example, if
one Protocol Stack has UDP as the top-level interface to the
application, then it is not equivalent to a Protocol Stack that
runs TCP as the top-level interface.  Among other differences, the
UDP stack would allow an application to read out message
boundaries based on datagrams sent from the remote system, whereas
TCP does not preserve message boundaries on its own.
Paragraph (version A):
Both stacks must offer the same security properties.  See the
security protocol equivalence section below for futher discussion
(security-equivalence).
Paragraph (version A):
The inclusion of transport security protocols I-D.ietf-taps-
transport-security in a Protocol Stack adds extra restrictions to
Protocol Stack equivalence.  Security features and properties, such
as cryptographic algorithms, peer authentication, and identity
privacy vary across security protocols, and across versions of
security protocols.  Protocol equivalence should not be assumed for
different protocols or protocol versions, even if they offer similar
application configuration options.
Paragraph (version A):
To ensure that security protocols are not incorrectly swapped,
Transport Services systems should only automatically generate
equivalent Protocol Stacks when the transport security protocols
within the stacks are identical.  Specifically, a system should
consider protocols identical only if they are of the same type and
version.  For example, the same version of TLS running over two
different transport protocol stacks may be considered equivalent,
whereas TLS 1.2 and TLS 1.3 I-D.ietf-tls-tls13 should not be
considered equivalent.
Paragraph (version B):
Both stacks MUST offer the same security properties.  The security
protocol equivalence section provides futher discussion (security-
equivalence).
Paragraph (version B):
The inclusion of transport security protocols I-D.ietf-taps-
transport-security in a Protocol Stack adds additional restrictions
to Protocol Stack equivalence.  Security features and properties,
such as cryptographic algorithms, peer authentication, and identity
privacy vary across security protocols, and across versions of
security protocols.  Protocol equivalence ought not to be assumed for
different protocols or protocol versions, even if they offer similar
application configuration options.
Paragraph (version B):
To ensure that security protocols are not incorrectly swapped,
Transport Services systems SHOULD only automatically generate
equivalent Protocol Stacks when the transport security protocols
within the stacks are identical.  Specifically, a transport system
would consider protocols identical only if they are of the same type
and version.  For example, the same version of TLS running over two
different transport protocol stacks are considered equivalent,
whereas TLS 1.2 and TLS 1.3 I-D.ietf-tls-tls13 are not considered
equivalent.
Paragraph (version A):
the ability to manage dependencies between messages, when some
messages may not be delivered due to either packet loss or missing
a deadline, in particular the ability to avoid (re-)sending data
that relies on a previous transmission that was never received.
Paragraph (version A):
All require explicit message boundaries, and application-level
framing of messages, to be effective.  Once a message is passed to
the transport, it can not be cancelled or paused, but prioritization
as well as lifetime and retransmission management will provide the
protocol stack with all needed information to send the messages as
quickly as possible without blocking transmission unnecessarily.  The
transport services architecture facilitates this by handling
messages, with known identity (sequence numbers, in the simple case),
lifetimes, niceness, and antecedents.
Paragraph (version A):
Transport protocols such as SCTP provide a message-oriented API that
has similar features to those we describe.  Other transports, such as
TCP, do not.  To support a message oriented API, while still being
compatible with stream-based transport protocols, implementations of
the transport services architecture should provide APIs for framing
and de-framing messages.  That is, we push message framing down into
the transport services API, allowing applications to send and receive
complete messages.  This is backwards compatible with existing
protocols and APIs, since the wire format of messages does not
change, but gives the protocol stack additional information to allow
it to make better use of modern transport services.
Paragraph (version B):
the ability to manage dependencies between messages, when the
transport system could decide to not deliver a message, either
following packet loss or because it has missed a deadline.  In
particular, this can avoid (re-)sending data that relies on a
previous transmission that was never received.
Paragraph (version B):
This requires explicit message boundaries and application-level
framing of messages.  Once a message is passed to the transport, it
cannot be cancelled or paused, but prioritization as well as lifetime
and retransmission management will provide the protocol stack with
all needed information to send the messages as quickly as possible
without blocking transmission unnecessarily.  The transport services
architecture facilitates this by handling messages, with known
identity (sequence numbers, in the simple case), lifetimes, niceness,
and antecedents.
Paragraph (version B):
Transport protocols such as UDP and SCTP provide a message-oriented
API that has similar features to those described.  Other transports,
such as TCP, do not.  To support a message-oriented API, while still
being compatible with stream-based transport protocols,
implementations of the transport services architecture should provide
APIs for framing and de-framing messages.  That is, we push message
framing down into the transport services API, allowing applications
to send and receive complete messages.  This is backwards compatible
with existing protocols and APIs, since the wire format of messages
does not change, but gives the protocol stack additional information
to allow it to make better use of modern transport services.
Paragraph (version A):
Transport Services APIs will expose similar functionality.
Paragraph (version B):
Transport Services APIs will expose similar functionality I-D.ietf-
taps-transport-security.
Paragraph (version B):
Clients need to ensure that security APIs are used appropriately.  In
cases where clients use an interface to provide sensitive keying
material, e.g., access to private keys or copies of pre-shared keys
(PSKs), key use needs to be validated.  For example, clients ought
not to use PSK material created for the Encapsulating Security
Protocol (ESP, part of IPsec) RFC4303 with QUIC, and clients ought
not to use private keys intended for server authentication as a keys
for client authentication.
Paragraph (version B):
Moreover, unlike certain transport features such as TCP Fast Open
(TFO) RFC7413 or Explicit Congestion Notification (ECN) RFC3168 which
can fall back to standard configurations, Transport Services systems
MUST prohibit fallback for security protocols.  For example, if a
client requests TLS, yet TLS or the desired version are not
available, its connection will fail.