Robert Wilton has entered the following ballot position for draft-ietf-taps-interface-22: Yes
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-taps-interface/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, Moderate level comments: (1) As per the architecture doc, I think that it is great that you are defining a new transport API. I note that this API doesn't really include any standard APIs or structures to monitor the state of the transport sessions for a given application (i.e., API user). E.g., how many connections are currently open, total number of connections (since library was initialized), number of errored transport connections, drops, mtu issues, flow rates, etc. I think that with some of the changes to the Internet architecture (e.g., QUIC to cite one obvious example), it reduces the ability for network operators to monitor and debug network issues between applications. A potential corollary of this is that a lot more debug and diagnostics information will need to be made available to applications in a common way to allow application support staff, and users of those applications to better understand where in the network issues and failures are happening. It would seem unreasonable for me to hold a discuss on this document for what might be a lot of work and discussion that could take a long time to resolve but I hope that the authors and WG will consider whether there is further useful future work required in additional RFCs. Minor level comments: (2) p 6, sec 1.1. Terminology and Notation * Array: Denoted []Type, an instance takes a value for each of zero or more elements in a sequence of the given Type. An array may be of fixed or variable length. * Collection: An unordered grouping of one or more values of the same type. Perhaps calling it a Set may be better than Collection (if duplicates are not allowed) or a Bag (if duplicates are allowed). (3) p 17, sec 6.1. Specifying Endpoints Note that an IPv6 address specified with a scope (e.g. 2001:db8:4920:e29d:a420:7461:7073:0a%en0) is equivalent to WithIPAddress with an unscoped address and WithInterface together. Would it not just be cleaner to not allow interface scoped IP addresses, and force the clients to use WithInterface, in the case they want to target a specific interface? (4) p 26, sec 6.2. Specifying Transport Properties Upon reading, the Preference type of a Selection Property changes into Boolean, where true means that the selected Protocol Stack supports the feature or uses the path associated with the Selection Property, and false means that the Protocol Stack does not support the feature or use the path. I misunderstood this on first reading - maybe explicitly state that the types for non Preference types are unchanged on a get, maybe give an example of the return type for section 6.2.11. (5) p 64, sec 9.2. Sending Data The optional endOfMessage parameter supports partial sending and is described in Section 9.2.3. If this is an asynchronous API, I presume that the caller must prevent any changes to, or freeing of, the messageData object until it has received a event to indicate that the send has successfully completed. Perhaps this is too detailed for this abstract level API and is left to the implementation. (6) p 70, sec 9.3.2. Receive Events Each call to Receive will be paired with a single Receive event, which can be a success or an error. This allows an application to provide backpressure to the transport stack when it is temporarily not ready to receive Messages. The backpressure aspect wasn't entirely clear to me. So, if an application can handle receiving multiple receive events at the same time, it can make multiple calls to receive without waiting for, or processing, any receive events? Is that how the application controls the backpressure? (7) p 70, sec 9.3.2. Receive Events Each call to Receive will be paired with a single Receive event, which can be a success or an error. This allows an application to provide backpressure to the transport stack when it is temporarily not ready to receive Messages. How does the transport stack know that the application has finished with the memory holding the message in the receive event, or is the expectation that the receive message contents is logically always allocated on the heap and it is responsibility of the receiver to free the memory once it is done with it? Regards, Rob _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
