Re: [Taps] Reviewing taps-impl-12

[Gorry Fairhurst <[e-mail]>]

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
> [e-mail]
> 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