Tree nomenclature and language nits

[mwelzl]

4.1. Structuring Candidates as a Tree

The parent (or trunk) node of the tree will be represented by
a single integer, such as "1".

My understanding is that the usual term is "root node".

As noted above, the consideration of multiple candidates in a
gathering and racing process can be conceptually structured as a
tree; this terminological convention is used throughout this
document.

In protocol stacks, the layers are
separated by '/' and ordered top-down.

Given that the tree structure has an up-down dimension and this
sentence is not referring to that dimension, it might be clearer to
say that the designations of protocol stack layers are "ordered
top-layer-first" since this document writes them that way
(e.g. "HTTP/TCP").

A connection establishment tree may be degenerate, and only have a
single leaf node, such as a connection attempt to an IP address over
a single interface with a single protocol.

Given that "degenerate" is used nowhere else, this could be simplified
to "A connection establishment tree may consist of only a single leaf
node, such as a connection attempt to a specified IP address over a
single interface with a single protocol."

4.1.2. Branching Order-of-Operations

For example, if the application has indicated both a preference for
WiFi over LTE and for a feature only available in SCTP, branches will
be first sorted accord to path selection, with WiFi at the top.
Then, branches with SCTP will be sorted to the top within their
subtree according to the properties influencing protocol selection.

I find the use of "top" confusing here. Given we are talking about
trees, I consider "top" to mean closer to the root of the tree. Here,
it appears to mean "earlier in the set of children of a parent node".
I think "first" would be better, as we are arranging the children
under a parent node in what is usually shows as left-to-right order
(or actually, into the time-order in which the children will be
tried).

Note this trouble comes from the compact notation used for trees,
which causes the typographical top-bottom dimension to be used both
for the top-bottom axis of the layers of the tree and for the
sequencing of the children of a mode. Make sure people aren't
confused if they continue to think about trees in the usual graphical
presentation.

4.1.3. Sorting Branches

Implementations should sort the branches of the tree of connection
options in order of their preference rank, from most preferred to
least preferred. Leaf nodes on branches with higher rankings
represent connection attempts that will be raced first.
Implementations should order the branches to reflect the preferences
expressed by the application for its new connection, including
Selection Properties, which are specified in
[I-D.ietf-taps-interface].

The first and third sentences of this paragraph are largely the same;
can they be combined?

4.3. Candidate Racing

However, an implementation is unable to know the full tree
before it is formed [...]

This is probably not phrased well. Strictly, it is a tautology, you
can't know the full tree until you know it. I suspect the meaning is
that an implementation may want to start racing candidates before the
full tree is known.

Any timer or racing logic is isolated to a
given parent node, and is not ordered precisely with regards to other
children of other nodes.

"other children of other nodes" s.b. "children of other nodes".

4.3.3. Failover

An example in which failover is recommended is a race between a
Protocol Stack that uses a proxy and a Protocol Stack that bypasses
the proxy. Failover is useful in case the proxy is down or
misconfigured, but any more aggressive type of racing may end up
unnecessarily avoiding a proxy that was preferred by policy.

This could be clarified. I started reading the paragraph assuming
that a connection without a proxy would always be preferred to one
with a proxy. However, in this example the opposite is true, and that
should be revealed at the beginning. Perhaps

An example in which failover is recommended is a race where a
Protocol Stack that uses a proxy is preferred to a Protocol Stack
that bypasses the proxy. Failover is useful in case the proxy is
down or misconfigured, but any more aggressive type of racing may
end up avoiding the proxy when it could have been used.

4.4.1. Determining Successful Establishment

If the only protocol being used is a transport protocol
with a clear handshake, like TCP, then the obvious choice is to
declare that node "connected" when the last packet of the three-way
handshake has been received.

We are discussing behavior of the client and the client does not know
when the last (ACK) packet of the three-way handshake has been
received because it does not receive that packet. You want to say
"... has been transmitted." since transmitting that packet is the last
thing the client does during TCP connection establishment.

---

From the review by Dale Worley: https://mailarchive.ietf.org/arch/msg/last-call/bpBk8QxZMLksr3ZuROtf2_BXYdI/
Note that indentation was lost by copy+pasting here - look at the edited version or the version at the URL to get a clearer view of what is being quoted.