Draft: draft-ietf-taps-interface

Commentary: We have RFCs now !
Paragraph (version A):
It derives specific path and protocol selection properties and
supported transport features from the analysis provided in RFC8095,
I-D.ietf-taps-minset, and I-D.ietf-taps-transport-security.  The
design encourages implementations underneath the interface to
dynamically choose a transport protocol depending on an application's
choices rather than statically binding applications to a protocol at
compile time.  The transport system implementations should provide
applications with a way to override transport selection and
instantiate a specific stack, e.g., to support servers wishing to
listen to a specific protocol.  This specific transport stack choice
is discouraged for general use, because it can reduce the
portability.
Paragraph (version B):
It derives specific path and protocol selection properties and
supported transport features from the analysis provided in RFC8095,
RFC8923, and RFC8922.  The design encourages implementations
underneath the interface to dynamically choose a transport protocol
depending on an application's choices rather than statically binding
applications to a protocol at compile time.  The transport system
implementations should provide applications with a way to override
transport selection and instantiate a specific stack, e.g., to
support servers wishing to listen to a specific protocol.  This
specific transport stack choice is discouraged for general use,
because it can reduce the portability.
Paragraph (version A):
These TCP-specific properties are included here because the feature
"Suggest timeout to the peer" is part of the minimal set of transport
services I-D.ietf-taps-minset, where this feature was categorized as
"functional".  This means that when an implementation offers this
feature, it has to expose an interface to it to the application.
Otherwise, the implementation might violate assumptions by the
application, which could cause the application to fail.
Paragraph (version B):
These TCP-specific properties are included here because the feature
"Suggest timeout to the peer" is part of the minimal set of transport
services RFC8923, where this feature was categorized as "functional".
This means that when an implementation offers this feature, it has to
expose an interface to it to the application.  Otherwise, the
implementation might violate assumptions by the application, which
could cause the application to fail.
Paragraph (version A):
The Transport Services architecture is based on the survey of
services provided by IETF transport protocols and congestion control
mechanisms RFC8095, and the distilled minimal set of the features
offered by transport protocols I-D.ietf-taps-minset.  These documents
identified common features and patterns across all transport
protocols developed thus far in the IETF.
Paragraph (version A):
Since transport security is an increasingly relevant aspect of using
transport protocols on the Internet, this architecture also considers
the impact of transport security protocols on the feature-set exposed
by Transport Services I-D.ietf-taps-transport-security.
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
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 B):
The Transport Services architecture is based on the survey of
services provided by IETF transport protocols and congestion control
mechanisms RFC8095, and the distilled minimal set of the features
offered by transport protocols RFC8923.  These documents identified
common features and patterns across all transport protocols developed
thus far in the IETF.
Paragraph (version B):
Since transport security is an increasingly relevant aspect of using
transport protocols on the Internet, this architecture also considers
the impact of transport security protocols on the feature-set exposed
by Transport Services RFC8922.
Paragraph (version B):
One of the key insights to come from identifying the minimal set of
features provided by transport protocols RFC8923 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):
Any functionality that is common across multiple transport protocols
SHOULD be made accessible through a unified set of Transport Services
API calls.  As a baseline, any Transport Services API MUST allow
access to the minimal set of features offered by transport protocols
I-D.ietf-taps-minset.
Paragraph (version B):
Any functionality that is common across multiple transport protocols
SHOULD be made accessible through a unified set of Transport Services
API calls.  As a baseline, any Transport Services API MUST allow
access to the minimal set of features offered by transport protocols
RFC8923.
Paragraph (version A):
To ensure that security protocols are not incorrectly swapped,
Transport Services systems MUST only select Protocol Stacks that meet
application requirements (I-D.ietf-taps-transport-security).  Systems
SHOULD only race Protocol Stacks where the transport security
protocols within the stacks are identical.  Transport Services
systems MUST NOT automatically fall back from secure protocols to
insecure protocols, or to weaker versions of secure protocols.  A
Transport Services system MAY allow applications to explicitly
specify that fallback to a specific other version of a protocol is
allowed, e.g., to allow fallback to TLS 1.2 if TLS 1.3 is not
available.
Paragraph (version B):
To ensure that security protocols are not incorrectly swapped,
Transport Services systems MUST only select Protocol Stacks that meet
application requirements (RFC8922).  Systems SHOULD only race
Protocol Stacks where the transport security protocols within the
stacks are identical.  Transport Services systems MUST NOT
automatically fall back from secure protocols to insecure protocols,
or to weaker versions of secure protocols.  A Transport Services
system MAY allow applications to explicitly specify that fallback to
a specific other version of a protocol is allowed, e.g., to allow
fallback to TLS 1.2 if TLS 1.3 is not available.
Paragraph (version A):
Security Parameters: Security Parameters define an application's
requirements for authentication and encryption on a Connection.
They are used by Transport Security protocols (such as those
described in I-D.ietf-taps-transport-security) to establish secure
Connections.  Examples of parameters that can be set include local
identities, private keys, supported cryptographic algorithms, and
requirements for validating trust of remote identities.  Security
Parameters are primarily associated with a Preconnection object,
but properties related to identities can be associated directly
with Endpoints.
Paragraph (version B):
Security Parameters: Security Parameters define an application's
requirements for authentication and encryption on a Connection.
They are used by Transport Security protocols (such as those
described in RFC8922) to establish secure Connections.  Examples
of parameters that can be set include local identities, private
keys, supported cryptographic algorithms, and requirements for
validating trust of remote identities.  Security Parameters are
primarily associated with a Preconnection object, but properties
related to identities can be associated directly with Endpoints.
Paragraph (version A):
The Transport Services architecture does not recommend use of
specific security protocols or algorithms.  Its goal is to offer ease
of use for existing protocols by providing a generic security-related
interface.  Each provided interface translates to an existing
protocol-specific interface provided by supported security protocols.
For example, trust verification callbacks are common parts of TLS
APIs.  Transport Services APIs will expose similar functionality I-
D.ietf-taps-transport-security.
Paragraph (version B):
The Transport Services architecture does not recommend use of
specific security protocols or algorithms.  Its goal is to offer ease
of use for existing protocols by providing a generic security-related
interface.  Each provided interface translates to an existing
protocol-specific interface provided by supported security protocols.
For example, trust verification callbacks are common parts of TLS
APIs.  Transport Services APIs will expose similar functionality
RFC8922.
Paragraph (version A):
Below, terms in capitals with a dot (e.g., "CONNECT.SCTP") refer to
the primitives with the same name in section 4 of RFC8303.  For
further implementation details, the description of these primitives
in RFC8303 points to section 3 of RFC8303 and section 3 of RFC8304,
which refers back to the relevant specifications for each protocol.
This back-tracking method applies to all elements of I-D.ietf-taps-
minset (see appendix D of I-D.ietf-taps-interface): they are listed
in appendix A of I-D.ietf-taps-minset with an implementation hint in
the same style, pointing back to section 4 of RFC8303.
Paragraph (version A):
This document defines the API mappings for protocols defined in I-
D.ietf-taps-minset.  Other protocol mappings can be provided as
separate documents, following the mapping template appendix-mapping-
template.
Paragraph (version B):
Below, terms in capitals with a dot (e.g., "CONNECT.SCTP") refer to
the primitives with the same name in section 4 of RFC8303.  For
further implementation details, the description of these primitives
in RFC8303 points to section 3 of RFC8303 and section 3 of RFC8304,
which refers back to the relevant specifications for each protocol.
This back-tracking method applies to all elements of RFC8923 (see
appendix D of I-D.ietf-taps-interface): they are listed in appendix A
of RFC8923 with an implementation hint in the same style, pointing
back to section 4 of RFC8303.
Paragraph (version B):
This document defines the API mappings for protocols defined in
RFC8923.  Other protocol mappings can be provided as separate
documents, following the mapping template appendix-mapping-template.