See in-line
On 05/03/2020 07:30, Michael Welzl wrote:
Hi,
A few comments in line:
On Mar 4, 2020, at 5:51 PM, Philipp S. Tiesel <phil...@tiesel.net
<mailto:phil...@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 <mich...@ifi.uio.no
<mailto:mich...@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?
I like this idea.
* 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.
I don't agree at all - To me this was just the default behaviour of the API.
I think the default needs to be "reliable" and an app will have to
over-ride that to get datagram/unreliable operation. That doesn't mean
if you have only UDP (for instance) that you can't offer TAPS, to me it
simply means you always need to say that the app wants this service.
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".
I don't much like Traffic Profile - to a traffic profile specifies the
characteristics of the traffic the sender is transmitting, not the
treatment that traffic expects from the network service.
I also object to /bandwidth efficiency/ - since sounds like it should be
measured in b/Hz which isn't at all what we are talking about. In fact,
I did not see anything in the text about the efficiency or the use of
bandwith ... as I read, it is all about capacity sharing tradeoffs.
_______________________________________________
Taps mailing list
Taps@ietf.org <mailto:Taps@ietf.org>
https://www.ietf.org/mailman/listinfo/taps
Cheers,
Michael
Best wishes,
Gorry
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps