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

Reply via email to