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

[Michael Welzl <[e-mail]>]

Dear Kyle,

Thanks so much for all your comments - and sorry for taking so long to get back to you!

I decided to begin attacking them now with a PR. Please see:
https://github.com/ietf-tapswg/api-drafts/pull/514
for the comments that I tried to address, my answers to them, and the changes that I propose to our draft.

For the record, if this PR can be merged, this still leaves us with the unresolved comments below. I inserted some answers below, prefixed with "MW:”. I think that some of them can be addressed relatively easily by others, whereas some should probably best be filed as an issue for further discussion… let’s take this step by step. Easy ones first, to make the list a bit more digestable  :-)

Cheers,
Michael

-------

REMAINING UNADDRESSED COMMENTS FROM KYLE ROSE:


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.


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.

 * 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?


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.

 * 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.


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)


5.2.10. Interface Instance or Type

 * These type symbols really deserve an actual registry, or at least the start of one. Otherwise, we are likely to end up with a mess.

5.2.11. Provisioning Domain Instance or Type

 * What about ordering of similar interfaces? I have a 2-SIM cellphone with wifi.

5.3.2. Connection Establishment Callbacks

 * What constitutes trust verification prior to the handshake?

7.3.1. Sent

 * It seems like an abstract API would be helpful for the reference to the Message to which a Sent event applies: this seems like something many, many applications would need to do. With callbacks, the application can always curry in a reference to the original message (that's what my event system from ~2001 did), so maybe that should be the recommendation and the message reference removed...? I don't have a strong feeling here other than that if something is included then its use should be more well-defined.

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?


7.4.7. Reliable Data Transfer (Message)

 * The default isn't "true", it's whatever the underlying connection had, right?


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.


8.2. Receive Events

 * "A call to Receive will be paired with a single Receive Event" or possibly multiple ReceivedPartial Events?

 * Also, can the draft be consistent about Receive vs. Received, et al.?


11. General comments

 * There's a lot of UNIXisms here that should probably be excised in favor of a more abstract presentation. The most obvious is the use of -1 to mean something other than the integer -1. In Python, for instance, you might want to use None for this purpose. I would specify non-numeric values symbolically, and maybe indicate in the appendix that a UNIX C implementation might want to use -1 to represent such values.

MW: agreed... TODO.


11.1.10. Capacity Profile

 * Very little of this section is about capacity. Traffic Profile?

 * "High Throughput Data" might be better phrased as "Capacity-Seeking".