Hi, A few comments in line:
> On Mar 4, 2020, at 5:51 PM, Philipp S. Tiesel <[email protected]> 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 <[email protected]> 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 >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/taps >> <https://www.ietf.org/mailman/listinfo/taps> Cheers, Michael
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
