Draft: draft-ietf-taps-impl

Commentary: After reading , I reviewed the latest text . I 'm unsure I want to make changes to Arch / API : I see path as " network path " , that is the set of hops through which the packet is forwarded ( the local interface being the first local hop , and PvD information / PMTU / etc relating to something non - local ) . This changes the examples using interface to align with this . 
 Impl draft , section 4.1.2 : " Each node will be summarized by a tuple of three elements : Endpoint ,  , and Protocol . The above example can now be written more succinctly as : 1 [ , Any , TCP ] 1.1 [ , Wi - Fi , TCP ] 1.1.1 [ 192.0.2.1:80 , Wi - Fi , TCP ] 1.2 [ ,  , TCP ] 1.2.1 [ 192.0.2.1:80 , LTE , TCP ] 1.2.2 [ 2001 : DB8::1.80 , LTE , TCP ] " looking at the example I would not call this " Endpoint , Path , and Protocol " but " Remote Endpoint , Local Endpoint or interface , and Protocol " . Not sure we have defined the term  well but I would consider a path to consists of both the local and remote endpoint plus optionally maybe even some more information about the path characteristics that might be known for this endpoint pair . 
 Yeah , it is " remote endpoint " , " interface / local endpoint " , and " protocol " . 
 note that the wording needs to be fix at least in a few more places , so whoever puts the PR in should probably reach for the word path and ensure it 's used correctly ... 
 especially 4.1.3.2 . ( Alternate Paths ) would n't fit that well anymore and would probably need some rewriting ...
Paragraph (version A):
The most simple example of this process might involve identifying the
single IP address to which the implementation wishes to connect,
using the system's current default interface or path, and starting a
TCP handshake to establish a stream to the specified IP address.
However, each step may also differ depending on the requirements of
the connection: if the endpoint is defined as a hostname and port,
then there may be multiple resolved addresses that are available;
there may also be multiple interfaces or paths available, other than
the default system interface; and some protocols may not need any
transport handshake to be considered "established" (such as UDP),
while other connections may utilize layered protocol handshakes, such
as TLS over TCP.
Paragraph (version B):
The most simple example of this process might involve identifying the
single IP address to which the implementation wishes to connect,
using the system's current default path (i.e., using the default
interface), and starting a TCP handshake to establish a stream to the
specified IP address.  However, each step may also differ depending
on the requirements of the connection: if the endpoint is defined as
a hostname and port, then there may be multiple resolved addresses
that are available; there may also be multiple paths available, (in
this case using an interface other than the default system
interface); and some protocols may not need any transport handshake
to be considered "established" (such as UDP), while other connections
may utilize layered protocol handshakes, such as TLS over TCP.
Paragraph (version A):
Each leaf node of the tree represents a single, coherent connection
attempt, with an endpoint, a path, and a set of protocols that can
directly negotiate and send data on the network.  Each node in the
tree that is not a leaf represents a connection attempt that is
either underspecified, or else includes multiple distinct options.
For example, when connecting on an IP network, a connection attempt
to a hostname and port is underspecified, because the connection
attempt requires a resolved IP address as its Remote Endpoint.  In
this case, the node represented by the connection attempt to the
hostname is a parent node, with child nodes for each IP address.
Similarly, an implementation that is allowed to connect using
multiple interfaces will have a parent node of the tree for the
decision between the paths, with a branch for each interface.
Paragraph (version B):
Each leaf node of the tree represents a single, coherent connection
attempt, with an endpoint, a network path, and a set of protocols
that can directly negotiate and send data on the network.  Each node
in the tree that is not a leaf represents a connection attempt that
is either underspecified, or else includes multiple distinct options.
For example, when connecting on an IP network, a connection attempt
to a hostname and port is underspecified, because the connection
attempt requires a resolved IP address as its Remote Endpoint.  In
this case, the node represented by the connection attempt to the
hostname is a parent node, with child nodes for each IP address.
Similarly, an implementation that is allowed to connect using
multiple interfaces will have a parent node of the tree for the
decision between the network paths, with a branch for each interface.
Paragraph (version A):
decision between the paths, with a branch for each interface.
Paragraph (version B):
decision between the network paths, with a branch for each interface.
Paragraph (version A):
If a connection originally targets a single endpoint, there may be
multiple endpoints of different types that can be derived from the
original.  The connection library creates an ordered list of the
derived endpoints according to application preference, system policy
and expected performance.
Paragraph (version B):
If a connection originally targets a single endpoint, there may be
multiple endpoints of different types that can be derived from the
original.  This creates an ordered list of the derived endpoints
according to application preference, system policy and expected
performance.
Paragraph (version A):
If a client has multiple network interfaces available to it, e.g., a
mobile client with both Wi-Fi and Cellular connectivity, it can
attempt a connection over any of the interfaces.  This represents a
branch point in the connection establishment.  Similar to a derived
endpoint, the interfaces should be ranked based on preference, system
policy, and performance.  Attempts should be started on one
interface, and then on other interfaces successively after delays
based on expected round-trip-time or other available metrics.
Paragraph (version A):
This same approach applies to any situation in which the client is
aware of multiple links or views of the network.  Multiple Paths,
each with a coherent set of addresses, routes, DNS server, and more,
may share a single interface.  A path may also represent a virtual
interface service such as a Virtual Private Network (VPN).
Paragraph (version A):
The list of available paths should be constrained by any requirements
or prohibitions the application sets, as well as system policy.
Paragraph (version B):
If a client has multiple network paths available to it, e.g., a
mobile client with intefaces for both Wi-Fi and Cellular
connectivity, it can attempt a connection over any of the paths.
This represents a branch point in the connection establishment.
Similar to a derived endpoint, the paths should be ranked based on
preference, system policy, and performance.  Attempts should be
started on one path (e.g., a specific interface), and then
successively on other paths (or interfaces) after delays based on
expected path round-trip-time or other available metrics.
Paragraph (version B):
This same approach applies to any situation in which the client is
aware of multiple links or views of the network.  A single interface
may be shared by multiple network paths, each with a coherent set of
addresses, routes, DNS server, and more.  A path may also represent a
virtual interface service such as a Virtual Private Network (VPN).
Paragraph (version B):
The list of available paths should be constrained by any requirements
the application sets, as well as by the system policy.