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

Hi,

A few comments in line:

> On Mar 4, 2020, at 5:51 PM, Philipp S. Tiesel <philipp@tiesel.net> wrote:
> 
> Hi,
> 
> Some of the remaining issues had already been discussed, but either did not lead to text or the text was lost. Let me comment on these issues:
> 
>>> On 4. Mar 2020, at 15:38, Michael Welzl <michawe@ifi.uio.no> wrote:
>> 
>> 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.
> 
> The solution for this issue was to allow implementations to change the property names in consistent ways, e.g., by replacing the dashes with underscores or removing them and use CamelCasing.
> The text was removed as over-specific.

I remember that. However, the proposal here would be to just replace the property names instead of adding new text.
Let me propose: can we just update them all to CamelCasing?

>> * 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?
> 
> The IANA registry question was explicitly postponed, be maybe we should re-iterate it now.
> The idea of having an „x“ namespace was rejected in fear we end up with quasi-standard properties that have an x prefix then. 
>> 
>> 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.
> 
> We had a lengthy discussion about this and rejected it as too complex and limiting for the implementation.

Right. Maybe we should just remove this item from this list.

>> * 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.
> 
> We had text saying that these should turn into Boolean when queried and should reflect whether the protocol stack chosen provides the feature. I will have to double-check whether this text is still in the description of the preference type.
> 
>> 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.
> 
> There is already one, but that one was not useful for our matters. 
>> 
>> 5.2.11. Provisioning Domain Instance or Type
>> 
>> * What about ordering of similar interfaces? I have a 2-SIM cellphone with wifi.
> 
> Each cellular provider will have a unique PVD. 
>> 
>> 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?
> 
> Ack

I agree too, but doesn’t this warrant some more discussion?
I think our defaults all translate into things that can work in some way when TCP is used - with “Reliable Data Transfer” being an exception, as it just can’t work in a UDP-only system. Are there others?  I think I’ll open an issue for this one.

>> 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".
>> 
>> _______________________________________________
>> Taps mailing list
>> Taps@ietf.org <mailto:Taps@ietf.org>
>> https://www.ietf.org/mailman/listinfo/taps <https://www.ietf.org/mailman/listinfo/taps>

Cheers,
Michael