Draft: draft-ietf-taps-impl

Commentary: Best reviewed by reading the full rendered document 
 Going ahead and merging this ahead of other editorial changes ( since it 's a big move and highly likely to conflict ) 
 “ 4.1.2 . Structuring Options as a Tree ” I do n’t like “ options ” on its own , I think this needs some other word with it ! what is an option v. an connection attempt ? “ When an implementation responsible for connection establishment needs to consider multiple options , ” … or is something optional here ( v. what is meant by 4.1.1.3.3 ) ? … or actually is this “ Alternatives for Structuring as a Tree ” ? ( help me please ! ) 
 Can we do this in ? 
 Section 4 paragraph 3 : " This document structures candidates for racing as a tree " . This statement is true , but it does n't say whether this structure is a necessary outcome of the architecture and the design of the interface , or merely a terminological convention that makes it much easier to discuss . I think it 's the latter . At the least , this sentence should be clarified to make it clear that the tree structure in section 4 ( and subsequent ) is terminological , not normative . To make this clearer , I 'd also create a new " operations on candidate trees " sections , containing sections 4.1.2 , 4.1.3 , 4.1.4 , and 4.1.5 . 
 Clarify that this document uses tree terminology , and that implementations can , but do n't need to , reflect that in their data structures . 
 Heading in what seems the correct direction , but needs changes to improve reading / consistency .
Paragraph (version A):
Connection establishment is divided into two top-level steps:
Candidate Gathering, to identify the paths, protocols, and endpoints
to use, and Candidate Racing (see Section 4.2.2 of I-D.ietf-taps-
arch), in which the necessary protocol handshakes are conducted so
that the transport system can select which set to use.  This document
structures candidates for racing as a tree.
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 vary 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):
Connection establishment is divided into two top-level steps:
Candidate Gathering, to identify the paths, protocols, and endpoints
to use, and Candidate Racing (see Section 4.2.2 of I-D.ietf-taps-
arch), in which the necessary protocol handshakes are conducted so
that the transport system can select which set to use.
Paragraph (version B):
This document structures the candidates for racing as a tree as
terminological convention.  While a a tree structure is not the only
way in which racing can be implemented, it does ease the illustration
of how racing works.
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 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 A):
Both Local and Remote Endpoint Candidates must be discovered during
connection establishment.  To support Interactive Connectivity
Establishment (ICE) RFC8445, or similar protocols that involve out-
of-band indirect signalling to exchange candidates with the Remote
Endpoint, it's important to be able to query the set of candidate
Local Endpoints, and give the protocol stack a set of candidate
Remote Endpoints, before it attempts to establish connections.
Paragraph (version A):
The set of possible Local Endpoints is gathered.  In the simple case,
this merely enumerates the local interfaces and protocols, allocates
ephemeral source ports.  For example, a system that has WiFi and
Ethernet and supports IPv4 and IPv6 might gather four candidate
locals (IPv4 on Ethernet, IPv6 on Ethernet, IPv4 on WiFi, and IPv6 on
WiFi) that can form the source for a transient.
Paragraph (version A):
How this is done will depend on the type of the Remote Endpoint, and
can also be specific to each Local Endpoint.  A common case is when
the Remote Endpoint is a DNS name, in which case it is resolved to
give a set of IPv4 and IPv6 addresses representing that name.  Some
types of remote might require more complex resolution.  Resolving the
Remote Endpoint for a peer-to-peer connection might involve
communication with a rendezvous server, which in turn contacts the
peer to gain consent to communicate and retrieve its set of candidate
locals, which are returned and form the candidate remote addresses
for contacting that peer.
Paragraph (version A):
Resolving the Remote Endpoint is not a local operation.  It will
involve a directory service, and can require communication with the
remote to rendezvous and exchange peer addresses.  This can expose
some or all of the candidate locals to the remote.
Paragraph (version A):
When an implementation responsible for connection establishment needs
to consider multiple options, it should logically structure these
options as a hierarchical tree.  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):
As noted above, the considereration of multiple candidates in a
gathering and racing process can be conceptually structured as a
tree; this terminological convention is used throughout this
document.
Paragraph (version B):
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):
Both Local and Remote Endpoint Candidates must be discovered during
connection establishment.  To support Interactive Connectivity
Establishment (ICE) RFC8445, or similar protocols that involve out-
of-band indirect signalling to exchange candidates with the Remote
Endpoint, it is important to query the set of candidate Local
Endpoints, and provide the protocol stack with a set of candidate
Remote Endpoints, before the Local Endpoint attempts to establish
connections.
Paragraph (version B):
The set of possible Local Endpoints is gathered.  In the simple case,
this merely enumerates the local interfaces and protocols, and
allocates ephemeral source ports.  For example, a system that has
WiFi and Ethernet and supports IPv4 and IPv6 might gather four
candidate Local Endpoints (IPv4 on Ethernet, IPv6 on Ethernet, IPv4
on WiFi, and IPv6 on WiFi) that can form the source for a transient.
Paragraph (version B):
How this resolution is done will depend on the type of the Remote
Endpoint, and can also be specific to each Local Endpoint.  A common
case is when the Remote Endpoint is a DNS name, in which case it is
resolved to give a set of IPv4 and IPv6 addresses representing that
name.  Some types of Remote Endpoint might require more complex
resolution.  Resolving the Remote Endpoint for a peer-to-peer
connection might involve communication with a rendezvous server,
which in turn contacts the peer to gain consent to communicate and
retrieve its set of candidate Local Endpoints, which are returned and
form the candidate remote addresses for contacting that peer.
Paragraph (version B):
Resolving the Remote Endpoint is not a local operation.  It will
involve a directory service, and can require communication with the
Remote Endpoint to rendezvous and exchange peer addresses.  This can
expose some or all of the candidate Local Endpoints to the Remote
Endpoint.