Robert Wilton has entered the following ballot position for draft-ietf-taps-arch-18: 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-arch/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, Thanks to Dhruv from the OPSDIR review. I found this document to be easy to read and understand and I think that is great to be defining a new clean transport API for use by applications. I hope that it is successful and gets traction. A couple of non-blocking minor comments follow. Minor level comments: (1) p 16, sec 4. Transport Services Architecture and Concepts The System Policy provides input from an operating system or other global preferences that can constrain or influence how an implementation will gather Candidate Paths and Protocol Stacks and race the candidates when establishing a Connection. As the details of System Policy configuration and enforcement are largely platform- and implementation- dependent, and do not affect application-level interoperability, the Transport Services API [I-D.ietf-taps-interface] does not specify an interface for reading or writing System Policy. Potentially specifying the System Policy as a YANG Model might be helpful. Even if different platforms are likely to expose this in different ways, having common standard definitions for the configurable fields would likely help interopability - even if only by defining common names and types for particular properties. (2) p 23, sec 4.1.6. Event Handling * Message Received: Delivers received Message content to the application, based on a Receive action. This can include an error if the Receive action cannot be satisfied due to the Connection being closed. Perhaps this is already answered by the other documents, but is it always the case that every message requires a separate event/notification to the application? E.g., I can imagine that under some high performance/throughput scenarios where there are large number of messages being received that the application may only want a single notification that there are one or more messages waiting to be processed, upon which it pulls some/all of them off a receive queue, and only receives another "message received/waiting" event if a message is received when the queue is empty, or the queue is not empty after a subset of the messages have been dequeued. Regards, Rob _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps