Draft: draft-ietf-taps-interface

Commentary: More to follow in a subsequent PR ( it 's lunchtime . :) ) 
 I think this protocol specific Property is only included because it comes from RFC8923 ? Should be made clear in the text . 
 Yes . Just for clarification : RFC 8923 takes this from RFC 8304 , which takes it from RFC 8085 . 
 How about something like : " [ RFC8293 ] following the guidance in [ RFC8085 ] " ? 
 I assume the example can only happen if preserveOrder is not required ? As  is the default for preserveOrder this should be made clear in the example . 
 I do not understand the relationship between bullets four and five . They seem to overlap ? 
 :  , is this resolved by this PR : Re - group managing properties & protocol instances ? 
 I can not parse the " to all remote systems " part of the following sentence . 
 so let 's remove it . 
 For this property we state . " This property applies to Connections and Connection Groups . " But I think this is true for all Selection Properties , so it read strangely to me to point it out for only one property . Particularly the part about the Connection Groups . It makes you wonder if the other properties do not apply to   . I guess it is here because the Property relates to messages , but maybe the text can be reformulated and the part about   can be removed . Maybe something like " This property specifies whether an application considers it useful to indicate its reliability requirements on a per - Message basis for the Messages within the Connection . " or " This property specifies whether an application considers it useful to specify different reliability requirements for individual Messages in a Connection . 
 A clarification : I 'm pretty sure that the statement " This property applies to Connections and Connection Groups . " comes from me - I had originally written this for all properties where it applies like this , the only different one being per - Message priority . Then we changed this at some point , to only make per - Message priority stand out , and removed that statement everywhere . In the process , we ( probably I ) must have overlooked this one . So yes , this statement does n't fit and should be removed .  's second paragraph above proposes an update to the only remaining sentence describing this property . I suggest to use her second suggestion . 
 Text that discusses the recommended default values for Selection Properties uses the word " recommended " in multiple places . It is unclear to me if any of them should be " RECOMMENDED " . Otherwise using another word may make it more clear . 
 Recommended -suggested ? 
 Introductory text says " All Transport Properties , regardless of the phase in which they are used , are organized within a single namespace . " But later in the text multiple name spaces are mentioned . Even if they are not related to the phase , this does not seem consistent . 
 reworked this section to avoid the namespace issue altogether . 
 The list of what the interface provides is in the form of one sentence per bullet . That makes some sentences very long with many commas . I find this hard to read , particularly the first and fourth bullet . Maybe allow multiple sentences per bullet for some of them ? 
 S1.1 , Definition of Tuple refers to property before it is defined 
 This must be about the sentence : " The composition of types and their order depends on the property and is fixed for the property . " I wonder if this could be addressed by just removing this sentence ? I 'm not sure it 's really needed . 
 Yep . Will remove the sentence . 
 Thanks for getting to this : My lunch - time was offset from yours , so here are a few initial NiTs to help finish this .
Paragraph (version A):
Tuple: An ordered grouping of multiple value types, represented as
a comma-separated list in parentheses, e.g., "(Enumeration,
Preference)".  Instances take a sequence of values each valid for
the corresponding value type.  The composition of types and their
order depends on the property and is fixed for the property.
Paragraph (version B):
Tuple: An ordered grouping of multiple value types, represented as
a comma-separated list in parentheses, e.g., "(Enumeration,
Preference)".  Instances take a sequence of values each valid for
the corresponding value type.
Paragraph (version A):
Explicit support for multistreaming and multipath transport
protocols, and the grouping of related Connections into Connection
Groups through cloning of Connections, to allow applications to
take full advantage of new transport protocols supporting these
features.
Paragraph (version B):
Access to 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 unified interface to datagram and connection-oriented
transports, allowing use of a common API for connection-
establishment and closing.
Paragraph (version B):
Message-orientation, as opposed to stream-orientation, using
application-assisted framing and deframing where the underlying
transport does not provide these.
Paragraph (version B):
Selection between alternate network paths, using additional
information about the networks over which a connection can operate
(e.g.  Provisioning Domain (PvD) information RFC7556) where
available.
Paragraph (version B):
Explicit support for transport-specific features to be applied,
should that particular transport be part of a chosen Protocol
Stack.
Paragraph (version B):
Explicit support for security properties as first-order transport
features.
Paragraph (version B):
Explicit support for configuration of cryptographic identities and
transport security parameters persistent across multiple
Connections.
Paragraph (version B):
Explicit support for multistreaming and multipath transport
protocols, and the grouping of related Connections into Connection
Groups through cloning of Connections.  This allows applications
to take full advantage of new transport protocols supporting these
features.
Paragraph (version B):
Selection Properties can be set on Preconnections, and the effect of
Selection Properties can be queried on Connections and Messages.
Connection Properties can be set on Connections and Preconnections;
when set on Preconnections, they act as an initial default for the
resulting Connections.  Message Properties can be set on Messages,
Connections, and Preconnections; when set on the latter two, they act
as an initial default for the Messages sent over those Connections,
Paragraph (version A):
Preference, which is an Enumeration with five possible values:
Prohibit, Avoid, Ignore, Prefer, or Require.  Each of these
denotes a level of preference of a given property during protocol
selection.  (See also selection-props.)  The Preference type is
used only on Preconnections, and only for Selection Properties.
Paragraph (version B):
Each Transport Property has a one of the basic types described in
notation.
Paragraph (version B):
Most Selection Properties (see selection-props) are of the
Enumeration type, and use the Preference Enumeration, which takes one
of five possible values (Prohibit, Avoid, Ignore, Prefer, or Require)
denoting the level of preference for a given property during protocol
selection.
Paragraph (version A):
An implementation of this interface must provide sensible defaults
for Selection Properties.  The recommended 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 implementation, 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 recommended below are used, it is
recommended to clearly document any differences.
Paragraph (version B):
An implementation of this interface 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 implementation, 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 an application considers it useful to
indicate its reliability requirements on a per-Message basis.  This
property applies to Connections and Connection Groups.
Paragraph (version B):
This property specifies whether an application considers it useful to
specify different reliability requirements for individual Messages in
a Connection.
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 all remote systems, 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 should define the "Cellular" interface type
for both systems, since an application might wish to always prohibit
cellular.
Paragraph (version A):
Representation of Security Parameters in implementations should
parallel that chosen for Transport Property names as recommended in
scope-of-interface-defn.
Paragraph (version B):
Representation of Security Parameters in implementations should
parallel that chosen for Transport Property names as sugggested in
scope-of-interface-defn.
Paragraph (version A):
For Connections that are Established, Closing, or Closed:
Connection Properties (connection-props) of the actual protocols
that were selected and instantiated.
Paragraph (version A):
For Connections that are Established or Closing: Transport
Properties that the application specified on the Preconnection.
Selection Properties indicate whether or not the Connection has or
offers a certain Selection Property, see selection-props.
The actually instantiated protocol stack might not match all
Protocol Selection Properties that the application specified on
the Preconnection.  For example, a certain Protocol Selection
Property that an application specified as Preferred might not
actually be present in the chosen protocol stack because none of
the currently available transport protocols had this feature.
Selection properties of type "Preference" will be exposed as
boolean values indicating whether or not the property applies to
the selected transport.
Paragraph (version B):
For Connections that are Established, Closing, or Closed:
Connection Properties (connection-props) of the actual protocols
that were selected and instantiated, and Selection Properties that
the application specified on the Preconnection.  Selection
Properties of type "Preference" will be exposed as boolean values
indicating whether or not the property applies to the selected
transport.  Note that the instantiated protocol stack might not
match all Protocol Selection Properties that the application
specified on the Preconnection.
Paragraph (version A):
Multiple invocations of ReceivedPartial deliver data for the same
Message by passing the same MessageContext, until the endOfMessage
flag is delivered or a ReceiveError occurs.  All partial blocks of a
single Message are delivered in order without gaps.  This event does
not support delivering discontiguous partial Messages.  If, for
example, Message A is divided into three pieces (A1, A2, A3) and
Message B is divided into three pieces (B1, B2, B3), the
ReceivedPartial may deliver them in a sequence like this: A1, B1, B2,
A2, A3, B3, because the messageContext allows the application to
identify the pieces as belonging to Message A and B, respectively.
However, a sequence like: A1, A3 will never occur.
Paragraph (version B):
Multiple invocations of ReceivedPartial deliver data for the same
Message by passing the same MessageContext, until the endOfMessage
flag is delivered or a ReceiveError occurs.  All partial blocks of a
single Message are delivered in order without gaps.  This event does
not support delivering discontiguous partial Messages.  If, for
example, Message A is divided into three pieces (A1, A2, A3) and
Message B is divided into three pieces (B1, B2, B3), and
preserveOrder is not Required, the ReceivedPartial may deliver them
in a sequence like this: A1, B1, B2, A2, A3, B3, because the
messageContext allows the application to identify the pieces as
belonging to Message A and B, respectively.  However, a sequence
like: A1, A3 will never occur.
Paragraph (version A):
When available, Message metadata carries the value of the Explicit
Congestion Notification (ECN) field.  This information can be used
for logging and debugging, and for building applications that need
access to information about the transport internals for their own
operation.  This property is specific to UDP and UDP-Lite because
these protocols do not implement congestion control, and hence expose
this functionality to the application.