On 19/05/2022 12:47, Christian Amsüss wrote:
Hello taps-impl authors,
I've had a look at Implementing Interfaces to Transport Services from
the point of view of a curious observer of the TAPS ecosystem without
actual hands-on experience. (Also, I thought I'd review this for the ART
review team -- I wasn't assigned, but still kept ART area issues in
mind, and none were even remotely encountered).
* "Connection establishment is only a local operation for a Datagram
transport (e.g., UDP(-Lite))": I think the criterion is not Datagram
transports but "transports without a handshake" or "connectionless
protocols" as it is used later in the document.
* "In effect, each leaf node will send the same early application data,
yet encoded (encrypted) differently on the wire.": There has been a
warning on the privacy implications of using the same token on
different paths; doesn't sending an identical 0-RTT message racingly
on multiple transports cause similar correlation issues?
* Framers: What is the difference between the Final message property and
the separate IsEndOfMessage event argument?
Also there, the term MessageContext could use a definition.
* Framers: The <tt> paragraphs in Defining Message Framers and later
might be formal language or pseudocode, I can't tell. It might help if
the introduction stated something around names and signatures of
signals and functions being expressed in pseudocode, and that
identifiers in implementations are expected to be similar to those but
following the conventions of the language they are implemented in.
* Is the content of messages always bytes? I certainly got that
impression, but didn't see it explicitly either. (The "protocols that
expose byte-streams" have that property visible in their name). When
framers are used a lot, I can envision that at some point a message
might not use data bytes at all any more, as all information in the
underlying message is being dissected into protocol specific
properties.
* UDP, ConnectionError: Would those soft errors contain additional
information about the ICMP error code, and can an application expect
to find the (partial) original datagram in the error?
* (More out of curiosity, with no expectation that this would find its
way into the text unless you think I've hit a bug): In UDP Multicast
Receive, which kind of ICMP notifications can come in there that would
constitute a ConnectionError -- given that this transport does not
send (and would thus usually not trigger any)?
* The most recent changes on the two linked Python implementations had
me briefly worry that they might be out of date with their last
changes around 2019/2020 -- but comparing -12 with -06 it seems that
the document has been stable for quite a while (with many changes
appearing editorial.
This nicely matches my the overall impression of this document, which
is that it looks mature and ready to implement.
Best regards, and thank you for the continuous work on this
Christian
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
This is very useful!! Thank you for sending these.
I have created 5 corresponding issues in the WG github for these
comments, and expect they can also be discussed there - please do
follow-up on proposals and comments.
Best wishes,
Gorry
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
