Re: [Taps] draft-ietf-taps-interface-05 review

[Kyle Rose <[e-mail]>]

On Wed, Mar 4, 2020 at 9:41 AM Michael Welzl <[e-mail]> wrote:

> 2. Terminology and Notation
>
>  * The notation "Sender -> Event" says nothing about who receives the
> event. Is it just assumed to be the application in the context of the
> particular event (e.g., a thread processing a particular connection)?
>
> MW: We have the following statement in this section: "Events could be
> implemented via event queues, handler functions or classes, communicating
> sequential processes, or other asynchronous calling conventions."
> I wonder why this isn't enough information? E.g., if handlers are used,
> then the recipient of the event is a pre-registered handler -  and handlers
> must therefore be registered before events can occur; this function isn't
> visible in the API because this is platform- and language-specific.
>

After some thought, I think I'm okay with this now. It feels like one of
those things that would make perfect sense if I were actually implementing
a TAPS interface.


> 4.2.1. Transport Property Names
>
>  * The use of dashes in property names means they will necessarily look
> different in almost every widely-used language, in which dash is an
> operator.
>

Following on to the discussion later in the thread, CamelCase would
probably be an improvement from this perspective. Underscores would also be
fine.



>   * If we're not currently asking IANA to create a registry of property
> names or namespaces, should we provide a recommendation that such symbols
> not listed explcitly in this document be prefixed with some experimental
> identifier?
>

Can't remember where I saw objection that this creates the possibility of a
bunch of long-lived X-* properties. To that I respond: which is worse? A
complete free-for-all, or a recommendation to have the free-for-all
confined to an X- namespace? Do properties starting with X- just offend
engineering sensibilities?

One "right" alternative is a documentation-required registry, but does that
raise the bar too high? How about a TAPS wiki as a compromise? The
important outcome is that properties be well-defined and not conflict with
each other. Since these properties have entirely local effects (e.g., they
don't get encoded as options and transmitted to the peer), we probably
don't need the level of precision motivating option registries, for
instance. Is there precedent at the IETF for a registry mechanism less
formal that what IANA provides?

5.2. Specifying Transport Properties
>
>  * There are a lot of choices being made about how users will want to
> prioritize transport protocol selection. How confident are we that, for
> instance, path selection should take priority over protocol selection? I
> think that's right, but I wonder if it might not make more sense to have
> two interfaces: one that provides a purely numeric priority ordering of
> preferences, and one (based on the existing 5-level preferences) that maps
> into it.
>

I'm okay with whoever said that this is unworkable. I'm sure I missed the
original discussion.


>  * Using the same enum (Require(d[sic])/Avoid/Ignore) for the queried
> output of selected properties seems like a shortcut that will lead to some
> confusion.
>
> MW: I agree;  partially addressed: s/Required/Require wherever it's a
> Preference level.
>

FWIW, my objection to the other issue (using a normative term as an
indication of what was chosen) isn't that it's underspecified, only that
it's confusing. I put it roughly in the same category as specifying -1 as
an error indicator in an abstract API. Is the idea that the output
parameters could be fed into the protocol selection logic for a subsequent
connection to select the same protocol? Is that useful?


> 5.2.5. Use 0-RTT Session Establishment with an Idempotent Message
>
>  * I'll repeat the same statement I made at the mic a few years ago:
> idempotency != replay-safe. DELETE is idempotent, but not safe for replay
> because someone might have done a PUT or POST in the meantime.
>
> MW: I remember you saying this, sorry that we haven't addressed it yet! I
> didn't understand - is your concern about replaying that a Message may
> arrive later, i.e. as Message X, Messages Y and Z in between, then Message
> X again?  => if so, are you saying that this could happen with TFO or
> QUIC?  (I didn't think so)
>

What I mean is maybe best illustrated by 0RTT in TLS or QUIC. If a user
sends a 0RTT DELETE /object, followed by a PUT /object, then within the
replay window and without any replay prevention at the application layer,
an attacker could replay the 0RTT DELETE /object and cause the object to be
deleted again. DELETE is idempotent but it's not safe to replay.

7.3.3. SendError
>
>  * Is there a reason why a single messageContext object is used for both
> sends and receives? I probably missed the original discussion about this,
> but I'd like to understand the reasoning.
>
> MW: I don't get this, where does it say that it's only a single object? Or
> do you mean that it's the same type? Why is that problematic?
>

Same type. (Maybe I should have said "class" instead of "object".) For
example, the "lifetime" property makes sense as metadata for sends, but is
completely irrelevant to the receiver. The same is true of several other
message properties. It might make sense for an implementation to use a
single type to represent metadata both for sends and receives, but is that
also true for an abstract API?


> 8. Receiving Data
>
>  * A connection can be used to receive data if it is not configured as
> unidirectional transmit.
>
> MW: that's obviously correct - but I can't find a statement that would
> contradict what you say here.
>

"Once a Connection is established, it can be used for receiving data." Not
true if it's a unidirectional connection.

I'll take a look at the subsequent replies and respond at the end of the
thread to anything that I didn't cover here.