Reviewer: Bron Gondwana
Review result: Ready with Nits
Apologies for the really delayed review - I clicked "accept" on this thinking
I'd get to it immediately, and then was unable to before I went on vacation.
Thanks Barry for prodding me to get back to it.
Overall, this document looks fine. I reviewed it in isolation, without reading
all the specs to which it refers.
Thanks for the detailed work. If I was to criticize the structure at all, I'd
say it's a bit repetative in some places - but I'm also aware that as a
reference, it's necessary to repeat the same information!
Having said that - he's some notes of things I noticed or that confused me on
the read through - take what you will if it's useful to you!
Cheers,
Bron.
-----
[...] During the process of
establishment (Section 4), the Connection will not be bound to a
specific transport protocol instance, since multiple candidate
Protocol Stacks might be raced.
It took me a while to understand "raced" in this context - but I guess it's
well known to anyone in the field.
There's a couple of English language things:
Once the Connection is established, Transport Services implementation
maps actions and events to the details of the chosen Protocol Stack.
"the Transport Services"?
[...] The properties held by a Connection or Listener is
independent of other connections that are not part of the same
Connection Group.
"the properties held by ... are"?
Connection establishment is only a local operation for a Datagram
transport (e.g., UDP(-Lite)), which serves to simplify the local
send/receive functions and to filter the traffic for the specified
addresses and ports [RFC8085].
That's a mess. I rewrote it as:
"For a Datagram transport (e.g. UDP(-Lite)), connection establishment is only a
local operation, where it serves to simplify the local send/receive functions
and ..."
The implementation stores these properties as a part of the
Preconnection object for use during connection establishment. For
Selection Properties that are not provided by the application, the
implementation must use the default values specified in the Transport
Services API ([I-D.ietf-taps-interface]).
Normative MUST? I guess this is just a guidance document so doesn't need
anything normative. There's some later "should" as well which I would
generally ask the same question for.
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.
Apart from the 'a a', the first sentence is also clumsy. Maybe:
"For ease of illustration, this document structures the candidates for racing
as a tree, however a tree structure is not the only way in which racing can be
implemented".
* "Interface Instance or Type": If the application specifies an
interface type to be preferred or avoided, implementations should
accordingly rank the paths. If the application specifies an
interface type to be required or prohibited, an implementation is
expeceted to not include the non-conforming paths.
Typo "expected".
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.
I don't recognise the term "transient" as a noun in this context. Maybe this
is lack of familiarity.
The timing algorithms for racing should remain independent across
branches of the tree. Any timers or racing logic is isolated to a
given parent node, and is not ordered precisely with regards to other
children of other nodes.
"Any timers or racing logic are"? Or "Any timer or racing logic is".
Something to align the plurals! Probably the later since the rest of the
paragraph remains in the singular.
4.7.2. Implementing listeners for Connectionless Protocols
Connectionless protocols such as UDP and UDP-lite generally do not
provide the same mechanisms that connected protocols do to offer
Connection objects. Implementations should wait for incoming packets
for connectionless protocols on a listening port and should perform
four-tuple matching of packets to either existing Connection objects
or the creation of new Connection objects. On platforms with
facilities to create a "virtual connection" for connectionless
protocols implementations should use these mechanisms to minimise the
handling of datagrams intended for already created Connection
objects.
This is really fuzzy. There's either a missing comma or some missing words.
The amount of data that can be sent as 0-RTT data varies by protocol
and can be queried by the application using the Maximum Message Size
Concurrent with Connection Establishment Connection Property. An
implementation can set this property according to the protocols that
it will race based on the given Selection Properties when the
application requests to establish a connection.
The capitalisation in there is very confusing to me - I would expect "With" to
also be capitalised if the whole thing is the name of something, and
"Concurrent" not to be capitalised otherwise.
Upon receiving this event, a framer implementation is responsible for
performing any necessary transformations and sending the resulting
data back to the Message Framer, which will in turn send it to the
next protocol. Implementations SHOULD ensure that there is a way to
pass the original data through without copying to improve
performance.
but... here we have some NORMATIVE language. That SHOULD should probably be
non-capitalised to align with earlier usage. (and so on later in the document,
e.g. in the SCTP description)
----
That's all the notes I took.
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
